Если я правильно понял-таблица Классификация менеджеров в Вашем случае состоит из 3-х полей:id манагера, id классификации товара и id региональной группы менеджера?
Если это так - я с этим бы не согласился в плане универсальности да и вообще нормализации,так как:
1.код региональной группы менеджера должен находиться на все 100 (и скорее всего там находится) в атрибутах самого менеджера и тащить его в связывающую менеджера и товар таблицу нелогично и неправильно.
2. путается сама идея: связь классификатора товара и менеджера-вспылывает какой-то классификатор менеджера - зачем то мешаются два абсолютно разных классификатора.

Если же п.1 нет,то надо заводить еще один классификатор - КЛассификатор менеджеров и делать аналогичную классификацию для менеджеров.

с точки зрения структуры базы все правильно,но с точки зрения сути - вы,как я и сказал сначала - смешали в одном месте 2 понятия - классификация менеджеров и классификация товаров для менеджеров. Я бы разделил все-таки эти вещи по разным таблицам (это выручит вас и в будущем с точки зрения производительности отчетов).

А классификаторы возможно и можно оставить в одной таблице (если их мало), на то они и классификаторы (главное только ввести еще одно поле - группа классификаторов,чтобы было ясно,что само значение классификатора нужно для товара, для менеджера и прочее (вводите поле "Группа классификаторов" для классификатора)).


P.S. всегда оглашайте предметную область - будет проще с оценками порядков.Если,например,вы торгуете канцелярскими товарами, то может быть стоит вообще делать отдельный классификатор (там может быть под 200000 позиций без проблем) ,а если у вас 200 позиций товарной номенклатуры - то можно и с мененжерским и со всеми остальными слить (уверен,что их будет тогда не очень много,ну 500-1000).

To guest_20040621 - хотя в тех системах,которые я видел (особенно для торговли) все классификаторы были залиты в одну таблицу. Как и следовало ожидать - на аналитических выборках все замечательно тормозило.

Главное подобрать под ошибку какой-нибудь фетишь,на который все падки и удача. Ключевые фетиши-"универсальность" (в одной таблицей можно сделать все структуры), "кросплатформенность" (один раз написали - работает на всех платформах клиент, работает на любых субд база и т.д.)