Форум Сообщества Аналитиков

×


Логическая модель БД: правила именования сущностей(Прочитано 7509 раз)
Периодически участвую в споре с коллегами на тему: использовать ли в именах сущностей на логической модели БД дополнительные пометки, раскрывающие общий тип назначения сущности?
Например, создаём мы сущность "Тип куздры" или "Вид бокрёнка", которые при реализации станут справочниками. Появляется предложение добавить в имена этих сущностей приставку "Справочник" или хотя бы "С_". В теории это должно облегчить поиск справочников и повысить читаемость модели и простого списка сущностей. Таким же образом предлагается поступать с внутрисистемными сущностями, не имеющими прямого отношения к бизнесу.
Есть альтернативная точка зрения - грамотно названная сущность и без дополнительных приставок позволяет легко раскрыть её предназначение и выгоды поиска(спорные) не стоят уродования модели приставками сущностей.
Проблема общего согласия по вопросу усугубляется тем, что разные точки зрения закреплены многолетними наработками нескольких проектов. Так что перспектива оказаться со своим проектом "вне закона" сильно мешает объетивному рассмотрению вопроса отдельным аналитиком.
Так же считаю нужным упомянуть, что ранее мы уже пришли к договорённости, согласно которой сущности на логической модели подкрашиваются в соответствии с назначением. Так же был выработан единый стиль расцветки.
Прошу участников сообщества помочь в аргументации того или другого подхода. Возможно, это позволит положить конец нашему противостоянию.



Используйте стереотип enumeration, т.е. перечисление



Используйте стереотип enumeration, т.е. перечисление
Дополняю изначальные данные: моделирование производится в ERwin. Нотация и программные средства использование стереотипов будто бы не поддерживают.



Периодически участвую в споре с коллегами на тему: использовать ли в именах сущностей на логической модели БД дополнительные пометки, раскрывающие общий тип назначения сущности?
Например, создаём мы сущность "Тип куздры" или "Вид бокрёнка", которые при реализации станут справочниками. Появляется предложение добавить в имена этих сущностей приставку "Справочник" или хотя бы "С_". В теории это должно облегчить поиск справочников и повысить читаемость модели и простого списка сущностей. Таким же образом предлагается поступать с внутрисистемными сущностями, не имеющими прямого отношения к бизнесу.
Есть альтернативная точка зрения - грамотно названная сущность и без дополнительных приставок позволяет легко раскрыть её предназначение и выгоды поиска(спорные) не стоят уродования модели приставками сущностей.
Проблема общего согласия по вопросу усугубляется тем, что разные точки зрения закреплены многолетними наработками нескольких проектов. Так что перспектива оказаться со своим проектом "вне закона" сильно мешает объетивному рассмотрению вопроса отдельным аналитиком.
Так же считаю нужным упомянуть, что ранее мы уже пришли к договорённости, согласно которой сущности на логической модели подкрашиваются в соответствии с назначением. Так же был выработан единый стиль расцветки.
Прошу участников сообщества помочь в аргументации того или другого подхода. Возможно, это позволит положить конец нашему противостоянию.
Если речь о моделях UML то:
- Для расширения семантики существуют стереотипы
- Для диаграмм классов анализа в рамках RUP определены стереотипы boundary, control, entity
Я сторонник использования терминов предметной области без дополнительных обозначений, это не накладывает на этапе анализа никаких ограничений на реализацию. Но зачастую от этих правил приходится отступать, в зависимости от наличия таких наименований в рабочем проекте или особенностей среды разработки.



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

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

Но при всем этом - в рамках проекта названия должны быть единообразны, когда доделывая какой-то функционала при развитии проекта его сущности начинают именовать не так как принято - это очень плохо. А вот в разных проектах в принципе можно именовать по-разному - когда человек меняет проект, то разница в именовании - небольшая трудность относительно остального.
Максим Цепков, CustIS




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19