« Поставить закладку » « Сделать стартовой »

« Форумы » « Блоги » « Статьи » « Новости » « Файлы » « Realcoding IRC » « Site map » « Поиск »


Главная Главная
Анонсы Анонсы
Форумы Форумы
Каталог Каталог
Поиск Поиск
Опросы Опросы
Книжный магазин Книжный магазин
Реклама на сайте
Публикации Публикации
Партнеры Партнеры
Карта Карта сайта
Рассылки Рассылки
RSS экспорт
Настройки Настройки
О нас пишут О нас пишут
Контакты Контакты
Гостевая книга Гостевая книга

Тестирование 64-битных приложений

ПнВтСрЧтПтСбВс
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31
    Популярное
Программирование метаклассов на Python

Функция GlobalFindAtom

Функция LoadString

Создание приложения в Дельфи, увеличивающее часть рабочего стола наподобие лупы.

Драйвер с нуля

Ссылки

Окончательная настройка приложения

Функция CreateMetaFile

Пример Web-службы Add (Сложение)

Динамически подключаемая библиотека (DLL) Web-приложения




    Архив файлов



    Сообщества



    Документация

Статьи:: Базы данных :: Учебник по Access 2002 :: Глава 17. Проекты Microsoft Access 2002.


отправить ссылку другу версия для печати  Обсудить на форуме

Глава 17. Проекты Microsoft Access 2002.





Глава 17.

Проекты Microsoft Access 2002

В данной главе мы постараемся показать, что Microsoft Access 2000, будучи настольной СУБД, не ограничивает пользователя в разработке приложений различной сложности и масштабируемости. Кроме создания достаточно сложных многопользовательских приложений, Access может использоваться в качестве средства для разработки клиентской части приложения с архитектурой "клиент-сервер". С помощью объектов Access может быть создан интерфейс к базам данных, которые размещаются на мощных серверах баз данных, таких как Microsoft SQL Server, Oracle и т. д.

Для доступа к серверным базам данных из приложений Access используется один из двух стандартных способов доступа к удаленным данным: ODBC или OLE DB. Достоинством Access как клиента к серверной базе данных является наличие мощных и простых средств для разработки интерфейса — форм, отчетов и страниц Web. Наиболее простым и перспективным способом создания приложений в архитектуре "клиент-сервер" являются проекты Microsoft Access 2002 — файлы с расширением adp. В отличие от файла базы данных Access файл проекта не содержит таблиц с данными. Все таблицы, с которыми работает клиентское приложение, размещаются на сервере базы данных, а файл проекта включает в себя только те объекты, которые создаются на базе этих таблиц: формы, отчеты, страницы, макросы и модули. Однако из проекта Access доступны не только таблицы, но и другие объекты сервера: представления (views), хранимые процедуры (stored procedures), схемы базы данных (database diagrams). Доступ к этим объектам выполняется посредством OLE DB — универсального интерфейса, разработанного фирмой Microsoft для доступа к данным произвольного типа как реляционным, так и нереляционным.

В качестве сервера базы данных в проектах Access 2002 может быть использован либо Microsoft SQL Server версии 6.5 и выше, либо настольная (desktop) версия Microsoft SQL Server 2000.

Замечание

В Access 2002 сохранилась возможность создавать интерфейс к серверным базам данных не только в проектах, но и в базах данных через присоединенные таблицы, используя доступ к серверу с помощью драйверов ODBC.

Основные понятия

В данном разделе мы рассмотрим основные понятия модели "клиент-сервер".

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

  • Сервер — логический процесс, который обеспечивает некоторый сервис по запросу от клиента. Обычно сервер не только выполняет запрос, но и управляет очередностью запросов, буферами обмена, извещает своих клиентов о выполнении запроса и т. д.
  • Клиент — процесс, который запрашивает обслуживание от сервера. Процесс не является клиентом по каким-то параметрам своей структуры, он является клиентом только по отношению к серверу. При взаимодействии клиента и сервера инициатором диалога с сервером, как правило, является клиент, сервер сам не инициирует совместную работу. Это не исключает, однако, того, что сервер может извещать клиентов о каких-то зарегистрированных им событиях. Инициирование взаимодействия, запрос на обслуживание, восприятие результатов от сервера, обработка ошибок — это обязанности клиента.

Здесь и далее в книге речь будет идти о частном случае архитектуры "клиент-сервер", а именно о приложениях баз данных, в которых сервером является мощная реляционная СУБД, такая как Microsoft SQL Server (back-end), а клиентом — приложение, созданное в среде Access 2000, которое использует данные с сервера (front-end).

