Time dimension different granularity

Hi, i have two facts tables. The first is the sales table and i receive the data each day. So the join with the time dimension is at the day level. The second is the costs level and here the data regard stuff like salaries, so clearly is a monthly input. In this second case with OWB i don't manage to join the fact table with the month id of the time dimension. I can't also create another time dimension starting at the month level.
What can i do?
thanks. Emilio

Emilio,
I guess what you can do on the short term is create a separate time dimension with month as the lowest level. We are working on a completely new dimensional design implementation that would enable you to implement your requirement. This will be available in the next major release (but that may take a while...).
Thanks,
Mark.

Similar Messages

Date and Time dimensions

After reading the following article, I have decided to use SSAS dimension wizard for generating our Date dimension, which creates a DATETIME PK.
http://www.made2mentor.com/2011/05/date-vs-integer-datatypes-as-primary-key-for-date-dimensions/
I have also created a separate Time dimension as granularity of an hour is required.
The Time dimension is very simple and only contains a surrogate key (INTEGER) and actual time in hours (VARCHAR).
DimTime(TimeKey, TimeInHours)
Our Fact table will now have a link to both the Date and Time dimension using the PK's.
Our analysis is required by hour, day, week, month and year.
My query is; Will this current structure cause any problems when creating MDX scripts to analyse our data (i.e. drilldown and rollup queries) Hour - Day - Week - Month - Year

Hi Darren,
According to your description, there a day and hour granularity in your fact table, so you want to a hierarchy like Hour - Day - Week - Month - Year, right?
In your scenario, you created a time table that only contains a surrogate key (INTEGER) and actual time in hours (VARCHAR). We cannot create a Hour - Day - Week - Month - Year hierarchy without ant relationship between date table and time table. As per my understanding,
you need create a foreigner key in time table, and join those table in the data source view, then you can create such a hierarchy. Here are some links about create time dimension, please see:
http://www.ssas-info.com/analysis-services-articles/59-time-dimension/1224-date-and-time-dimensions-template
http://www.codeproject.com/Articles/25852/Creating-Time-Dimension-in-Microsoft-Analysis-Serv
Regards,
Charlie Liao
TechNet Community Support

Time dimension population

Hi
I am taking "clndr" as source and populate time dimension table.Time dimension table ( granularity is an hourly basis) will be populated with date with 24 intervals and based on the cln_dt whether it falls in weekened or holiday ,If falls in weekened or holiday , populate 'Y' Else 'N' .Please see the below example
clndr(source table)
cln_dt cldr_day busday cldr_yr
1/05/2006 monday y 2005
2/5/2006 Tuesday y 2005
Expected data
==========
Time_dim(Target table)
Time_dt interval holidy ind
1/05/2006 0 N
1/05/2006 1 N
1/05/2006 2 N
1/05/2006 3 N
1/05/2006 23 N
2/5/2006 0 N
2/5/2006 1 N
2/5/2006 23 N
Thanksinadvance
MR

