Я все-таки немножко реабилитирую ERD. В отличие от UML, иногда действительно можно использовать CASE-средсвта (ErWin, PD), работающие с ER-диаграммами, именно в процессе разработки. Я сам иногда практикую такое. Но это возможно, во-первых, только для новых систем (рефакторинг существующих баз с информацией, которую нельзя удалять, не прокатит), во-вторых, это означает, что мы делаем модель, например, в ErWin и только в ErWin, минимизируя любую ее правку средствами СУБД. И еще один момент: опираясь на ERD, мы имеем проблему, когда нам нужно не только задавать структуру БД, но и инициализировать ее какими-то исходными данными — современные CASE-средства для этого приспособлены крайне плохо. Важно, однако, то, что (кроме указанной проблемы с самим данными) реализуя модель средствами СУБД мы не располагаем практически никакими дополнительными возможностями (не можем руками/скриптами создать какие-то особенно хитроумные структуры), недоступные нам при проектировании в CASE-системе.

Собственно сама возможность использования ERD на этапе проектирования баз данных обусловлена именно практически полной эквивалентностью доступных инструментов с традиционными скриптовыми возможностями SQL и гибкими средствами синхронизации, имеющимися в современных CASE-системах. Они действительно позволяют синхронизировать модель с "кодом" (реализацией БД) в обе стороны почти без потерь (к сожалению теряются сами данные в таблицах). Но вот про UML-инструменты такого сказать уже нельзя, т.е. синхронизацией сегодня приходится заниматься вручную, а сами возможности кода много шире возможностей UML. Т.е. UML-модель, в отличие от ERD, не полна и в общем случае полной быть и не может, что существенно ограничивает наши возможности при проектировании средствами UML и затрудняет синхронизацию UML с исходным кодом.