Решил за неделю освоить IDEF1X и IE нотацию, используя примеры из интернета и документацию ERwin. Для этого начал делать шпаргалку, в которой решил более менее ясно описать отношения ERwin'a Мне кажется нотация IE очень понятна для тех, кто сталкивается с размерностями, но IDEF1X понравилось тем, что показывает вложенность множеств друг в друга.

Хочу услышать мнение насчет
0. Правильны ли мои объяснения в тексте и примеры?
1. Можно ли сюда притягивать за уши аналогию с UML? Правильны ли мои аналогии?
2. Какой вариант IDEF1X отношения можно рассматривать как настоящую композицию и агрегацию?
3. Надо ли ставить в UML стрелку к ромбу от потомка и если не всегда, то в каких случаях? Я никак не могу врубиться что подразумевается под направлением навигации, если эти направления почти всегда двусторонни.
4. Можно ли рассматривать отношение много ко многим, как двунаправленную агрегацию?

http://www.jhazz.com/jhazz-idef1x-ie-uml-1.pdf
Файл 1,3 Мб

1. Для начала Вы напутали с методологией IE , ровно наоборот. Читатся просто. птичья лапка - значит много, аналог точки в IDEF1x.
2. То что Вы изобразили в UML неверно, тут нет никакой связи с композиции, родитель же не состоит из потомков, он сними связан простой ассоциацией, может быть зависимостью, от потомков и то до соврешенннолетия:)
3. С процедурами поддержания целостности я бы не баловался пока - это есть суть реализации на мой взгляд. Хотя для шпаргалки может и ничего
4. Слово инеидентифицирующая свзяь принадлежности означает, что родитель не идентифицирует потомка! Причем тут композиция?
5. Пример для описания идентифицирующих связей несовсем корректен, правда для понимания связей потянет. Однако именно в этом случае можно отобразить в UML связь композицией, хотя тоже будет по смыслу не корректно.
6. Свзяь многие-ко-многим в IDEF1x неспецифична и при реализации действительно распадается как на слайде 5, однако причем тут агрегация на UML? подумайте сами: я агрегирую тебя множество раз как и ты меня агрегируещь одновременно? Агрегат как и композит моделирует целое и его части.
7. по 6 слайду, такое возможно при реализации, но уже сильно будет зависить от конкретной ситуации и других требований.

Кстати, а ERwin какой используете? Версия?

У меня ERWin 4.1.

1. Для начала Вы напутали с методологией IE , ровно наоборот. Читатся просто. птичья лапка - значит много, аналог точки в IDEF1x.

Erwin ставит размерность множества на противоположных концах от сущностей (то есть, лапка с одной стороны означает n с другой). Это я в Sybase Power Designer'e узнал?

4. Слово неидентифицирующая свзяь принадлежности означает, что родитель не идентифицирует потомка! Причем тут композиция?

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

5. Пример для описания идентифицирующих связей несовсем корректен, правда для понимания связей потянет. Однако именно в этом случае можно отобразить в UML связь композицией, хотя тоже будет по смыслу не корректно.

Почему же не корректен? В ERwin рассматривается пример с MOVIE и MOVIE-COPY, где родител идентифицирует потомка через movie-number<FK> , а вместо уникального идентификатора movie-copy-id (как это сделали бы многие сходу) используется copy-number. То есть у всех фильмов все первые копии будут иметь copy-number=1, вторые копии copy-number=2. Но, лично я, считаю такой способ идентификации потомков не совсем аккуратным, так как счетчик будет увеличиваться вручную. Удалив 2-ю копию и добавив опять 2-ю копию фильма мы получаем неверную связь: старые объекты также могут ссылаться на 2-ю "старую" копию.
  Лично мое мнение - идентифицирующая связь хороша только для объединения двух и более сущностей. Ну и также как обязательное неидентифицирующее (Z) отношение является примером композиции.

6. Свзяь многие-ко-многим в IDEF1x неспецифична и при реализации действительно распадается как на слайде 5, однако причем тут агрегация на UML? подумайте сами: я агрегирую тебя множество раз как и ты меня агрегируещь одновременно? Агрегат как и композит моделирует целое и его части.

Но согласитесь, рассматривается же случай, когда агрегат сам себя агрегирует. Почему я тогда не имею права разбить агрегирование по концам ассоциации?

7. по 6 слайду, такое возможно при реализации, но уже сильно будет зависить от конкретной ситуации и других требований.

6-й слайд один в один взят из примера ERwin'a Просто я отбросил мусор, который мешал восприятию.

-----
Итого. UML вообще лучше сюда не включать ибо механизмы слишком другие

Интересно, а зачем Вы испрашиваете совета и указаний на Ваши ошибки? Я их Вам указал, а Вы мне говорите мол сами вы...

У меня ERWin 4.1.Erwin ставит размерность множества на противоположных концах от сущностей (то есть, лапка с одной стороны означает n с другой). Это я в Sybase Power Designer'e узнал?

