ЧАСТЬ 2 Проектирование рит)цтжнык систем oaq данных

Например, создав компонент ствляющий обмен данными с SQL Server 7.0 нр ощи ADO 2.0, вы сможете использовать его в других системах, которые будете разрабатывать в дальнейшем. При этом вам не потребуется вносить никаких если только вы

не решите использовать другой механизм СУБД или изменить обьек-тную модель.

Программная архитектура и схема базы данных

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

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

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

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

ошибки.

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

Во-Бторых, ожидание, нокныс отправляются для проверки их механизмом СУБД, затем выполняется проверка и выдастся ответ. может существенно снизить производительность системы. Как правило, проверка правильности ввода данных выполняется нрактичес-ки сразу же, после того как пользователь введет очередное значение.

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

Иногда (например, когда вводимое значение должно содержать только а не буквы) проверка выполняется сразу же, как только пользователь введет очередной символ с клавиатуры. В других случаях - лишь после того как данные введены в поле или в несколько, полей: например, если нужно проверить, что дата, введенная в поле DesiredDeliveryDate (Планируемая дата доставки), не предшествует дате, введенной в поле OnlerDah-{Лата заказа).

Даже при работе с приложением, установленным на выделенном компьютере (на том же самом, где работает СУБД), отправка набора данных механизму СУБД после ввода каждого символа или заполнения очередного поля приведет к значительному снижению производительности. Если же приложение подключается к базе данных через локальную сеть (не говоря уже об удаленном доступе к базе данных через глобальную сеть или Интернет), весьма вероятно, что время отклика системы окажется столь длительным, что система не будет оправдывать себя.

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

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

ных относительно неизменны, вы, в принципе, можете реализовать проверку данных только на уровне приложения, полностью исключив проверки на уровне механизма СУБД. предотвратит двойную ра-

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

Допустим, впоследствии для работы с той же базой данных будет

создано другое приложение - тогда база лишится механизмов, гарантирующих целостность данных. И конечно, всегда остается вероятность, что пользователи будут работать с базой данных не только при помощи созданного вами клиентского приложения, а выполнять произвольные запросы посредством Microsoft Access или SQL Server Enterprise Manager. Безусловно, можно попытаться создать строгую модель защиты данных, запретив любые изменения данных иным способом, кроме как из созданного вами приложения. Но тогда будут существенно ограничены возможности доступа к данным.

ЧАСТЬ 2 шт релвцйрннь[А систем баз даннык

Итак, реализуйте адства проверки данных и в клиентском нри-ложении, и в схеме базы Microsoft Access делает это автома-

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

В версиях Microsoft Access более ранних, чем Access 2000, существует проблема синхронизации правил проверки в клиентской части и схеме базы данных. Включив поле в связанную форму, а затем изменив правило проверки правильности ввода данных для этого ноля на уровне таблицы, вы обнаружите, что соответствующие изменения не распространились таниую форму автоматически. В Microsoft Access 2000 эта проблема устранена, а вот в Visual Basic она все еще существует, даже в последних версиях. Допустим, имеются ссылки на одно из полей таблицы из нескольких форм (или, вернее, из нескольких компонентов уровня интерфейса данных, которые используются в разных формах). При каждом изменении правил проверки для этого поля придется обновлять соответствующие правила во всех формах или компонентах уровня интерфейса данных, которые содержат ссылки на это поле.

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

скольку все правила в одном месте.

правил проверки из механизма СУБД выполняется или при первом запуске приложения, или при загрузке формы, или перед обновлением каждой записи. Я считаю оптимальным второй вариант. Если выполнять проверку нр утюжения, то одновременно с нужной информацией будет загружаться и много лишней, относящейся к формам, которые пользователю никогда не понадобятся. Загрузка правил проверки перед обновлением каждой записи, конечно, полностью гарантирует, что используемые правила проверки не устарели. Но при этом приложение обращается к схеме базы данных столько раз, сколько к самим записям. Лично я не сталкивалась на практике с системами, в которых правила проверки изменялись бы настолько часто, чтобы приходилось загружать их перед обновлением каждой лшиси.

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