ЧАСТЬ 2 баз

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

зультатов помешается в кэш либо на клиенте, либо на сервере. Но для приложения, в результаты не мо-

гут на сервере, поскольку сервер разрывает соедине-

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

туна) также должны размещаться на клиентском компьютере. А но-добную конфигурацию уже никак нельзя назвать тонким клиентом.

В технологии ActiveX Data Objects (ADO) для таких ситуаций используется механизм, который называется Перед как отправить запрос серверу приложение может задать число записей. возвращаемых за один раз. Для этого используется свойство PageSize объекта Recordset. Если задать число записей равным 15, то сервер будет возвращать записи партиями (страницами) по 15 записей за один раз. Свойства o/w/c Page позволяет указать, какую именно страницу следует а свойство возвращает общее число страниц. Это похоже на возможность выбрать первые N записей из отсортированного списка, предоставляемую выражением ТОР N стандартного SQL-онератора SELECT. Различие в следующем - в технологии ActiveX можно выбрать и отправить пользователю не тп 11, -ко самые верхние N записей, но и N записей из середины результирующего набора.

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

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

смотреть следующие гь записей!

Проблему сложного запроса в приложении, для

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

ГЛАВА 10 Схема бэш димных

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

Однако, несмотря на все преимущества толстого клиента, эта архитектура гораздо используется в интранет-приложениях, чем в Интернет-среде, не исключая и Microsoft Distributed Networked Architecture. Причина здесь одна; большинство пользователей не хотят загружать на свой компьютер компоненты кода.

Но когда приложение доступно всем пользователям одновремен-но отивленис: возникает гораздо реже. К тому же, скорее всего, информация, доступная пользователям при помощи этого приложе-настолько ценна для них, что они согласятся терпеть некоторые

неудобства.

Компоненты схемы базы данных

После того как вы создали концептуальную модель данных и выбрали системную архитектуру, у вас есть вся необходимая информация

для создания схемы базы данных.

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

Для системы, реализуемой средствами Access, схема базы данных содержит определения всех таблиц, запросов и связей, но не ния форм, отчетов и программных компонентов, даже если последние хранятся в файле

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

Таблицы и связи

Определение физических таблиц в схеме базы данных можно получить непосредственно из концептуальной модели данных. Сущности

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

ЧАСТЬ 2

Офаничения

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

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

Большинство ограничений, определенных на уровне домена и атрибутов, станут ограничениями на уровне нолей в схеме базы данных (в Access это, как правило, правила проверки правильности Если вы рещили создавать базу данных при ]10мощы операторов SQL, а не \>л<- или пользовательского интерфейса Access, воспользуйтесь ограничением CHECK, которое поддерживают и Access, и SQL Server.

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

целостности сущности, позволяющие уникально идентифицировать каждый сущности, реализуют, определяя первичный ключ

для каждой таблицы.

Если вы реализуете базу данных средствами SQL Server или механизма СУБД Microsoft Jet, может оказаться, что некоторые ограничения, в концептуальной модели данных, невозможно реализовать в определении таблицы. SQL Server позволяет задать до-нолнительные ограничения при помощи триггеров. Но механизм СУБД Microsoft Jet не поддерживает триггеры, и поэтому такие ограничения следует реализовать в приложении.

Связи

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