Forum Discussion
Data Modeling Best Practice: One column in a table?
Hello - I'm designing a data model for a field service project. Although I use Power BI extensively and have been exposed to databases and models, it's my first go at designing one. What can I say - resources are tight, and I'm up for the challenge. My question is a simple one. Is it ok or good data modeling design to have a table with one column?
I have two tables: exceptions and na_reasons (na stands for not available). The exceptions table tracks dates/times a technician will not be available to receive jobs. As part of the exceptions record, the na_reason must be indicated. The na_reasons table has all the valid na_reasons.
See the example below. Thanks.
As an example:
absolutely ok to set up such a "dimension" table. Additional columns may suggest themselves in due time for aspects associated with reasons. They may be grouped for instance using the ad hoc grouping feature, or ordered using an Order ID column. You may want to report quantities on all reasons, and so you need your master list of reasons. Also if you have another employee table that makes sense not to consolidate with the main, you'll have a one-to-many relationship to both tables and key your filters to na_reasons
2 Replies
Hi ConnieMaldonado
I depends a bit on the rest of the model. But if in this model the excemptions tables is a fact table (which it looks like in this example) then it is a good solution if you need all reasons.
If you need to know for example the count of exceptions by na_reason and you want to display all the reasons that have no excemption this is the way I would go.
If this post helps, please consider accepting it as the solution to help the other members find it more quickly.
Appreciate your Kudos!!
Best regards,
JeroenJeroen
absolutely ok to set up such a "dimension" table. Additional columns may suggest themselves in due time for aspects associated with reasons. They may be grouped for instance using the ad hoc grouping feature, or ordered using an Order ID column. You may want to report quantities on all reasons, and so you need your master list of reasons. Also if you have another employee table that makes sense not to consolidate with the main, you'll have a one-to-many relationship to both tables and key your filters to na_reasons