Отличие архитектуры "клиент-сервер" от архитектуры "файл-сервер"

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

Сетевое многопользовательское приложение строится по принципу файл-серверной архитектуры. Данные в виде одного или нескольких файлов размещаются на файловом сервере. Файловый сервер принимает запросы, поступающие по сети от компьютеров-клиентов, и передает им требуемые данные. Однако обработка этих данных выполняется на компьютерах-клиентах. На каждом из компьютеров запускается полная копия процессора обработки данных Jet Engine. Любая копия Jet независимо управляет файлами MDB, содержащими данные. Единственная связь между этими независимыми действиями — файл блокировок (файл, который имеет имя, совпадающее с именем файла приложения, но с расширением Idb), который обязательно создается для каждого файла базы данных с расширением mdb. При этом каждая копия Jet выполняет изменения индексов, работу с системными таблицами и другие функции, входящие в компетенцию СУБД.

В архитектуре "клиент-сервер" сервер базы данных не только обеспечивает доступ к общим данным, но и берет на себя всю обработку этих данных. Клиент посылает на сервер запросы на чтение или изменение данных, которые формулируются на языке SQL. Сервер сам выполняет все необходимые изменения или выборки, контролируя при этом целостность и согласованность данных, и результаты в виде набора записей или кода возврата посылает на компьютер клиента.

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

Архитектура "клиент-сервер" позволяет устранить все указанные недостатки. Кроме того, она позволяет оптимальным образом распределить вычислительную нагрузку между клиентом и сервером, что также влияет на многие характеристики системы: стоимость, производительность, поддержку.

Распределение функций в архитектуре "клиент-сервер"

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

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

Основные функции серверной СУБД — обеспечение надежности, согласованности и защищенности данных, управление запросами клиентов, быстрая обработка SQL-запросов.

Вся логика работы приложения — прикладные задачи, бизнес-правила — в двух-звенной архитектуре распределяются разработчиком между двумя процессами: клиентом и сервером (рис. 17.1).

Сначала большая часть функций приложения решалась клиентом, сервер занимался только обработкой SQL-запросов. Такая архитектура получила название "толстый клиент — тонкий сервер". Появление возможности создавать на сервере хранимые процедуры, т. е. откомпилированные программы с внутренней логикой работы, привело к тенденции переносить все большую часть функций на сервер. Сервер становился все более "толстым", а клиент — "утоньшался". Такое решение имеет очевидные преимущества, например его легче поддерживать, т. к. все изменения нужно вносить только в одном месте — на сервере. Однако язык, на котором пишутся хранимые процедуры, не является достаточно мощным и гибким, чтобы на нем было удобно реализовывать сложную логику приложения.

Рис. 17.1. Распределение функций между клиентом и сервером

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

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

Универсальный доступ к данным через OLE DB

Интерфейс ODBC был первым средством, которое обеспечило универсальный доступ к данным реляционного типа посредством SQL-запросов. Однако реляционные базы данных не единственный формат хранения данных, а современные приложения требуют интеграции информации из разных источников, не только SQL-ориентированных. Отсюда возникает потребность либо перевести все данные в единый формат, т. е. создать универсальную базу данных, что очень-дорого и неэффективно, либо обеспечить универсальный доступ к данным разных типов без необходимости их преобразовывать и реплицировать.

OLE DB представляет собой разработанный фирмой Microsoft набор интерфейсов OLE, обеспечивающих унифицированный доступ приложений к данным из разнообразных источников, включая текстовые файлы, файлы электронной почты, электронные таблицы, данные мультимедиа и пр.

Основные отличия OLE DB от ODBC состоят в следующем:

  • OLE DB обеспечивает доступ к данным произвольных типов, а не только реляционным;
  • OLE DB не является набором функций, а представляет собой набор интерфейсов, построенных в соответствии с компонентной моделью объектов (СОМ).

Общие сведения

Архитектура приложения, использующего интерфейсы OLE DB для доступа к данным, представлена на рис. 17.2. Эта архитектура является многокомпонентной. Компоненты доступа к данным делятся на три категории: потребители, провайдеры и сервисные компоненты.

Потребители данных (Data Consumer) — это любое приложение или компонент, которые используют интерфейсы OLE DB для доступа к данным.

Провайдеры данных (Data Provider) — это компоненты, которые обеспечивают потребителям доступ к данным через строго специфицированный набор интерфейсов. Они взаимодействуют с данными и представляют их единообразно в табличном виде, используя абстракцию, называемую набор рядов (rowsef).

