Дамы и господа, вот такой вопрос. Мне кажется поддерживать логический уровень при проектировании БД достаточно накладная работа, неимеющая большой практической пользы.  Как мне кажется заказчику база неинтересна, так как не его забота что где будет храниться.  Для команды разработчиков тоже мне кажется бесполезным логический уровень.  Если "физика" сделана нормально, то любой разработчик разберется на раз-два.
Прошу высказываться.

Не плохо бы сначала определить, что такое логический и физический уровни.

Схема базы данных, нарисованная на бумажке и SQL запросы для создания таблиц?

Кейс-средствами проектирования БД мы не пользуемся (причины могу рассказать отдельно, так сложилось, в свое время - использовали ErWin). Однако описание логической структуры БД в виде UML-диаграммы классов - активно используем при проектировании и сопровождаем по мере изменений в системе, обычно рисуем в Visio. Это именно логическая структура, на которой скрыто большое количество служебных классов, служебных атрибутов, ограниченно прописана типизация. Структура представляется и активно обсуждается с заказчиком, обычно мы взаимодействуем с его IT-подразделениями.

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

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

В целом, я сторонник поддержки и физического и логического уровней в больших проектах.

Логический уровень нужен при проектирование гетерогенных систем (больших),
когда при 1 логическом можно построить несколько физических уровней (под разные СУБД).

Логический уровень (названия) можно использовать в интерфейсах пользователя (выгрузили таблицу программисту и сказали - у пользователя должны быть такие то поля = автоматизация .

Если под лог уровнем понимается Domain Object Model, то мы делаем ее.
Например, для ERP систем нет смысла в физ модели данных.

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

Доброго времени суток всем, дамы и господа, и гости форума.
 Я не профессионал - аналитик, но... суммируя всё, что видел, всё, чему преподаватели в универе учили, всё, что сам делал... делаю вывод совершенно однозначный: логическую структуру БД необходимо поддерживать и сопровождать. АБСОЛЮТНО НЕОБХОДИМО. Но вот как именно и почему - вот где дорожка раздвоилась. Вариантов ровно 2.

Вариант 1. Логическую структуру БД сопровождают и поддерживают крайне неохотно потому, что (как выразился автор вопроса) в этом никто не заинтересован.

Вариант 2. Логическую структуру БД сопровождать приходится крайне редко вследствие того, что изначально при проектировании БД были учтены все требования к структурированию, представлению, хранению и обработке информации, как текущие, так и предполагаемые в ближайшей перспективе (2 - 5 лет развития).

Резюме по варианту 1: ТАК ДЕЛАТЬ НИ В КОЕМ СЛУЧАЕ НЕЛЬЗЯ (если ваша цель не провалить проект или обанкротить фирму; если цель именно такова - это вернейший путь к ней, и довольно короткий). Почему? На какой этап ЖЦПО приходится наибольшее количество времени и затрат? Ответ: на сопровождение. Что приходится сопровождать? Всё, из чего проект состоит: БД, код middle-ware и исполняемый front-end код. А вот теперь вопрос уже не риторический: ошибки на каком уровне обойдутся дороже всего для проекта? Может, для кого-то ответ не самоочевиден, но правильный ответ: на уровне БД. Логическая структура БД - часть, наиболе дорогостоящая в плане внесения изменений в проект: любое её изменение неминуемо повлечёт за собой лавинообразные изменения на всех остальных уровнях. Каждый DDL - оператор в уже работающей БД - это в лучшем случае десятки переработанных или добавленных строк кода на других уровнях, а теперь добавьте сюда отладку, документирование, развёртывание - и вы на тривиальную операцию угрохали, минимум, полный рабочий день (к слову сказать, я аж 6 лет проработал в подразделении крупного предприятия, где такая практика считалась не просто нормальной - она была единственной, о которой начальник отдела имел хоть какое-то представление, и на любое предложение спроектировать нормальную систему вопрошал: "Да разве иначе возможно??? К чему нам эти студенческие глупости???"). Если БД спроектирована правильно, то всё управление уровнем БД сводится к DML-операторам, и схемы БД никогда не затрагивает. И в хорошем проекте такая ситуаця является нормальной из года в год, до тех пор, пока в предметной области не начнут происходить кардинальные изменения. Мне можно возразить, что альтернативой тщательному проектированию БД может быть более сложная обработка информации на стороне сервера (на уровне  middle-ware), но, прошу прощения, хрен редьки не слаще. Только долбёжка кода станет более объёмной, и требоваться будет чаще, со всеми вытекающими последствиями. Не стану своего мнения навязывать, но лично для себя: ТЩАТЕЛЬНОГО ПРОЕКТИРОВАНИЯ ЛОГИЧЕСКОЙ СТРУКТУРЫ БД НЕ ЗАМЕНИТ НИЧТО. Даже если будут сорваны все мыслимые сроки проекта, даже тогда время, затраченное на проектирование БД - точно не затрачено впустую. В дальнейшем, на этапе сопровождения, проект окажется и чрезвычайно дёшев, и чрезвычайно живуч! А чаще всего от неправильного будет отличаться просто тем, что окажется жизнеспособным.

Резюме по варианту 2. Если бы мне предложили использовать в условиях реального бизнеса информационную систему, в которую для добавления одной операции необходимо было бы изменять логическую структуру БД, я бы такую систему не взял. Вообще, мне не представляется нормальным, если в работающей системе приходится делать изменения чаще 1 раза в 6 месяцев (при очень динамично развивающейся предметной области).  На 6 месяцев вперёд увидеть предметную область не удаётся только в исключительных случаях (единственный пример, быстро приходящий на память, - законотворчество в некоторых странах мира). И частота внесения в проект изменений, и объём этих изменений напрямую зависят от того, насколько тщательно спроектирована логическая структура БД. И общие наблюдения за опытом - своим и чужим - подтверждают: если БД сделана правильно, сопровждать её структуру приходится очень редко, но вовсе не потоу, что это никому не выгодно. В этом просто необходимости нет. И затраты на сопровождение такого проекта - просто мизерные по сравнению с попытками заставить нормально работать мастодонтов, где вместо изначального правильного структурирования информации выбрали путь более сложной обработки информации на сервере (думали, сейчас сделаем что-нибудь для отчётности, а уж потом-то мы всё это заставим работать так, как нам надо!... ОЧЕНЬ РАСПРОСТРАНЁННОЕ МНЕНИЕ, И ОЧЕНЬ ОШИБОЧНОЕ...).

Есть еду не только полезно, но и нужно.

Коллеги, извините, выпал немного из обсуждения вернемся к теме )
Речь о чем: в Erwin например есть логический и физический уровень. Физический - это непосредственно сама база данных, ее объекты. Из этой модели в Erwin генерируются скрипты для создания объектов БД (таблиц, сиквенсов, триггеров и т.д), а вот логический уровень на мой взгляд- это попытка в те давние времена (могу ошибиться), когда только зарождалась нотация UML, сделать нечто подобное в том же направлении. 
В настоящее время для описания объектов предметной области я использую UML и, естественно делаю это не в Erwine, а с помощью специализированных продуктов, таких как Enterprise Architect. Структуру базы проектирую в Erwin. Логический слой в модели erwin я выбросил на начальном этапе, за что сейчас и поплатился, но не потому что не вел его, а потому что вообще не создал. В erwin есть возможность некоторой автоматизации путем написания скриптов(например для задания имен связей) и оказалось, что этот механизм вообще не работает, если нет логического слоя модели.

