Мне нужно создать диаграмму сущности базы данных MSSQL 2005.
Отношения определяются последовательным использованием первичных ключей, но нигде нет внешних ключей. Я попробовал функцию Microsoft Visio «Reverse Engineer», которая, конечно же, не удалась из-за отсутствия внешних ключей.
Поэтому мне нужен инструмент диаграммы, который не полагается исключительно на внешние ключи при рисовании отношений.
Создайте сценарий, который создает правильные отношения внешних ключей, запустите инструмент диаграммы, а затем запустите второй сценарий, который удаляет внешние ключи.
Это позволит вам использовать ваш инструмент, не слишком нарушая работу базы данных. Если первый сценарий завершится ошибкой, вы поймете, что с данными тоже что-то не так.
[EDIT] Если есть какое-то правило, как называются столбцы внешнего ключа, вы можете использовать язык сценариев для создания SQL для вас.
Если это также не удается, любой инструмент проектирования должен позволить вам создать недостающие отношения. Это означает, что вы, вероятно, столкнетесь с несогласованностью данных. Решение здесь состоит в том, чтобы сделать снимок определений таблиц и воссоздать базу данных (без данных) на частном сервере базы данных. Там вы можете возиться с дизайном столько, сколько хотите, не нарушая исходную систему.
Когда вы закончите с исправлением дизайна, вы можете извлечь команды для создания внешних ключей и применить их к реальной системе — если хотите. Таким образом, вы можете почувствовать, насколько велик беспорядок в базе данных. Если нет, то вы можете просто сохранить новую копию, внести в нее любые изменения дизайна и, после того, как они будут проверены, вы можете перенести изменения в производственную базу данных.
В моих собственных системах у меня всегда есть сценарии для быстрого создания клона текущей базы данных разработки и производства. Обычно я использую встроенную базу данных, такую как Derby или HSQL. Но если вы добавите в процесс фильтр, вы сможете использовать $(SCHEMA) в файлах DDL и установить одну и ту же базу данных в разные схемы на одном сервере. Мы использовали это с большим успехом во время проекта миграции данных, где мы сохраняли результаты каждого теста миграции в новой схеме (TABLE_DATE_XX, где XX — двузначное число, поэтому вы можете создавать более одного теста в день).
Это позволило нам проверить различные исправления, сравнить две миграции и т. д. Поскольку весь процесс был на 100 % автоматизирован, создание новой схемы стало дешевле, чем исправление существующей схемы.