Рис. 17.2. Архитектура универсального доступа к данным

Сервисы (Services) — это дополнительные компоненты, которые обеспечивают функции, не реализованные провайдером OLE DB. Они являются как потребителями OLE DB данных, так и провайдерами. Примером сервиса может быть процессор запросов, который может объединять табличную информацию от разных OLE DB провайдеров и обеспечивать доступ к результирующим данным через OLE DB-интерфейс.

Функционирование компонентов может реализовываться как разными процессами, так и на разных компьютерах через сетевые протоколы, такие как DCOM (Distributed Component Object Model — Распределенная компонентная модель объектов) или HTTP. При этом для выполнения распределенных транзакций может использоваться координатор распределенных транзакций, например Microsoft Transaction Server (MTS).

Компоненты OLE DB

В OLE DB определена иерархия компонентов, каждый из которых является СОМ-объектом (рис. 17.3).

Рис. 17.3. Объекты — компоненты OLE DB

П Источники данных (Data Source) — объекты, которые реализуют подключение к источнику данных: Они определяют нужный OLE DB-провайдер, проверяют права доступа потребителя данных и инициируют соединение с источником данных.

Замечание

Следует различать объект — источник данных и источник данных, который фактически содержит данные.

  • Сеансы (Sessions) — объекты, которые реализуют функции поддержки соединения с источником данных. Они предоставляют контекст для выполнения транзакций и команд. Основная цель сеанса — установить рамки транзакции. Один объект — источник данных может поддерживать несколько сеансов, а значит, и несколько транзакций.
  • Транзакции (Transactions) — объекты, которые обеспечивают реализацию механизма транзакций. Они предоставляют методы для того, чтобы начать транзакцию для сеанса или новую транзакцию внутри текущей и подтвердить или отменить транзакцию самого нижнего уровня.
  • Команды (Commands) — объекты, которые реализуют выполнение действий с данными (например, запросов). Команды порождаются сеансом, и в одном сеансе можно создать несколько команд.
  • Наборы рядов (Rowsets) — объекты, которые предоставляют данные в табличной форме. Они порождаются либо сеансом, либо командой в качестве результата ее выполнения. Непосредственно из сессии можно создать набор рядов, содержащий все данные таблицы. Для реализации такого простого запроса не требуется команды. В остальных же случаях для создания набора рядов используются команды.

Microsoft ActiveX Data Objects (ADO)

Хотя OLE DB является очень мощным интерфейсом для работы с данными, этот интерфейс является низкоуровневым. Для удобства работы с OLE DB, так же как и для ODBC, была разработана объектная модель, которую назвали ADO (ActiveX Data Objects). Эта модель была описана в разд. "Объектные модели Microsoft Access" гл. 13. Здесь хотелось бы указать на те достоинства этой модели, которые позволяют говорить о ее ключевой роли в приложениях, связанных с обработкой данных, в ближайшем будущем.

  • ADO является общей программной моделью для работы с данными различных типов. Она разрабатывалась специально для того, чтобы заменить все другие интерфейсы работы с данными. Впервые она была реализована в Internet Information Server (IIS), где успешно работала вместе с Active Server Pages.
  • Модель включила ряд возможностей других известных объектных моделей (DAO и RDO), хотя и не полностью. Но она является расширяемой и в очередной версии должна превзойти эти модели как по функциональности, так и по производительности.
  • Так как ADO реализована на базе СОМ-объектов, то она может быть использована в любом языке, который может работать с СОМ-объектами, в том числе и в VBA.
  • ADO обеспечивает доступ к любому OLE DB источнику данных, для которого имеется OLE DB провайдер, и, более того, она позволяет расширить функциональность провайдера.
  • ADO реализована таким образом, чтобы минимизировать сетевой трафик в ин-тернет-приложениях и сократить число промежуточных слоев между фронтальным (клиентским) приложением и источниками данных. Это требуется для того, чтобы сделать интерфейс как можно более легким и высокопроизводительным.

Установка связи с источником данных посредством интерфейса OLE DB

При установке на компьютере Microsoft Office XP или отдельного приложения Access 2002 автоматически устанавливаются следующие провайдеры OLE DB:

  • Microsoft Jet 4.0 OLE DB Provider;
  • Microsoft OLE DB Provider for SQL Server;
  • OLE DB Provider for ODBC Drivers;
  • OLE DB Provider for Oracle.

