Results 1 to 11 of 11
  1. #1
    Join Date
    Oct 2003
    Posts
    163

    Question Unanswered: Please guide - especially about Time Dimension and approach in general

    Hi,

    I have a table which contains all the transaction details for which I am trying to create a CUBE... The explanation below in brackets is only for clarity about each field. Kindly note that I am using the following table as my fact table. Let's call it tblFact

    This table contains fields like transaction date, Product (which is sold), Product Family (to which the Product Belongs), Brand (of the product), Qty sold, Unit Price (at which each unit was sold), and some other fields.

    I have created a Product dimension based on tblFact. I don't know if this is a good idea or not Is it okay and am I on the right track or should I base my Product Dimension on some other table (say tblProducts and then in the Cube editor link tblProducts with tblFact based on the ProductID field? Please guide.

    Now coming to my last question:
    Currently I am also creating my Time Dimension based on tblFact. Is this also a wrong approach?
    1. Should I instead create the Time Dimension based on a different table (say tblTime) and again link up tblTime and tblFact in the Cube editor?

    2. if yes, then how do I create tblTime from tblFact in a manner that it only contains all the transaction dates.

    3. Assuming that I should take the tblTime approach, then should this table (tblTime) also contain the ProductID - representing the Product which was sold for each date in tblTime?

    I realize that this is a lenghty post but reply and more importantly guidance from the experienced users will be greatly appreciated becuase I have recently started learning/playing around on the OLAP side of things and I know that this is the time that I get my foundations correct otherwise I'll end up getting used to some bad practice and will find it difficult to change my approach to cube designing later down the road.

    So many thanks in advance and I eagerly look forward to reply from someone.

  2. #2
    Join Date
    Nov 2003
    Location
    Edinburgh
    Posts
    149
    No worries mate,

    This is what the forum is for...

    Ok - Down to what you need to do

    When doing the design for a cube I always do a bit of anyalsis first. Looks like you have crack this bit. You know what your dimensions are - Time , product , brand etc This is what you should group on to build your fact table.

    Your facts are going to be Qty Sold , Price. This is what you will be suming on with the SQL to build your fact table.

    You said "should I base my Product Dimension on some other table (say tblProducts and then in the Cube editor link tblProducts with tblFact based on the ProductID field? Please guide."

    This is exactly what a good cube design is based on mate.

    I presume the basis of your fact table is a transactions type table.
    First thing you need to do is build all your dimension tables.

    A table for product dimension table should look something like :

    create table tblProduct
    (prod_id tinyint ,
    prod_txt varchar (255)
    )

    Don't forget to put in a id for unknown product - just in case you get these in your base transaction table

    Build the rest of your dimension tables like this and assign a tinyint composite key to each dimension. What you what is your fact table to be as small as possible in terms of datatypes.

    Now once you have this you want to build your fact table.

    What you do is take your fact table and join to each of you dimension tables (should be a left outer join) and sum on the qty and unit price and group up accross all your dimensions.

    This now should be you fact table that you can reference in Anyalsis Manager. You will have to define all this with in here as well.

    Whoo, that was an effort.

    Any problems , questions give me a shout

    Cheers

  3. #3
    Join Date
    Oct 2003
    Posts
    163
    Hi aldo_2003,

    Many thanks for the reply. It answers a good number of my questions. Can you kindly advise regarding the remaining question i.e. the quoted portions below:

    Build the rest of your dimension tables like this and assign a tinyint composite key to each dimension. What you what is your fact table to be as small as possible in terms of datatypes.

    Question: By composite key do you mean define a Primary key in each table? I will do so but was planning to define the data type for my ProductID field (for example) in my tblProducts as int. However I'll follow your advise and instead use the datatype tinyint. Thanks for the tip

    And my last question hopefully:
    Now coming to my last question:
    Currently I am also creating my Time Dimension based on tblFact. Is this also a wrong approach?
    1. Should I instead create the Time Dimension based on a different table (say tblTime) and again link up tblTime and tblFact in the Cube editor?

    2. if yes, then how do I create tblTime from tblFact in a manner that it only contains all the transaction dates.

    3. Assuming that I should take the tblTime approach, then should this table (tblTime) also contain the ProductID - representing the Product which was sold for each date in tblTime?


    I think Part 2 (above) is easy and all I have to do is make a copy of tblFact but this copy (say tblTime) will only contain the transaction date column (from tblFact). Kindly confirm my understanding.

    However it's the answer to part 1 (above) and especially the part 3 above that is requested.


    Looking forward to your reply.

  4. #4
    Join Date
    Nov 2003
    Location
    Edinburgh
    Posts
    149

    Talking

    Your welcome,

    forgot about the time question

    what you want to do is create a tblTime dimension table

    should basically have the grandularity that you want to use

    you can find scripts on the net that will help you create and manage a time dimension table.

    table should look like

    create table tblTime
    (date_time smalldatetime,
    quarter tinyint,
    month tinyint,
    week tinyint ,
    day int
    )


    populate this table with all the dates in your date range i.e

    Jan 1999 12:00am to Jan 2009 12:00am

    This is now your time dimension table.
    Using anyalsis manager join back on to the fact table.
    Anyalsis manager should guide you through the process of creating a time dimension.

    Hope this helps

    p.s the only reason I used a tinyint is that I assumed you would have no more than 255 products, if you have more then up the datatype to what you need

    Cheers

  5. #5
    Join Date
    Oct 2003
    Posts
    163
    Hi again,

    Don't mean to "over-flatter" but your replies REALLY have been of great help... Here I was trying to build everything (the fact as well as the dimensions) using only a single table and now I am quite clear regarding what's the right approach

    3 last questions please

    you can find scripts on the net that will help you create and manage a time dimension table.
    table should look like

    create table tblTime
    (date_time smalldatetime,
    quarter tinyint,
    month tinyint,
    week tinyint ,
    day int
    )



    That's another new tip Can u kindly guide where I can get these scripts from? I am assuming that these scripts will not only create the table (in a similar structure as you have suggested above) but will also populate the table with the all the desired date ranges e.g. Jan 1999 12:00am to Jan 2009 12:00am.

    2nd last question: So my approach which I was assuming for creating tblTime (for the Time dimension was incorrect) i.e. I thought that this will simply contain the ALL the transaction dates from the transaction table (as I described in my previous post). But from your reply my understanding is that this approach is wrong.

    and the last question: So the tblTime does not have to store the ProductID?

    Sorry for all the botheration.

  6. #6
    Join Date
    Nov 2003
    Location
    Edinburgh
    Posts
    149
    No worries buddy

    Glad to be of help

    The time dimension table is stand alone and does not have to contain any other info other than time info.

    I'll see if my collegue know and get back to you

    Cheers

  7. #7
    Join Date
    Nov 2003
    Location
    Edinburgh
    Posts
    149

  8. #8
    Join Date
    Oct 2003
    Posts
    163
    Originally posted by aldo_2003
    The time dimension table is stand alone and does not have to contain any other info other than time info.

    I'll see if my collegue know and get back to you

    Cheers
    Thanks aldo : for the reply, the link to articles, and also for the clarification about the time dimension's underlying table containing only time related information.

    Kindly do let me know if you get a script which not only creates the table for time but also populates it ....

    Bless you!

  9. #9
    Join Date
    Aug 2002
    Location
    Scotland
    Posts
    1,578
    --Satya SKJ
    Microsoft SQL Server MVP
    [IMG]http://sqlserver-qa.net/google_bart.gif[/IMG]

  10. #10
    Join Date
    Oct 2003
    Posts
    163
    Originally posted by Satya
    Check this link http://www.winnetmag.com/Articles/Ar...31/pg/4/4.html for any help.
    Hi Satya,

    Many sincere thanks for the article. I went through it...

    However at this stage I am learning the basics (as evident from this post and my questions to aldo) therefore I found he article to be real "HEVY STUFF" and very difficult to digest at the moment. I talks about the MDX world and that's something that I have yet to explore... I know I will have to get into MDX soon but have enough of the basic to get right first

    I however would like to request if you can help me with another post from me in this forum (Subject" Need help to create my Time Dimension")... it's somewhat related to portion of the discussion in this post but I did not want to unnecessarily prolong this particular thread/post...

    Looking forward to your help in my other post.


    Thanks again and regards.

  11. #11
    Join Date
    Feb 2004
    Location
    San Antonio, TX
    Posts
    565
    Joozh
    Since this has been answered so well i just wanted to chime in and suggest some reading for you

    The Data Warehouse Toolkit by Ralph Kimball

    this is the second edition of this book revised in 2002 and it is a must have for every OLAP develper.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •