Home/ Questions/Q 8514975
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-11T05:00:54+00:00

Simple scenario: I’d like to create data warehouse which information about issues (cost, wroking

  • 0

Simple scenario: I’d like to create data warehouse which information about “issues” (cost, wroking time etc.). issue also has status which might change over time. So then i’m creating fact table called issueRealization decribing each issue.

My question is: should i create “issue” dimension which will give me one to one relationship beetwen dimension and fact table? Or i should divide Issue dimension to smallest dimension like status etc?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Issue status tracking is a good case to use an Accumulating Snapshot fact table, to track the changes in the status of an issue over time.

    As an example, let’s say this is an IT issue/bug/enhancement management system, with issues that only have 3 statuses, ‘Created’ and ‘In Progress’ and ‘Resolved’.

    The issue fact table would look like such:

    ID Number (Degenerate Dimension)
Issue description (Degenerate dimension. You can also create a 1-1 table for these if it's not often used in reporting)
Type ID (bug/enhancement/etc, this is a dimension key)
Assigned Developer ID (Dimension key)
Current Status ID (Status dimension key)
Date Created (DATE dimension)
Created Flag (1 = created, 0 = otherwise)
Date In Progress (DATE dimension)
In Progress Flag (1 = created, 0 = otherwise)
Date Resolved (DATE dimension)
Resolved Flag (1 = created, 0 = otherwise)
Created Datetime (measure)
InProgress Datetime (measure)
Resolved Datetime (measure)
Worktime Interval (measure)
Cost (measure)

    The grain of this table is 1 row per issue ID number.

    With this type of fact table, you update the same row each time the source system modifies an issue. Note how we create a field for each status type, as well as a datetime record to allow us to compute metrics such as “time between created and resolved status”. In addition, I added an interval field to allow you to store “actual” work time, such as “hours” the developer put towards the fix. This could easily be an integer.

    This table would then be able to answer any questions about an issue, and provide rollups to show “how many issues took longer than 1 week to resolve”, etc.

    • 0