Для того чтобы посмотреть, какие провайдеры OLE DB установлены на вашем компьютере, необходимо открыть диалоговое окно Data Link Properties. Это окно открывается при создании или редактировании специальных файлов — Microsoft Data Link, или файлов UDL (universal data link), в которых хранится информация о конкретном источнике данных OLE DB (тип провайдера OLE DB, сервер, на котором размещаются данные, база данных или файл, в котором они хранятся).

Информация о соединении может храниться и запрашиваться также в том приложении, которое использует интерфейс OLE DB для доступа к данным. В нашем случае таким приложением яапяется проект Microsoft Access, однако о проектах Microsoft Access речь еще впереди, поэтому пока мы опишем только, как работать с файлами связей Microsoft Data Link.

Для того чтобы создать новый UDL-файл, проще всего воспользоваться программой Проводник (Explorer) Windows:

  1. В окне Проводника откройте папку, в которую вы хотите поместить UDL-файл. Щелкните правой кнопкой мыши по правой панели и выберите из контекстного меню команду Создать, Microsoft Data Link (New, Microsoft Data Link). В результате будет создан новый файл с расширением udl.
  2. Дайте этому файлу название, например TestSQLServer, а затем откройте его двойным щелчком кнопки мыши. Появится диалоговое окно Data Link Properties.
  3. Раскройте вкладку Provider. Вы увидите список доступных провайдеров OLE DB, например такой, как показано на рис. 17.4.
  4. Выберите один из провайдеров, например Microsoft OLE DB Provider for SQL Server, и нажмите кнопку Next. Раскроется вкладка Connection.

Вкладка Connection и следующая вкладка Advanced содержат параметры соединения с источником данных. Вид этих вкладок зависит от используемого провайдера OLE DB. Для SQL Server провайдера OLE DB вкладка Connections выглядит так, как представлено на рис. 17.5.

Замечание

Вкладка такого же вида отображается в диалоговом окне Data Link Properties, появляющемся при выборе команды Файл, Подключение (File, Connection) в окне приложения Access 2000 при работе с проектом Access 2002.

Рис. 17.4. Список провайдеров OLE DB

Рис. 17.5. Определение связи с SQL Server

На этой вкладке нужно определить сервер, с которым будет выполняться соединение, имя базы данных и параметры регистрации на сервере. Можно использовать интегрированную с Windows NT (Use Windows NT integrated security) или стандартную (Use a specific user name and password) схему безопасности. При выборе переключателя Use a specific user name and password нужно ввести имя и пароль для регистрации на сервере. Флажок Blank password предназначен для использования пустого пароля в строке соединения (connection string). Флажок Allow saving password позволяет сохранить пароль в строке соединения. Если используется интегрированная схема безопасности, то подключение к SQL Server будет выполняться с тем именем и паролем, под которым вы зарегистрировались в сети Windows NT. На этой вкладке есть также кнопка Test Connection, позволяющая немедленно протестировать соединение с заданными параметрами.

Следующая вкладка Advanced позволяет определить дополнительные свойства соединения, например Connection timeout (рис. 17.6). Это время ожидания (в секундах) соединения с источником данных. Если через заданный промежуток времени связь с источником данных установить не удалось, выдается сообщение об ошибке.

Рис. 17.6. Определение дополнительных свойств соединения

Все свойства соединения можно увидеть и отредактировать на вкладке All (рис. 17.7). Перечень свойств в списке зависит от типа провайдера OLE DB. Для того чтобы отредактировать любое свойство, нужно выделить его в списке и нажать кнопку Edit Value. Появится диалоговое окно Edit Property Value. В поле Property Value можно ввести новое значение свойства, предварительно очистив его при необходимости нажатием кнопки Reset Value (рис. 17.8).

Рис. 17.7. Список свойств соединения

Рис. 17.8. Диалоговое окно Edit Property Value

Настольная версия Microsoft SQL Server 2000

Данная версия сервера представляет собой процессор обработки данных, который является альтернативой процессору Jet (первая версия этого процессора называлась MSDE — Microsoft Server Database Engine и была совместима с Microsoft SQL Server 7.0). Он может быть использован либо как локальный сервер, и в этом случае устанавливается на тот же компьютер, на котором установлен Access 2002, либо как сервер баз данных для небольшой рабочей группы, и в этом случае будет удаленным по отношению к клиентским компьютерам. Основное его достоинство по сравнению с процессором Jet — полная совместимость с Microsoft SQL Server 2000. Это означает, что, создав приложение целиком на персональном компьютере, можно в любой момент времени без труда перенести всю серверную его часть на Microsoft SQL Server 2000. В результате становится возможным многократное увеличение числа пользователей приложения и получение доступа к многочисленным службам SQL Server, например Data Transformation Services, OLAP Services и т. д.