Интересно, кто это Вам сказал? Плюньте ему в ...сами знаете куда.
Вы грубо ошибаетесь или сильно заблуждаетесь. Читайте теорию. Пока "двойка".

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

Глупости, при чем тут реализация мыслей разных авторов. Вы рассматриваете данный конкретный пример, в котором есть живой родитель и его живой потомок. Отец-сын, мать-дочь и т.д. Вы же не рассматриваете задачу просто так. Я Вам указал, что если воспринимать родителя - просто как некую родительскую сущность, а потомка - кк некоторую дочернюю - в самом абстрактном понимании, то да Ваш пример как шпаргалка потянет, но не более того.
Сын не есть отец. Если не дай Бог отец умрет, сын не перестанет существовать. Композиция и идентифицирующая связь принадлежности в смысле IDEF1x отражает такую подчиненность, когда  часть не может существовать без целого.
Факт же того, что у каждого сына должен быть , причем только один, отец (биологический), отражается не идентифицирующей связью, агрегацией или композицией, а обязательностью связи, то есть минимальной кардинальностью. В ER есть понятие слабой сущности, которая передает подчиненность (но не вложенность). Руководитель-подчиненный. Однако в IDEF1x средств выраженияявных такой зависимотси нет, но она может быть реализована через процедуры обеспечения ссылочной целостности.

 

Ведь если на программном уровне поддерживается отношение "родитель не может существовать без потомков, а у потомка ровно один родитель" то это композиция.

А потенциальный родитель?, разве человек половозрелого возраста не есть потенциальный родитель, а родитель у которого к сожалению погиб потомок не родитель? Да потомок не может образоваться без участия родителя, но причем тут композиция?
 
 

Лично мое мнение - идентифицирующая связь хороша только для объединения двух и более сущностей. Ну и также как обязательное неидентифицирующее (Z) отношение является примером композиции.

идентифицирующая связь не объединяет, она идентифицирует. А композиция в применении к ER это уже реализация

Но согласитесь, рассматривается же случай, когда агрегат сам себя агрегирует. Почему я тогда не имею права разбить агрегирование по концам ассоциации?

целое есть целое. как это яблоко агрегирует самое себя?

-----

Итого. UML вообще лучше сюда не включать ибо механизмы слишком другие

неверно. вы здесь рассматриваете использование UML для моделирования ER, которое осуществляется по определенным правилам. ВОт и следуйте им

Да я не ставил вопрос  - просто английский переключал на 10 раз , когда название вспоминал и неусмотрел. Это не вопрос, а обычная точка, только в английской раскладке    Прошу извинить, если доставил неудобства. Мне на самом деле все интересно. 

Итак, по поводу птичьих лапок. Вот снапшоты из PowerDesigner 8. Я менял Cardinality и соответственно видно где лапки меняются и множественность.

P.S. 15 раз делаю пост. Что с форумом? Всегда тут так?

По поводу композиции самого себя - вот тут:
http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=117.msg1138#msg1138
Отдел агрегирует Отдел.

ничего не могу сказать по поводу пауэр дизайнера. Может у него крыша съехала, может еще какая оказия.

Но тут явная ошибка и она видна невооруженным глазом. даже простая логика работает на то, что лапка - это много, кружочек это нулик.

работал я с пауэром в году так эээ, ничего похожего не было. Может просто роли и кардинальности нужно перенести?

Вот попробывал в Visual Paradigm for UML построить ER, правда не совсем стандартна она реализована в VPUML

Лапка ставится там где много.

2 Galogen
Так на вашей диаграмме нет подписей множественности у лап и хвостов. Можно это включить?
Дело в том, что PowerDesigner лапки ставит логически верно. Там где много. Но множественность я понял так показывается сколько связей реализуется с данного конца. Роль - как при чтении от_данной_сущности, т.е. удобно.

Как насчет композиции самого себя? Я взял этот рисунок с диаграммы Boatman'a http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=117.msg1138#msg1138

Мы видим, что ОТДЕЛ является композицией самого себя. Правильно ли такое утверждение?

2 Galogen
Так на вашей диаграмме нет подписей множественности у лап и хвостов. Можно это включить?

Подписей нет, по какой-то причине VPUML их не отображает. Хотя понятно по какой. Сама метафора связи четко отображает кардинальности связей, потому и нет нужды в отображении этих кардинальностей.

Дело в том, что PowerDesigner лапки ставит логически верно. Там где много. Но множественность я понял так показывается сколько связей реализуется с данного конца. Роль - как при чтении от_данной_сущности, т.е. удобно.

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

Как насчет композиции самого себя? Я взял этот рисунок с диаграммы Boatman'a http://www.uml2.ru/index.php?option=com_smf&Itemid=45&topic=117.msg1138#msg1138

Мы видим, что ОТДЕЛ является композицией самого себя. Правильно ли такое утверждение?

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