data warehouse - Is my accumulating snapshot design correct for my DW and my need -


i discovered accumulating snapshot design dw.

i need record bug info come bug tracker. bugs have info (a bug number, sentence ...). has status: created, canceled, affected, resolved

a bug don't have go through status (it can go created cancel, or created affected resolved ...)

here central fact table

ft_bug_track


idbug int

bugsentence varhchar(100)

createddate date

resolveddate date

affecteddate date

canceleddate date

fkstatus int

the status foreign key link dimension tells me in status i'm in (created, canceled ...)

(of course have others dimensions project, client, typeofbug ...)

everytime bug changing of status, i'll put new date needed , update fkstatus one

is design dw , system?

i have no idea if it's design situation, depends on requirements are, i.e. need able show in reports. if don't understand how data used , users expect find out it, should first before making big design decisions.

having said that, accumulating snapshots work best if goes through (relatively) well-defined, stable series of steps, manufacturing process or loan approval. unfortunately, case bug trackers: tickets can re-assigned different person without changing status; can re-opened , go through whole resolution process again; can 'bounce' , forth between 'in development' , 'in testing' , on. means can't know in advance how many dates , statuses required on lifetime of 1 ticket (unless have unusually simple process).

i worked on helpdesk reporting , came solution using 2 fact tables. first has 1 row per ticket , shows current status (new, assigned, closed, whatever), timestamps 'created' , 'last modified' only. second fact table has 1 row per ticket modification, can drill down detailed history of ticket. it's worth noting here many common changes ticket don't change status (e.g. adding comment) need decide 'modification' in case: change, or status change?

the etl process calculates , maintains ticket-level kpis on first fact table such how long ticket has been (or was) open, how long between submitting ticket , first being assigned etc. report users (e.g. managers) interested in durations between 2 specific events, , handling repeating or cyclical processes isn't particularly easy. reason try generate reports using main (aggregate) fact table, , leave second 1 interactive analysis, depends on want out off data.

even if doesn't answer question, hope gives ideas.


Comments

Popular posts from this blog

monitor web browser programmatically in Android? -

Shrink a YouTube video to responsive width -

wpf - PdfWriter.GetInstance throws System.NullReferenceException -