Access - это и СУБД, и RAD (среда разработки приложений). Причем, можно воспользоваться только первым, только вторым, или обеими частями одновременно. Если пользуются только вторым, то роль СУБД выполняет уже не Access, а, например, MS SQL Server.

Как СУБД Access является СУБД файл-серверной архитектуры. Это означает, что множество клиентских приложений САМИ, НЕПОСРЕДСТВЕННО обращаются к данным, хранящимся в MDB-файле. Если они используют SQL-запросы, то парсит и исполняет эти запросы само клиентское приложение с помощью библиотек, расположенных на компьютере каждого пользователя. Недостаток такой архитектуры очевиден - огромные массивы данных перегоняются по сети между файл-сервером и пользовательскими компьютерами, даже если реально использованы (например, отображены на экране) будет из них только очень небольшая часть.

Клиент-серверная архитектура, в отличие от файл-серверной предполагает наличие промежуточного программного обеспечения, расположенного на сервере (обычно на том же компьютере, где расположены базы данных). Оно получает SQL-запросы от клиентских приложений, парсит их, исполняет, и по сети отправляет только результат их выполнения. Объемы информации, передаваемой между сервером и клиентскими приложениями в такой архитектуре существенно меньше.

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

Как для файл-серверной, так и для клиент-серверной архитектуры данные хранятся в некоторой базе, как правило, в виде совокупности реляционных таблиц. Кто-то должен разработать состав таких таблиц (сколько их, для хранения какой информации они будут использоваться, состав и тип их полей, задать связи между ними и т.п.). Если используется клиент-серверная архитектура, то кроме собственно таблиц в базе данных еще расмещается часть функционала по обработке данных на сервере - в виде хранимых процедур, функций, запросов (VIEW), триггеров. Для такой архитектуры архитектор обычно производит разграничение таким образом, чтобы часть функционала, отвечающего за целостность данных, за транзакции, за их синхронную модификацию и представление более близкое к предметной области, было расположено на сервере. А часть функционала, связанного с отображением данных, интерфейсом и т.п. - на клиенте. На самом деле разгарничить эти вещи не так просто, но углубляться в эти вопросы мы не будем, чтобы не отклониться от темы.

Таким образом, разработчик средствами СУБД разрабатывает серверную часть - таблицы, VIEW, хранимые процедуры, серверные функции (UDF), триггеры (обработчики событий на стороне сервера), связи DRI (декларативной ссылочной целостности). Для клиентского приложения разрабатывается визуализация и интерфейс - средсвами RAD (Delphi, Visual Studio, VBA MS Access и т.п.) и та часть, которая должна обращаться к серверу с помощью SQL-запросов.

Любые ли клиентские приложения связаны с разработкой форм? Чаще всего, да. Но бывают и исключения. Я, например, не имея достаточного времени на разработку интерфейса, буквально за 2-3 дня разработал приложение на MS Access, не использующее ни одной формы, а использующее только продвинутые средства визуализации данных на закладках MS Access "таблицы" и "запросы" - для библиотеки ВУЗа. Это приложение продолжает использоваться уже на протяжении нескольких лет, и оказалось вполне удобным и эргономичным. Access позволяет задавать "подчиненные таблицы" (при этом визуализация одних таблиц "встраивается" визуализацию других таблиц таким образом, что их данные могут отображаться в виде иерархического дерева, а скрытые из визуализации поля Primary-Foreign keys заполняются автоматически сами). Можно в настройке отображения полей таблиц и VIEW настроить визуализацию таким образом, что поле реально будет заполняться целочисленным значением суррогатного ключа, но для пользователя все будет выглядеть как "выбор записи справочника", то есть, отображение полей другой таблицы, с которой связана данная таблица. Конечно, для сложных приложений таких возможностей врядли будет достаточно, но в данном конкретном случае мне удалось покрыть потребности пользователей полностью. Замечу, что разработка интерфейса именно таким способом в 10 - 100 раз отнимает меньше времени, нежели разработка форм, написание обработчиков событий и т.п. Использовалась файл-серверная архитектура, роль базы данных, в которой хранились основные таблицы и связи между ними (и больше ничего!), играл один MDB-файл. Другой MDB-файл играл роль "клиентского приложения". Реальных таблиц в нем не было, а были выставлены ссылки на таблицы первого файла. Еще в нем были VIEW и настроенные отображения таблиц и VIEW. Ну, и парочка отчетов. Больше - ничего.

Настоятельно рекомендую взять MS Access и научиться пользоваться сначала его типовым интерфейсом, не создавая никаких форм. Для того, чтобы не напортачить со структурой таблиц, настоятельно рекомендую ознакомиться с правилами нормализации реляционных данных. Лучше всего внимательно прочитать книжка Эдгара Кодда.

2 All. Понятно, что задавший вопрос в данной области начинающий. Однако, это не дает морального права "крутым спецам" глумиться и выпячивать свою "крутость". Если не охота отвечать по существу, то лучше просто промолчать. Вспомните, что кода вы родились, то тоже не знали, что такое 3-я нормальная форма.