Inventory Database Design Issue
I agree with TomTom on the merits of the Datamodel resource book - it will give you more insight than StackOverflow, and if memory serves, there's a fairly detailed discussion of exactly this scenario. 

The design you've come up with is similar to what I've seen for other systems - what you call ProductVariation is often called "variant".

I'm a little confused about the role of SKU in your design - the acronym stands for "Stock Keeping Unit". As it's supposed to be unique and never change, I'd make that the primary key of your ProductVariation table, rather than ID. 

If you're only ever going to sell your current product range, or are happy to refactor in future, you can leave it as is; alternatively, you could consider a design with "table per subclass". This would give you a schema along the lines of:


Product (id, name, categoryID, description)

SizeVariant (SKU, productID, finish, width, thickness, Size, location, quantity)
ColourVariant (SKU, productID, Colour, finish, location, quantity)
NoVariant (SKU, productID, location, quantity)



Note how I've also put some of the attributes you've currently assigned to "Product" into the child tables. 

This keeps the schema more "self describing", but adds a lot of work - only do that if you think the product catalogue will grow in the future, and you want to avoid EAV.