Does one of the normal forms require separation of repeating clusters of values into another table?
There is no normal form which would have you move those columns to a separate table. Normalization is a process in the logical design of tables that discusses functional dependency between a table's columns. If there is no un-resolved functional dependency there is no more normalization to perform.
Further, a logical table represents a class of objects, events or ideas from our business domain. There is a real-life thing that the table holds data for. What is that thing that your proposed &quot;Sales Types&quot; table would hold? Likely your business users would shrug at this question.
That said, during the physical implementation (distinct from the logical design before) you may choose to move columns between tables for reasons other than functional dependency. This can be confusing because the end results look the same - columns moved to new tables. The difference is why we move these columns. This will be important later when change happens. We need to know why we did someting so we will know why we may choose to undo it. We undo normalization if the business rules change. We undo physical implementation if the desired performance profile changes.
In the context of physical implementation your proposed table looks like a dictionary encoding scheme. There is nothing wrong with doing this. If your application benefits overall from this extra development work then go fot it.
Many DBMS offer compression natively. Column-oriented storage is particulary effective at this if your product offers this choice. By using native features you gain the performance benefits you seek without taking on the development and maintenance cost. I'd recommend you stress-test any native feature to see if it can deliver your desired performance.