"Junk" dimension looking more like a "Header" dimension

I'm breaking up a process I'm modeling (a "Bid" in this case) into various dimensions. I will be modeling the bid as a factless-fact simply identifying the existence of a bid.

After breaking up all aspects into their own dimensions, I'm left with upwards of 10+ fields which have no reasonable home (that I can see) other than a new junk dimension as their context is ONLY used within a bid:

- bid_title
- bid_type
- bid_status
- bid_description
- project_number
- client_number
- service_type
- location
- job_number
- client_job_number
- contractor
- sub_contractor

That being said, because there are so many fields, most of which are very unique to the very bid they represent, there are no two rows which would be the same, thus making the junk dimension look more like a Bid Header table. I have 1 entry in the junk table for each entry in the fact table.

This type of things makes me wondering if a bid itself should be modeled as a dimension vs. a fact.

Any suggestions on how to work this scenario would be appreciated!

I don't have an answer for your question but I just wanted to say that when you decide on an approach for this, can you share it here so readers can benefit from it, months and years down the road
I have a similar question posted on here where I am not sure if it makes sense to store these extra fields as degenerated dimension or as junk dimension.

Hi Raza,

I decided to make these fields into their own Bid dimension. I decided to go this direction, because:

1. There were MANY fields (as shown above) which had only one context: a bid. They are not used anywhere else, so we could say these fields are highly correlated.
   
2. Not only did these fields only have one, highly correlated context, they were all unique from bid to bid which also dissuaded me from wanting to put them in a junk dimension because my affinity would be 1-to-1 which is not really a junk dimension (as I understand it).
   

In the end, technically speaking, the result was the same: all these fields made their way to a singular new table. The only difference is what I'm calling that table semantically. Instead of calling it a "Junk" dimension, I'm calling it a "Bid" dimension.

If I'm off on this, hopefully someone will pipe up set me straight.

Hi,

Thanks for posting your approach. This process makes sense to me because personally I rather not burden my fact table with extra column (degenerate dimension) if there are as many as they are in your case (or in my case). It adds to the size of the table/indexes. However in both of our cases, because there is a 1-1 relationship between the dim and fact, the dim will grow proportionally to almost the same size as the fact which itself is not ideal. So I hope someone can provide some insight on what should be a good approach in these types of situations.

I just had another situation which came up exactly like this and wanted to come back to the forum to see if anyone had chimed in with a better solution.

Any insight would be appreciated.

Bid stuff should go into the bid dimension. Your analysis on the cardinality confirmed this approach. The remaining columns look like a good fit for a junk dimension. I would confirm the uniqueness of each attribute as well as the combination of the attributes before finalizing on how many junk dimensions you might need.

Thanks B&L, second and third opinions help solidify my perspective.