Добавление отношений в базу данных доступа

Question

У меня есть база данных MS Access с большим количеством данных. Он используется приложением, которое я и моя команда разрабатываем. Однако мы никогда не добавляли какие-либо внешние ключи в эту базу данных, потому что мы могли контролировать отношения из самого кода. Никогда не было проблем с этим, вероятно, никогда не будет.

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

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

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

---

Это приложение было создано более 10 лет назад и имеет более 3000 платных клиентов, которые все его используют. На самом деле это документ, использующий документ XML для внутреннего хранения. База данных просто используется в качестве хранилища, и единственная процедура импорта / экспорта преобразует ее обратно и в XML. К сожалению, XML-структура не очень практична для использования в документации, и вокруг этого XML-документа есть второй слой, который представляет ее как объектную модель. Эта объектная модель тоже далека от совершенства, но это то, что 10 лет разработки могут сделать с приложением. Мы действительно хотим улучшить его, но это требует времени, и мы не можем разочаровать текущих пользователей, откладывая новые обновления.
По сути, мы застряли в его нынешнем дизайне, и для его улучшения нам необходимо убедиться хорошо задокументированы. Это то, над чем я сейчас работаю.

Answer 1

только 30+ столов? Не должно быть полчаса или часа, чтобы создать все необходимые отношения. Что я и призываю вас сделать. Да, я знаю, что вы заявляете свои проверки кода для тех. Но что, если вы пропустили немного? Что, если есть действительно осиротевшие записи? Как ты узнаешь? Или у вас есть пуленепробиваемые процедуры, которые просматривают все ваши таблицы в поисках всех этих проблем?

Используйте большой 23-дюймовый ЖК-монитор и держите его.

Answer 2

Вы можете создать небольшой фрагмент кода VBA, разделенный на 2 части:

1. Шаг 1 реализует отношения базы данных с методом database.createrelation
2. Шаг 2 удалил все созданные отношения с командой database.delete

Как сказал Тони, 30 таблиц не так уж много, и сценарий должен быть прост в настройке. После этого остановите процесс после шага 1, запустите документирующий доступ (tools \ analysis \ documentmenter), чтобы подготовить документацию, запустите шаг 2. После этого ваша база данных останется неизменной и документация будет готова.

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

Answer 3

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

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

Например, я использую схему, подобную этой:

Table Product
- Field ID          /* The Unique ID for a Product */
- Field Designation
- Field Cost

Table Order
- Field ID          /* the unique ID for an Order */
- Field ProductID
- Field Quantity

Отношение легко обнаружить, если взглянуть на Order: Order.ProductID относится к Product.ID, и это легко определить из кода, проходящего через каждое поле.

Если у вас есть подобная схема, то, сколько вы сможете извлечь из нее, зависит от того, насколько хорошо вы будете следовать своему собственному соглашению, но она может достичь 100% точности, хотя у вас, вероятно, есть некоторые исключения (которые вы можете построить - в вашем коде или, лучше, посмотрите где-нибудь).

Другое решение заключается в том, что каждый из уникальных идентификаторов вашей таблицы соответствует своей схеме нумерации.
Скажем, ваш Order.ID фактически следует схеме, подобной OR001, OR002 и т. Д., А Product.ID следует PD001, PD002 и т. Д.
В этом случае, просматривая все поля во всех таблицах, вы можете искать записи FK, которые соответствуют каждому PK.

Если вы придерживаетесь вменяемого соглашения об именовании ваших полей и таблиц, то, вероятно, вы можете автоматизировать обнаружение отношений между ними, сохранить их в таблице и вручную выполнить исправления.
Как только вы закончите, используйте эту таблицу результатов, чтобы фактически построить отношения из кода, используя метод Database.CreateRelation() (посмотрите документацию по Access, для этого есть пример кода).

Answer 4

Там может быть инструмент, который сможет "угадать" отношения, но я сомневаюсь в этом. Честно говоря, я боюсь баз данных без надлежащих внешних ключей, в частности, многопользовательских приложений, которые также используют Access в качестве СУБД. Я предполагаю, что приложение должно быть своего рода внутренним инструментом, в противном случае я бы посоветовал вам перейти на подходящую СУБД (SQL Express бесплатно) и добавить внешние ключи.