Try this, Modified Dnikiforov's solution:
SQL> ed
Wrote file afiedt.buf
1 select date#, hour, decode(busday,'Fri','Y','Sat','Y','Sun','Y','N') flag
2 from ( select to_date('06-MAY-06') date#, to_char(to_date(
3 '06-MAY-06'),'Dy') busday from dual
4 union all
5 select to_date('07-MAY-06') date#, to_char(to_date(
6 '07-MAY-06'),'Dy') from dual
7 union all
8 select to_date('08-MAY-06') date#, to_char(to_date(
9 '08-MAY-06'),'Dy') from dual ) calendar,
10 (select rownum-1 hour from dict where rownum <=24) hours
11* order by 1,2
SQL> /
DATE#        HOUR F
06-MAY-06       0 Y
06-MAY-06       1 Y
06-MAY-06       2 Y
06-MAY-06       3 Y
06-MAY-06       4 Y
06-MAY-06       5 Y
06-MAY-06       6 Y
06-MAY-06       7 Y
06-MAY-06       8 Y
06-MAY-06       9 Y
06-MAY-06      10 Y
06-MAY-06      11 Y
06-MAY-06      12 Y
06-MAY-06      13 Y
06-MAY-06      14 Y
06-MAY-06      15 Y
06-MAY-06      16 Y
06-MAY-06      17 Y
06-MAY-06      18 Y
06-MAY-06      19 Y
06-MAY-06      20 Y
06-MAY-06      21 Y
06-MAY-06      22 Y
06-MAY-06      23 Y
07-MAY-06       0 Y
07-MAY-06       1 Y
07-MAY-06       2 Y
07-MAY-06       3 Y
07-MAY-06       4 Y
07-MAY-06       5 Y
07-MAY-06       6 Y
07-MAY-06       7 Y
07-MAY-06       8 Y
07-MAY-06       9 Y
07-MAY-06      10 Y
07-MAY-06      11 Y
07-MAY-06      12 Y
07-MAY-06      13 Y
07-MAY-06      14 Y
07-MAY-06      15 Y
07-MAY-06      16 Y
07-MAY-06      17 Y
07-MAY-06      18 Y
07-MAY-06      19 Y
07-MAY-06      20 Y
07-MAY-06      21 Y
07-MAY-06      22 Y
07-MAY-06      23 Y
08-MAY-06       0 N
08-MAY-06       1 N
08-MAY-06       2 N
08-MAY-06       3 N
08-MAY-06       4 N
08-MAY-06       5 N
08-MAY-06       6 N
08-MAY-06       7 N
08-MAY-06       8 N
08-MAY-06       9 N
08-MAY-06      10 N
08-MAY-06      11 N
08-MAY-06      12 N
08-MAY-06      13 N
08-MAY-06      14 N
08-MAY-06      15 N
08-MAY-06      16 N
08-MAY-06      17 N
08-MAY-06      18 N
08-MAY-06      19 N
08-MAY-06      20 N
08-MAY-06      21 N
08-MAY-06      22 N
08-MAY-06      23 N
72 rows selected.

Time dimension and chronological key

HI ALL
I WORK ON OBIEE 11G REPORTS
WHAT IS THE EXACT USE OF TIME CHECK BOX AND CHRONOLOGICAL KEY??
AND HOW CAN I USE IT
ANY HELP ??

Hi,
What is the chronological key use?
A. Typically time dimension differs from all other dimensions in one way and that is,
all other dimensions dont care about the order of the values in it.
e.g. in region_dim the values are north, south, west and east. Here nobody wants to see whether north comes first or south comes first. i.e. no order is required here.
in the case of time dimension there needs to be a particular order for all the values present in it.
e.g. 2010 is earliest and 2004 is older. Dec-10 is earliest and jan-10 is older. i.e. the values in the time dimensiion needs to follow a particular sorting order. So the chronological key is the key which tells the obiee that the data is incrementing based on the chronological column.
Here you may get another doubt. i.e. you are having columns like year, half_year, quarter, month, week and day. Here which one should become the chronolgocial key?
Analyse it yourself. If you kept year as chro key then obiee will be confused whether jan-10 is earliest or feb-10 is earliest. Because it knows only that 2010 is earliest and 2009 is older.
So always it should be the lowest level oif the dimension which needs to be the chronological key. In the abouve case it should be date.
You can select either date or date_id(this could be a sequence generator values).
2. what is the use time dimension?
A.If all you want is to achieve drills from Month, Quarter and Year then treat it as a normal dimension and create the levels. But if you want to do calculations like YTD, QTD and MTD then you need to create a time dimension.
http://oraclebizint.wordpress.com/2007/11/05/oracle-bi-ee-101332-understanding-todate-and-ago-achieving-ytd-qtd-and-mtd/
Refer the above link for time dimension.
Award points it is useful.
Thanks
satya
Edited by: Satya Ranki Reddy on May 2, 2012 12:29 AM

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

Setup time dimension in some different fiscal calendars

