student42,

Если связи будут реализованы ТОЛЬКО через суррогатный ключ, то все окончиться плачевно (если система будет сильносвязной).
Суррогат лучше использовать как ровгуид.

guest_20040621Расскажите о необходимости динамического создания сущностей. Опционально: кто научил вас этой ахинее?
Допустим невозможнсть четкой предварительной классификации сущностей. Например, в Процессе участвуют Вход, Процессор, Выход. Но что это именно зависит от отрасли. Все эти понятия являются точкой входа в множественный классификатор, а сами сущности классифицируемые этими понятиями (как Материал, Обрудование,Специалист..........) появятся в модели позже (кое-что прямо при процессе внедрения).

guest_20040621> Допустим невозможнсть четкой предварительной классификации сущностей.

Не канает. Модель может быть построена в общем виде, тем более, если речь идет о процессах и классификации. Можно порекомендовать более формально подходить к классификации, - это чуть сложнее, чем обычно принято, но окупает себя. Еще варианты?
Поговори немного о "не канает", интересно.
Допустим мне абсолютно пофигу как называется процессор - Инструмент, Оснастка, Учитель, Корова и т.д., важно что они являются процессорами процесса. Но я н могу перечислить все возможные типы процессров. Вот модельщик и создает сущности которые ему нужны для описания предмета и классифицирует их как процессор.

iscrafm Я бы сказал , что следование сказанной однажды кем-то глупости ничего кроме множества бессмысленной и ненужной работы не приносит.
Ну чисто гуид для связей приносит свои сложности с лукапом.
Смотри,
Квалификация(ИД,Наим,...)
Специальность(ИД,Наим...)
Специалист(Квалификация, Специальность,...)
ФизЛицо(ИД, Наим,...)
Сотрудник(ФилЛицо,.....)
Компетенция сотрудника(Сотрудник, Специалист,...)
....

Сложность лукапа :)все растет и растет, а если можно было использовать миграцию ключей то все бы упрощалось (пришлось ввести)

к ГОСТ20040621,
ну согласись, что вышеперечисленные процессоры ну очень уж отличаются что бы их залить в одну структуру - процессоры

Классификатор типизирует типы :) (доопределяет семантику с помощью новых свойств = путь от вершины множ классификатора до типа)
А типизация связей производится отдельно (по типу ссылки и ролям связанных типов в связи).
Методы пишутся с учетом этих дженерик вещей.
Эти 3 фундаментальных вещи дают возможность оставить уточнение списка и сосава сущностей модельщику.

т.е. наследуемость с точностью (изоморфность с точностью, подобность с точностью) СТРУКТУР

ViPRos,

ViPRos,

ViPRos,

Классификаторы, типы, связи, типизация связей и т.д.

guest_20040621> Классификатор типизирует типы

Разве? Классификатор как раз в качестве как минимум одного из критериев классификации использует типы. Не определяет, а использует готовые.
>

Эхма, начинается. :)
1. Что за критерий классификации?
Классифицировать можно как минимум 2 способами.
а) Есть Заданный кем-то классификатор (т.е. заданы признаки классификации и метод отбора). Все свойства (или значение свойства, если свойства неименованы) объектов подлежащих классификации сопоставляются с "признаки классификации" по методу.
В этом случае объект ничего нового не получает от процесса классифиации.
Статический классификатор.
б)Динамический классификатор. Стрятся по заданным алгоритмам анализа свойств и значений свойств объектов. Это типизация объектов. Типизированная часть в классификаторе (все объекты типа с одним и тем же свойством имеют одинаковое значение = имя ветки классификатора), нетипизированная(объекты типа с одним и тем же свойством НЕ имеют одинаковое значениечастично), но обработанная часть в типах и (или в куче - приемнике, если все значение всех объектов разные).
Тут никто никакого классификатора не задает, он строится находу.
в)Принудительный классификатор. Пофиг все свойства и значения свойств объекта. К объекту приписывается Новое свойство со значением заданном в имени принуждающей ветки.
б+в дает возможность изучить и ввести допсемантику в объектную кучу.
Это чуть чуть о механизме классфикации.

guest_20040621> > ролям связанных типов в связи

Интересно, а что это за роли типов в связи? Можно подробнее?
Классификатор НЕ является деревом.
Между отдельными элементами внутри классификатора и Леса классификаторов заданы отношения. Все типы отнсящиеся к этим веткм классфикатора имеют те же отношения. Тип связи в отношении задан именнм связи в межкласссификационном отношении. мя связи меж типами может быть другой. То же самое и ролями типов, они типизированы именем роли в межкласссификационном отношении,а в самих межтиповых могут быть другими.
Но все они могут быть обработаны методами межкласссификационного отношения.

ViPRos,
Механизм принудительно-динамической классификации + ООП на структурах.

guest_20040621,

guest_20040621>
> Все типы отнсящиеся к этим веткм классфикатора имеют те же отношения.

Почему вдруг? Они могут иметь любые другие отношения, никто не запрещает.

Как минимум. Эти генерятся автоматом. Конечно и другие.

guest_20040621,

Отношения таие же типы и могут классфицироваться.
Дополнительно связи типов образующих данное отношения с этим же отношением типизированы.

Есть Класиификаторы "Процесс" и "Процессор". Есть между ними витруальное отношение "Процессор" является "Процессором" "Процесса" в отношение "Процесс_Процессор{Процесс}".

Тогда
"Нормативный процесс" и "Нормативные процессоры" имеют виртуалное отношение "Нормативный процесс_Нормативные процессоры{Нормативный процесс}" и каждый реальный тип допустим "Оборудование" имеет реальное отношение "Нормативный процесс_Оборудование{Нормативный процесс}"
Нормативный процесс d hjkb Ghjwtccf
Нормативные процессоры, Оборудование и т.д. в роли Процессора.
Тип ссылок "(ассосиация)является процессором}/

Эх, блин надо документацию писать, а мне некогда, все никак с мес не закончу. Да и рисовалка уже не все отображает и сама типизация ссылок не до конца осмыслена.:(

ну да
наследование через классифкатор, а ассосияции через типизации ссылок
но кое что счас пересекается есть избыточность :(

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

guest_20040621> каждый реальный тип допустим "Оборудование" имеет реальное отношение "Нормативный процесс_Оборудование{Нормативный процесс}"

Какие атрибуты может наследовать отношение в данном случае?
Реально в проге автоматом НИКАКИЕ, а так можно включить какие надо через Миграцию ссылок и свойств и указать что они персистентны. Пока вручную все. Та как самих отношений межклассификацонных не реализвал. Времени нет, одновременно на этой же недоделке пишу мес для завдодв и апс для кнцерна и по возниквноению новых обобщений меняю платформу. :( И идет пилотное внедрение в 3 местах. :(

guest_20040621> наследование через классифкатор, а ассосияции через типизации ссылок

На мой взгляд, сильно хитро-геморройный метод. ;) Впрочем, если работает... хорошо. При случае тоже попробую такой вариант.
да всем пофиг. а мне надо как то свою работу мимоходом автоматизировать. вот сделал визуализацию всей этой херни и послал всех нах с ихними формами ввода. хотите саи настройте как хотите, пока терпят

guest_20040621,

спасибо