В отличие от Microsoft SQL Server 2000, Standard Edition Microsoft SQL Server 2000 Desktop Engine имеет ограничение на количество одновременно работающих с базой данных пользователей и на объем базы данных, не поддерживает симметричную мультиобработку (SMP) и в процессе репликации может функционировать только как подписчик. Максимальный объем базы данных, так же как и у Jet равен 2 Гбайт, а количество одновременно работающих пользователей ограничивается пятью активными запросами (потоками).

Итак, с помощью проектов Access, используя Microsoft SQL Server 2000 Desktop Engine, вы можете создавать надежные многопользовательские приложения, а когда потребуется подключить к базе данных большое число пользователей или объем базы данных будет превышать 2 Гбайт, можно легко масштабировать этот проект, просто перенеся базу данных на SQL Server 2000.

Установить Microsoft SQL Server 2000 Desktop Engine можно с того же компакт-диска, что и Microsoft Office XP. Он находится в папке Msde2000. При этом программа установки не запрашивает ни имя папки, в которую будет установлен сервер, ни имя самого сервера. Установка выполняется в папку C:PROGRAM FILESMICROSOFT SQL SERVER, а имя сервера по умолчанию — MSSQLSERVER. Если требуется изменить эти значения, нужно использовать при установке параметры командной строки (см. разд. справки Access 2002 "Работа с проектами Microsoft Access, Основные задачи, Установка и конфигурирование SQL Server 2000 Desktop Engine" (Working with Microsoft Access Projects, Basic Tasks, Install and configure SQL Server 2000 Desktop Engine)).

Замечание

Установка Microsoft SQL Server 2000 Desktop Engine выполняется корректно на компьютер с операционными системами Windows 98 или Windows 2000. Все попытки авторов установить его на компьютер с Windows NT не увенчались успехом.

Создание проекта Access 2002

Создание проекта Access аналогично созданию базы данных Access. Поэтому мы опишем эту процедуру кратко (см. разд. "Создание новой базы данных" гл. 2). Существует три возможности создания проекта Access:

  • создать проект и сразу же связать его с существующей базой данных на сервере;
  • создать проект и одновременно создать новую базу данных на сервере;
  • создать проект, не связывая его пока с базой данных сервера.

В любом случае нужно сначала выполнить команду меню Файл, Создать (File, New), чтобы появилась область задач Создание файла (New File).

Создание проекта с использованием существующей базы данных

  1. Выберите в группе Создание (New) на Панели задач ярлык Проект (существующие данные) (Project (Existing Database)).
  2. В диалоговом окне Файл новой базы данных (File new database) введите имя файла проекта. Этот файл получает расширение adp. Нажмите кнопку Создать (Create). Появится диалоговое окно Data Link Properties, в котором нужно задать параметры соединения с сервером.
  3. Введите имя сервера, если требуется — имя и пароль, и выберите из списка нужную базу данных.

Замечание

Если вы хотите использовать SQL Server 2000 Desktop Engine, установленный локально, то поля в спецификации соединения должны быть заполнены так, как это представлено на рис. 17.9 (имя сервера — это имя вашего компьютера или специальный идентификатор local, и имя пользователя — за).

Рис. 17.9. Установление соединения с базой данных на сервере

Можно убедиться в правильности задания параметров соединения, нажав кнопку Test Connection. Нажмите кнопку ОК. Появится окно проекта Access 2000, очень похожее на окно обычной базы данных Access, однако список ярлыков на панели объектов будет несколько отличаться от традиционного списка объектов базы данных Access (рис. 17.10).

Рис. 17.10. Окно проекта Access 2002

Замечание

В качестве примера мы используем учебный проект NorthwindCS, входящий в комплект демонстрационных приложений Access 2002. При установке Access 2002 в папке SAMPLES размещается сценарий установки этой базы на Microsoft SQL Server — файл NorthwindCS. SQL. Этот файл содержит набор предложений SQL, которые создают на сервере необходимые таблицы, представления, хранимые процедуры и загружают данные. Этот сценарий можно выполнить на сервере с помощью утилиты SQL Enterprise Manager, которая включена в дистрибутивный пакет любой версии сервера, либо он выполняется автоматически при открытии файла NordwindCS.adp.

Еще одним примером может служить демонстрационная база данных Pabs, которая создается на SQL Server при его установке и содержит данные о книгах, их авторах и издателях.

Создание проекта с новой базой данных

