minvaВопрос, получилась некое зацикливание по схеме... Это нормально или так нельзя?
Нормально. Есть сверхстандартный пример, Сотрудники - Отделы. Каждый сотрудник входит в какой-нибудь отдел, у каждого отдела есть начальник из числа сотрудников.

MasterZivНу разумеется одно из полей в цикле связей должно быть обязательно NULL, если связи обязательные.
Cтрого говоря, даже этого не обязательно. Есть deferred constraints и есть возможность создавать вторичные записи триггерами.

Это не то что серьезное возражение, просто "ради математической точности".

minvaИ еще загвоздка вот в чем... Что я чисто теоритичеки могу по этой схеме назначить для конкретной модели некую характеристику, которая не принадлежит к той группе характеристик, которая назначена моделе через отраслевой код...
Признаться, не вникал в Вашу схему, но часто это решается через составной внешний ключ. Пример.... допустим, сущности:

Факультеты (department_id PK, .......)
Дисциплины (course_id PK, department_id FK -> Факультет, ...)
Студенты (student_id PK, department_id FK -> Факультет, ...)

Допустим, мы хотим сделать таблицу назначений, хранящую дисциплины, изучаемые каждым студентом. Если мы сделаем ее в виде развязки студент-дисциплина, примерно так

ДисциплиныСтудентов (student_id FK -> Студенты, course_id FK -> Дисциплины)

получится, что мы можем назначить студенту изучать предмет, не соотнесенный его факультету. Поэтому делаем так: в таблице дисциплин делаем альтернативный ключ (course_id, department_id), в таблице студентов аналогично делаем ключ (student_id, department_id), включаем department_id в развязку и ссылаемся из развязки на составные ключи, обеспечивая тем самым равенство department_id у связанных записей.

minvaИдея то ясна, но как это на концептуальной модели в PD изобразить???
Хм. Ну это уже вопрос в топик по PD.