Так что поймите правильно, я не против создания объектной модели предметной области. Вопрос именно в инструменте. Насколько я знаю, в Power Designer разработчики сделали шаг именно с сторону UML (или скорее даже каких то языковых платформ) и там можно создавать классы и из этого по-моему даже получать исходный код каркаса программы на языке программирования (другой вопрос уже кто и как это использует).



 

Коллеги, извините, выпал немного из обсуждения вернемся к теме )

Шутить изволите? Выпали из темы эдак на 4 года:)

Речь о чем: в Erwin например есть логический и физический уровень. Физический - это непосредственно сама база данных, ее объекты. Из этой модели в Erwin генерируются скрипты для создания объектов БД (таблиц, сиквенсов, триггеров и т.д), а вот логический уровень на мой взгляд- это попытка в те давние времена (могу ошибиться), когда только зарождалась нотация UML, сделать нечто подобное в том же направлении. 

ERWin появился в 90 годы, ну может чуть раньше. И был ориентирован на создание БД по классическому принципу нормализации отношений. Исходно поддерживались две нотации IDEF1x и Information Engineering. IDEF1x вырос из IDEF1 и заточен под реляционную модель, которая есть суть ЛОГИЧЕСКАЯ модель. Потому логический уровень во многом важен.

Идея UML стала возникать позже, но в ДК UML и в моделях ERWin заложены совершенно иные принципы. Впрочем не будет эту тему развивать.

В настоящее время для описания объектов предметной области я использую UML и, естественно делаю это не в Erwine, а с помощью специализированных продуктов, таких как Enterprise Architect. Структуру базы проектирую в Erwin.

А зачем? Я делаю обычную DDL трансформацию. Вернее делаем два этапа. UML превращаем в модель БД и далее трансформационный код с подключением и выгрузкой в физическую БД. Можно использовать и другие подходы, например, ORM преобразование.

Логический слой в модели erwin я выбросил на начальном этапе, за что сейчас и поплатился, но не потому что не вел его, а потому что вообще не создал. В erwin есть возможность некоторой автоматизации путем написания скриптов(например для задания имен связей) и оказалось, что этот механизм вообще не работает, если нет логического слоя модели.

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

Так что поймите правильно, я не против создания объектной модели предметной области. Вопрос именно в инструменте. Насколько я знаю, в Power Designer разработчики сделали шаг именно с сторону UML (или скорее даже каких то языковых платформ) и там можно создавать классы и из этого по-моему даже получать исходный код каркаса программы на языке программирования (другой вопрос уже кто и как это использует).

ERWin просто изначально на это не ориентирован. По-моему СА делали какой-то инструмент типа Object Paradigm, но не знаю, какова его судьба.

Цена ERWin, как и Power Designer, астрономическая. Да признаю, PD делает некоторые вещи совсем неплохо.