Составление схемы данных – еще один способ «документирования» проекта. Access имеет средства визуального построения схемы данных в окне, которое так и называется «Схема данных». В нем просматривают, создают или изменяют связи между таблицами или запросами.
Составление схемы помогает разработчику определить, по каким полям связаны основные таблицы и каков тип связи. Конечно, в запросах таблицы можно связать как угодно. Но даже если таблицы БД и не связаны постоянными связями с поддержкой целостности, разработчик обычно «для себя» все равно рисует схему и строит связи. В самом деле, если это позволяет средство разработки, то удобнее хранить графическое описание структуры базы в самом проекте – это значительно упростит понимание (вспоминание через какое то время) логики работы БД. Кроме того, если речь идет о создании постоянных «связей» между таблицами, то для обеспечения целостности данных желательно построить эти связи между ними.
Среди разработчиков есть как сторонники создания схемы, так и противники. В последнем случае аргументируют это тем, что сама по себе схема - это просто график, и кроме как отображение «связей по умолчанию» между таблицами, проку от нее мало. Кроме того, при разработке сложных проектов, где присутствуют несколько десятков таблиц, схема получается громоздкой и довольно затратной в плане времени составления. Так же при сложной логике работы, не всегда оказывается удобным жестко прописывать связи и тем более каскадные удаления/обновления. Иногда это лучше сделать программно.
Однако при отказе от составления схемы данных следует учитывать, что Access «скрывает» от пользователя реализацию так называемых «вторичных ключей», которые собственно и создаются при «графическом» создании связей. Их можно найти в соответствующих семействах, например DAO (indexes, объектов tabledefs). Эти индексы не показываются в окне индексов таблицы (в режиме конструктора таблицы нажмите кнопку «Индексы») и имеют специфические имена. Индексы создаются ускорения процесса поиска и упорядочения данных.
Access так же скрыто реализует наиболее «стандартные триггеры» - проверку целостности и каскадные обновления/удаления. Вот именно для задачи описания (представления) «механизмов» связанности данных и нужен интерфейс «схема данных».
Итак, основные аргументы составления структурной схемы данных:
ЗА
Значительно облегчает понимание логики работы БД за счет графически наглядного представления связей между таблицами
Позволяет создавать каскадные обновления/удаления средствами Access (не программно)
Позволяет отслеживать целостность данных средствами Access (не программно)
ПРОТИВ
В больших проектах - значительные временные затраты на создание связей между таблицами
Не всегда целесообразно жестко прописывать связи – иногда это мешает реализации сложной логики работы приложения
