InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comWed, 19 Jun 2013 14:03:55 GMT20http://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxNo need to have a separate fact table to store all those dates.The ticket process is actually a perfect candidate for an [url=http://www.kimballgroup.com/2002/06/13/design-tip-37-modeling-a-pipeline-with-an-accumulating-snapshot/]accumulating fact table[/url].If you are interested in a current status snapshot of tickets, then a standard accumulating snapshot is ideal. You add in some extra fields for each of those dates on the fact table (date dimension FK's), and fill them as the information becomes available. If the detailed history of each ticket change is required (as Jeff mentioned, tickets regressing in their status) then a [url=http://www.kimballgroup.com/2012/05/01/design-tip-145-time-stamping-accumulating-snapshot-fact-tables/]Time stamping accumulated snapshot [/url]might be more appropriate, but this is overkill IMO.Mon, 18 Mar 2013 21:51:44 GMTdavoscollectivehttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspx[quote][b]alan.hollis 1097 (1/14/2013)[/b][hr]Hi all,I've been brought on board to help a company start to build their first business intelligence setup. I'm a developer by trade, and have good knowledge of SQL and application design using relative tables but this is my first step into designing a data warehouse.I have two questions initially from the customer, and if I can do a good job of providing a report setup for this we'll expand from there. The questions I'm tasked to answer are:How many support tickets are being opened each day?How many support tickets have been closed each day?How many does each employee have?How many does each group of employees have?I've designed my first start schema to handle the answering of these questions which is as follows.I would love any feedback/critique of this design.Thanks Alanp.s As a side note I'm planning on using SISS to perform the ELT tasks rather than programming my own software to do the job? Does this seem like a sensible opinion? For the first part of the data entry I'll be pulling information out of Dynamics CRM and Request Tracker.[/quote]As the others have mentioned, you'll need a "Group" dimension to identify how many tickets a group has.As for your first two questions, you'll need to identify the status as a date. That's the only way you'll be able to firgure out those two. You might even want to create a separate fact table to store the different statuses and dates of those statuses that any give ticket goes through. Don't forget that the status of a ticket may regress.Mon, 18 Mar 2013 21:12:03 GMTJeff Modenhttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxI would add the group id that the employee is in to the dim user table as well. This will allow group counts.Mon, 18 Mar 2013 10:40:58 GMTmmartin1http://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspx[quote]I wonder if a snow flake schema might be better for you to model the ticket dimension[/quote]While anything is possible, the uses for a snow flake schema are uncommon. It should never be used simply to normalize in the manner as a transactional database. I recommend you start with a star schema.Wed, 16 Jan 2013 09:43:25 GMTRonKylehttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxI've modified the schema slightly to incorporate your suggestions. What I'm struggling with now is how using this schema I'd deal with tickets that are currently in an open state per day ( keeping in mind that an open ticket might not necessarily have any information associated with a particular day ) without doing some horrible looking SQL.Wed, 16 Jan 2013 01:57:27 GMTalan.hollis 1097http://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxI wonder if a snow flake schema might be better for you to model the ticket dimension but without actually seeing the schema of your source data I can only guess.You can create a main ticket dimension table which will have all the attributes shared by all you ticket types. Then for each distinct type of ticket (this replaces the queue dimension in your original design) you place it's attributes in a new table and link it back to the ticket dimension table.Tue, 15 Jan 2013 14:37:41 GMTAbu Dinahttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxGood point. I wasn't sure whether it was best to have many different dimension tables for the different queue attributes or a single one. On reflection I think you're right and I should include a single attributes table for the ticket.Thanks again,AlanMon, 14 Jan 2013 07:37:36 GMTalan.hollis 1097http://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxShouldn't there be a Ticket dimension table with attributes that describe the type of ticket?Not entirely sure the Queue dimension table is appropriate to be honest.Mon, 14 Jan 2013 07:32:02 GMTAbu Dinahttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxThe tickets are entered into queues ie ( Hosting, Hardware, Software ) and these descriptions are I think subject to changes.Thanks for the reply and the good luck ;)Mon, 14 Jan 2013 07:09:35 GMTalan.hollis 1097http://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxWhat's the purpose of the Queue dimension table?SSIS is great for performing ETL, so yes, if you have the knowledge and you're comfortable developing packages then go ahead and use it. It also comes with components specifically designed for data warehousing such as the Slowly Changing Dimension component.Good luck!Mon, 14 Jan 2013 07:02:27 GMTAbu Dinahttp://www.sqlservercentral.com/Forums/Topic1406667-373-1.aspxHi all,I've been brought on board to help a company start to build their first business intelligence setup. I'm a developer by trade, and have good knowledge of SQL and application design using relative tables but this is my first step into designing a data warehouse.I have two questions initially from the customer, and if I can do a good job of providing a report setup for this we'll expand from there. The questions I'm tasked to answer are:How many support tickets are being opened each day?How many support tickets have been closed each day?How many does each employee have?How many does each group of employees have?I've designed my first start schema to handle the answering of these questions which is as follows.[img]http://alanhollis.com/wp-content/uploads/2013/01/datawarehouse-2.png[/img]I would love any feedback/critique of this design.Thanks Alanp.s As a side note I'm planning on using SISS to perform the ELT tasks rather than programming my own software to do the job? Does this seem like a sensible opinion? For the first part of the data entry I'll be pulling information out of Dynamics CRM and Request Tracker.Mon, 14 Jan 2013 05:17:25 GMTalan.hollis 1097