Modelling Fashion

I'm dealing with a customer in the fashion industry, and we are modelling a sales schema. We're discussing how best to model Product.

Their view of a Product is that it is a dimension comprising a compound key which represents a combination of style/fabric/color/size, and some additional data such as description, price, etc.

My view is that we're actually talking about a number of dimensions here. Style, Fabric, Color and Size could all be represented as separate dimensions, with Style being closest in concept to the original Product.

How have others resolved similar issues?

Size - seems to be an obvious candidate for putting in a separate dimension as this would allow you to have columns for UK, EUR and US sizes - assuming that's a requirement.
Colour - I assume there are no other attributes of "colour" apart from the name? In that case I would keep it in your Product Dim. You could have it as a degenerate dim on fact tables but that would probably only boost query performance if users queried for "everything that's red", for example; more likely they will query for "red dresses" so having it on the Product Dim makes more sense to me
Fabric - if there are other descriptive attributes for fabric other than its name then that's probably a candidate for its own dimension otherwise I'd keep it in the Product Dim. Probably a similar decision to "colour" - if you'd query for everything made of denim then have it as a DD but if you'd query for "denim dresses" keep it in the Product Dim

One of the additional data items you mention is price (and I assume this means cost price rather than the price it is being sold at which should definitely be in a fact). I would put this in its own Product fact table; if you keep it as a dimension attribute then you immediately constrain that dimension to include every attribute that effects the price e.g. if size affected the price then you'd have to have size in your Product dim. Though if the price doesn't change regardless of fabric/colour/size this may not be an issue for you.

Hope this helps?

If an item goes on sale then its price cuts down. Price is a candidate of a Fact table. BTW you also need a Sale promotion dim.

I tend to go with how the business identifies the items. If each unique iteration of the item has it's own SKU, then I would treat the characteristics of the item as attributes.  You didn't mention, but I assume this is a manufacturer, so it is more than likely they all have separate SKUs.

Breaking out separate dimensions may be an query optimization, but probably not worth the bother unless you are dealing with a very large number of unique items.

Thank you for the useful input, everyone.

This is an interesting case. It is a highly specialised, collection-based fashion house.

Products have a life span of 6 months (a season). Because it is collection-based, the Product dimension only ever has 'n' active products, but grows at 'n' products per season. The inventory counts per product are tiny in comparison to typical retail scenarios, and the fact transactions are also low in volume. There are no "sales", at the end of the season anything not sold is scrapped.

One of our partners is building this warehouse, and I'm learning a lot through our discussions about some of the design challenges