Я делаю модель UML, основанную на моем ERD, сгенерированном с MySQL workbench. Но теперь я сомневаюсь в представлении первичных и внешних ключей в диаграмме классов.первичные/внешние ключи в uml
В традиционной диаграмме UML мы должны включать первичные ключи как атрибуты каждого класса? Например, id_user или id_list? А о внешних ключах? Они игнорируются как атрибут, но отражаются как ассоциации?
благодаря
Во-первых: почему вы хотите сделать это в UML? Если у вас уже есть ERD, какое дополнительное/альтернативное свойство вы хотите проиллюстрировать диаграммой классов UML, которую ERD не дает вам?
Почему? Потому что UML - это инструмент. В предположении, что диаграмма предназначена только для потребления человеком (т. Е. Вы не являетесь кодом, генерирующим ее), тогда вы должны использовать UML для раскрытия информации, которую вы пытаетесь установить.
Как обычный стандарт UML ничего не говорит о том, как вы формализуете идентичность (PK/FK). UML следует за идиомой OO, что каждый объект имеет неявный идентификатор, поэтому вам не нужно явно указывать его. Поэтому в простейшем случае вы можете:
Если это соответствует вашим потребностям моделирования, тогда все готово.
В качестве второго уточнения вы можете пометить атрибуты PK с помощью ограничения ocl isUnique(), снова игнорируя FK.
Другим вариантом является использование правил Executable UML. Он обозначает как PKs («Идентификаторы»), так и FKs («ссылочные атрибуты») непосредственно на диаграмме классов. Поэтому он наиболее близок к захвату всего в ERD.
Итак, вкратце: нет правильного ответа на UML. все зависит от того, что вы хотите общаться с диаграммой.
НТН.
вы можете использовать/создать «профиль базы данных» аннотировать модель UML с этой информацией. Без профиля вы могли бы использовать OCL для указать ограничения уникальности, в то время как нормальных ассоциаций должно быть достаточно для представления того, что было бы преобразовано в внешние ключи на уровне базы данных.
Вы можете использовать пробную версию EclipseUML Omondo и отменить свою базу данных.
Вы получите необходимую информацию, и затем сможете ее скопировать в бесплатный или с открытым исходным кодом.
Игнорирование FK не имеет большого смысла, imo. Использование ассоциаций (которые имеют свойства для членов, а также), как и запрос, более подходит. – Christian
@Christian: Да, FK могут быть показаны как роли в конце ассоциации. Мое мнение заключалось в том, что нет жестких и быстрых правил, которые должны применяться. У вас есть широта, чтобы делать что-то, что работает в вашем конкретном случае. FKs как роли были бы хорошим дефолтом. – sfinnie