Defining the granularity for a Fact Table
3 posters
Page 1 of 1
Defining the granularity for a Fact Table
I am modeling a DWH for a private practice. They perform hemodialysis and the goal of the DWH is improve the prognosis and quality of life of the patients. We have a table with the hemodialysis records, and many to many relation with "vital signs" (pulse and blood pressure before, during and after hemodialysis) and zero to many with "complications". The original idea was to analyze the evolution of the patients in hemodialysis and my first approach was to build a hemodialysis fact table. Now, I dont know how to model vital signs (min 0 max 70 average 22 per hemodialysis) and complications.
Thank you for any idea.
Thank you for any idea.
KarinaM- Posts : 1
Join date : 2014-07-28
Re: Defining the granularity for a Fact Table
You're not measuring, or trending in this case hemodialysis, your're trending vital signs. Hemodialysis would be a dimension if there are important attributes other than the date when it occurred. I would put all vital signs in the fact table. Complications could be a bridge table or another fact table altogether.
BoxesAndLines- Posts : 1212
Join date : 2009-02-03
Location : USA
Re: Defining the granularity for a Fact Table
I agree with B&L. There would be additional dimensions identifying what each complication (complication type) or vital sign measurement (measurement type) represents.
The procedure (hemodialysis) could be an actual or implied dimension. If the intent is to only every use it for tracking hemodialysis and nothing else … ever, then you really don't need it as a physical dimension. However, if it is ever to be used for other procedures, then having a procedure dimension is critical. Even if you don't think you need it, put it in. It saves a lot of headache later.
The procedure (hemodialysis) could be an actual or implied dimension. If the intent is to only every use it for tracking hemodialysis and nothing else … ever, then you really don't need it as a physical dimension. However, if it is ever to be used for other procedures, then having a procedure dimension is critical. Even if you don't think you need it, put it in. It saves a lot of headache later.
Similar topics
» Granularity of Fact table
» Granularity - One Fact Table or Two
» 'Routing' the grain of the fact table to multpile members of multiple dimensions causes the fact table to 'explode'
» Integrating new fact table which has one to many relationship with the main fact table in existing star schema
» Fact Table(s) for Invoice Lines with Further Granularity
» Granularity - One Fact Table or Two
» 'Routing' the grain of the fact table to multpile members of multiple dimensions causes the fact table to 'explode'
» Integrating new fact table which has one to many relationship with the main fact table in existing star schema
» Fact Table(s) for Invoice Lines with Further Granularity
Page 1 of 1
Permissions in this forum:
You cannot reply to topics in this forum