Okay, understood. Does user have to make the price selection or do you want to automate associating price with quantity? This can be done with your original structure but what is the likelihood of someday needing more than 6 price options? Adding another would mean redesigning table, query, form, report, code. However, I expect this has low probability of occurrence. If the options were arranged vertically then a query joining tables could probably work to associate individual price, and adding a new option would be easy. In either case complication arises if the quantity breaks and/or prices are ever modified and existing records should retain the old values. This can be managed in either structure by saving price to record, which can be automated with code. Another approach is to save price break record ID. Flag obsolete records as 'archived' and exclude from consideration for new records by filter criteria. Create new records for the new pricing.
IMHO, it is a balancing act between normalization and ease of data entry/output. More reading material
http://www.agiledata.org/essays/dataNormalization.html