I have the different fiscal calendars.
Then, I wanna compare the current month fiscal amount and the previous month fiscal amount with AGO function.
The calendars are like below.
Calendar A : fiscal month start April
Calendar B : fiscal month start January
In this case, how should I define the chronological key in the time dimension?
For example, I try the below setup in the calendar period hierarchy.
Year 2008
Half 1H 2H
Quarter 1Q 2Q 3Q 4Q
Month 1Q = {Apr-08 in CAL_A, May-08 in CAL_A, Jul-08 in CAL_A, Jan-08 in CAL_B, Feb-08 in CAL_B, Mar-08 in CAL_B}
and some.
In this examle, the number of MONTH level members are 24.
Then I make a column for sort.
The sort number is below.
For CAL_A
Month SortNo.
Apr-08 1
May-08 2
Jun-08 3
Jul-08 4
Aug-08 5
Sep-08 6
Oct-08 7
Nor-08 8
Dec-08 9
Jan-09 10
Feb-09 11
Mar-09 12
For CAL_B
Month SortNo.
Jan-09 13
Feb-09 14
Mar-09 15
Apr-08 16
May-08 17
Jun-08 18
Jul-08 19
Aug-08 20
Sep-08 21
Oct-08 22
Nor-08 23
Dec-08 24
In this case, if I try to get the previous month of Jan-09 in CAL_B with AGO function, the system get Mar-09 for CAL_A. Because the record of Mar-09 for CAL_A is 12 in SortNo. column.
As far as possible, I wanna use AGO function.
Does anyone have good ider for this problem?
Edited by: user3532462 on 2008/08/28 2:57

Hi,
I guess it's easier to setup two different time dimensions; one for calendar A and one for calendar B. Use aliases in the Physical Layer.
Good Luck,
Daan Bakboord

Time Dimension Type allows different values in attributes - Bug or Feature?

Not sure if this is a bug or a feature.
But if one has multiple hierarchies on a Time dimension. You have the ability to specify different values for member attributes in different hierarchies.
Example.
Hierarchy A has MIN_ID for it's Member and uses MIN_END_DATE for it's END_DATE
Hierarchy B has MIN_ID for it's Member and uses SESS_END_DATE for it's END_DATE
As per this post and David Greenfield's comment:
Dimension Sort issue when multiple mappings for different hierarchies
"Are you attempting to map the same attribute, SORT, to different columns in the two hierarchies? Put another way, do you expect the same member to have different values for the attribute in the two different hierarchies? If so, then this is a problem since a member must have the same value for the attribute regardless of the hierarchy."
Unlike a user dimension, a time dimension appears to allow this and it appears to work as intended. Is the behavior in this case intended to be different between a user and time dimension?

I think that this is not a bug. There is an incompatibility in design which prevents you from using the same attribute differently for both hierarchies.
NOTE: Unlike parent relationship which depends on <dimension, dimension hierarchy>, Dimension Attribute is dependent on <dimension> alone, not dependent on <dimension, dimension hierarchy> combination. Hence it can only take on 1 value for 1 dimension member.
I think that the time dimension only appears to allow this. The key thing to check is for Time Dimension members which are common to both the hierarchies. Only one of the mappings will take effect (usually the hierarchy which is loaded last will remain in the aw/usable for queries, reports.. it would have over-written the earlier attribute value loaded as per the earlier hierarchy load).
Visualize a dimension as a long list of members which are built up contiguously on a per hierarchy, per level process using the mapping information saved. Once a member is defined (created) via Hierarchy A, it wont be created once again while loading Hierarchy B but is instead updated or redefined based on Hierarchy B's mapping info.
Assuming the dimension load attempts to load Hierarchy A first and then Hierarchy B,
* Dimension load for Hierarchy A will define the various members using MIN_ID and set the END_DATE attribute to value=MIN_END_DATE
* Dimension load for Hierarchy B will re-define the various members using MIN_ID and re-set or over-write the END_DATE attribute to value=SESS_END_DATE
* In this case, it looks like all members are common for both hierarchies (as both members are mapped to same column MIN_ID) and you would end up with END_DATE=SESS_END_DATE.
Actually whether all members are common to both hierarchies or not depends on the quality of data in your snowflake/star table: if parent level for Hierarchy A as well as Hierarchy B is setup fine then the members will be same set (overlapping in whole). If some rows for MIN_ID have parent column for Hierarchy A setup correctly but parent column for Hierarchy B =null or invalid value then that member will exist in Hierarchy A alone and would contain END_DATE=MIN_END_DATE as the corresponding update along Hierarchy B would fail due to hierarchy data quality issues (join from current level to parent level).
As regards a solution to your problem, you should not use the same attribute "SORT" for dual purpose (both hierarchies). Instead define attributes SORT_A and SORT_B and make them enabled for Hierarchy A, Hierarchy B respectively and map/use them appropriately in your reports.
HTH
Shankar