Выберите ярлык Проект (новые данные) (Project (New Database)) в группе Создание (New) области задач Создание файла (New File). Откроется пустое окно базы данных и запустится Мастер баз данных Microsoft SQL Server (Microsoft SQL Server Database Wizard). В диалоговом окне мастера (рис. 17.11) нужно ввести имя сервера (если Access обнаруживает на локальном компьютере MSDE, то имя сервера автоматически подставляется), имя и пароль пользователя для регистрации на сервере и имя базы данных. После этого нажмите кнопку Далее (Next). Если все введено правильно, во втором диалоговом окне мастера нужно только нажать кнопку Готово (Finish). После этого появится окно с индикатором процесса создания новой базы "данных на сервере (рис. 17.12).

Рис. 17.11. Первое диалоговое окно Мастера баз данных Microsoft SQL Server

Рис. 17.12. Диалоговое окно с индикатором процесса создания базы данных на сервере

Замечание

Если база данных создается на SQL Server 6.5, то появятся дополнительные окна мастера, в которых нужно ввести названия и размеры устройств для базы данных и журнала транзакций, а также размеры базы данных и журнала транзакций.

При создании нового проекта можно не устанавливать соединение с базой данных на сервере сразу, а выполнить подключение позже. Для этого в диалоговом окне Data Link Properties необходимо нажать кнопку Отмена (Cancel). Присоединить базу данных на сервере к существующему проекту Access 2002 можно с помощью команды меню Файл, Подключение (File, Connection). Эту же команду можно использовать также для соединения проекта с другой базой данных. Чтобы подключить проект Access 2000 к базе данных на сервере, выберите команду меню Файл, Подключение (File, Connection) и введите необходимые параметры соединения в диалоговое окно Data Link Properties.

Открытие файла проекта

Файл проекта Access открывается аналогично файлу базы данных. Однако, в отличие от файла базы данных, файл проекта всегда открывается в монопольном режиме. Если вы пытаетесь открыть файл, который уже открыт другим пользователем, он откроется в режиме "только для чтения". Тем не менее и в этом режиме можно работать с объектами, размещенными на сервере (изменять, удалять, создавать новые объекты). Запрещается только модифицировать объекты, находящиеся в самом файле проекта. Для примера можно открыть файл NorthwindCS.adp, который размещается в папке Samples при установке Access 2002. При первом открытии данного файла Access может автоматически создать базу данных на SQL Server. Для этого используется файл сценария установки NorthwindCS.SQL, который находится в той же папке Samples. Сначала Access ищет настольную версию SQL Server на локальном компьютере, и если найдет, то спросит вас, хотите ли вы создать на нем новую базу данных "NorthwindCS". Если на локальном компьютере сервер не найден, то Access попросит ввести имя удаленного сервера, имя пользователя и пароль. После этого исполняется сценарий установки базы данных на соответствующем сервере, и файл проекта NorthwindCS.ADP соединяется с новой базой данных "NorthwindCS".

Окно проекта представлено выше, на рис. 17.10. В списке таблиц вы видите те же таблицы, что и в базе данных "Борей" (Northwind). Однако эти таблицы хранятся не в файле проекта, а на сервере. Хотя значок таблицы выглядит так, как если бы это были локальные таблицы. На панели объектов проекта Access 2002 по сравнению с базой данных Access 2002 появился новый ярлык — Схемы баз данных (Database Diagrams). Соответствующие новые объекты также размещены на сервере. Все остальные объекты (кроме страниц доступа к данным) находятся в файле проекта.

Работа с таблицами

Если вы откроете одну из таблиц, например "Товары" (Products), то увидите, что форма представления таблицы почти не изменилась (рис. 17.13). Появились только две дополнительные кнопки справа от кнопок навигации. Одна из них (крайняя справа) используется для задания максимального числа записей, которые будут передаваться с сервера. Это значение отображается в небольшом диалоговом окне. Вы можете ограничить передаваемое число записей, введя требуемое значение в текстовое поле Максимальное число записей (Max Record Count). Еще одна кнопка (вторая справа) подсвечивается красным цветом в процессе передачи записей. С помощью этой кнопки можно прервать процесс передачи записей с сервера. Заметим, что такой возможности явно не хватает в базе данных Access. Когда запрос выполняется достаточно долго, вы не можете прервать этот процесс.

Рис. 17,13. Отображение таблицы, хранящейся на SQL Server, в проекте Access 2000

Определение и изменение структуры таблицы

Открыв таблицу в режиме Конструктора, вы увидите, что способ отображения структуры таблицы незначительно отличается от принятого в режиме Конструктора таблиц базы данных Access (рис. 17.14). В верхней части Конструктора появились два новых столбца:

  • Длина (Length) — длина поля в байтах;
  • Разрешить Null (Allow Null) допустимо или нет значение NULL в данном поле.

