Results 1 to 9 of 9
  1. #1
    Join Date
    May 2005
    Posts
    12

    Should I Combine these Dimensions?

    I'm learning dimensional modeling and I i ran into a problem.
    I've built the models and attached the pictures.

    I decided to keep the tables from my previous question separate. So i deleted the question since no one answered. HEre is my new question regarding Exhibit Parts and Inspection fact table.

    Now I'm wondering where I should put price in Exhibit Part or the Fact table? Based on the information that's found at this link, it seems that I should put it in the Fact table because it is to calculate the cost of the part. These prices could also change. They are not stable. So I'm thinking the fact table is best. http://www.kimballgroup.com/data-war...tribute-fact/*

    The next questions are much harder for me at least.

    I'm also wondering about duplicate rows. Supposed there are 16 parts of the same type. I would have to show that i inspected each one of them individually giving them each a row. OR I could make the grain one PART TYPE and add a QTY column to state the number parts inspected, replaced or broken.

    So there could be one row with 10 parts inspected, another row with 4 parts identified as broken, and another row for 2 parts that were replaced. That would save me 16 records. (At least right now i don't think the individual parts themselves are important. Parts wear out and need to be replaced. So why provide a record for each and every part?)

    Also i notice, price is not addictive except on replaced parts. I'm not sure how i will handle that especially if i put it in the Fact table.

    I was wondering how i could record how much it cost to maintain the exhibit.

    This is a problem I have no clue what I should do--assuming the rest of my design is ok and I'm not fooling myself. :-)

    I'm open to ideas and suggestions.
    Attached Thumbnails Attached Thumbnails Combine ExhibitPart.PNG   Combine ExhibitSeat.PNG  
    Last edited by maurices5000; 09-19-13 at 02:10.

  2. #2
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    First, you should be aware that most experienced DBAs don't think too highly of Kimball's dimensional modeling. So if you're dead set on implementing it then you might want to look for a forum dedicated to that.

    That said, is Price an attribute of the Exhibit, or of the Ride? Put it wherever it belongs.

    You question about duplicate part rows can't be answered unless we know more about your business model. We have no idea what this application is. I'm guessing Amusement Park rides?
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  3. #3
    Join Date
    May 2005
    Posts
    12
    Sorry, i thought i said it was an amusement park.

  4. #4
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Then the ticket prices is an attribute of the exhibit, unless different people pay different prices for the same ride.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  5. #5
    Join Date
    Nov 2004
    Location
    out on a limb
    Posts
    13,692
    could you explain your thinking on the 'date dimenison' entity.
    I'd rather be riding on the Tiger 800 or the Norton

  6. #6
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by healdem View Post
    could you explain your thinking on the 'date dimenison' entity.
    That's classic Kimball data mart design....
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

  7. #7
    Join Date
    May 2005
    Posts
    12
    Yes, Healdem, it is a classic data mart for data warehousing. You'd have to study the whole concept to understand the madness. It is a De-normalized structure designed to optimize data retrieval. Its purpose is different from that of a normalized data base which is developed for day-to-day operations.

  8. #8
    Join Date
    May 2005
    Posts
    12
    Thanks Blindman, i guess I'm not going to get much help from this forum as you said. That is sad that this is a DB forum and not too many people understand this.

  9. #9
    Join Date
    Jun 2003
    Location
    Ohio
    Posts
    12,592
    Quote Originally Posted by maurices5000 View Post
    Yes, Healdem, it is a classic data mart for data warehousing. You'd have to study the whole concept to understand the madness.
    Not quite. It is for data marts, not data warehouses.

    Quote Originally Posted by maurices5000 View Post
    It is a De-normalized structure designed to optimize data retrieval. Its purpose is different from that of a normalized data base which is developed for day-to-day operations.
    Normalized data schemas are also appropriate for data warehouses. The denormalized schema is really only appropriate for data marts.

    A data mart is not a data warehouse, despite what Kimball claims.
    If it's not practically useful, then it's practically useless.

    blindman
    www.chess.com: "sqlblindman"
    www.LobsterShot.blogspot.com

Posting Permissions

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