Aggregation mode along one dimension (product) different than along the time dimension

Dear All,
In IBP S&OP, Is it possible that the aggregation mode along one dimension (product) could be different than along the time dimension?
For a demo, a customer has an input at the product family level (vehicle production) which we just “copy” for disaggregation purposes, to the product level (parts), see attached. So for aggregation we used average.
However, time-wise, we need to sum it up.
Thanks for your insight and help.
Kind Regards,
Omar

Hi Omar,
Yes it is possible.
1. Create a new planning level (say PERPRODCUST1) which will be a copy of PERPRODCUST (you base planning level).
2. In the PER section of PERPRODCUST1, do NOT mark any period attribute as root. In other words, the roots for this PL will only be PRDID and CUSTID.
3. Now your KF calculations will be:
VEHICLEPRODUCTION@PERPRODCUST1 = SUM(VEHICLEPRODUCTION@PERPRODCUST)
VEHICLEPRODUCTION@REQUEST = AVG(VEHICLEPRODUCTION@PERPRODCUST1)
Since your KF is editable, it is worth mentioning that, following the above steps has trade-offs. Since your KF is editable, you will have issues with disaggregation when you enter the values at an aggregated level of both time and other attributes. My recommendation (for your configuration) is that this will work fine as long you enter the values at the root level of you time attribute.
Hope this helps,
Chendur

Time dimension generated differently in 11gR2

Hi,
on generating a new default time dimension, I noticed some strange behaviour compared to the former release which seems to be incorrect.
1. No DIMENSION_KEY column as PK
2. the %_START_DATE columns are defined as business key instead of the %_NUMBER ord %_CODE columns
3. DAY_START_DATE is defined as PK column
I can modify this manually but what is the intention behind?
Is it meant that we should use a date column as FK reference in the cubes instead of the surrogate key.
Very odd !!
regards
Thomas