Рис. 17.14. Таблица SQL Server в режиме Конструктора

Значение в столбце Длина (Lengh) может изменяться пользователем только для текстовых полей, в остальных случаях это значение устанавливается по умолчанию при выборе типа данных и не может быть изменено. Раскрывающийся список в столбце Тип данных (Data Type) содержит значения, отличающиеся от типов данных, принятых в базах данных Access. Это типы данных для Microsoft SQL Server.

Столбец Описание (Description) — эквивалент поля Примечание (Comment) в Access — отображается только для SQL Server 2000.

Остальные свойства полей таблицы отображаются на вкладке Столбцы (Columns) в нижней части окна Конструктора. Описание этих свойств приведено в табл. 17.1.

Таблица 17.1. Свойства полей

Свойство

Описание

Значения по умолчанию

Значение по

Значение, которое вставляется в поле, если

Пусто

умолчанию

пользователь ничего не ввел в него. Это


(Default Value)

значение игнорируется для полей, имею-



щих тип данных timestamp. Если значе-



ние по умолчанию не задано, в поле встав-



ляется значение Null


Число цифр

Максимальное количество цифр (для чи-

Зависит от типа дан-

(Precision)

словых полей), разрешенных для данного

ных. Например, для


поля

int равно 4

Точность (Scale)

Максимальное количество десятичных зна-

Как правило 0, для


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

типа данных money и smallmaney — 4


Precision


Идентификация

Свойство, которое обеспечивает автомати-

Нет (флажок сбро-

(Identity)

ческую генерацию уникальных значений в

шен)


этом поле при вставке новых записей


Начало иденти-

Значение, которое присваивается первой

1

фикации (Identity

записи в таблице


Seed)



Шаг идентифи-

Шаг изменения значений в поле. В каждой

1

кации (Identity

последующей записи значение поля увели-


Increment)

чивается на это число


IsRowGuid

Указывает, является ли данное поле гло-

Нет


бальным идентификатором. В отличие от



поля, которое имеет значение свойства



Идентификация (Identity) равным Да (Yes)



и которое однозначно идентифицирует ка-



ждую запись в таблице, SQL Server версии



7.0 и выше позволяет создать поле в таб-



лице, которое является глобальным иден-



тификатором, т. е. каждое значение этого



поля может быть уникальным в пределах


всей базы данных или даже во всех базах


данных на всех серверах сети.


 

Свойство

Описание

Значения по умолчанию


В этом случае значение данного поля должно быть Да (Yes), но тип данных может быть только uniqueidentif ier


Формула

(Formula)

Показывает формулу для вычисляемого столбца. Только для SQL Server 2000

Пусто

Сортировка

(Collation)

Для текстовых полей позволяет выбрать способ сортировки данных в поле. Только для SQL Server 2000

По умолчанию для базы данных

Формат (Format)

Позволяет задать формат отображения данных в поле. Только для SQL Server 2000

Пусто

Число десятичных знаков

(Decimal Places)

Для числовых полей определяет количество десятичных знаков при отображении данных в поле. Аналог соответствующего свойства в Access. Если установлено значение [Авто] (Auto), то количество отображаемых десятичных знаков определяется значением свойства Формат (Format)

Авто

Маска ввода

(Input Mask)

Аналог соответствующего свойства в Access. Только для SQL Server 2000

Пусто

Подпись

(Caption)

Определяет подпись для поля, которая появляется в формах. Только для SQL Server 2000

Пусто

Индексация

(Indexed)

Определяет, будет ли создаваться индекс для данного поля. Только для SQL Server 2000

Нет

Гиперссылка

(Hyperlink)

Указывает, будет ли значение этого поля интерпретироваться как гиперссылка. Только для SQL Server 2000

Нет

Режим IME (IME Mode)

Позволяет задать способ ввода данных в поле при использовании китайского, японского и некоторых других языков. Только для SQL Server 2000

Нет

Режим предложений IME (IME Sentence Mode)

Определяет режим преобразования данных при использовании китайского, японского и ряда других языков. Только для SQL Server 2000

Отсутствует

Почтовый адрес

(Postal Address)

Содержит имя элемента управления или поля, которое отображает почтовый адрес, соответствующий введенному в данное поле почтовому коду, либо штрих-код клиента, соответствующий введенному адресу. Только для SQL Server 2000

Пусто

Фуригана

(Furigana)

