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

Similar Messages

  • Difference between Time dimension and product(regular) dimenstion

    Hi All,
    I would like to know what is the difference between time dimenstiona and regular dimenstion. How can we differentiate and how Oracle bi server knows a dimension
    as Time dimenstion.
    Thanks,

    Hi,
    By using Logical Dimensional Structure and chronological keys it identify time or other types of dim.
    Just double clik time dimension then you can find the
    root type (Time, Ragged and skipped) and for the chronological keys > just double click logical level then select keys tab -- here u can find chronological keys
    Thanks
    Deva

  • Time Dimensions and Logical dimension "..that not join to any fact source"

    Hi Guys,
    I get the following error on the ANSWERS front end:
    Error Codes: OPR4ONWY:U9IM8TAC:OI2DL65P
    State: HY000. Code: 10058. [NQODBC] [SQL_STATE: HY000] [nQSError: 10058] A general error has occurred. [nQSError: 14026] Unable to navigate requested expression: ToDate(SPECIFICG:[DAggr(RFACT.SPECIFIC [ ] by [ EFact.NO [ ] , Year.ID [ ] ] )], [Level Years]). Please fix the metadata consistency warnings. (HY000)
    SQL Issued: SELECT EFact.NO saw_0, Fact.YTD_E saw_1, EFact.MTD_E saw_2 FROM "E#1" ORDER BY saw_0
    The consistency manager shows no errors and the tables are physically joined up via foreign key i.e.
    fact year monthday
    data - date - date
    year month
    day
    [see screen print|www.metallon.org/test/foreign.jpg]
    I would be thankfull for any suggestions!

    Hello wildmight.
    I followed this tutorial:
    http://www.rittmanmead.com/2007/04/30/obi-ee-time-dimensions-and-time-series-calculations/
    Why should this layout not work?
    Do you have a better idea?
    When you say "it has to be one table" do you mean
    that quartermonthday and year need to be ONE?
    I just rememered that Oracle Hyperion Planning has to have
    time and months seperated.
    Hello mod100.
    What do you mean hierachy over the time dimension?
    Is it not obvious from the screen print that I have a hierachy
    i.e. yeartotal - years and
    quarters - months- days.
    I read that by default the LEVELS are set to the lowerst. so thats fine. I set them by myself to the lowest as well but the ERROR is still the same.
    no, I have not set the levels as in
    http://obiee-tips.blogspot.com/2009/10/logical-levels.html

  • Time Dimension and database 8.1.7.3

    Hi,
    I imported owb_bp project that is located in: <OWB install directory>\owb\misc\time directory into my OWB. Then i copied the standard time dimension and mapping from that project to my project. I changed the necesary things(removed day level, did reconcile inbound on a dimension in a mapping with "match by bound name" strategy) in the dimension and mapping and when i tried to deploy the mapping i got an error:
    VLD-3268: A mapping can be deployed only if the database version is Oracle 9.2 or higher.
    Is it true that you need Oracle 9.2 or higher for deploying this kind of time dimension. If that is so, how can i create a time dimension that is going to work with Oracle 8.1.7.3
    Thx

    Thanks for your answer Igor.
    The problem is that we cant upgrade our database to 9.2, becouse our customers dont use it, so we are stuck with 8.1.7.3, which by the looks of things doesnt support a lot of things in OWB 9.04.
    So I would really appreciate it if someone could give me some pointers as to how to generate data for time dimension, thats going to work on database 8.1.7.3.
    Thanks you all for your time.

  • Time dimension and 1h periods

    Hi All,
    1. I'm new to OWB and I was wondering is there any chance to force default (made using wizard) time dimension to have 'smaller' level then one day (let's say 1h) ?
    If not, have you tried to manually update the dimension & mapping ?
    Or it is better to leave default dimension and start with my own time dim ?
    2. What's the difference between dimension created as 'time' dimension and dimension with similar content but defined as typicall dim ? (any performance/analysis issues?)
    Thanks in advance.
    Cheers,
    B

    Hi Carsten,
    Thanks for reply.
    Carsten Herbe wrote:
    Have you considered using a date dimension on day level and a second time dimesion containing only the hours 1-24?It seems to be a good idea. I'll try this.
    Using the wizard does make live easier, but there is no performance advantage compared to a normal dimension. Great. Wizard's time dimension contains much more fields then I'd suspect thus I want to avoid situation when I make simple time dim at the begining and after some time I find out that there' s something important missing ;)
    Thanks for help.
    Cheers,
    B.

  • Primary Key and Chronological Key for Time Dimension

    Could someone please shed light whether it's better to use normal PK or Calendar Date (which is a chronological key on the most detailed level). I tried both and haven't noticed any difference. But my understanding is that I still need to have the PK key on the most detailed level in time hierarchy.
    Thanks

    Matt,
    the PK of the Time Dimension is a regular sequence numeric key. I have it defined as a logical PK for the dimension. However, I guess I was talking about hierarchy key. I tested it either way and the query time is the same. So I guess it doesn't really matter.
    --------Year
    Year (chronological key and primary key)
    ------------------Quarter
    Quarter (key)
    Quarter+Year (primary key, chronological key)
    ---------------------------------Day Detail
    PK (key)
    Date (primary key , chronological key)
    I hope it makes sense.

  • Demographics dimension and Logical Key.

    Hello,
    I have a simple star schema where there is a fact table linked to four dimensions. One of the dimensions is Customer Demographics. Others are Product, Time and Dealer.
    Am I correct in using surrogate key of the demographics dimension as Logical Key for Demographics dimension in the BMM layer? Could you please let me know?
    Thanks,
    Manoj.

    If the requirement is to do lots of "demographic" type queries - like sales amounts by race, gender, age, etc. - then snowflaking it off of a "person" dimension would really hurt query performance. Typically you only have demographic dimensions when either:
    1. You don't have a person dimension at all - it's only the demographics you are interested in, or
    2. You have a person dimension with millions of members, and splitting the demographics out into a separate dimension (typically a few thousand rows) means you can do a small join between the fact and a 3 thousand row demographics dimenion instead of doing a join between the fact table and a multi million row dimension table
    In either case, snowflaking off of a person dimension table is either impossible or very bad for performance.
    Thanks,
    Scott

  • Day dimension and surrogate keys

    Hello,
    I'm trying to create a 'day' dimension using OWB. I was thinking about a set of levels like this:
    - 'date_id'
    - 'special_value' (such as unknown)
    - 'calendar_date'
    - 'month_day'
    - 'month'
    - 'year'
    How can I implement something similar with OWB? I have to create one level for each dimension column? And how can I determine the value of date_id in the mapping?
    Thanks in advance for the help
    Cosma

    Hi Cosma,
    There's an example for this in the Oracle-by-Example session for OWB: http://www.oracle.com/technology/obe/obe9ir2/obe-dwh/owb/owb.htm
    Around halfway through you'll find it.
    Good luck, Patrick

  • Composite key in Time dimension

    Hi All,
    I would like to know Time dimension with Composite key. I have a requirement where I want to store 2 Calendars in Time dimension table. for e.g :
    for one calendar Weekstarts from SUN-SAT and for another it is from MON-TUE
    DateKey   Type WeekStart   WeekEnd
    20140101   1       Sun               Sat      
    20140101   2       Mon               Tue
    ..................etc
    I have a measure group which is related to Time dimension (DateKey and Type used a Composite key). This implementation has no issues for additive measures but there are few issues with semi-additive measures (last non-empty,...).
    Will composite Key have any effect on semi-additive measures ?
    what if i use surrogate key instead of composite key.
    Please suggest if the approach has any issue with Time intelligence. Advise if there is any better approach for the same.
    Ram MSBI Developer

    Hey.. Thanks!
    I am clear about the concept about defining annotation based composite key. Also, I read in the documentation that I'll be needing to define as direct, aggregate or one-to-one. But, I am not able to define and run the same in the project mapping xml of toplink.
    It would be great if you can share some sample code for defining the same. For e.g. in my mentioned example, there is TestEntity POJO having 'id' as the attribute which gets populated with the testEntityCode of the TestEntityKey POJO. Please suggest the same for the same:
    <opm:primary-key>
    <opm:attribute-name>id</opm:attribute-name>
    <opm:field table="TEST_ENTITY_B" name="TEST_ENT_CODE" xsi:type="opm:column"/>
    </opm:primary-key>
    Thanks!

  • Primary Key Data type in Time Dimension????

    I have to create a Time dimension with day grain in a Datawarehouse system and I don’t know what is the best data type for the primary key...
    For example
    1) I could put Number(8) datatype, then the dates will be: 20050114, 20050115, 20050116.... Then in the fact tables I put the Number(8) datatype in the date fields... But in my reporting tools I have to put the to_date function to show the dates in the right format.
    2) Or I could put Date datatype, then the dates will be: 01/14/2005, 01/15/2005, 01/16/2005.... Then in the fact tables I put the Date datatype in the date fields...
    It’s the Date primary key a bad datatype? (Very slow)
    What is the best Primary Key Data type in Time Dimension???
    Thanks!

    <quote>I have to create a Time dimension with day grain</quote>
    OK.
    <quote>But in my reporting tools I have to put the to_date function to show the dates in the right format</quote>
    Why? ... if you’ve decided to have a Day dimension table what is stopping you from having the day represented as a DATE column in there? (plus all the other "right formats" you may need). The join keys should only be used for … joining.
    <quote> It’s the Date primary key a bad datatype? (Very slow)</quote>
    No … DATE or NUMBER won’t make any noticeable difference when used as the join key between the time dimension and the fact table.
    Some see advantages in having the DATE FK in the fact table …
    1. One can have range partitioning in the fact using real DATEs
    2. One can get Day-derived info right from the fact table … that is, the join to the Day dimension is not needed
    I don’t (see them as advantages) … for #1, range partitioning by some measure of time is still achievable as long as the PK values on the Day dimension are immutable (as they should) … and I don’t see #2 as an advantage for the DW end-users.
    Personally, I prefer a surrogate numeric PK … but not things like 20050129.
    <William>If you need dates then use dates. They are more robust, you can never accidentally have November 43rd</William>
    Of course this can not be about the fact table … since there the column is constrained … so this is about accidentally getting "November 43rd, 2004" into the Day dimensions when the PK is numeric 20041143; true, but is a DATE PK more robust in this case? … No … one could accidentally insert to_date('29-Jan-2005','DD-Mon-YYYY') and to_date('29-Jan-2005 00:00:01','DD-Mon-YYYY HH24:MI:SS') and that won't be very good, would it? In both cases, one would need something extra to 100% protect the integrity of the Day dimension (mind you, loading the Day dimension probably happens once a year under the supervision of the most technical people on the project).
    There is no best PK data type for the Day dimension (between NUMBER and DATE) … they are both workable solutions ... go with what you’re comfortable.

  • Modifying Existing Time Dimension

    Hi All,
    Presently I have a Time Dimension and a Fact table which has a FK to this Dimension. The Time Dim has a level upto hourly values.
    Now it's in production and I need to change the Time Dim to take on minutes 'cause some reports need minutes.
    1. So what is the best way to go about this?
    2. Is it better just to add another extra field which has the required date, in the fact table?
    3. How can the existing data be easily ported to the new Time Dim(if it has a minute-level)?
    Thanks,
    Justin.

    I am wondering how you implemented the time dimension which only has a level up to hourly values. Do you mean the time dimension only has 24+1 = 25 rows? Usually the time dimension is separate from the date dimension and its lowest level values are minutes or seconds, depending on the business requirements. Therefore the time dimension should have 24X60 + 1 or 24X60X60 +1 rows.
    The solution is depended on what you want.
    My suggestion is as the follows:
    1.     Create a new time dimension with the desired lowest level values (minutes or seconds).
    2.     Create or modify the foreign key of the fact table to point the new created time dimension.
    3.     Modify the ETL mappings.
    4.     Option 1: If you want the new functionality available for the existing rows in the fact, you have to reload the fact no matter which approach you use.
    Option 2: If you only want the new functionality available for the subsequent refresh load, you can modify the foreign-key values pointing to the old time dimension to the new time dimension, using the rule XX --> XX:00 or XX --> XX:00:00 (where XX is the hour number in the old dimension). In the subsequent refresh load, map the foreign-key values to the actual time.
    Maybe other else can provide better solutions. IF so, please let me know.
    Good luck!

  • Problem with drill down in time dimension - OBIEE 11G

    Hello There,
    I have a problem with drill down in time dimension. The hierarchy for time dimension is " Fiscal Year---> Fiscal Quarter---> Month(Name)--->Date". When I select a Time dimension and click results its getting opened in a Pivot table view. The problem here is, when I click the "Total" its getting drilled down to Year ---> Quarter but when I click on "+ sign next to quarter" it should drill down to month for that particular quarter for that particular year but its drilling down to month for that particular quarter for all years.
    Any suggestions are much appreciated.
    Thanks,
    Harry.

    1.) Congrats for resurrecting a year-old thread.
    2.) Your answer is here: "Check the level key of the quarter level...it should include both quarter and year columns. Since a specific quarter occurs every year, quarter column alone can't be used as the level key."

  • TIME_DSO_1 attribute in Time Dimension

    Hi,
    We are using Oracle Analytic Workspace Manager version 10.2.0.3.0A for creating a cube.
    We have defined a dimension as "Time" dimension and have also specified the dimension type as "Time".
    This dimension has the levels: Year, Quarter, Month, Week and Day. These levels are for the one and only hierarchy of the Time dimension.
    The attributes of the dimension (applicable to all the levels) are: END_DATE, LONG_DESCRIPTION, SHORT_DESCRIPTION, and TIME_SPAN.
    In this structure, we are having a strange observation : During the process of defining this TIME dimension, there were some problems with the machine (it got hanged) and so we had to exit (kill) the AWM and come in again. When we logged in to AWM again, we could see a new attribute called TIME_DSO_1 defined within the Time dimension by itself.
    Can anyone let us know what is this attribute all about ? And can we go ahead and just delete this from our dimension structure without creating problems for ourselves?
    Many thanks in advance for the kind inputs of the forum.
    Regards,
    Piyush

    Hi,
    I can't say that I really understand how your data shows up, but I do see an error in your hierarchy.
    What you should do is split it up into two hierarchies.
    Year-> Quarter-> Month-> Day
    and
    Year-> Week-> Day
    And here is the reason:
    A day can easily have a week as a parent and month. But week cannot. Since a month can end on any given day in a week, that means that a week can have two parents. If I take the next week as an example. Mon, tue, wed, thu and fri would belong to the august month, while the rest of the week would belong to september. But the entire week would still be week 35. And its the same issue with quarter. Months can be added into a quarter, but weeks can not.
    Now, I'm not sure if this would solve all your problems, but there might be a few other things you might check out and thats what ID's you populate your member fields with.
    say that you have used the month numbers (or at least the same id for every january and so on)to populate your months. If that is the case things will also behave extremely weird and slow. What you need to do is to create unique IDs for every month (and any other level) so that you are sure that january 2007 don't have any child records that really should belong to january 2006.
    As a general rule, the member field needs to contain a completely unique value across on from all levels. The "generate surrogate key" functionality helps you a bit along the way as it adds the name of your level in front of the value that you load. If the values you load doesn't have unique values within the level it won't help you any.
    Hope this can help you some more... ;)
    regards Ragnar

  • Time Dimension

    I have created a Time dimension using the Dimension Wizard with two hierarchies:
    Year - Quarter - Month - Date
    Year - Week - Date
    We have a data warehouse with two fact tables, FactSite and FactWell.
    Each table contains a different date field and we hope to use the Time dimension as a role playing dimension for each.
    So we wish to filter FactSite and FactWell data by
    Year - Quarter - Month - Week - Date using
    the operational date fields.
    My queries are. Must we now:
    1 - Populate (using wizard) the Time dimension with a suitable date range? (i.e. the start date and expected end date of our data set).
    Then during our ETL process, we do a lookup in the Time dimension and set the surrogate key in the corresponding fact table.
    2 - Populate the Time dimension during the
    ETL process from our OLTP data source? 
    3 - What is the best practice for this type of scenario?

    Hi Darren,
    According to your description, you need a time table to create your time dimension, now you want to know which is better, creating the time table in the project or creating the table in the OLTP data source during ETL process, right?
    Microsoft SQL Server Analysis Services provide a convenient way to create time table, you can use the Dimension Wizard in SQL Server Data Tools (SSDT) to create a time dimension when no time table is available in the source database. As per my understanding,
    it better to generate the time table in data source view using wizard. Please refer to the link below to see the details.
    http://msdn.microsoft.com/en-us/library/ms174832.aspx
    Then you can create a Date hierarchy Year - Quarter - Month - Week - Date using this time table.
    http://msdn.microsoft.com/en-IN/library/hh231692.aspx
    Regards,
    Charlie Liao
    TechNet Community Support

  • OWB 10.2 - How are you handling time dimensions?

    Hi all,
    I am struggling with what should be a simple thing to do. I want to create a time dimension and then have many "roles" or aliases for the time dimensioin WITH UNIQUE COLUMN NAMES across all of the roles.
    When the time dimensions are deployed to Discoverer, I want every one of them to have unique names and the column names within the time dimension have a unique prefix so that report users know which date column is from which table or dimension.
    Here's what I've done and failed at:
    1. Use the time dimension wizard - I can create any number of dimensions and corresponding tables BUT all of them have the same column names and I would have to manually change each and every one of them to get unique names (which may not even be possible with the wizard). Also, because I require ISO weeks, I can't really use the wizard at all.
    2. Manually create a time dimension (that supports ISO weeks) and create multiple "roles" for it:
    Thanks to a bug, I cannot exceed 4 roles without OWB crashing. Even with those 4 roles, when deployed to Discoverer, every attribute within the item folders has the same name. When I drag them to a report, there is no way to tell one from another. Is there some way I could do this without having to manually rename hundreds of columns?
    3. I wrote an elaborate SQLPlus script to copy and prefix dimensions and tables from a base dimension and table. When I then import the Dimension to OWB, the metadata for business identifier and surrogate identifier is not there and any cubes using those dimensions do not work with these attributes missing. I can't find a way to cleanly reverse engineer these into OWB.
    I have a cube with 12 dates - each of which should be a foreign key to a date dimension.
    How can I have all of these be uniquely named with uniquely named columns?
    How can I make it easy for my reporting users to select dates onto their reports?
    I hope I am missing an obvious solution, because so far, I cannot see where Oracle Warehouse Builder supports such a basic data warehousing concept.

    Well, since I'm the only one obsessed with time dimensions I guess, here is my ugly workaround:
    1. I create a base time dimension in OWB which I named 'ATLAS_TIME_DIM'
    2. I run the OMB script below which clones the dimension and table and renames the columns and attributes with a user supplied suffix. The end result is I get a full copy of the time dimension metadata with uniquely named columns.
    You then have to deploy the objects, and with SQLPlus, ensure that the table gets its data copied from your original table. Hope it helps someone until we have better Time dimension support from OWB.
    OMBCONNECT repos/password@SERVERNAME:1521:sidname
    # Prompt for new Dimension name and prefix
    puts -nonewline "Please enter name for new Dimension: "
    gets stdin newDim
    puts -nonewline "Enter Prefix for Dimension table columns: "
    gets stdin dimPrefix
    # Change into ATLAS_DW module in project ATLAS_DW
    OMBCC 'ATLAS_DW'
    OMBCC 'ATLAS_DW'
    # Copy the ATLAS_TIME_DIM to this dimension
    OMBCOPY DIMENSION 'ATLAS_TIME_DIM' TO '$newDim'
    # Set the business name
    OMBALTER DIMENSION '$newDim' \
    SET PROPERTIES (BUSINESS_NAME) VALUES ('$newDim')
    # Unbind the dimension from original table
    OMBALTER DIMENSION '$newDim' \
    DELETE BINDING
    # Bind to new table
    OMBALTER DIMENSION '$newDim' \
    IMPLEMENTED BY SYSTEM STAR
    # Add a prefix to all of the Dimension attributes
    set attrList [OMBRETRIEVE DIMENSION '$newDim' GET DIMENSION_ATTRIBUTES]
    foreach attrName $attrList {
    OMBALTER DIMENSION '$newDim' \
    MODIFY DIMENSION_ATTRIBUTE '$attrName' RENAME TO '$dimPrefix\_$attrName'
    # Add a prefix to all level attributes of the Dimension
    set levelList [OMBRETRIEVE DIMENSION '$newDim' GET LEVELS]
    foreach levelName $levelList {
    set levelAttrList [OMBRETRIEVE DIMENSION '$newDim' \
                            LEVEL '$levelName' GET LEVEL_ATTRIBUTES]
    foreach levelAttr $levelAttrList {
    OMBALTER DIMENSION '$newDim' MODIFY \
    LEVEL_ATTRIBUTE '$levelAttr' OF LEVEL '$levelName' \
    SET PROPERTIES (BUSINESS_NAME) VALUES ('$dimPrefix\_$levelAttr')
    OMBALTER DIMENSION '$newDim' MODIFY \
    LEVEL_ATTRIBUTE '$levelAttr' OF LEVEL '$levelName' \
    RENAME TO '$dimPrefix\_$levelAttr'
    # Add a prefix to all of the table columns except DIMENSION_KEY
    set columnList [OMBRETRIEVE TABLE '$newDim' GET COLUMNS]
    foreach colName $columnList {
    if { $colName == "DIMENSION_KEY" } {
    puts "$colName"
    } else {
    OMBALTER TABLE '$newDim' \
    MODIFY COLUMN '$colName' SET PROPERTIES (BUSINESS_NAME) VALUES ('$dimPrefix\_$colName')
    OMBALTER TABLE '$newDim' \
    MODIFY COLUMN '$colName' RENAME TO '$dimPrefix\_$colName'
    puts "$dimPrefix\_$colName"
    OMBSAVE
    OMBDISCONNECT
    Message was edited by:
    mike_fls

Maybe you are looking for