Car service database design (domain model)?
I think you are trying to be a bit too "elegant".  Einstein is quoted as saying "things should be made as simple as possible, but no simpler."  

You are trying to have a single record for something like an oil change - but then you need two other tables that give you the flexibility to apply the approriate price for this service in different situations.  

Instead, I would suggest that you flatten out your three tables and just have a SKU table which includes a default price.  You would have different SKU records for each kind of oil change, for example. 

The service technician (i.e. user) needs to apply the proper SKU to each service they provide.  This way, you are relying on the user to pick the right service/price rather than trying to build a table-driven set of business rules that must be used so that you can "deduce" the proper pricing.  I would say, based on my experience, that users would much rather have a short list of SKUs to scan through and to pick from rather than having some kind of interactive expert system that asks them multiple questions about different criteria until the right answer finally pops out the bottom.

If you want to allow some drilling down (or some rolling up) for SKUs, you can create a grouping table that groups similar SKUs.  If you really feel it necessary, you could even make this grouping hierarchical.

Your model might look something like this:



This will be easier to build and maintain, and much easier to explain to your users.  I believe too, as I said before, that your users will find this to be easier to use at the service counter too.