Содержит имя столбца таблицы, в котором может храниться Furigana-эквивалент введенного текста. Только для SQL Server 2000

Пусто

Теперь и в проекте Access таблицы могут иметь поля подстановки. Раскройте вкладку Поиск (Lookup) и вы увидите знакомые свойства, которые позволяют определить поле подстановки. Оно задается точно так же, как и в базе данных Access.

Типы данных, которые поддерживает SQL Server, приведены в табл. 17.2.

Таблица 17.2. Типы данных Microsoft SQL Server

Типы данных

Типы данных SQL Server

Примечания

Двоичные

binary[ (n) ] varbinary [ (n) ] .


Символьные

char[(n) ] varchar [ (n) ]



nchar nvarchar

Используются для поддержки Unicode-символов. Только в Microsoft SQL Server 7.0

Дата и время

clatetime smalldatetime

Нет отдельных типов для даты и времени

Числовые с фиксированной точностью (Exact numeric)

decimal [ (p[, s] ) ] numeric! (p[, s] ) ]

Не теряют точность за счет округления

Приблизительные число-вые (Approximate numeric)

floatf (n) ] real


Целые

int smallint tinyint

4 байта 2 байта 1 байт

Денежные

money

smallmoney


Специальные

bit timestamp


Текст

text ntext

Используются для поддержки UNICODE-символов. Только в Microsoft SQL Server 7.0

 

Типы данных

Типы данных SQL Server

Примечания

Графика

image


Курсор

cursor

Можно использовать для выходных параметров процедур Только в Microsoft SQL Server 7.0

Уникальный идентификатор

unique identifier

Соответствует QUID в модели СОМ. Только в Microsoft SQL Server 7.0

Пользовательские типы данных (user-defined datatypes)


Определяются на базе системных типов данных

Диалоговое окно свойств таблицы

Если щелкнуть правой кнопкой мыши в верхней части окна Конструктора и выбрать в контекстном меню команду Свойства (Properties), появится диалоговое окно Свойства (Properties), имеющее пять вкладок. На них перечисляется ряд свойств таблицы, которые можно просматривать и изменять. Наиболее важны три вкладки:

  • Связи (Relationships);
  • Индексы и ключи (Indexes/Keys);
  • Проверить ограничения (Check'Constraints).

На вкладке Связи (Relationships) отображаются и могут модифицироваться внешние ключи (foreign keys) таблицы, которые отражают ее связи с другими таблицами. Внешние ключи создаются автоматически в процессе задания связей между таблицами на схеме данных.

Поле со списком Выделенная связь (Selected relationship) содержит список связей таблицы. Выбрав из этого списка значение, в остальных полях можно увидеть описание выбранной связи.

Поле Имя связи (Relationship name) показывает имя данной связи.

Таблица из двух столбцов отображает две стороны связи: слева — имя таблицы и имя поля, которое является первичным ключом; справа — имя таблицы и имя поля, которое является внешним ключом, т. е. содержит значения первичного ключа другой таблицы. Эти таблицы связаны по полю "КодТипа" (Categoryld). Это поле в таблице "Типы" является первичным ключом, а в таблице "Товары" — внешним. Имя связи состоит из трех частей и формируется следующим образом: первым пишется имя таблицы, включающей внешний ключ, затем имя таблицы, содержащей первичный ключ, и перед ними ставится префикс. Префикс зависит от того, на какой стороне оказывается таблица, связи которой мы описываем: если она содержит внешний ключ, то пишется префикс FK_, если она содержит первичный ключ, то пишется префикс РК_. В данном примере получается имя FK_Products_Categories, т. к. мы смотрим связи таблицы "Товары" (Products). Перед именем связи присутствует значок. Значок "бесконечность" указывает, что данная таблица находится в связи на стороне "многие", а значок "ключ" означает, что данная таблица находится на стороне "один". Имя связи формируется автоматически, однако оно может быть откорректировано в поле Имя связи (Relationship name).

Для выбранной связи можно изменить поле, которое будет содержать вторичный ключ, выбрав из списка полей таблицы нужное поле. Изменить поле первичного ключа нельзя, это можно сделать только на вкладке Индексы и ключи (Indexes/Keys).

Флажки в нижней части вкладки имеют следующие значения.

  • Флажок Проверить имеющиеся данные при создании (Check existing data on creation), будучи установленным, гарантирует, что для всех данных, которые были введены в таблицу до того, как наложили данное ограничение, будет выполнена проверка, удовлетворяют ли они этому ограничению.
  • Флажок Применить связь при репликации (Enforce constraint for r