В моём понимании, логическая схема данных - это ER-диаграмма.

А в Вашем?

И ещё в моём понимании, логической схемой данных можно назвать только ту схему, которую можно с помощью ФОРМАЛЬНОГО МЕТОДА преобразовать в физическую. То есть между логической моделью и физической моделью должно быть однозначное отображение.

В настоящих современных и особенно высоконагруженных решениях такого однозначного отображения нет.

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

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

Определение логической схемы привел в сообщении выше. ER-диаграмма это нотация подходящая для того чтобы нарисовать логическую схему. Можно еще диаграммой классов из UML или любой своей с квадратиками и стрелочками-связями. По поводу формального метода - это уже проектирование. Действительно формальных методов однозначно сказать что и как будет храниться нету. Но в момент проектирования можно делать трассировку, с каким конкретно объектом из логической модели/домена связана конкретно эта структура хранения.

👍

Согласен, не прав, не только ER-модель, но должна быть обязательно формальная нотация, артефакты которой можно конвертировать в схему БД.

При проектировании не можно, а нужно делать трассировку. И в этом вся соль. Более того, имея трассировку, можно уже потом, в озере данных, например, получить полную картину данных. Но это уже другой вопрос.

СА, работающие с хранилищами проектируют логическую модель данных почти всегда. Либо мне так повезло)

Это другое) это их работа

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

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

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

Иначе прилетит, тоже однозначно.

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

На практике оба варианта встречал и оба работали. А лучше всего когда и аналитик шарит и разработчик не боится в бизнес лезть

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

Хранилища данных, это другой домен. Аналитики которые работают с хранилищами конечно должны понимать в базах. Они не только проектировать умеют, но SQL знают часто не хуже разработчиков.

И всегда делают это ужасно, так как некомпетентны.

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

Только это не СА, а совсем другие аналитики.

Наличие в проекте СА - bad smell. Очень редко - оправданный. Но почти всегда симптом чьего-то конкретного факапа (обычно  - руководителя проекта на ранней стадии)