Hi,
thanks to Google I found Dave Allens excellent paper on [degenerate dimensions|http://blogs.oracle.com/warehousebuilder/2010/05/owb_11gr2_degenerate_dimensions.html].
Now it's a lot clearer to me.
Supposing you will read this, Dave, some more remarks:
1. The date column in the cube is a blessing not only with partitioning. Until now, I used to update the surrogate key of the time dimension to a number of format YYYYMMDD in order to ease my life.
2. But the time dimension table is still used not a mere stub as with DD?
3. I don't understand the context with SCD2. There, I need the DIMENSION_KEY.
4. I have the situation with a fact table containing one row per phone call. The unique phone call ID would be a candidate for a DD. But what would be the advantage to define the stub DD instead of just entering the string ?
Please give some more hints for a better understanding.
regards
Thomas

Fact tables with different granularity

We currently have 3 dimensions (Site, Well, Date) and 2 fact tables (GasEngine, GasField), both having granularity of a day.
GasEngine is linked to Site and Date
GasField is linked to Site, Well and Date
We now have a requirement to make the GasEngine fact table have granularity of an hour but keep
GasField at a day.
We therefore must include a new Time dimension, which would only be linked to GasEngine.
Is it ok to have a DW with these two fact tables having different granularity?
And would we therefore require two separate cubes for querying this data?

Hi Rajendra and Visakh16,
Based on your input provided to this thread, I would like to ask a question just to fine-tune my knowledge regarding data modelling. In Darren’s case I guess his date dimension only store dimension records up to day level granularity. Now the requirement
is to make the “GasEngine” fact table to hold data granularity of an hour.
Now based on Rajendra’s input
“Yes, you can have. but why you need new time dimension, I recommend, make GasEngine fact to
hour granularity.”
How Darren could display data for each hour without having a time dimension attached to GasEngine fact table? With the existing date dimension he ONLY can display the aggregated data with the minimum granularity of day level.
Now anyone can modify the date dimension to hold time records which will complicate the date dimension totally. Instead why Darren cannot have a separate time dimension which hold ONLY time related data and have a timekey in GasEngine fact table and relate
those tables using the time key? This way isn’t Darren’s data model become more readable and simplified? As we provide another way of slicing and dicing data by using a time dimension I do not think Darren’s cube becomes a complex STAR schema.
I could be totally wrong therefore for the sake of knowledge for Darren and me I am asking the question from both of you.
Best regards…
Chandima Lakmal Fonseka

OLAP time dimension - how are the weeks allocated

Could someone please help me understand what logic Oracle uses when one makes use of Oracles OLAP time dimension based on weeks.
I am use Oracle OLAP 11.2
I have a Time dimension that has the following hierarchy:-
YEAR
QUARTER
MONTH
WEEK
For calculating the weeks ID I make use ISO week and year i.e. IYYYIW
For calculating the end date I use the following:- NEXT_DAY( l_date, 'MON' ) -1
i.e. the weeks end date is the Sunday.
According to me this is the required result.
Problem is that for some months there are 3 weeks allocated which makes no sense to me.
I cannot understand the logic used in allocating the weeks.
The following is an example:-
the following weeks were allocated to the month February
201306 (end date= 10-2-2013)
201307 (end date= 17-2-2013)
201308 (end date= 24-2-2013)
but the following week was allocated to January which makes no sence to me,
I would have expected it to be found in February
201305 (end date= 3-2-2013)
Week 201309 (end date= 3-3-2013) was allocated to March which according to me is correct..
Another example is week *201030 (end date= 1-8-2010)* that is allocated to July while I would have expected that it should be August.
I would have thought that it uses the end date that is placed in the mapping to determine the month to place it in.
Could some one please explain what the reason for this could be.

Oracle OLAP model/design (in this case, at least) cannot compensate to coverup existing flaws in the relational model/design.
I dont think this is a valid hierarchy even considering relational model/design.
Weeks do not fit in below Months (calendar months).
You can force fit them by making Weeks the source of truth and making all Months logical Months like "Business Month", "Business Quarter", "Business Year" etc. which will be composed of whole weeks but differ significantly from the calendar definition of Month, Quarter, Year etc.
You are better off modeling time as composed of two hierarchies:
H1: DAY -> MONTH -> QUARTER -> YEAR and
H2: DAY -> WEEK
Alternately if you dont want to introduce DAY level (lower granularity), you can split up the Time dimension into 2 different dimensions. And also modify your star schema to add an additional time dimension key to fact table - one key pointing to WEEK and another pointing to MONTH (independently).
TIME_MO: MONTH -> QUARTER -> YEAR
TIME_WK: WEEK
The fact data will need to be split up to correctly identify the coirrect MONTH-WEEK combination for the relational record.
E.g:
Fact table should have 2 dimension Fks for WK_KEY as well as MO_KEY so that a fact figure of 1000 evaluated over 7 days is split up into 300 from 29-31st of previous month and attached to MO_KEY of previous month and another record of 700 covering days from 1-4 and recorded/tied to same WK_KEY but next month (next month's MO_KEY).
HTH
Shankar

Fiscal Year Time Dimension - Month Time Span

I have a need to create a fiscal year time dimension and I created using Time Wizard in OWB. When I was developing BI Reports, I found some inconsistencies in Time dimension as it was showing figures in all the months of my first quarter of new financial year that Apr 2009 – Mar 2010. On close inspection of Time Dimension table I found that fiscal_month_time_span value varies from 35 to 28 to 29 for different months. i.e. it’s not matching with corresponding Calendar month. This means I am unable to plot data correctly using fiscal year dimension.
Maybe this is how it works in Oracle, but this does not solve my problem. Could anyone give me some solution for this ? My Fiscal year is from ‘1- Apr – 09’ to ’31-Mar-10’. In my reports I would like to see transactions for April month when I use month attribute of time dimension like it happens in Calendar time dimension.

May be someone from
Forum: Business Intelligence Suite Enterprise Edition can answer this .
Please post it there.

Multiple Fiscal Calendars Displayed in Subject Area Time Dimension

Hi all,
Thanks for taking the time to review my post.
Environment
Oracle BI Applications 7.9.6 Financial Analytics
Oracle E-Business Suite 11.5.10
Query
The Time dimension on my Subject Areas (Financial Analytics) are showing more period data than I expected.
I have configured one Enterprise Calendar (WPG_Calendar) that I set in the DAC parameters - $$GBL_CALENDAR_ID (WPG_Calendar~Month) and $$GBL_DATASOURCE_NUM_ID (4). The warehouse Enterprise Calendar table W_ENT_PERIOD_D is populating with the periods as configured in EBS for that calendar(Jan-09, Feb-0, Mar-09, etc). I noticed that the Multiple Fiscal W_MCAL_PERIOD_D table is also been populated with the Enterprise Calendar data PLUS, the Seeded EBS calendar (JEBE_MONTH_VAT) and a generated Calendar that appears to be a 5-4-5-4 Calendar (Jan-01-09, Jan-02-09, Jan-03-09, etc). The trouble is these W_MCAL_PERIOD_D periods and dates are all coming through in my Time dimensions and make it confusing for the Answers Users when choosing a Time dimension.
Also, for columns W_CURRENT_MCAL_PERIOD_CODE, W_CURRENT_MCAL_QTR_CODE, W_CURRENT_MCAL_YEAR_CODE there are rows with Current, Previous and Next populated that span these different periods as you would expect, but I'm concerned these return multiple rows for Filters Current Fiscal Quater, Current Fiscal Year.
Funnily enough, W_CURRENT_MCAL_MONTH_CODE has nothing populated (NULLs for all rows).
Your comments are most welcome.
Kind Regards,
Gary.

The filtering of the calendar can be done directly on the logical layer.
for the logical dimension "Dim - Date Fiscal Calendar", Logical Table Source "Dim_W_MCAL_PERIOD_D_Fiscal_Period"
set the content as :
"Oracle Data Warehouse".Catalog.dbo.Dim_W_MCAL_PERIOD_D_Fiscal_Period.MCAL_CAL_WID = VALUEOF("MY_MCAL_WID")
and setup the repository variable MY_MCAL_WID to match with your calendar wid.
If your calendar depends on any context then you can use session variable instead of repository variable

How to handle Fact tables with different granularity in OBIEE 11g RPD

Hello Everyone,
I have got stuck here and need your help.
I have two fact tables (Say F1 and F2... F1 is containing data at month-level and F2 is containing data at day level) and one Date DIMENSION TABLE. Date_Code is the PK of Date dimension table.I need to use time-series functions also.
Can anyone tell me how to model this requirement in the RPD.
Can we use a single dimension table(Here Date dimension table) with two fact table of different grainularity? What would be the best way to implement this requirement?
Thanks in advance :)

Hi Veeravalli,
Thanks for your reply :)
Let me explain the problem in more detail. I have one Date dimension(Date_Code,Month_Code,Quarter_Code,Half_Year_Code,Year_Code). Here Date_Code is the PK.
In F1---->Date (Using Month_Code key)
F2-------->Date (Using Date_Code Key)
Level based hierarchy is there starting from Year to Date.Each level has PK defined and chronological key selected.
F1 has level set to Month and F2 has level set to Day.
Now if i am using ago() function on measure of F2 (having day level data) then it's working fine but if i am using ago() function on measure of F1...I am getting an error at Presentation service: Date_code must be projected for time-series functions.
So the whole issue is with time-series functions. As per my research...I think for time series the tables in the physical model containing the time dimension cannot join to other data sources, except at the most detailed level but here i am joining with F1(using Month_Code which is not the most detailed level).
So kindly let me know how to achieve this in rpd?

Problem with time dimension aggregation

I have a time dimension with 2 columns:Year and week
I've created a hierarchy in it to drill down from the year to the week.
when I report the sales in week level I have the right values but when I report the sales value in year level I don't have the right aggregation.Even if the year Level is a grand Total in the hierarchy.
The problem is that for all the years I have the same value but when I add the week level to the report Then I have the right values.
What could be the problem

Hi,
1.Actually the drill down Route path is not properly generated with your given key columns in herarchies.
need to give correct key columns
like year(YYYY)-->Week(wee should be the unique column for each and evry year)
suppose:
2000-sunday
2001-sunday should be different
so mostly the problem at your week column make the unique yearweek column as the key identifier at that level
Every Week is unique cause the logical key is a combination of the year and the weeknumber
2.if not you need to set individual levels for measures in content tab...
you mean by the content tab the level tab when you doubleclick into the measure???
Thanks

Time dimension different granularity

Similar Messages

Maybe you are looking for