It's a tricky issue, isn't it?, knowing just when to stop normalizing. As I said, it depends on the requirements, they needed to work with thousands of items, which turned out to be a bad idea, they are now reducing they're catalog to what they can really sell, but the model adapts very well to both cases.

To tell you the truth, I would love to be able to reduce it to something like

5170WHS Cotton t-shirt

That would be a small white cotton T-Shirt, plain and simple, but there's a number of issues with that, among them, some items have complicated color combinations, and it would be up to whoever registers the item to come up with a short version of it, not a good idea, they came up with some codes the likes of WHITESHIRT, DENIMPANTS , REALLYCOOLSHIRTONSALE, heck that's not a code that's a description, so I believe you have to set some limits and somehow guide them to keep a clean catalog, and I believe having them pick a predefined class, color and size, helps acomplish that.

>This is precisely why I chose a 'flat' table approach for my solution. Less >tables, easier RI, smaller footprint, ease of queries, etc. With storage >space so cheap today, I don't care if "BLUE" pants repeats 200 times in the >data. I didn't want to spend days training the client how to query his data >with Excel. 30 minutes and he had the basics down. Having to drill down >through 5 or more tables didn't look very appealing to me. Or adding a new >item and updating all the underlying tables is more work