Конспект лекций ТПСЭК

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ

Кафедра «Программного обеспечения интеллектуальных систем»

КОНСПЕКТ ЛЕКЦИЙ

ПО ДИСЦИПЛИНЕ "ТЕХНЛОГИИ

ПРОЕКТИРОВАНИЯ СИСТЕМ ЭЛЕКТРОННОЙ

КОММЕРЦИИ"

Донецк 2013

2

1 ОБЩИЕ СВЕДЕНИЯ 1.1 Что такое база данных За прошедшие годы было сделано немало попыток дать определение понятию база данных. Для наших целей

вполне подойдет следующее: база данных — это совокупность данных, организованная с определенной целью. Здесь слово организованная означает, что указанная совокупность включает данные, которые сохра-няются, имеют определенный формат (отформатированы), к ним может быть обеспечен доступ (доступны), и они могут быть представлены потребителю информации в приемлемом виде (репрезентативны). Упоминанием в определении цели подчеркивается, что состав данных должен соответствовать некоторой задаче (или классу задач): с одной стороны, в базе не должны содержаться данные, не имеющие отношения к задаче, а с другой — должна содержаться вся информация, касающаяся задачи. Прекрасным и понятным примером базы данных может служить телефонный справочник. Он содержит данные, имеющие прямое отношение к цели его существования (в данном случае — имена абонентов), которые открывают доступ к номеру телефона. В справочнике отсутствует избыточная информация, скажем цвет аппарата абонента. То есть в этой простейшей базе содержится информация, непосредственно связанная с целью ее создания. Наиболее часто цель существования базы данных связана с деловой сферой, но в ней может содержаться и научная, военная и прочая информация, в ряде случаев не имеющая отношения к сфере бизнеса. Существуют деловые, научные, военные и прочие базы данных, причем список возможных областей человеческой деятельности, в которых находят применение данные, организованные таким образом, может быть продолжен практически неограниченно. Кроме разделения баз данных, основанного на областях их применения, можно предложить и другой подход, взяв за основу форматы включенной в них информации. Помимо текстовой и числовой это могут быть изображения, различного рода графики и схемы, аудио- и видеоинформация. В последнее время все чаще речь идет о состав-ных документах, которые представляют собой связную совокупность различных видов информации.

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

В прежние времена разработчики программ для автоматизированной обработки данных часто встречались с ситуацией, когда нужно было сохранять данные между прогонами программы. Эта процедура получила наименование сохранения с восстановлением (persistent storage). To есть речь идет о том, что данные должны быть сохранены в том виде, в каком они оказались на момент завершения одного прогона программы, а затем в начале следующего прогона восстановлены, чтобы программа продолжала их обрабатывать так, будто перерыва не было. Именно эта потребность и привела со временем к появлению баз данных, о которых мы сейчас говорим. Вторая объективная потребность, которая дала дополнительный толчок этому процессу, — необходимость в накоплении и сохранении данных. Хотя в большинстве случаев для этого оказывается вполне достаточно иерархической структуры файлов и каталогов, а также возможностей системы их обслуживания, включая индексацию, базы данных открывают в этой области такие перспективы, которые недоступны системам управления файлами. Современные базы данных, как правило, служат для сохранения и обработки информации, касающейся различных аспектов деятельности как подразделений (достаточно крупных или мелких, состоящих всего из нескольких человек), так и организаций. Таким образом, мы можем использовать термин база данных уровня предприятия (enterprise-wide database), когда речь идет об информации, охватывающей деятельность предприятия в целом, или база данных уровня подразделения (department-wide database), если соответствующая информация не выходит за рамки его деятельности, или база данных уровня рабочей группы (workgroup database) для самых мелких коллективов. Наиболее распространены базы данных двух последних уровней — уровня подразделения и уровня рабочей группы.

Иногда можно встретить базы данных уровня предприятия, например ведомости на выдачу зарплаты или штатное расписание, но при этом весьма небольшого объема. Фактически, когда базы данных отдельных подразделений сливаются (интегрируются) в одну большую базу, есть смысл говорить о банке данных (data warehouse — DW). Базы данных меньшего объема, которые служат источником информации для баз более крупных, в последнее время довольно часто называются операционными базами данных (operational databases). Однако в этом нет ничего нового. То, что сейчас называется операционной базой, прежде было известно под именем продукционной базы данных (production database), поскольку в рамках такой базы продуцировались

3

(подготавливались) данные, которые затем включались в более крупную базу. В контексте формирования DW можно встретить упоминание о продукционной базе как об операционной, а иногда — как о накопителе данных (data store). С развитием сети Internet базы данных и банки данных все чаще становятся конечными пунктами маршрута поиска информации, который начинается от Web-броузера.

Когда база данных рабочей группы интегрируется для обслуживания потребностей более высокого уровня — уровня подразделения, то, что получается в результате, часто называются кладовой данных (data mart, DM). Фактически DM является банком данных уровня подразделения. У вас не должен вызвать удивление тот факт, что термин банк данных, как и термин база данных, может иметь множество толкований. Тем не менее, когда несколько небольших по масштабам баз данных объединяются в одну большую, которая может обслуживать более широкий круг запросов, чему соответствует более высокий уровень организационной структуры, результирующая объединенная база может рассматриваться как хранилище информации при том, однако, условии, что в ней оказываются данные, накопленные за достаточно длительный период времени, которые могут служить основой для принятия определенных управленческих решений, а сформировавшаяся в результате информационная среда позволяет обобщать данные и обеспечивает защиту первичных данных от искажения или модификации. Такое хранилище информации служит как бы резервуаром, в который сливаются потоки от множества питающих его продукционных баз.

Возможен и другой вариант: БД просто увеличивается в объеме, поскольку в ней оседают данные за довольно продолжительное время, и в результате она становится чем-то вроде исторического архива. Примером, может служить накопление в электронном виде результатов переписей. Еще одной причиной чисто количественного роста объема БД может служить сам тип накапливаемой информации (например, если БД включает изображения) или частота ее поступления. Примером здесь может служить накопление данных спутниковой телеметрии. За такими БД закрепилось название сверхбольшие БД (very large database — VLDB).

Совершенно естественно, что со временем, по мере повышения плотности хранения информации и удешевления необходимых для этого носителей, совершенствования методов и средств распараллеливания обработки на небольших машинах, развития технологии RAID (RAID — аббревиатура от Redundant Array of Inexpensive Disks, избыточный массив недорогих дисков) и программных комплексов для работы с большими массивами данных, претерпевали изменения и представления о масштабах границы, отделяющей сверхбольшие БД от прочих.

На сегодняшний день эта граница лежит где-то в пределах 100 Гбайт- БД большего объема уже может претендовать на то, чтобы считаться сверхбольшой. А всего-то несколько лет назад казалось, что мыслимый предел наращивания объема — это 10 Гбайт.

1.2 Понятие о СУБД

Система управления базой данных — СУБД (Database Management System — DBMS) — это программный комплекс, обеспечивающий функционирование БД. Она играет роль кладовщика при данных, отвечает за их сохранность, безопасность, целостность, взаимное соответствие и обеспечивает доступ пользователей к данным. В ведении СУБД находится словарь данных (data dictionary), который иногда называют каталогом системы (system catalog). В этом словаре содержатся сведения обо всем, что хранится в БД, — наименованиях, структуре, размещении и типах. Сведения такого характера представляют собой метаданные (metadata), т.е. данные о данных. Весь жизненный путь некоторого фрагмента данных — от создания до уничтожения — отражается в словаре данных так же, как и информация о его логической и физической структуре. Администратор БД должен поддерживать тесную связь со словарем данных, который будет служить ему все время существования базы. 1.3 Безопасность данных

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

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

4

1.4 Целостность данных Под термином целостность (integrity) понимается взаимная согласованность отдельных фрагментов данных

и их корректность. Согласованность (consistency) означает, что все порции данных в БД должны быть единообразно смоделированы и включены в систему. Квалифицировать данные как корректные можно в том случае, если они достоверны, точны и значимы.

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

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

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

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

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

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

Выше уже упоминалось об одном из аспектов технологии параллельного доступа — блокировке (locking). Вообще говоря, чем более мелкий фрагмент данных может быть адресован механизмом блокировки, тем лучше обеспечивается параллелизм при многопользовательском доступе к БД — т.е. тем больше пользователей могут с ней работать, не мешая друг другу.

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

Таким образом, обеспечение параллельного доступа и сохранение целостности — две очень тесно связанные между собой функции СУБД. Фактически, это две стороны одной медали. В основе механизма реализации этих функций в СУБД лежит понятие транзакции (transaction). Когда пользователь пытается просмотреть некоторые данные или изменить их, он по отношению к БД выполняет транзакцию.

1.5 Понятие транзакции Одним из ключевых компонентов СУБД является администратор транзакций (transaction manager), един-

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

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

5

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

Транзакция представляет собой элементарную непрерываемую операцию в механизме параллельного доступа и в функционировании СУБД в целом. Не может быть ничего более мелкого в плане выполняемых операций, чем транзакция. То есть никакого постороннего вмешательства в данные после запуска транзакции на выполнение быть не может. Все транзакции должны быть атомарными, независимо от того, успешно или нет завершается та или иная конкретная процедура. В той незамутненной картине мироздания, которая существовала до того как в XX веке физики не превратили ее в неизвестно что, атом считался наименьшей неделимой частицей материи. Вот так же и транзакция является простейшей непрерываемой операцией в процессе функционирования СУБД. Транзакция, которая дала ожидаемый результат, называется свершившейся, принятой (committed), в противном же случае — отвергнутой, аннулированной (rolled back).

СУБД организует обновление данных в БД, используя транзакции в качестве логических единиц работы. Нормальное завершение операции, явное прерывание пользователем уже запущенной операции или неожиданное се прерывание вследствие аппаратного сбоя или по такой-либо другой причине, выходящей за рамки нормального функционирования системы, — все эти события побуждают СУБД вернуться к множеству сформированных заранее копий порций данных и либо обновить их, если транзакция совершилась, либо восстановить данные в прежнем виде, аннулировав все незавершенные изменения. Для того чтобы такое ан-нулирование было возможно, а также для повторения операции изменения данных, прерванной на полдороги ввиду экстраординарных обстоятельств, СУБД ведет журнал транзакций (transaction log). Фактически операция аннулирования (rolling back) — это привычная многим операция отката (undo), а восстановление процедуры после прерывания (rolling forward) — операция повторения (redo). К последней приходится обра-щаться в том случае, когда принятая транзакция не завершилась перезаписью обновленных данных из памяти на диск вследствие аппаратного сбоя. В таких условиях СУБД повторяет всю транзакцию. Из всего сказанного со всей очевидностью следует, что именно атомарный, неделимый характер транзакции является ключевым моментом возможного ее аннулирования или восстановления при необходимости.

1.6 Общение пользователя с БД Совершенно очевидно, что поддержка живого общения пользователя с БД, является одной из важнейших

функций СУБД. Каким образом может пользователь обратиться к БД? Посредством языка доступа (access language) или языка запросов (query language). В последние годы доминирующее положение среди подобного класса языков занял SQL — Structured Query Language (язык структурированных запросов). Особенно это касается наиболее распространенного класса СУБД — систем управления реляционными БД (RDBMS — Relational Database Management System), о которых речь пойдет в дальнейшем. Обращение пользователя к БД так или иначе осуществляется через СУБД; именно она воспринимает операторы языка запросов — SQL или ему подобного. Администратор БД использует язык запросов для формирования и обслуживания БД, а пользователь — для доступа к данным, их просмотра и модификации.

6

2 АРХИТЕКТУРЫ СОВРЕМЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ ЭЛЕКТРОННОЙ КОМЕРЦИИ

2.1 Введение

(По материалам статьи Михалев О. В. " Выбор платформы и цена системы" в журнале

Компьютеры + Программы №5(20), 1995)

2.1.1 Вступление На примере банковских приложений анализируется технические и ценовые аспекты, на которые

следует обращать внимание при выборе проекта системы в архитектуре клиент/сервер. Концепция клиент/сервер лежит в русле новейших тенденций в развитии объектно-ориентированного подхода

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

Рассмотрим технические и ценовые аспекты, на которые следует обращать внимание при выборе проекта системы в архитектуре клиент/сервер.

2.1.2 Выбор платформы Не секрет, что, приступая к работе над проектом в архитектуре клиент/сервер и выбирая для него платформу,

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

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

Это вполне естественно, поскольку многие эксплуатационные характеристики прикладных систем

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

7

крайней мере сегодня, менее значимыми. 2.1.2 Производительность Среди многочисленных функциональных характеристик СУБД в архитектуре клиент/сервер

производительность, пожалуй, самая важная. В связи с этим отметим, что для банков самыми важными в оценке производительности являются результаты оперативной обработки транзакций — OLTP (on-line transaction processing). Лучшие показатели таких тестов имеют системы, специально ориентированные на обработку транзакций в этом режиме, — Oracle фирмы Oracle и SQL Server фирмы Sybase.

С точки зрения производительности, наибольшее значение в современных СУБД имеют: — параллельная обработка данных с использованием многопотоковой (multithread) архитектуры сервера БД

и параллельного выполнения запросов; эти возможности становятся сейчас весьма актуальными в связи с ростом популярности многопроцессорных систем;

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

— реализация хранимых процедур и триггеров; сохраняя часто выполняемые наборы операторов на сервере, можно добиться существенного увеличения производительности;

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

— возможность СУБД формировать отчеты на сервере; — поддержка кластеризованной индексации, благодаря которой оказывается возможным располагать

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

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

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

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

8

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

2.1.4 Поддержка распределенных баз данных Современные СУБД обладают разными возможностями поддержки распределенных баз данных. Однако, на

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

Такой подход имеет определенные преимущества и представляется более реалистичным. Средства тиражирования данных не предъявляют высоких требований к линиям связи и устойчиво работают, даже если связь не поддерживается стабильно 24 часа в сутки. Последнее объясняется просто: при разрыве соединения, например, между центральным офисом и филиалом, работа не прерывается; все изменения накапливаются в узлах базы данных, а после восстановления связи в автоматическом режиме распространяются по сети и фиксируются во всех соответствующих узлах. В физически распределенной базе данных при нарушениях в каналах связи ни одно обновление данных не может завершиться. До восстановления связи не могут работать ни пользователи в центре, ни пользователи в филиалах.

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

Другой довод заключается в дороговизне ведения полностью распределенных баз донных, что объясняется большими накладными расходам, которые в основном складываются из расходов на выполнение распределенных транзакций. Как отмечают ведущие американские разработчики СУБД, эти расходы остаются непомерно большими и при повышении качества телекоммуникаций. Более того, их величину даже невозможно предсказать, поскольку трафик в полностью распределенных системах трудно прогнозировать. Тиражирование же данных не требует больших накладных расходов, так как в этом случае процедуры внесения изменений в БД и подтверждения их выполнения относительно просты. И, наконец, еще одно соображение. Отечественные разработчики финансовых приложений только начинают приобретать опыт создания систем с полностью распределенной базой данных. К сожалению, и о масштабировании данных мы пока знаем не так много, кик хотелось бы. Однако, возможно, именно за этим способом будущее. Ведь недаром же большинство фирм-разработчиков современных СУБД предоставляют пользователям серверы-репликаторы (replication-server), позволяющие копировать и тиражировать данные.

2.1.5 Стратеги автоматизации банка и цена проекта Переход к архитектуре клиент/сервер открывает перед банком широкие перспективы развития за счет

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

9

Однако переход к архитектуре клиент/сервер требует затрат, и значительных. Если несколько упростить ситуацию и пренебречь такими важными составляющими проекта, как обследование банка, внедрение системы и переобучение персонала, то цена проекта в архитектуре клиент/сервер будет складываться из четырех ком-понентов: затрат но приобретение нового или развитие имеющегося оборудования; стоимости современной СУБД-платформы прикладной банковской системы; стоимости инструментария (средств администрирования, обеспечения взаимодействия с другими платформами, средств разработки приложений, а возможно, и средств планирования и проектирования системы, в том числе CASE-продуктов); и, наконец, цены прикладного комплекса для автоматизации банка. Рассмотрим некоторые возможности выбора, которые следует иметь в виду при разработке проекта создания системы в архитектуре клиент/сервер, и факторы, влияющие на его стоимость.

2.1.6 О цене системно-технического комплекса В СНГ в силу некоторых исторических причин наиболее распространенным средством для решения задачи

коллективного пользования распределенными ресурсами являются локальные сети но базе персональных компьютеров. Поэтому можно ожидать, что из всего многообразия компьютерных платформ, предлагаемых для построения систем в архитектуре клиент/ сервер, основными будут следующие два варианта: локальная сеть но базе ПК с микропроцессором семейства Intel, работающая пол управлением ОС Unix, NetWare или Winndows NT, и локальная сеть на базе ПК с использованием бизнес-серверов и рабочих станций на RISC-процессорах, работающая под управлением ОС Unix.

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

Затраты на приобретение общесистемного программного обеспечения и СУБД, в первую очередь, существенно зависят от лицензионной политики производящих фирм. Ток, например, существуют два варианта современной СУБД SQL Server, используемой для разработки финансовых приложений в архитектуре клиент/сервер: Microsoft SQL Server для операционной системы Windows NT и Sybase SQL Server для ОС Unix. Первый продукт ориентирован на машины класса Pentium, второй — на Unix-серверы фирм Hewlett-Packard, Sun и IBM. Среди них можно выбрать модели, цена которых будет не намного выше суперсерверов на базе процессоров фирмы Intel. Однако, если в первом случае системно-технический комплекс, необходимый для эксплуатации банковской системы, может стоить порядка $10 000, то во втором случае затраты могут оказаться на порядок выше. Объясняется это различиями в лицензионной политике Microsoft и Sybase. Последняя ориентируется на крупных и состоятельных клиентов, которым требуется не коробка с документацией и дискетами, а комплекс услуг по внедрению передовой технологии. Вследствие этого СУБД фирмы Sybase, предназначенная для работы но машинах класса Sun/HP, реально обходится в десятки тысяч долларов, что существенно выше затрат на оборудование.

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

2.1.7 Выбор инструментария Набор необходимых инструментальных средств определяется принятой банком стратегией автоматизации. В

простейшем случае, когда руководство банка не планирует развивать систему силами своих специалистов и речь идет только об эксплуатации одной из готовых систем (т.е. предполагается, что дорабатывать систему будет фирма-разработчик), банку потребуется приобрести только средства администрирования и, возможно (в зависимости от политики производителя СУБД), лицензии на рабочие места. Так, корпорация Microsoft не включает в стоимость своей СУБД SQL Server плату за использование библиотеки доступа к SQL Server, a вот фирма Sybase предлагает покупать лицензию на право пользования такой библиотекой (QpenClient) на каждой рабочей станции.

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

Для специалистов банка, где принято решение о доработке приобретаемой системы, потребуется набор

10

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

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

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

Кроме того, через некоторое время банки могут столкнуться с необходимостью интегрировать отдельные элементы банковской системы, скажем операционный день, процессинговый центр и систему валютного ди-линга, реализованные на разных СУБД (например Sybase, ORACLE и Ingres). Но, как уже отмечалось, фирменный инструментарий ориентирован на роботу с одной СУБД, и поэтому для доступа к другим базам потребуется приобретать специальные средства.

Полезно иметь в виду, что покупка инструментария у фирмы-производителя СУБД — не единственная возможность. Необходимые продукты выпускают сегодня и третьи фирмы, причем, покупая продукты разных производителей (в том числе и современных СУБД), можно сформировать набор действительно качественных инструментальных средств. Главное требование здесь — совместимость.

На рынке имеются такие средства: например, CASE-продукты ERWin фирмы Logic Works и System Architect фирмы Pоpkin Software & Systems совместимы с популярными средствами разработки PowerBuilder фирмы Powersoft и SQLWindows фирмы Gupta, Delphi фирмы Borland. Средство разработки приложений BuildMomentum фирмы Sybase, позволит работать с продуктами, выполненными но платформе любой СУБД, которая входит в большую четверку—Oracle, Informix, Ingres и Sybase.

А как относиться к собственному инструментарию фирмы, у которой вы приобретаете прикладную систему? Очевидны его недостатки: с точки зрения банка, система, построенная на нестандартном инструментарии, может быть менее открытой; из соображений повышения эффективности в нем могут быть реализованы решения, затрудняющие перенос систем но другие платформы; такой инструментарий, как правило, не оформляется как программный продукт, и кроме того, он увеличивает стоимость системы.

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

2.1.8 Стоимость прикладной системы Не менее ощутимо, чем инструментальные средства, поднимает цену банковской системы, выполненной в

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

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

11

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

для ее разработки общесистемного ПО. Если для освоения СУБД FoxPro или Clipper профессиональному программисту требуется несколько месяцев, то на изучение таких сложных систем, какими являются СУБД в архитектуре клиент/сервер, нужно несколько лет. Иначе говоря, создание систем в новой архитектуре под силу только команде очень квалифицированных разработчиков.

2.1.9 Преимущества архитектуры клиент/сервер

Преимущества архитектуры клиент/сервер 1. Высокая производительность Вся обработка производится на сервере БД. Производительность не зависит от пропускной способности локальной сети. 2. Надежность Изменения данных производятся только сервером. Обеспечивается логическая целостность БД. 3. Мобильность Возможен перенос сервере БД на различные платформы. 4. Открытость Доступ к данным осуществляется средствами языка SQL Возможно использование различного ПО для доступа к базе данных.

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

(По мотивам статьи "Архитектура распределенных приложений" по материалам Gupto Corp., Компьютеры + Программы №5(20), 1995)

2.2.1 Три типа архитектуры клиент/сервер Все приложения клиент/сервер имеют одну общую особенность: одно часть процесса обработки информации

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

• интерфейс пользователя; • прикладная логика; • доступ к БД. В монолитной архитектуре (в отличие от архитектуры клиент/сервер) все три части выполняются на одном

компьютере (см. рис. 1). Рассмотрим, каким образом происходит распределение указанных компонентов между клиентом и сервером, и кратко охарактеризуем особенности получаемых при этом архитектур.

12

2.2.2 Архитектура Screen Scraper В архитектуре Screen Scraper (дословный перевод «экранный скребок») интерфейс пользователя реализуется

на компьютере клиента, в то время как работа прикладной логики и средств доступа к базе данных вынесена на сервер (см. рис. 2). Обычно этот тип архитектуры используется для построения нового графического интерфейса пользователя в существующих или «наследуемых» системах.

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

2.2.3 Архитектура удаленной БД (Remote Database) В этой архитектуре (см. рис. 3) интерфейс пользователя и прикладная логика реализованы на компьютере

клиента, а доступ к БД выполняется средствами сервера. Этот тип приложений наиболее распространен, он составляет около 95% всех приложений клиент/сервер. Данная архитектура предъявляет повышенные требования к мощности рабочей станции клиента. Своей популярностью она обязана языку SQL, который применяется в качестве языка доступа к удаленной БД. При этом используются два вида интерфейса с БД:

— Встроенный интерфейс. В программу клиента (например, на С или Cobol) вставляются операторы препроцессора. Ими могут быть операторы SQL или другие команды, которые препроцессор БД использует для создания специального прикладного протокола между клиентом и сервером.

— Интерфейс вызова функций. SOL специфицируется внутри функций, которые встроены в программу клиента. Например, спецификация ODBC фирмы Microsoft является универсальным промежуточным интерфейсом между приложениями клиента в среде MS-Windows и реляционными БД.

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

прикладной логики разделено между клиентом и сервером (см. рис. 4). Логика, которая обрабатывается на машине клиента, называется прикладной логикой клиента (client application logic); логика, обрабатываемая на сервер-машине, называется прикладной логикой сервера (server application logic).

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

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

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

2.2.5 Достоинства и недостатки архитектуры распределенных приложений Архитектура распределенных приложений обладает следующими достоинствами: Изоляция. Распределенные приложения воплощают в себе одно из свойств объектной ориентации —

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

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

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

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

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

13

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

2.3 Архитектура клиент/сервер

(По материалам статьи Сергея Высоцкого " Архитектура клиент/сервер" в журнале Компьютерное обозрение, №20(44)-№22(46), 1996)

2.3.1 Введение Почему архитектура клиент-сервер завоевала такую популярность у корпоративных пользователей? Почему

ей уделяется такое внимание в прессе? Под термином «корпоративный пользователь» наши соотечественники, как правило, понимают сотрудника

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

Поясним некоторые термины. - «Бизнес-процесс» — процесс реализации бизнес-плана предприятия, т. е. производство + управление +

планирование + сбыт + анализ + ... - «Бизнес-подразделение» — структурная единица организации, выполняющая определенный круг работ в

рамках бизнес-процесса. Например, плановый отдел. - «Корпоративная система» — система организации, управления и контроля за ходом бизнес-процесса.

14

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

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

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

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

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

Эффект Некоторое повышение производительности труда персонала. Появление дополнительных возможностей для анализа и систематизации данных. Электронное представление данных, возможность тиражирования, дублирования и т. д. (косвенные эффекты).

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

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

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

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

· необходимо постоянно печатать (или передавать на магнитных носителях, что не намного эффективнее) выходные документы для передачи в другие подразделения;

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

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

15

на складе, такая корпоративная система никуда не годится. Резюме. Использование персональных компьютеров для решения корпоративных задач на автономных

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

2.3.3 Локальные сети — решение найдено? Естественным способом объединения подразделений и отдельных сотрудников в единое информационное

пространство является локальная вычислительная сеть (ЛВС). Это решает проблему актуализации данных и обмена документами между подразделениями предприятия (документы «сами доходят» до адресатов).

До последнего времени на отечественных предприятиях применяется сетевая организация бизнес-процесса на основе сетевой операционной системы Novell Netware 3.11, 3.12, 4.1. Эта схема обработки данных называется FS-моделью доступа к информационным ресурсам. Она подразумевает наличие в сети одного или нескольких компьютеров, которые предоставляют услуги по обработке файлов другим пользователям сети. Компьютеры, предоставляющие файлы, называются файл-серверами, компьютеры, пользующиеся этими ресурсами, — клиентскими машинами, или рабочими станциями. Единицей информации в такой модели является файл. Эта модель исключительно популярна среди разработчиков, использующих такие СУБД, как FoxPro, Clipper, Clarion, Paradox, dBase.

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

Проблема решена? Установим в нашей организации персональные компьютеры в бухгалтерии, на складе и в отделе сбыта.

Объединим их в локальную сеть. Рассмотрим эффективность вложения средств. Затраты

Установка (+ затраты на установку сети). Обучение персонала (+ затраты на обучение работе в сети). Установка программного обеспечения (+ затраты на ЛВС). Эксплуатация (+ нужен администратор ЛВС).

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

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

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

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

Наличие ЛВС является необходимым, но недостаточным условием для существования корпоративной

16

системы обработки информации на базе ПК. Приобретенное оборудование еще не является залогом его эффективного использования. ЛВС — только средство, но не цель. Точно так же, как пользователь покупает компьютер не ради компьютера, а ради решения с его помощью конкретных задач, сеть, устанавливаемая в рамках корпорации, должна служить средством для решения вполне определенных корпоративных проблем. В действительности, часто «телега ставится впереди лошади». Сначала руководство осознает, что эффективность работы бизнес-подразделений чрезвычайно низка, затем принимает решение об установке ЛВС и только после этого начинает понимать, что для эксплуатации сетевого оборудования необходимо программное обеспечение. Но самое печальное, когда к пониманию необходимости существования концепции корпоративной системы приходят лишь только после того, как первое программное обеспечение, написанное случайными людьми, вводится в эксплуатацию часто силами студентов вузов (большинство предприятий упорно экономят десятки долларов, чтобы потом потерять тысячи), которые решают задачи для отдельных подразделений, исходя из собственного понимания проблемы, и не задумываются об интеграции.

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

Что случилось с нашей сетью? В определенный момент при дальнейшем увеличении интенсивности использования ЛВС начинают возникать

трудности. Что же случилось? Разгадка проста — недопустимо возрос сетевой трафик. Причин несколько. корпоративные приложения, создаваемые в рамках FS-модели, вынуждены использовать локальные СУБД,

работающие с базами данных, находящимися на файл-сервере. Большой популярностью у разработчиков пользуются FoxPro, Clipper, Paradox, Clarion и dBase.

Процесс доступа к информации в такой СУБД выглядит следующим образом. Для поиска данных информация с сервера передается на рабочую станцию до тех пор, пока необходимая запись не будет найдена. Таким образом, по сети на рабочую станцию будет передан как минимум индексный файл, необходимый для определения местоположения требуемой записи, и только затем — нужный фрагмент из базы данных. Если запрос сложный, то количество служебной (т. е. не нужной пользователю) информации, передаваемой по сети, многократно возрастает. В результате нагрузка на сеть растет, что при интенсивной работе клиентов сети приводит к общему снижению производительности.

К технологическим недостаткам этой модели относят следующие: · высокий сетевой трафик (передача множества файлов, необходимых приложению, но лишних, с точки

зрения необходимости пользователю); · узкий спектр операций манипуляции с данными (файлами); · отсутствие адекватных средств безопасности доступа к данным (защита осуществляется только на уровне

файловой системы). В общем случае описанные положения не являются собственно недостатками, они — следствие присущих

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

Именно в таких случаях попытки создания на основе FS-модели крупных корпоративных систем обречены на неудачу.

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

оборудования, которое непосредственно хранит эти данные. Файл-сервер имеет собственную систему безопасности и поддержания целостности данных, однако единицей

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

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

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

17

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

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

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

2.3.4 Особенности архитектуры клиент-сервер Итак, нагрузка на рабочие станции велика, сеть перегружена, и пользователи испытывают затруднения в

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

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

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

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

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

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

· Архитектура клиент-сервер не требует графического пользовательского интерфейса. · Логика приложения клиент-сервер остается независимой от интерфейса с пользователем, поэтому

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

· Системы клиент-сервер не обязательно ориентированы на базы данных. Множество существующих приложений для баз данных, удовлетворяющих требования архитектуры клиент-сервер, породило мнение, что работа с базой данных — это неотъемлемый и необходимый атрибут таких приложений. Архитектура

18

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

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

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

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

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

Архитектура клиент-сервер при работе с базами данных 2.3.5 Работа в неоднородной вычислительной среде Одним из важных преимуществ рассматриваемой архитектуры является возможность работы в сетях, в

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

Многоплатформенные вычисления. Часто возникает необходимость в том, чтобы приложение работало на нескольких платформах. Хотя это требует значительных усилий со стороны разработчика, полученные в результате преимущества превзойдут затраты. Общие требования к разработке таких приложений состоят в следующем:

· Выполняемость на нескольких платформах. · Одинаковые интерфейс и логика работы на всех платформах (подразумевается только сходство схем

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

· Интегрированность с «родной» операционной средой. · Одинаковое поведение на различных платформах. · Согласованная поддержка вне зависимости от платформы. Реализовать приложение одновременно в нескольких средах весьма непросто. Поэтому появились

интегрированные среды разработки (frameworks), которые облегчают эту задачу. Такие среды, как Windows Open Systems Architecture (WOSA) и Win32 корпорации Microsoft, общая открытая программная среда UNIX COSE и AppWare Foundation компании Novell существенно облегчили перенос приложений между различными средами. Многие компании принимают решения о вложении средств именно с учетом поддержки многих платформ.

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

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

19

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

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

2.3.6 RDA-модель RDA — Remote Data Access. Она существенно отличается от FS-модели характером доступа к

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

Клиент направляет запросы к информационным ресурсам (например, базам данных) по сети удаленному серверу. На сервере функционирует ядро СУБД, которое обрабатывает запросы, выполняя предписанные в них действия, и возвращает клиенту результат, оформленный как блок данных. Инициаторами манипуляций с данными являются прикладные программы, выполняющиеся на компьютерах-клиентах. Ядру СУБД отводится пассивная роль — обслуживание запросов и обработка данных.

RDA-модель позволяет избавиться от следующих недостатков, присущих системам с централизованной архитектурой мэйнфрейм и с файловым сервером (FS-модель):

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

· Сервер БД освобождается от несвойственных ему функций — процессор или процессоры сервера целиком загружаются операциями обработки данных, запросов и транзакций.

· По сравнению с FS-моделью резко снижается загрузка сети, так как по ней передаются только запросы на данные и обработанные результаты запросов.

· По сравнению с архитектурой мэйнфрейм клиентские места становятся «интеллектуальными» — в отличие от терминалов они обладают собственными вычислительными ресурсами, поэтому вычислительные мощности сервера (как правило, мощной и дорогой машины) загружаются только для обработки данных.

2.3.7 DBS-модель DBS - Data Base Server. Эта модель в последнее время достаточно популярна. Как правило, именно она реали-

зуется в реляционных СУБД, таких как InterBase, Oracle, Informix, Ingres, Sybase. Кроме описанных выше преимуществ, ее основу представляет механизм хранимых процедур — средства программирования SQL-сервера. Процедуры хранятся в словаре БД, могут разделяться несколькими клиентами и выполняются на том же компьютере, на котором функционирует SQL-сервер.

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

· Кроме достоинств, присущих RDA-модели, DBS-модель обладает еще рядом преимуществ: · Возможность централизованного администрирования. · Дополнительное снижение графика за счет выполнения хранимых процедур на SQL-сервере. · Разделение хранимых процедур несколькими приложениями, что позволяет организовать задачи

поддержания целостности данных вне зависимости от прикладных программ, использующих эти данные. 2.3.8 AS-модель AS - Application Sever. В этой модели процесс, выполняющийся на компьютере-клиенте, отвечает за ин-

терфейс с пользователем. Обращаясь к прикладному компоненту, расположенному на сервере, этот процесс играет роль клиента приложения (Application Client). Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server). Все операции над информационными ресурсами могут осуществляться соответствующим компонентом, расположенным на другом сервере, по отношению к которому AS играет роль клиента.

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

20

механизмы многозадачной операционной системы и стандартизированы интерфейсы с другими компонентами. Резюме. RDA- и DBS-модели опираются на двухзвенную схему разделения функций. В RDA-модели

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

2.3.9 Методы построения приложений клиент-сервер Приложения клиент-сервер имеют множество применений, но их разработка достаточно сложна. Она может

выполняться на языках разных поколений. Средства разработки третьего поколения (3GL). Под этим термином подразумеваются языки Си, C++,

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

Средства разработки четвертого поколения (4GL). Они позволяют скрыть сложности взаимодействия операционной системы и базы данных. Разработчик управляет компонентами более высокого уровня и поэтому может относительно легко и быстро строить приложения. Однако такие приложения, как правило, очень гро-моздки и часто менее производительны. Сегодня семейство инструментальных средств разработки

4GL достаточно многочисленно — Gupta SQL Windows, Powersoft PowerBuilder, Delphi, а также программные продукты компаний Progress и Oracle. Это, в большинстве случаев, оптимальный вариант для корпоративных пользователей. Инструментальные средства четвертого поколения позволяют абстрагироваться от особенностей операционной системы и кон-кретных баз данных, что делает приложения переносимыми между различными платформами.

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

Средства разработки пятого поколения (5GL). Эти системы предназначены для проектирования чрезвычайно сложных приложений. Разработчик оперирует только компонентами, моделирующими процессы взаимодействия клиента и сервера, причем, основную массу программного кода генерирует средство разработки, т. е. он может создать приложение, не написав ни строчки программного кода. Такие продукты логически представляют крупные компоненты приложения и позволяют разработчику визуально комбинировать их в единое целое. Эти приложения могут обеспечивать связь с базами данных, видео, обработкой изображений и передачей сообщений. Сложность создания приложений клиент-сервер «маскируется» от разработчика. Примером такого продукта является Visual AppBuilder компании Novell.

21

Приложение

Операционная система

Сетевой протокол обмена


Файловая система

Клиент

Сервер


API доступа к данным


ПО обработки запросов

Клиент

Сервер

Драйвер ОС


Данные


API доступа к данным


ПО обработки запросов

Клиент

Сервер

Драйвер ОС


Данные

ПО выполнения процедур


API доступа к AS


DBS сервер

Клиент Драйвер ОС

Операционнаясистема

Данные

AS сервер

Операционнаясистема

FS модель RDA модель (Remote Data Access)

AS модель (Application Server)DBS модель (Data Base Server)

Рисунок А Рисунок Б

Рисунок В Рисунок С

Модели доступа к данным

22

3 ВЫЧИСЛЕНИЯ КЛИЕНТ-СЕРВЕР В МАСШТАБЕ КОМПАНИИ

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

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

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

Перепроектирование бизнес-процессов (Business Process Reengi-neering - BPR) является ключевым из факторов, обусловливающих смену архитектур вычислений в информационных технологиях. BPR опреде-ляется как «фундаментальное переосмысление и радикальное перепроектирование бизнес-процессов с целью достижения значительных улучшений в критически важных современных критериях производительности, таких как стоимость, качество, сервис и скорость».

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

Рисунок 3.1 - Модель Хендерсона В данной модели основная бизнес-платформа представляет собой набор стратегий, рынков, предписаний,

технологий производства продуктов и ресурсов, выбранный организацией как соответствующий поставленным целям. Отсюда следует бизнес-архитектура - тот набор товаров и услуг, организационных структур, процессов управления, распределения ресурсов, ценностей и стимулов, который необходим для внедрения основной бизнес-платформы. Под соответствующей основной информационной платформой (Information Technologies - IT) - IT-платформой понимается ряд адекватных компьютерных технологий, доступных компании, и способы, которыми эти технологии могут быть реализованы для повышения конкурентоспособности.

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

· Существует двунаправленное воздействие основных бизнес- и технологических платформ. · Если основные бизнес- и технологическая платформы меняются, то маловероятно, что соот-

ветствующая наследуемая IT-архитектура сохранится. · Соответствие между бизнес- и технологической платформами является решающим фактором успеха,

23

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

архитектуры на IT-архитектуру. Автономность бизнес-подразделения Различные поставщики оборудования, сети, платформы,

операционные системы

Меньшее количество уровней управления Повсеместные почта, телеконференции

Переход от ориентированности на задачи к ориентированности на процессы

Переход от OLTP-мониторов к менеджерам прш^сг:пр

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

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

Интенсивная фокусировка на обслуживании клиента

Быстрое развитие приложений. Приложение клиент-сервер от нескольких поставщиков. Надежная передача сообщений. Круглосуточная работа

Возросшая мобильность персонала. Расширение телекоммуникаций

Беспроволочные коммуникации. Асинхронные сообщения. Тиражирование баз данных. Круглосуточная работа

Конкуренция, минимизация затрат Использование новейших технологий

Рассмотрим некоторые аспекты влияния бизнес-архитектуры на IT-архитектуру.

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

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

щие разные бизнес-подразделения, укомплектованные неоднородным оборудованием и географически разрозненные.

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

Соотношение количества сотрудников и управляющего персонала обычно составляет от 7:1 до 15:1 и даже больше. Компании быстро переходят к «обеспечению уровня рабочих групп» (groupware) - компьютерной прикладной поддержке групповых коммуникаций и групповой работы. Фундаментом таких систем являются сети. В связи с этим растет количество типов данных, не поддерживаемых современной коммуникационной технологией (например, образы, речь).

Реорганизация работы от ориентации на задачи к ориентации на процессы. Системы обработки транзакции вводят и поддерживают «конвейерный» подход к организации работы.

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

24

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

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

3.1 Стоимость вычислений клиент-сервер С появлением архитектуры клиент-сервер подразумевалось, что ее реализация даст не только некие

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

Приведенные далее данные взяты из отчета «Стоимость систем клиент-сервер» компании Forester Research за 1993 г.

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

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

Единовременные затраты - это разработка приложений + инфраструктура + обучение и подготовка персонала. Для системы клиент-сервер единовременные затраты составляют:

28% + 25% + 7% = 60% общей стоимости проекта, для мэйнфрейма - 40% + 27% + 3% = 70%. Теперь предположим, что оба проекта одинаковы по стоимости, которая достигает $10 000, а период эксплуатации составляет пять лет. Примем коэффициент дисконтирования 7%. Таким образом, затраты на проект клиент-сервер составят:

$6 000 + $3 280 (с учетом коэффициента дисконтирования) = $9 280. Затраты на работу с мэйнфреймом: $7 000 + $2 460 = $9 460. Получаем экономию $9 460 - $9 280 = $180, которая тем больше, чем выше стоимость проекта. Таким

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

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

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

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

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

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

25

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

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

3.2 Преимущества вычислений клиент-сервер Вычисления клиент-сервер выгодны всем пользователям, кто связан с информационными системами

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

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

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

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

26

4 ОСНОВЫ ТЕОРИИ БАЗ ДАННЫХ СЭК 4.1 Определение назначения и задач приложения База данных — это только средство для достижения цели, а ваша цель состоит в обеспечении сервиса,

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

Предназначение приложения Первый шаг в проектировании любого приложения (для работы с базой данных или любого другого)

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

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

Цели приложения Что конкретно данное приложение собирается делать? При ответе на этот вопрос постарайтесь

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

Система RENTALMAN будет отслеживать процесс обслуживания арендуемой недвижимости, а именно: · регистрировать поступающие заявки от арендаторов; · выдавать заказы на работу и отслеживать процесс в развитии; · предоставлять накопленную информацию по конкретным объектам.

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

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

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

4.2.1 Моделирование данных При построении базы данных прежде всего необходимо определить, какие нужно иметь таблицы и что

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

· Моделирование центрального приложения старается удовлетворить потребности приложения в данных с помощью одной-единственной базы данных. Каждое приложение здесь обладает своей собственной базой данных или сугубо личным набором таблиц. Таблицы не связаны с внешним миром — приложение и база данных являются по существу их миром.

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

27

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

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

Более того, копирование зависимых объектов приложения из одного севера на другой (например, из сервера разработки на сервер производства или из сервера производства на сервер резервирования) многократно усложняется, если эти объекты размещены в различных базах данных. Получение некого устойчивого состояния данных с целью резервирования также затрудняется, поскольку большинство DBMS не поддерживает моментальных снимков связанных баз данных. Sybase, например, поддерживает моментальные снимки состояния только одной базы данных: если резервирование начато на данной базе данных, то все данные, записываемые в устройство резервирования, будут соответствовать одному моменту времени. Это не годится для случая с использованием нескольких баз данных. После восстановления с резервной копии баз данных продажи и производства может оказаться, что они не соответствуют прежним базам данных — о продукции, записанной в базе данных продажи, ничего "не знает" база данных производства.

При всем уважении к Delphi запоминание объектов баз данных в нескольких базах данных требует для получения доступа к этим объектам нескольких псевдонимов BDE (Borland Database Engine), а следовательно, и нескольких подключений к, возможно, одному серверу базы данных. Другими словами, вам придется несколько раз регистрироваться на одном и том же сервере базы данных — по одному разу для каждой базы данных, к которой вы получаете доступ.

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

Предпочтительней использовать комбинацию этих двух подходов. Начинают проект любого приложения баз данных с обдумывания того, что это приложение призвано сделать, а затем определяю, какие нужны таблицы, чтобы приложение могло справиться с поставленными задачами. Далее просматривают другие имеющиеся в распоряжении базы данных, чтобы оценить, могут ли они пригодиться. Если да, то использую их в одном из двух вариантов. Либо пользуются множественными псевдонимами, чтобы получить доступ к нескольким базам данных, любо создают просмотр SQL в главной базе данных приложения для каждой внешней таблицы, на которую есть ссылка. Просмотр используется в приложении вместо базовой таблицы. Главная база данных приложения является видовой базой данных, которая создается либо вместе с проектом, либо она уже существует. Использование этого метода избавляет от необходимости выполнять требование BDE, заключающееся в раздельном входе в каждую базу данных, поскольку кажется, что все объекты находятся в одной базе данных. В то же время здесь сохраняется сущность видового моделирования — просмотр не копирует базовую таблицу, он просто ссылается на нее через запрос SQL. Такой подход является удачным компромиссом между этими двумя методами.

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

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

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

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

28

SELECT TENANT.tenantNo, TENANT.Name, PROPERTY.Address FROM TENANT, PROPERTY WHERE TENANT.tenantNo=PROPERTY.tenantNo Объединения имеют две основные разновидности: внутренние и внешние. Внутреннее объединение не

возвратит ни одной строки из любой таблицы, если не будет обнаружено выполнение условия объединения. Внешнее объединение возвратит строки из таблицы слева, невзирая на то, было ли обнаружено выполнение условия объединения или нет. Если условие объединения не было обнаружено, поля в результирующем наборе, размещаемые справа, возвращаются как NULL. Приведенный выше пример синтаксиса SQL демонстрирует внутреннее объединение. Пример, показанный ниже, представляет собой тот же самый запрос, но выраженный в виде внешнего объединения:

SELECT TENANT.tenantNo, TENANT.Name, PROPERTY.Address FROM TENANT LEFT OUTER JOIN PROPERTY ON TENANT.tenantNo=PROPERTY.tenantNo Обратите внимание на использование синтаксиса LEFT OUTER JOIN во втором запросе. Он обязывает

запрос возвращать строки в таблице слева, невзирая на то, было ли обнаружено совпадение в таблице справа, используя при этом общие для двух таблиц поля tenantNo.

4.2.3 Задачи в операционных процессах Для продолжения работы над проектом вашего приложения разделите задачи, поставленные вами на

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

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

4.2.4 Базы данных операционного процесса Теперь вы готовы начать разработку объектов баз данных, которые призваны обслуживать намеченные

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

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

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

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

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

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

29

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

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

Мысли об эффективности Подумайте также и об эффективности. Спросите себя: "Какой наименьший тип данных я могу

использовать для этого поля и одновременно запомнить максимально возможное значение?" Если полю никогда не придется хранить значение, превышающее 255, то запомните его как значение типа byte или int. Где только возможно, используйте вместо вещественных значений целочисленные. Если длина символьных полей может значительно меняться от записи к записи, используйте переменные символьные типы вместо фиксированных символьных типов.

Пользовательские типы данных Пора поговорить о типах данных, определяемых пользователем, если, конечно, ваша платформа

поддерживает такую возможность. Пользовательский тип данных — это просто удобный способ обращения к типам данных, которые уже поддерживаются сервером. InterBase называет их доменами (domains). Они предоставляют простой и надежный метод определения похожих столбцов таблицы. Предположим, например, что в вашем хранилище есть несколько полей, которые представляют имена некоторого типа, скажем, CustomerName, VendorName и EmployeeName. Пусть все три поля будут символьными полями переменной длины по 40 байт каждое. Вместо того, чтобы определять эти поля как VARCHAR (40), вы могли бы определить пользовательский тип данных с именем, скажем, NameTYPE, который сам определяется как переменный символьный тип данных длиной в 40 байт. После этого для этих трех полей вместо типа VARCHAR (40) можно было бы использовать тип NameTYPE. Этот способ определения похожих полей является более экономичным.

Опишите свои поля Настоятельно рекомендуется описать ваши поля в хранилище. Опишите тип данных для каждого поля и

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

Использование хранилища полей для построения таблиц Используйте вашу информацию о полях для построения таблиц. Распределите определения полей из

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

4.5 Кодирование определений в SQL Иногда на этой стадии мне кажется полезным забежать вперед и закодировать структуры таблиц в SQL,

т.е. для каждой таблицы записать оператор SQL CREATE. Это заставит вас формализовать определение каждой таблицы и принять решение относительно реально используемых типов данных SQL. Вам придется решить, какие поля могут оставаться пустыми, а какие — нет, и определить их либо как NULL, либо как NOT NULL соответственно. Несмотря на то что ваш сервер, возможно, по умолчанию использует обозначение NULL/NOT NULL, все равно задайте его — это способствует большей ясности. Тем самым вы приступаете к настоящей работе по созданию таблиц, так как позже вы сможете использовать операторы CREATE для их построения (использование таких средств, как Database Desktop, построение таблицы с помощью SQL является необязательным, но написание операторов CREATE по-прежнему остается хорошей практикой). Например, для таблицы TENANT вы могли бы написать следующий оператор CREATE:

CREATE TABLE TENANT ( TenantNo smallint NOT NULL, Name varchar(30) NOT MULL, Employer varchar(30) EmpAddress varchar(30) EnipCity varchar(30)

30

EmpState char(2) EmpZip char(10) HoinePhone char (10) WorkPhone char(10) ICEPhone char(10) LeaseBegin datetime NOT NULL, LeaseDuration tinyint NOT NULL, Movein datetime NOT NULL, MoveOut datetime NOT NULL, RentDueDay tinyint NOT NULL, PetDeposit money LawnService bit NOT NULL) 4.6 Организация таблиц по типам Разделите все таблицы на базовые и таблицы транзакций (изменений). Базовые таблицы (справочники)

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

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

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

внутри конкретной таблицы. Следовательно, данные должны дублироваться на межтабличном уровне. Это вытекает из того, что первичный ключ одной таблицы должен быть продублирован первичным или внешним ключом другой таблицы с целью установления между ними взаимоотношений. Эти взаимоотношения выражаются в двух разновидностях: один-к-одному и один-ко-многим. Взаимоотношения один-к-одному используются довольно редко. Данные, содержащиеся во второй таблице, доступ к которой производится через взаимоотношение один-к-одному, можно с таким же успехом включить в первую таблицу. И, наоборот, взаимоотношения один-ко-многим весьма распространены — они образуют основу для большинства PC-ориентированных приложений ведения баз данных. (Заметьте, что взаимоотношения многие-к-одному явля-ются на самом деле просто перевернутыми взаимоотношениями один-ко-многим.) Таблицы, ориентированные на взаимоотношения один-ко-многим, называются обычно главными и подчиненными таблицами.

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

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

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

Диаграммы отношений между объектами отображают вид связи элементов (записей) в одной таблице с элементами другой. Причем здесь не нужна детальная разработка или использование сложных символов. Цель такой диаграммы заключается в визуальном представлении отношений между таблицами, и это можно сделать без применения специальных символов. Главное, чтобы вы правильно понимали связи между таблицами, и тогда вы имеете право на продолжение работы. На рис. 4.1 показана диаграмма отношений, которая придерживается более формального стиля, а на рис. 4.2 — менее формального.

31

Рис. 4.1. Диаграмма отношений между объектами для таблиц TENANT и PROPERTY формального стиля Кроме того, считается очень полезным построение схематического изображения полного проекта базы

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

Рис. 4.2. Диаграмма отношений между объектами для таблиц TENANT и PROPERTY, которая следует

менее формальному стилю построения диаграмм отношения

Рис. 4.3 - Схематическое изображение базы данных иллюстрирует взаимоотношения между таблицами в базе

данных

32

4.8 Диаграммы потоков данных Есть еще одна полезная вещь при разработке проекта базы данных — это построение диаграмм потоков

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

Рис. 4.4. Стандартная диаграмма потоков данных

4.9 Нормализация базы данных Процесс трансформации данных в реляционную форму называется нормализацией (см. известную

публикацию доктора Кодда "Реляционная модель данных для больших совместно используемых банков данных" (Dr. E.F. Codd "A Relational Model of Data for Large Share Data Banks", 1970)). Говоря проще, нормализация — это удаление избыточных данных из каждой таблицы в базе данных. У нормализации двойная цель — удалить лишние копии данных и обеспечить максимальную гибкость как в структурах таблиц, так и в интерфейсных приложениях на случай возможных будущих изменений в базах данных.

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

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

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

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

Повторяющаяся группа — это поле, которое повторяется внутри определения записи с целью хранения нескольких значений для атрибута. Мы могли бы, например, применить этот подход в проекте нашей таблицы TENANT, запоминая в ней, а не в отдельной таблице PROPERTY, информацию об арендуемой недвижимости. Чтобы предусмотреть возможность, когда один арендатор арендует больше одной единицы недвижимости (например, в случае сети ресторанов), необходимо принять решение о максимальном количестве единиц собственности, которое можно арендовать одному арендатору, и добавить в таблицу необходимое число соответствующих полей. Эти поля-близнецы и будут составлять повторяющуюся группу.

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

33

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

Вторая нормальная форма Для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все неключевые поля

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

Давайте снова воспользуемся примером таблицы счетов. Если первичный ключ состоит из полей LocationNo и InvoiceNo, то хранение имени Location в каждой записи нарушит вторую нормальную форму, поскольку поле LocationName не будет уникально определено целым первичным ключом. Это поле будет зависеть только от поля LocationNo, а поле InvoiceNo не окажет на него никакого влияния. Вместо того, чтобы постоянно хранить поле LocationName в таблице INVOICE, нужно по необходимости выбирать его из таблицы LOCATION путем присоединения.

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

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

Давайте вернемся к нашему примеру таблицы INVOICE. Пусть снова первичный ключ составляют поля LocationNo и InvoiceNo. Возьмем в качестве неключевого поле CustomerNo. Если в той же таблице хранить еще и поле CustomerName, то такая таблица нарушит критерий для третьей нормальной формы, поскольку поля CustomerNo и CustomerName зависят друг от друга. Если изменилось поле CustomerNo, то соответственно нужно изменить и поле CustomerName, и наоборот. Выход из этого положения лежит в занесении поля CustomerName в таблицу CUSTOMER и получения к нему доступа только по необходимости путем присоединения.

Четвертая нормальная форма Четвертая нормальная форма запрещает хранить независимые элементы в одной и той же таблице, когда

между этими элементами существуют взаимоотношения типа многие-ко-многим. Используя пример таблицы INVOICE, давайте предположим, что каждый счет может включать только один элемент, и что таблица INVOICE содержит столбцы Vendor и Item. Столбец Vendor означает продавца элемента, указанного в счете, например, "Vendor X". Столбец Item содержит код компании для данного типа продукции, который она регулярно покупает, скажем бумагу для копировальных машин. В таблице INVOICE может храниться много записей, относящихся к продавцу X, который может продавать много товаров, а не только бумагу для копировальных машин. Кроме того, в той же таблице может быть много записей, содержащих информацию о бумаге для копировальных машин — ведь компания может покупать ее не только у продавца X, но и у дру-гих продавцов. В этом случае говорят, что столбцы Vendor и Item находятся во взаимоотношении типа многие-ко-многим. Для каждого Item в таблице INVOICE может существовать много продавцов и для каждого Vendor — много элементов. Четвертая нормальная форма требует, чтобы вы запомнили такие элементы в отдельных таблицах и создали таблицу отношений для организации связей между таблицами, характеризующихся взаимоотношениями типа многие-ко-многим.

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

Пятая нормальная форма Пятая нормальная форма требует, чтобы вы имели возможность перестраивать свои данные в

нормализованных таблицах, в которые они были переведены. Это значит, что если вы начинаете с ненормализованных таблиц, то у вас не должно быть препятствий к вырезке и вставке данных и после нормализации. Это осуществимо, если есть гарантия, что в процессе нормализации не будет потери данных. Например, если вы начинаете с таблицы INVOICE, которая включает столбцы CustomerNo и CustomerName, то нормализация базы данных заставит вас создать отдельную таблицу CUSTOMER и перенести в нее столбец CustomerName. Конечно, вы скопируете в ту же таблицу и столбец CustomerNo. Но если вы по ошибке просто удалите столбец CustomerName из таблицы INVOICE, то вы не сможете перестраивать свою исходную ненормализованную таблицу, так как столбец CustomerName больше не существует в вашем новом

34

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

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

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

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

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

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

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

Отсюда следует, что при введении в проект базы данных контролируемой избыточности необходимо сначала полностью нормализовать базу данных, а затем ввести избыточность только в случае абсолютной необходимости.

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

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

Ключи Ключевые поля определяют методы доступа, которые вы собираетесь использовать, чтобы добраться до

определенных строк таблицы. Выбранные вами на этой стадии ключи будут позже преобразованы в индексы. Подберите все необходимые вам ключи, но учтите, что ненужные индексы зря занимают дисковое пространство и снижают производительность. Кроме того, не беспокойтесь насчет выбора первого поля или полей составного ключа в качестве отдельного ключа. Например, если поля Location и InvoiceNo образуют первичный ключ для таблицы INVOICE, то нет необходимости в установке Location как отдельного ключа. Почти все DBMS поддерживают частичный поиск ключа, поэтому создание индекса для столбца Location приведет к неоправданным затратам дискового пространства и ресурсов DBMS.

Первичные ключи Просмотрите таблицы своей базы данных и задайте для каждой свой первичный индекс. В своих

диаграммах я отмечаю каждое поле первичного индекса прописной буквой Р, за которой следует в виде верхнего индекса номер, означающий его порядок в составном ключе, если это нужно (рис. 4.2).

Имейте в виду, что первичный ключ может быть составным ключом — он может состоять из более чем одного поля. Выбранный вами первичный ключ должен быть уникальным по определению и являться самым популярным путем доступа к данным таблицы. При этом учтите способ использования этих данных. Насколько часто они будут запрашиваться? На какие поля в этой таблице могут ограниченно ссылаться другие таблицы? (Подробнее см. раздел "Ограничения" далее в этой главе.) Например, в таблице TENANT, описанной выше, записи арендаторов уникально определяются полем TenantNo. Это поле, безусловно, будет

35

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

Вторичные ключи Используйте вторичные ключи для установления вторичных путей доступа к данным таблицы. Они менее

популярны, но достаточно существенны. Не следует слишком увлекаться ими — ведь позже выбранные вами ключи будут преобразованы в индексы, и ненужные индексы просто зря займут дисковое пространство и загрузят DBMS. На создание нового индекса уйдет меньше времени, чем на поддержку индекса для многих серверов SQL. Каждый новый индекс снижает производительность системы, как это видно на примере баз данных PC. Приложения SQL часто создают вторичные индексы только в случае крайней необходимости, а затем разрушают их.

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

Ограничения Существует три основных типа ограничений: ограничения первичных ключей, ограничения внешних

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

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

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

Ограничения внешних ключей Ограничения внешних ключей являются внешними в том, что они не являются первичным ключом данной

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

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

Ограничения внешних ключей являются по своей природе двунаправленными, т.е. такое ограничение действует не только на значения, которые может иметь поле, но и значение, запомненное в поле, препятствует удалению или модификации соответствующего значения во второй таблице. Например, поле TenantNo в таблице PROPERTY должно позволять только те номера арендаторов, которые существуют в таблице TENANT. Аналогично, если данный номер арендатора хранится в таблице PROPERTY, то соответствующая запись в таблице TENANT не должна быть удалена. Удаление "осиротило" бы номер TenantNo, хранящийся в таблице PROPERTY и препятствовало его использованию для определения текущего обитателя жилища. В своих диаграммах я использую прописную букву "F", за которой следует номер, означающий порядок внешнего ключа среди других внешних ключей. Второе число, используемое как верхний индекс, обозначает порядок полей в составном внешнем ключе (см. рис. 4.2).

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

данному критерию или является членом заданного набора значений. Управляющий критерий проверяемого ограничения фиксируется вами в период проектирования. Например, в таблице PROPERTY вы можете ограничить допустимые значения для поля GarageType диапазоном 0-4, поскольку вам известно, что все виды собственности либо не имеют гаража (тип 0), либо имеют гараж для одной, двух, трех или четырех машин соответственно. В моих диаграммах поле с проверяемым ограничением соединяется линией с прямоугольником, содержащим управляющий критерий, как показано на рис. 4.2.

Умолчания Существует еще один класс правил, устанавливаемых для полей таблиц базы данных — это действующие

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

36

электричество во всех видах собственности. В своих диаграммах я проставляю значение поля, принимаемое по умолчанию, после знака равенства справа от названия поля (см. рис. 4.2).

4.11 Создание объектов баз данных Если определены межтабличные зависимости, правила, ключи и тому подобное, то можно считать, что

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

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

Таблица 4.1- Соотношение элементов проекта базы данных н объектов базы данных

Элемент проекта Объект базы данных

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

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

Для этого вам будет нужен каталог или папка на дисковом устройстве для локальных систем DBMS или реальный объект сервера базы данных для удаленных систем. Очевидно, что вам просто нужно создать подкаталог, предназначенный для выдачи системных команд. Если есть необходимость в создании базы данных на удаленном сервере, то SQL— к вашим услугам. Точный синтаксис и поддерживаемые расширения файлов для команды SQL CREATE DATABASE варьируются для разных платформ, но вы можете оттолкнуться от следующего синтаксиса для InterBase:

CREATE DATABASE "C:\DATA\DELPHI\PENTMAN\PENTAL.GDB" USER "SYSDBA" PASSWORD "masterkey" LENGTH=100;

Обратите внимание на использование устройства С: \DATA\DELPHI\PENTMAN\PENTAL.GDB. База данных могла бы состоять из файлов, размещенных на нескольких различных дисковых устройствах. В этом состоит главное различие между локальными системами DBMS и системами клиент/сервер. Как правило, такие локальные системы, как dBASE или Paradox, не поддерживают размещения одного объекта базы данных на нескольких дисковых устройствах, если базовая операционная система не в состоянии представить несколько устройств как один том. Высокоуровневые системы клиент/сервер не страдают таким ограничением.

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

таблицы. В SQL это делается с помощью ограничения PRIMARY KEY. Вы могли определить это и во время создания таблицы, но я разделил эти две задачи, чтобы вам было легче отличить их друг от друга. Для уже созданной таблицы назначение первичного ключа выполняется с помощью команды SQL ALTER TABLE. Вот ее синтаксис:

ALTER TABLE PROPERTY ADD PRIMARY KEY (PropertyNo) Кроме того, задание первичного ключа создает уникальный индекс для указанных столбцов. Выражаясь

терминами индексирования, создание первичного ограничения выполняют операторы языка определения данных (Data Definition Language — DDL):

CREATE UNIQUE INDEX RDB$PRIMARY1 ON PROPERTY (PropertyNo) Вторичные ключи Создав первичный ключ, можно установить и вторичные ключи. Как уже упоминалось, вторичные ключи

устанавливают вторичные пути доступа к таблице. Эти "тропки" не такие проторенные, но достаточно важные. Примером вторичного ключа для таблицы PROPERTY может служить столбец Address. Вполне вероятно, что пользователь захочет взглянуть на предлагаемый дом, используя его адрес, а не его номер.

37

Создав вторичный индекс по полю Address, вы ускорите получение доступа. Для создания вторичных индексов используйте команду CREATE INDEX. Вот пример:

CREATE INDEX PROPERTY02 ON PROPERTY (Address) Внешние ключи Определившись с первичным и вторичными ключами, можно позаботиться о задании ограничений

внешних ключей. Напомню, что внешние ключи представляют собой поля таблицы, которые ссылаются на первичные ключи других таблиц. В предьюу-щем примере поле TenantNo в таблице PROPERTY является внешним ключом. Несмотря на то что он не уникальным образом определяет записи в этой таблице, и следовательно, не является первичным ключом, он имеет честь быть первичным ключом таблицы TENANT. Чтобы применить ограничение внешнего ключа к полю TenantNo в таблице PROPERTY, используется сле-дующий синтаксис:

ALTER TABLE PROPERTY ADD CONSTRAINT INVALID TenantNo FOREIGN KEY (TENANTNO) REFERENCES TENANT (TENANTNO) Определение ограничения внешнего ключа создает вторичный индекс для столбца (столбцов). В терминах

индексирования, создание ограничения предыдущего внешнего ключа выполняет оператор DDL, аналогичный следующему:

CREATE INDEX RDB$FOREIGN4 ON PROPERTY (TenantNo) Ограничения Проверяемое ограничение ссылается на фиксированный набор значений. Выше вы видели хороший

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

AT TFR TURT F PROPERTY ADD CONSTRAINT INVALID_GARAGETYPE CHECK (GarageType>=0 and GarageType<=4) Умолчания Следующим номером нашей программы является установление действующих по умолчанию значений для

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

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

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

Запрос SQL, предназначенный для добавления к существующей таблице столбца по умолчанию, выглядит следующим образом:

ALTER TABLB TENANT ADD RentDueDay SMALLINT DEFAULT 15 Триггеры Триггер — это обычно маленькая скомпилированная программа SQL, которая выполняется, когда в

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

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

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

CREATE TRIGGER Delete Detail FOR HORDERS BEFORE DELETE POSITION 0 AS BEGIN DELETE FROM WODETAIL WHERE WODETAIL.WorkOrderNo=01d.WorkOrderNo;

38

END Обратите внимание на использование логической таблицы "Old". С помощью этого механизма вы

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

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

В основе реляционной модели, которая, начиная с середины 70-ых годов, заняла доминирующее поло-жение в области организации БД, лежит технология моделирования взаимосвязей, позволяющая формализовать процесс проектирования логической структуры данных. Наиболее популярной в этой области стала предложенная в 1976 г. П.П.Ченом (P.P.Chen) методика диаграмм взаимосвязей между объектами (Entity-Relationship Diagram — ERD). Она также известна под названием семантической модели данных (semantic data model), поскольку в ней учитывается семантика (смысл) данных по отношению к той предметной области, в которой будет использоваться проектируемая система. А поскольку реляционная модель по своему характеру является семантической, связанной главным образом со структурами, ERD ее органически дополняет. Фактически методика ERD предшествует реляционному моделированию. После завершения работы над диаграммой ERD результаты могут быть непосредственно преобразованы в реляционную модель, а последняя — в физическую модель.

Объект (entity) — некоторый элемент (сущность) применительно к конкретной предметной области. Например, это может быть сотрудник фирмы или проект, которые реализуется в фирме. То есть под термином "объект" понимается все, что может быть представлено в БД. Взаимосвязь (relationship) — это ассоциативная связь между объектами, как, например, связь между сотрудниками, с одной стороны, и проектами, в выполнении которых эти сотрудники принимают (или не принимают) участие, с другой стороны. Атрибуты (attributes) — это характеристики объекта. Например, атрибутом объекта сотрудник будет зарплата, а объекта проект — его сметная стоимость. Говорят, что атрибут принимает некоторое конкретное значение из домена (domain) атрибута — множества допустимых значений. Значения и являются теми данными, которые в дальнейшем будут использованы в реляционной модели. Все эти определения абстрагированы от конкретной предметной области, для которой проектируется БД. Графическое представление ERD может быть самым разнообразным. В принципе, не имеет значения, какое именно вы выберете. Единственное, что можно порекомендовать — всегда пользоваться одним и тем же, чтобы не вспоминать каждый раз назначение и смысл тех или иных условных обозначений.

Диаграммы ERD: объекты представлены в виде прямоугольников, наименования атрибутов объекта приведены внутри прямоугольника, а наименование объекта — снаружи. Между прямоугольниками объектов проведены стрелки, которые представляют тип взаимосвязей между объектами. Существует три типа взаимосвязей: один-к-одному, один-ко-многим и многий-ко-многим. Взаимосвязь типа один-к-одному изображается одинарной стрелкой либо на одном, либо на двух концах линии связи, в зависимости от вида этой связи. Взаимосвязь типа один-ко-многим изображается двойной стрелкой на одном из концов линии связи, а типа многий-ко-многим — двойными стрелками на обоих концах. Чистая взаимосвязь типа один-к-одному отображает такой характер отношений между объектами, когда каждому значению одного объекта соответствует только одно значение другого, и наоборот. Такой тип взаимосвязи встречается очень редко. На рис. 4.5 представлено схематическое изображение взаимосвязи типа один-к-одному. Муж женат только на одной жене, а жена, в свою очередь, состоит в браке только с одним мужем (Вариант полигамного брака здесь не рассматривается).

39

Рис. 4.5 - Взаимосвязь типа один-к-одному (1:1)

В классе взаимосвязей один-к-одному более распространен вид, который получил название взаимосвязи

подтипов (subtype). Такого рода соотношения между объектами являются одним из фундаментальных по-нятий в объектно-ориентированном (ОО) анализе и проектировании. В объектно-ориентированных системах этот вид взаимосвязи ярко проявляется в соотношении класса и подкласса или, что по сути то же самое, — в иерархии классов. На рис. 4.6 показано, как взаимосвязь такого типа изображается графически на диаграмме ERD.

Рис. 4.6 - Взаимосвязь подтипов класса один-к-одному(1:1)

На диаграмме представлен классический пример: квадрат является частным случаем (подтипом)

прямоугольника. Направление стрелки на линии связи указывает направление наследования (inheritance). Наследование — еще одна из базовых концепций объектно-ориентированного подхода в иерархии классов. Иными словами, атрибуты объекта более высокого уровня (представляющего более общее понятие) передаются объекту более низкого уровня. В нашем примере такими атрибутами являются длина и ширина. Таким образом, направление наследования указывает переход от общего к частному.

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

· Можно ли эти два объекта объединить? Не представляют ли они в контексте приложения одно и то же?

· Существуют ли какие-либо серьезные аргументы в пользу того, чтобы держать эти объекты в системе по отдельности?

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

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

Рис. 4.7. Взаимосвязь типа один-ко-многим(1:М)

Объект штат связан с множеством объектов город, но объект город связан с единственным объектом

штат. (Можно возразить, что города с одинаковыми названиями встречаются в разных штатах. Но отсюда для проектировщика следует только один вывод: нельзя использовать название города в качестве первичного ключа. Например, можно использовать для первичного ключа комбинацию Имя_штата+Название_города. В предыдущем подразделе уже шла речь об ограничениях, которые нужно соблюдать при формировании

40

первичных ключей.) И, наконец, на рис. 4.8 показан пример взаимосвязи типа многий-ко-многим, которая существует между

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

Рис. 4.8 - Взаимосвязь типа многий-ко-многим (М:М)

Преобразование взаимосвязи типа многий-ко-многим в две типа один-ко-многим в нашем примере можно

сделать следующим образом. Вместо того, чтобы рассматривать множество служащих, принимающих участие во многих проектах, будем рассматривать одного служащего, принимающего участие во многих проектах, и один проект, в реализации которого принимает участие множество служащих. В результате у нас| появится новый объект распределение работ. На рис. 4.9 показано, как будет выглядеть диаграмма после такой замены взаимосвязей. Обратите внимание: у объекта распределение работ имеется пара атрибутов - идентификаторов.

Рис. 4.9 - Замена взаимосвязи типа многий-ко-многим (M:N)

двумя взаимосвязями типа один-ко-многии (1:М и 1:М) Таблица новых объектов распределение работ, которая появилась в результате преобразования типов

взаимосвязей, в реляционной модели часто называется таблицей пересечения (intersection table). Такая таблица в контексте приложения вроде бы и не нужна, но она играет очень важную роль в формализации структуры БД в соответствии с требованиями реляционной модели.

4.14 Преобразование диаграммы ERD в реляционную модель Диаграмма ERD очень просто преобразуется в реляционную модель, поскольку она именно для этого и

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

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

41

Computer Assisted Software Engineering — автоматизированное проектирование программного обеспечения. Примерами могут служить продукты Erwin фирмы LogicWorks и Designer/2000 разработки Oracle. Эти программы позволяют не только построить диаграмму EDR, но и специфицировать первичные и внешние ключи, индексы, ограничения и даже сформировать стандартный SQL-код определения данных, который поможет создать таблицы и индексы. Работая в среде Oracle, можно сразу же запустить этот сценарий на выполнение, но чаще всего в него требуется внести некоторые коррективы с тем, чтобы указать типы данных и добавить параметры, касающиеся их объемов. С помощью этих же средств можно проанализировать структуру уже существующей БД, на которую отсутствует документация. Это особенно удобно при объе-динении баз или передаче на обслуживание созданных ранее систем. Таким образом, CASE-систсмы могут оказаться весьма кстати не только на этапе проектирования новых БД, но и в процессе эксплуатации су-ществующих.

42

5 МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ (По материалам статьи Михаил Евтеев. " BPwin - средство моделирования бизнес-процессов" в журнале

КОМПЬЮТЕРНОЕ ОБОЗРЕНИЕ - № 26 (99) 1997) 5.1 Общие сведения Человек всегда стремится облегчить свой труд. И это стремление является движущей силой

разработок инструментария особого рода — средств разработки. К этой категории относится средство моделирования бизнес-процессов BPwin компании Logic Works.

BPwin — это система для моделирования функций, процессов отображения де-

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

схемы: · структурную схему элементов предметной области; · функциональную схему с указанием информационных потоков.

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

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

Процесс моделирования позволяет рассматривать систему на различных уровнях детализации, анализировать ее и, что самое главное, взаимодействовать с другими разработчиками. Все это возможно до создания первого образца продукта. Попытки автоматизировать процесс моделирования предпринимались неоднократно. В течение 60—70 гг. Дуглас Т. Росс разрабатывал технику моделирования, известную как SADT (Structured Analysis & Design Technique). Военно-воздушные силы США адаптировали SADT как часть своей программы ICAM (Integrated Computer Aided Manufacturing) и называли ее IDEF0 (Integrated Compiler Automated Manufacturing Definition). Целью IСАМ было увеличение производительности посредством использования компьютерных технологий. Однако, как оказалось, описательные языки не эффективны для документирования и проверки процессов. Длинные процедурные описания имеют ограниченное применение, потому что они трудны для непротиворечивого описания, полного представления, сложны при изменениях и не приспособлены для описания альтернатив. Поэтому как часть программы (САМ были разработаны несколько графических языков моделирования бизнес-процессов:

IDEF0 (Integrated Computer Automated Manufacturing Definition) - для документирования процессов производства и отображения информации и ресурсов, используемых на каждом этапе;

IDEF1 - для документирования информации, необходимой для производственного окружения; IDEF2 - для документирования поведения системы во времени (IDEF2 никогда не был полностью

реализован и постепенно вытесняется техникой имитации). IDEF1X - в 1985 г. IDEF1 был расширен и переименован в IDEF1X. Эта методология

поддерживается семейством средств проектирования базы данных ERwin фирмы Logic Works. В 1993 г. был принят стандарт для IDEF1 и IDEF1X под названием FIPS для обеих технологий. Строительными блоками любой модели IDEF0 процесса являются деятельность (activity) и стрелки

(arrows). Деятельность представляет собой действие или набор действий, которые имеют цель и достигают результата. Английское слово «arrows» (стрелка), используемое в терминологии IDEF0, имеет множество значений. В целом, под стрелкой понимают воздействие, переносящее данные или объекты от одной деятельности к другой. Стрелки также применяются для описания того, что является результатом деятельности и какие ресурсы она потребляет. Это так называемые роли стрелок — IСОМ. IСОМ — акроним от категорий, описываемых IDEF0.

IDEF0:

I — Input: объект, поступающий на вход процесса; С — Control: ограничение процесса; О — Output: результат процесса; М — Mechanism: механизм, используемый для выполнения процесса.

43

В модели IDEF0 деятельность может быть представлена в виде диаграммы или узла в дереве процессов.

Для пояснения воспользуемся поставляемой в комплекте с пакетом BPwin диаграммой, моделирующей деятельность фирмы по прокату видеокассет.

Существуют диаграммы двух видов — контекстные и диаграммы декомпозиции. Каждая модель IDEF0 начинается с единственного прямоугольника, представляющего изучаемую систему в самом общем виде. Эта диаграмма называется контекстной, или А0, и служит началом работы по проектированию. Открыв диаграмму, вы увидите этот прямоугольник, подписанный как Run video store. В прямоугольник и из него идут стрелки, представляющие собой связи с внешним миром. Для каждой стрелки имеет значение, с какой стороны она проведена. Следуя пошаговым инструкциям системы помощи, можно построить точно такую же диаграмму.

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

· наименование проекта; · описание модели и ее рамки; · точка зрения (может быть несколько различных точек зрения на один и тот же процесс); · наименование и статус модели (рабочая, черновая, рекомендованная и т. п.).

Можно ввести также расширенную информацию, специфичную для каждой диаграммы в модели, поскольку основным действием над диаграммой является ее уточнение (декомпозиция).

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

5.2 Методология IDEF0 Методология IDEF0 жестко определяет вход и выход стрелки каждого вида: · Input выходит с левой стороны рамки рабочего поля и входит слева в прямоугольник процесса; · Control выходит сверху и туда же входит; · Output выходит с правой стороны процесса и входит в правую сторону рамки; · Mechanism — снизу.

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

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

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

BPwin самостоятельно обнаруживает противоречия в связях (туннелирование) между процессами и информирует о них пользователя.

Диаграммы BPwin являются иерархическими, поэтому существует второе ее представление — дерево. Система предоставляет великолепные возможности по построению дерева процессов. При этом для

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

Для особенностей, не предусматриваемых методологией IDEF0, в системе имеется функция построения FEO-диаграмм (For Exposition Only), в которых некоторые правила ослаблены (т. е. не проверяются BPwin). Это допустимость повторяющихся имен деятельностей и туннелирования стрелок (стрелок, нарушающих

44

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

удаления стрелки. Эта особенность гарантирует ссылочную целостность между родительской и дочерней диаграммами. Однако к FEO-диаграммам она не относится, поэтому вы можете удалять или скрывать любые стрелки. Для сокрытия стрелок в системе предлагается использовать туннелирование. Существует два вида туннелей: сигнализирующие о проблеме (unintendet) и намеренные — скрывающие стрелку на одном из уров-ней (intendet).

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

Можно очень быстро создать большое количество диаграмм, описывающих сложные процессы. Однако во всем этом изобилии стрелок и прямоугольников легко запутаться. BPwin снова окажет вам помощь. Достаточно задействовать в системе функции автонумерации стрелок и деятельностей — и вся работа будет проделана автоматически. Допустимо полностью изменять визуальные настройки, такие как шрифт и цвет, всех или выбранных объектов. Более того, хорошим стилем диаграммы считается, когда пересечений стрелок малое количество. Полностью избежать их, конечно, невозможно, однако система позаботится об этом и сведет их к минимуму. Необходимо только указать, какие из них (вертикальные или горизонтальные) предпочтительнее. Для стрелок, имеющих множество сегментов и пересечений, система может добавлять избыточные указатели в «стратегических» точках, что значительно упрощает навигацию по диаграмме.

Полезной особенностью системы BPwin является функция учета стоимости процессов. В совокупности с другими возможностями она позволяет учитывать стоимость как реального процесса, так и проектируемого. Учет этого показателя опирается на понятие «cost center» (источник затрат). Источник затрат — это «счет», который отражает стоимость специфической группы деятельностей. В системе Bpwin отношения между источниками затрат и деятельностями — «многие ко многим», т. е. деятельность может относиться к многим источникам затрат, и источник затрат может содержать много деятельностей.

Система также оперирует понятиями «единицы измерения времени» и «количество» (unit of measure) для вычисления стоимости деятельности. Введя данные об источниках и единицах, вы можете установить их связь с деятельностями. Чтобы подсчитать стоимость, необходимо ввести такие данные, как частота (количество циклов родительский детальности), продолжительность (длительность одного цикла), стоимость цикла и к какому источнику эта стоимость относится. Система автоматически рассчитывает стоимость родительских процессов на основе стоимости процессов декомпозиций. Допускается округление вычисленных сумм. Например, вы получили расчетную стоимость процесса и, воспользовавшись некоторым алгоритмом, округлили ее. Можно ввести эту сумму напрямую для любой декомпозиции и также привязать ее к источнику затрат. При этом вы всегда можете использовать как расчетную, так и округленную суммы.

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

5.3 Связь с другими продуктами фирмы Logic Works Предположим, вы достигли той стадии в совершенствовании модели, когда все особенности процесса

смоделированы. Неужели на этом нужно поставить точку? Фирма Logic Works предлагает семейство продуктов для автоматизации моделирования. Между всеми

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

Стрелки в модели IDEF0 могут представлять собой данные. Одни стрелки обозначают устойчивые данные, т. е. которые могут быть сохранены, другие — временные, а некоторые — и те, и другие.

Данные обычно отображаются в виде наборов строк и колонок. Рассмотрим, например, данные типа «потребитель».

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

Модели данных описывают устойчивые данные, а устойчивые данные в модели процесса соответствуют элементам в модели данных. Временные денные не отображаются в моделях данных.

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

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

45

модели. Для модели одного процесса допустима задержка моделирования данных, но параллельное моделирование намного эффективнее.

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

BPwin является хорошим подспорьем для специалистов по реинжинирингу бизнес-процессов и управлению качеством.

46

6 ТИПЫ ПРИЛОЖЕНИЙ 6.1 Классификация Прежде чем приступить к обсуждению методики физического проектирования БД и настройки

параметров, определяющих ее производительность, необходимо хотя бы вкратце рассмотреть основные типы приложений. Во-первых, постараемся уточнить смысл терминов транзакция и запрос. С точки зрения теории баз данных транзакция представляет собой непрерываемый процесс выполнения операций выбора (SELECT), вставки (INSERT), обновления (UPDATE) или удаления (DELETE). В контексте приложения транзакция может пониматься более широко — как некоторое задание, которое может включать комбинации перечисленных выше элементарных операций. Кроме того, язык манипулирования данными непо-средственно ссылается на INSERT, UPDATE или DELETE. Чаще всего под этим подразумеваются операции классов "только запись" (write-only) или "только обновление" (modify-only). Для того чтобы выделить характер операции SELECT как "только для чтения" (read-only) по отношению к ней используется термин запрос (query).

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

• Оперативная обработка транзакций (On-Line Transaction Processing — OLTP). Приложения этого типа в основном используются с развитыми средствами манипулирования данными, их работа связана с интенсивным потоком транзакций, которые выполняют преимущественно обновление данных, реже — вставки или удаления. Классическим примером могут служить системы резервирования билетов или мест в гостиницах. Большое значение для систем типа OLTP имеет параллелизм доступа к данным, то есть одновременный доступ большого количества пользователей к одной БД.

• Системы поддержки принятия решений (Decision Support System — DSS). Системы этого типа опираются как правило на БД большого объема, в которых накапливается информация за достаточно большой период времени. Операции в таких приложениях чаще всего носят характер поиска и считывания ранее сохраненных данных. Часто системы DSS вырастают в объеме до уровня сверхбольших БД или хранилищ информации, в том смысле, как они были определены в разделе 1. Примером подобной системы могут служить системы, находящиеся на верхнем уровне сети intranet предприятия.

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

Ниже приведены менее распространенные типы приложений. • Системы оперативного анализа (On-Line Analytical Processing — OLAP). Как следует из названия,

OLAP-системы предлагают услуги по анализу и обобщению имеющейся в БД информации. В понятие анализа включается разнообразная математическая обработка, получение статистических и обобщающих сведений и тому подобные функции, реализация которых сопряжена с большим объемом вычислений. Системы такого класса фактически сочетают в себе свойства систем OLTP и DSS. Многие полагают, что приложения типа OLAP — это надстройка приложений типов OLTP и DSS. Иногда для уточнения того, что данное аналитическое приложение ориентировано именно на реляционные БД, приложения этого класса обозначают аббревиатурой ROLAP — Relational OLAP. Но по большому счету этот термин мало что добавляет к классификации. OLAP-приложения часто бывают очень тесно связаны с многомерными БД (см. раздел 1), а иногда представляют собой надстройку реляционных СУБД. Примером прикладной системы такого класса может служить система статистического анализа демографической информации.

• БД с переменной структурой (Variable Cardinality Database — VCDB). Приложения этого типа являются, как правило, начальной ступенью в развитой системе обработки данных и служат для формирования таблиц БД, структура которых в процессе построения может в значительной мере изменяться - в основном в сторону увеличения количества атрибутов. Здесь термин cardinality в оригинальном наименовании типа понимается в смысле текущего количества столбцов таблицы. В некоторых случаях это могут быть статические таблицы, но чаще всего для них характерны значительные изменения в количестве записей. Примеры такого рода приложений можно найти в области БД, которые фиксируют данные о текущей состоянии системы, например БД кодов идентификации пользователей с различными привилегиями доступа.

47

6.2 Анализ транзакций в различных типах приложений Анализ транзакций представляет собой количественную оценку процесса функционирования системы.

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

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

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

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

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

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

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

48

7 БИЗНЕС-ПРАВИЛА (ЧАСТЬ I) 7.1 Введение Существует три типа бизнес-правил: для сервера; для клиента; для микропрограммных средств. В этом разделе описана реализация бизнес-правил в приложениях баз данных применительно к серверу. В

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

7.2 Определение бизнес-правил Давайте определим стратегию бизнес-правил. Эффективная реализация бизнес-правил гарантирует, что

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

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

Ограничения хранят недопустимые данные вне базы данных. Они также определяют значения по умолчанию для полей, если никакие значения не присвоены. Пример ограничения: "Поле CustomerNumber в таблице INVOICE должно иметь соответствующую запись в таблице CUSTOMER". Это ограничивает значения в таблице INVOICE. Другой пример ограничения: "Поле PaymentType во всех таблицах должно быть в следующем списке: 'С', 'Н', 'R'". Ограничение, которое определяет значение по умолчанию для поля, могло бы быть выражено так: "Если поле PaymentType не определено, его значение по умолчанию — Cash".

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

Бизнес-правила могут также использоваться для того, чтобы описать источник элемента данных. Описание источника элемента данных показывает, откуда происходит элемент. Откуда берется элемент базы данных? Является ли он суммой колонки Х в таблице Y? Простой пример: "Баланс оплачиваемых счетов главной бухгалтерской книги модифицируется при применении к нему новой транзакции АР". Это определяет источник баланса оплачиваемых счетов главной бухгалтерской книги.

По возможности, следует избегать базирования одного элемента данных на другом. Я не говорю, что этого никогда нельзя делать, только для того, чтобы вы могли тщательно рассмотреть все возможные ответвления. Получение одного элемента данных из другого создает внутритабличные зависимости. Если исходные данные меняются, зависимые данные также потребуют изменений. Вы можете избежать этого, применяя механизмы "сохранения" данных. Данные, которые были сохранены, модифицируют зависимые элементы (как в примере баланса книги счетов GL), таким образом делая себя недоступными для редактирования — никакие дальнейшие модификации не разрешаются, если зависимые элементы модифицировались.

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

7.3 Реализация бизнес-правил для сервера 7.3.1 Введение Может быть, это предубеждение, но я сторонник размещения бизнес-правил на сервере. Поскольку микропрограммные средства для бизнес-правил еще недостаточно распространены, чтобы

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

49

Я думаю, что причины моих убеждений станут более очевидными после обсуждения "за" и "против" этих трех моделей.

7.3.2 Преимущества реализации бизнес-правил для сервера При размещении бизнес-правил на сервере базы данных данные самостоятельно защищаются от

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

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

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

Серверы баз данных, обычно, достаточно мобильны. Это значит, что, если Вам требуется достичь максимальной эффективности, которую может предоставить данная аппаратная платформа, вы можете переместить сервер и банк данных на более мощную аппаратную платформу без смены производителей системы управления базой данных или перепроектирования базы данных. Этот же тип мобильности должен был бы присутствовать в микропрограммных средствах и реализациях клиента, чтобы он был жизнеспособен. Однако это не так. Если ваши клиенты используют Windows, вы, в основном, связаны с платформой Intel. Конечно, Windows NT также доступна на некоторых других платформах, но она не переносима так, как Sybase SQL Server, который доступен почти на всех основных аппаратных платформах и операционных системах.

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

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

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

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

Ответ на это находится в требовании к производителям систем управления базами данных увеличить возможные взаимодействия между серверами и между базами данных. Sybase, например, поддерживает запросы базами данных уже много лет. Кроме того, такая технология, как Replication Server в Sybase решает проблему взаимоотношений между серверами, позволяя создавать ключевые таблицы, которые автоматически копируются с одного сервера на другой. Решение состоит не в перескакивании на другую незрелую технологию, а во влиянии на существующих производителен, чтобы они разрабатывали средства связи между серверами и базами данных.

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

Выход заключается в требовании от производителей клиентского программного обеспечения (например,

50

от Borland) обеспечения полной поддержки соответствующих серверов. Если Delphi обеспечивает поддержку для Sybase SQL Server, эта поддержка должна быть полной и распространятся на все связанные с клиентом средства, которые обеспечивает SQL сервер, включая обнаружение нарушений бизнес-правил.

7.3.4 Преимущества реализации бизнес-правил для клиента При реализации бизнес-правил для клиента устанавливается высокий уровень настройки и контроля,

существующий при работе с отчетами и ответами на бизнес-правила. Контроль "поле-за-полем" хорошо использует инструментальные средства внешнего интерфейса. Например, довольно просто запретить пользователю выход из формы, пока ее данные недопустимы.

Другое преимущество клиентской реализации — богатство языков программирования, по сравнению с SQL. Object Pascal — значительно богаче, как язык, чем SQL. Даже BASIC — более разнообразный язык, чем SQL.

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

7.3.5 Недостатки реализации бизнес-правил для клиента Главным недостатком размещения бизнес-правил исключительно для клиента является потребность в

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

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

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

Другая проблема с реализацией бизнес-правил в клиентских приложениях состоит в том, что такие реализации имеют несовместимые инструменты. Это значит, что вы должны будете "изобретать велосипед", если вам необходимо, скажем, разработать приложение, которое модифицирует данную таблицу в Delphi на этой неделе, и приложение, которое модифицирует ее в Borland C++ на следующей. Так как приложение Borland C++ не может обращаться к бизнес-правилам, которые вы встроили в приложение Delphi, вы должны будете повторить эту операцию в приложении C++. Ситуация ухудшается, когда существует перспектива работы с инструментальными средствами от нескольких производителей. Даже если BDE будет расширена, чтобы поддерживать бизнес-правила для несовместимых инструментов, вы все еще будете испытывать большие трудности, пытаясь использовать эту возможность в приложениях, связанньгх с, скажем, Visual Basic.

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

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

7.3.6 Сильные стороны промежуточных средств Промежуточные средства находятся на уровне программного обеспечения между клиентом и сервером.

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

51

определены в объектах операционной системы, ссылающихся на объекты сервера базы данных. Некоторые операционные системы, например NeXTSTEP, сделали значительные шаги в этом направлении.

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

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

7.3.7 Слабые стороны промежуточных средств Единственная проблема с промежуточным подходом состоит в том, что нет достаточного количества

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

Логично было бы установить переносимые определения бизнес-правил или в ODBC, или в IDAPI. Проблема состоит в том, что ODBC и IDAPI являются неотъемлемой частью платформы Windows. Если Вы должны разработать приложение базы данных UNIX, Вам это не удастся. Вы не сможете использовать бизнес-правила, определенные на уровне драйвера базы данных в Windows.

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

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

7.4 Реализация бизнес-правил на сервере 7.4.1 Введение Теперь, когда мы определили правильную стратегию бизнес-правил, как лучше реализовать ее? Выбор

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

7.4.2 Первый этап Первое, что надо будет сделать при разработке схемы бизнес-правил — вместе с пользователями

приложения или базы данных разработать каждое правило и каждую стратегию, которая может применяться к соответствующим данным. Лучший способ сделать это состоит в том, чтобы использовать простые предложения, написанные доступным языком. Сделать это стоит сразу после того, как вы проанализировали состав полей в таблицах приложения или базы данных. Некоторые примеры бизнес-правил: · Каждый номер счета в таблице INVOICE должен быть уникален. · Каждый номер заказчика в таблице в таблице INVOICE должен иметь соответствующую строку в таб-

лице CUSTOMER. · Принимаемые кредитные карточки — Visa, Mastercard и American Express. · Каждая строка в счете подытоживается, умножая стоимость элемента на количество заказов. · Запись заголовка счета не может быть удалена, пока имеются записи счетов, которые ему соответствуют.

Если не определено иначе, заданный по умолчанию метод пересылки — Federal Express. Каждое поле в каждой таблице должно быть рассмотрено. Должны быть приложены все усилия, чтобы

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

7.4.3 Ограничения первичного ключа В терминах SQL, ограничения — транспортное средство, часто используемое при реализации бизнес-

52

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

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

Первый применяемый тип ограничения — ограничение первичного ключа. Он обозначает, какие поля в таблице единственным образом идентифицируют каждую строку. Первичный ключ — заданный по умолчанию метод доступа к таблице. Примеры первичных ключей— поле InvoiceNumber в таблице INVOICE и поле CustomerNumhpr в таблице CUSTOMER. Добавляя ограничение Первичного ключа, вы заставляете сервер базы данных гарантировать, что значения, вставленные в поле первичного ключа, уникальны внутри таблицы. Хотя вы обычно определяете ограничение первичного ключа во время создания таблицы, вы можете захотеть определить его позже. Вот синтаксис SQL для добавления ограничения первичного ключа после того, как таблица была создана:

ALTER TABLE CUSTOMER ADD PRIMARY KEY (CustomerNuinber) 7.4.4 Ограничения внешнего ключа Ограничения внешнего ключа популярны для определения связей между таблицами. Они вынуждают

значение в поле в одной таблице существовать в другой таблице. Аналогично, они предотвращают стирание данных из второй таблицы, имеющих связи в первой. Вы используете ограничение внешнего ключа, например, чтобы гарантировать, что все числа заказчика, перечисленные в поле CustomerNumber таблицы INVOICE, существуют в таблице CUSTOMER. Обычно вы создаете внешний ключ одновременно с таблицей, но иногда это необходимо сделать позже. Вот синтаксис SQL для добавления ограничения внешнего ключа:

ALTER TABLE ORDERS ADD FOREIGN KEY (CustomerNumber) REFERENCES CUSTOMER 7.4.5 Ограничения проверки Еще один тип ограничения — ограничения проверки. Ограничение проверки гарантирует, что значение,

вставленное в поле, существует в данном наборе фиксированных значении. Предположим, что данная организация розничной торговли принимает только некоторые кредитные карточки, например. Visa, Mastercard и American Express. Это — фиксированный набор значений, и вы могли бы закодировать его как ограничение проверки, используя следующий синтаксис SQL:

ALTER TABLE ORDERS ADD CONSTRAINT INVALID CREDIT CARD CHECK (CreditCardType in ('V','H','A'))

7.4.6 Значения по умолчанию Значения по умолчанию для полей определяют значение, которое получает поле во время операции

INSERT, если она не определяет его. Существует тенденция среди разработчиков устанавливать значения полей по умолчанию, используя код программы. Например, вы можете использовать событие OnNewRecord в Delphi. Однако при этом необходимо "рыться" в коде программы, чтобы найти значения по умолчанию для полей данной таблицы. Гораздо лучше сохранять эти значения по умолчанию на сервере, где они могут быть легко просмотрены или изменены.

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

ALTER TABLE ORDERS ADD CreditCardType char(l) DEFAULT 'V' 7.4.7 Просмотры Иногда для реализации некоторого бизнес-правила удобно использовать просмотр таблицы SQL.

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

Вот просмотр для вычисления итога элемента строки счета: CREATE VIEW INVOICEDETAIL AS SELECT InvoiceNumber, LineNumber, PriceEach * UnitsOrdered as ExtendedTotal FROM INVOICE Этот просмотр осуществляет бизнес-правило, которое гласит, "Каждая строка в счете подытоживается,

умножая стоимость элемента на количество заказов".

53

7.4.8 Триггеры Когда все остальное не удается, обычно могут помочь триггеры. Многие платформы содержат

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

CREATE TRIGGER ORDERSlnsert FOR ORDERS BEFORE INSERT AS BEGIN

IF (New.CreditCardType='V' AND New.Amount<50.00) THEN EXCEPTION BELOW MINIMUM VISA; END Этот триггер гарантирует, что заказы, сделанные с помощью кредитной карточки Visa, — $50 или больше.

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

7.4.9 Хранимые процедуры В некоторых диалектах SQL имеется тенденция использовать хранимые процедуры для выполнения

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

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

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

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

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

CREATE PROCEDURE POSTAP (APACCCOUNT) AS DECLARE VARIABLE APTOTAL FLOAT BEGIN

SELECT SUM(AmountOfTransaction) as TranAmount INTO :APTOTAL FROM APTRANS; UPDATE GLBAL SET APMonthEndBalance=APMonthEndBalance+:APTOTAL WHERE AccountNumber=:APACCOUNT;

END Эта процедура определяет поле APMonthEndBalance как происходящее от поля AmountOfTransaction

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

Хранимые процедуры хороши для подобных ситуаций, потому что они могут выполнять столько команд SELECT, сколько нужно. Они особенно хорошо подходят для таких пакетных операций, как сохранение подпрограмм.

54

8 БИЗНЕС-ПРАВИЛА (ЧАСТЬ II) 8.1 Введение В этом разделе обсуждается вопрос успешной реализации бизнес-правил, основанных на приложении. Как

говорилось в предыдущем разделе, бизнес-правила должны реализовываться на SQL-сервере, когда это возможно. Однако неизбежно, что вы должны будете дополнять бизнес-правила сервера правилами клиента.

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

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

К их чести, производители систем управления базами данных делают большие успехи в поддержке их стратегий бизнес-правил. В прошлом, большинство реализации бизнес-правил было безопасно, — но недружелюбно. Разработчики сталкивались с трудностями, пытаясь заставить работать вместе объекты базы данных и объекты приложения. Например, если в Sybase используется триггер, чтобы обеспечить значения по умолчанию для строк таблицы, как об этом узнает приложение, чтобы отобразить заданные по умолчанию значения поля на экране, когда пользователь добавит строку к таблице? Разработчик вынужден был выбирать меньшее из двух зол: или игнорировать бизнес-правило сервера и дублировать его в разрабатываемых приложениях, или отказываться от необходимости синхронизировать вид приложения на экране с копиями базы данных. Ни одно из этих решений не было особенно привлекательно, и, как заметил однажды Джерри Гарсия: "Выбор меньшего из двух зол, тем не менее, выбор зла".

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

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

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

· уровень типа данных; · уровень компонента; · уровень TField; · уровень TDataSet.

8.2 Типы бизнес-правил Бизнес-правила делятся на два различных типа: элементарные и расширенные. Элементарные правила

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

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

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

55

вообще. Delphi обеспечивает ряд способов построения элементарных бизнес-правил без кодирования чего бы то ни

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

8.3 Два правила бизнес-правил Существуют два фундаментальных положения теории разработки бизнес-правил. Следуя этим двум

основным правилам, вы обезопасите себя от большинства проблем, с которыми сталкиваются разработчики. Правило №1 Первое правило при установке бизнес-правил клиента — начинать с использования соответствующих

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

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

Другой случай, когда использование правильного типа данных критично для правильной разработки деловых правил, работа с полями, которые содержат последовательные значения. Вы могли бы, конечно, осуществить систему последовательной нумерации через код или даже через триггеры базы данных, однако предпочтительнее в первую очередь использовать типы данных, которым присуще свойство последовательности. Sybase называет их полями идентификации, в Paradox они известны как автоинкрементные поля. Используя правильный тип данных в этой ситуации, вы освобождаете себя от необходимости поддержки последовательных чисел самостоятельно и гарантируете, что необходимо базисное правило — числа в поле Y таблицы X, должны быть последовательными — обеспечивается без чрезмерных усилий с вашей стороны.

Правило №2 Второе правило при реализации бизнес-правил, основанных на приложении, — использование

компонентов Delphi, которые лучше всего подходят соответствующим типам данных. Самая распространенная ошибка разработчиков в этом отношении состоит в использовании простых текстовых компонентов. Эти текстовые компоненты (типа DBEdit, TEdit и TMaskEdit) часто позволяют вводить в поле такие данные, которые являются недопустимыми для соответствующего типа данных компонента. Этого можно обычно избежать, используя правильный компонент. Например, вы не должны использовать DBEdit для булева поля. Поле может иметь только два значения: True и False. Используйте вместо этого выключатель, переключатели или раскрывающийся список. Не используйте DBEdit для поля, которое установлено только для чтения; используйте вместо этого компонент DBText. Это сохраняет ресурсы системы и вас от необходимости устанавливать свойство Readonly компонента. Кроме того, вы не должны использовать DBEdit для числового поля, которое может иметь только несколько допустимых значений. Используйте вместо этого DBRadioGroup.

В табл. 8.1 представлены компоненты с соответствующими основными типами данных. Таблица 8.1 - Типы данных полей и соответствующие им компоненты VCL

Тип данных Компоненты Булев DBCheckBox, DBRadioGroup, DBComboBox,

DBListBox Дата DBEdit, Calendar, SpinEdit Числовой (позволяет большое количество значений) DBEdit, SpinEdit Числовой (позволяет только несколько значений) DBRadioGroup Строка (позволяет большое количество значений) DBEdit Строка (позволяет только несколько значений) DBComboBox, DBListBox

Это только общие руководящие принципы. Основное правило здесь — использовать компонент, который

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

56

8.4 Компоненты пользователя Благодаря тому, что архитектура Delphi основана на компонентах, был выпущен ряд качественных

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

Эти инструментальные средства обычно дают возможность вам определить все от индивидуальных масок ввода поля до сложных связей между таблицами. Это, особенно с Delphi 1.0, очень практичный подход к построению надежных реализации бизнес-правил.

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

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

8.5 Свойства TField и бизнес-правила Бизнес-правила обычно обращаются к более сложным объектам, чем простые маски поля и метки. Все

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

Существует два способа реализации элементарных бизнес-правил с использованием установок свойств компонента TField. Первый метод состоит в том, чтобы использовать словарь данных в Delphi и устанавливать соответствующие свойства TField с помощью наборов атрибутов. Второй метод состоит в том, чтобы установить эти свойства TField непосредственно в компонентах DataSet приложения. В первую очередь используйте словарь данных, чтобы определить установки TField. То, что вы не можете определить через словарь, или то, что не имеет смысла определять в словаре, может быть установлено в компонентах DataSet непосредственно. Эта глава исследует оба метода так, чтобы вы могли видеть относительные выгоды каждого подхода.

8.6 Словарь данных Delphi Вне зависимости от выбора соответствующего класса компонента для представления типов данных

следующий уровень определения бизнес-правил, основанных на приложении, — атрибуты полей. Атрибуты поля устанавливаются с помощью свойств класса компонентов TField. Они включают такие характеристики поля, как ввод и шаблоны редактирования, минимальные и максимальные допустимые значения для поля, флажки, указывающие, должно ли поле иметь значение и может ли оно изменяться и т.д. Вы можете обращаться к словарю данных в Delphi через опцию Explore из меню Database в Delphi. Словарь данных дает вам возможность определить наборы атрибутов, которые вы затем можете применить к полям таблицы в базе данных. Ссылаясь на эти поля в приложении Delphi, вы увидите установки свойства, которые вы определили раньше, отраженными в редакторе полей Delphi и непосредственно в приложении.

57

9 ОСНОВЫ ПОСТРОЕНИЯ ПРИЛОЖЕНИЙ 9.1 Общие сведения Существует пять стадии разработки приложения базы данных. Приведем этот список: 1. Определение назначения и задач приложения. 2. Проектирование структуры базы данных и прикладных процессов, необходимых для реализации

этих задач. 3. Воплощение проекта в приложение путем создания необходимых объектов баз данных и объектов

программы. 4. Тестирование приложения на соответствие поставленным целям. 5. Инсталляция приложения для эксплуатации пользователем.

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

9.2 Проектирование структуры базы данных и прикладных процессов 9.2.1 Введение Заложив фундамент базы данных, переходите к построению прикладных бизнес-процессов, необходимых

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

9.2.2 Выбор типа приложения Первым шагом в проектировании процессов, составляющих разрабатываемое вами приложение, является

выбор его типа. Различаются два типа организации приложений: системы принятия решений и системы обработки транзакций. Вообще говоря, системы принятия решений используются управляющим персоналом компании для получения обобщенного представления о некоторой порции данных. Системы обработки транзакций, с другой стороны, несут ответственность за ввод и обработку этих данных. Первые нуждаются в доступе к данным только в режиме чтения, а вторые должны уметь как считывать, так и записывать данные. Учитывая эти фундаментальные различия, вы должны четко определиться с типом приложения, к разработке которого вы приступаете (смотри раздел 6).

9.2.3 Схема работы приложения Используя список операционных процессов, изобразите протекание каждого отдельного процесса

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

58

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

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

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

9.2.4 Укажите типы операционных элементов Вы должны "пройти" по всем элементам, из которых состоят ваши операционные процессы, и указать тип

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

59

Рис. 9.3 - Узлы внутри процессов приложения с указанными типами

9.3 Проектирование иерархий форм и отчетов Наметив, какие формы и отчеты необходимы вашему приложению, разработайте отдельную иерархию для

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

9.4 Оценка и заимствование стороннего кода Теперь попытайтесь определить, какие вам могут потребоваться библиотеки и сторонние программы. В

качестве примеров популярных библиотек, используемых мною в приложениях Delphi, могу привести Orpheus Visual Component Library и Asynch Professional из TurboPower Software. Об использовании библиотек поддержки, возможно, вам придется посоветоваться с руководителями подразделений, в которых они были разработаны. Теперь, когда вы решили, какие процессы будут иметь соответствующие формы, а какие — неинтерактивный код, можно подумать над тем, какие библиотеки вам пригодятся. Гораздо лучше сделать это сейчас, чем откладывать до той поры, пока вам на самом деле потребуется приобрести библиотеку, приостанавливая работу над проектом до ее появления.

9.5 Планирование процессов разработки Следующий шаг, на который вам следует направить свои усилия, заключается в планировании разработки

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

60

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

9.6 Сроки исполнения Процесс планирования проекта вместе со сроками исполнения — это нечто из области черной магии. Это

сложный процесс, который варьируется от исполнителя к исполнителю. Он еще более усложняется, когда в разработке участвует целый коллектив. Меня не так волнует объем времени, который потребуется для полного завершения вашего приложения, как порядок действий. Я оставлю оценку времени для вас (это как раз то, за что вам платят!).

9.7 Построение приложения Наконец мы подошли к разработке самого приложения в соответствии с намеченным нами планом.

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

Проектирование форм Подход, применяемый для разработки форм, очень зависим от типа приложения, которое вы строите, а

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

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

1. Выберите стиль. Стиль определит внешний вид вашего приложения и скажется на внешнем виде форм, его составляющих. В мире приложений Windows широкое применение получили три стиля: Corel PerfectOffice, Lotus SmartSuit и Microsoft Office. Если вы выберите Corel PerfectOffice, то ваше приложение и формы, из которых оно состоит, будет напоминать Quattro Pro WordPerfect, если выберите SmartSuit, то оно будет похожим на Lotus 1-2-3 и WordPro. А если остановите свой выбор на Microsoft Office, то получите имитацию Word или Excel.

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

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

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

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

5. Используйте интерфейс форм SDI (Single Document Interface — Интерфейс для работы с одним документом), а не MDI (Multiple Document Interface — Интерфейс для работы с несколькими документами).

61

10 ПРИМЕР ПРИЛОЖЕНИЕ БАЗ ДАННЫХ НА DELPHI 10.1 Введение С помощью Delphi вы начнете конструировать приложение средней сложности, предназначенное для

работы с базами данных. Это приложение мы назовем Системой учета работ по обслуживанию арендованной недвижимости

(Rental Maintenance Management System — RENTALMAN). Вы познакомитесь с самыми важными моментами разработки мощных приложений для работы с базами данных в среде Windows. Как и во всех остальных разделах, основное внимание здесь будет уделяться прагматичной стороне дела (что и как работает).

Как уже было сказано в разделе 9, процесс создания базы данных разбивается на пять следующих этапов. 1. Определение задач, которые должно выполнять приложение. 2. Разработка основы базы данных, а также соответствующих процессов, необходимых для достижения

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

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

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

соответствующее описание целей разработки. Это описание должно состоять из одного приложения, в котором должны присутствовать подлежащее, сказуемое и дополнение к сказуемому. Подлежащее— ваше приложение (например, "Система RENTALMAN..."), сказуемое описывает действия, выполняемые приложением (например, "Система RentalMan ведет статистику..."), и дополнение, описывающее, над чем же выполняются приложением эти действия (например, "Система RENTALMAN ведет статистику проведения работ по обслуживанию арендованной недвижимости").

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

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

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

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

Система RENTALMAN должна вести учет работ по обслуживанию арендованной недвижимости: · записывать поступающие вызовы; · следить за исполнением работ по обслуживанию; · предоставлять информацию о проведенных работах.

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

Закончив определение целей приложения, приступайте к разработке баз данных и объектов программы, необходимых для достижения этих целей.

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

RENTALMAN. Процесс разработки базы данных начинается с моделирования объектов, необходимых для выполнения задач приложения. Предположим, что никакие дополнительные объекты нам для работы не понадобится. Таким образом, можно сконструировать единственную базу данных, содержащую все

62

используемые в этом приложении объекты. Основной акцент при моделировании структуры данных будет сделан на ее использовании в приложении, а не на ее качествах. В главе 6 описаны относительные достоинства и недостатки каждого из этих подходов.

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

Программа RENTALMAN должна выполнять следующие операции. 1. Система RENTALMAN должна вести учет работ по обслуживанию арендованной недвижимости:

· записывать все поступающие вызовы; · создавать "журнал" вызовов по мере их получения; · добавлять полученные вызовы в новый или существующий порядок исполнения.

2. Следить за исполнением работ по обслуживанию: · вести список открытых заказов на исполнение работ; · разрабатывать расписание работ для каждого служащего.

3. Предоставлять информацию о проведенных работах: · вести статистику выполнения работ по обслуживанию каждого конкретного объекта; · вести статистику выполнения каждого типа работ на объектах.

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

10.5 Определение необходимых для работы объектов базы данных Рассмотрев определенные вами процессы, решите, какие таблицы понадобятся для их обслуживания.

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

Этот список строится в результате построения следующей цепи рассуждений. 1. Первая из основных задач приложения — регистрация входящих вызовов от арендаторов. Очевидно,

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

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

3. И наконец, желательно выяснить, на каких объектах выполнялись определенные типы работ (например, регулярная профилактика систем кондиционирования воздуха), так что без классификации выполненных заказов не обойтись. С точки зрения реляционных DBMS, оптимальным способом выполнения этих требований будет хранение кода типа выполняемых работ в записи о каждом заказе. Затем будет создана основная или связанная таблица, использование которой позволит перевести эти коды в значащие описания (т.е. потребуется таблица для регистрации типов выполненных работ).

10.5 Проверка существующих баз данных

63

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

10.6 Создание хранилища полей После того как вы определили, какие таблицы вам понадобятся, определите столбцы, которые эти

таблицы должны содержать. Используя созданный вами список таблиц, составьте список информационных элементов, которые должна содержать каждая из этих таблиц. В табл. 10.1-10.7 представлены приблизительные списки полей определенных до сих пор таблиц базы данных.

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

Следующим шагом в составлении списка полей будет соединение их всех в один большой список содержащихся во всей базе данных полей. Каждое поле должно быть внесено в список только один раз. При внесении полей в список определите оптимальный тип данных, которые будут храниться в этом поле и его максимальный размер. Используйте полученный список в качестве основной описи доменов и пользуйтесь им при создании таблиц. Некоторые инструментальные средства обращаются к этому списку как к словарю данных или таблице ссылок. Для обращения к информации такого типа Delphi использует термин набор атрибутов (Attribute Set). Вы можете приравнять эти атрибуты к шаблонам полей — они определяют вид данного атрибута базы данных во всех таблицах, в которых он появляется. Прежде всего, создадим полный список уже определенных столбцов таблиц (табл. 10.8).

Теперь нужно присвоить атрибуты всем имеющимся в списке столбцам. Обдумайте тип данных, который будет использован в каждом из полей. Если вы знаете, на какой DBMS-платформе будет реализовано ваше приложение, можете присвоить полям поддерживаемые платформой типы данных уже на этом этапе. Поскольку система RENTALMAN разрабатывается нами для платформы Paradox, нужно использовать поддерживаемые ею типы полей.

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

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

Табл. 10.10 содержит дополненный список полей, с размерами каждого столбца.

64

Таблица 10.1. Список столбцов таблицы TENANT

Таблица 10.2. Список столбцов таблицы PROPERTY

Таблица Столбец

TENANT TenantNo Name Employer EmpAddress EmpCity EmpState EmpZip Home Phone WorkPhone ICEPhone LeaseBeginDate LeaseEndDate MovedInDate MovedOutDate RentDueDate PetDeposit LawnService

Conments


PROPERTY PropertyNo TenantNo Address City State Zip Addition BedRooms LivingAreas BathRooms GarageType School District Deposip Rent Range Refigerator DishWasher CentralAir GasHeat PrivacyFence Last Spray Date LastLawnDate

Comments

Таблица 10.3. Список столбцов таблицы CALLS

Таблица 10.4. Список столбцов таблицы WORDERS


CALLS CalINo CallDateTime PropertyNo Description Priority WorkOrderNo

Comments


WORDERS WorkOrderNo

PropertyNo

EmployeeNo

StartDate

EndDate

Comments

Таблица 10.5. Список столбцов таблицы WDETAIL

Таблица 10.6. Список столбцов таблицы EMPLOYEE


WDETAIL WorkOrderNo LineNo

WorkTypeCode


EMPLOYEE EmployeeNo

Name

Таблица 10.7. Список столбцов таблицы WORKTVPE Таблица Столбец

WORKTYPE 'WorkTypeCode Description TaskDuration

65

Таблица 10.8. Приблизительный список полей таблиц системы RENTALMAN Столбец Столбец Столбец

Addition EmpState PetDeposit Address EmpZip Priority Baths EndDate Privacy Fence Beds GarageType PropertyNo CallDateTime GasHeat Range CalINo HomePhone Refigerator CentralAir ICEPhone Rent CentralAir LastLawnDate RentDueDate City LastSprayDate SchoolDistrict Comments LawnService StartDate Deposip LeaseBeginDate State Description LeaseEndDate TaskDuration Dishwasher LineNo TenantNo EmpAddress LivingAreas WorkOrderNo EmpCity MovedInDate WorkPhone EmployeeNo MovedOutDate WorkTypeCode Employer Name Zip Таблица 10.9. Почти полный список полей базы данных системы RENTALMAN Столбец Тип Столбец Тип

Addition Alpha LawnService Logical Address Alpha LeaseBeginDate Date BathRooms Short LeaseEndDate Date BedRooms Short LineNo Short CallDateTime Date LivingAreas Short CalINo Autolncrement MovedInDate Date CentralAir Logical MovedOutDate Date CentralHeat Logical Name Alpha City Alpha PetDeposit Money Comments Alpha Priority Alpha Deposip Money Privacy Fence Logical Description Alpha PropertyNo Autolncrement Dishwasher Logical Range Logical EmpAddress Alpha Refigerator Logical EmpCity Alpha Rent Money EmployeeNo Autolncrement RentDueDate Short Employer Alpha SchoolDistrict Alpha EmpState Alpha StartDate Date EmpZip Alpha State Alpha EndDate Date TaskDuration Number GarageType Short TenantNo Autolncrement GasHeat Logical WorkOrderNo Autolncrement HomePhone Alpha WorkPhone Alpha ICEPhone Alpha WorkTypeCode Short LastLawnDate Date Zip Alpha LastSprayDate Date

66

Таблица 10.10. Практически полный список полей базы данных системы RENTALMAN Столбец Тип Размер Столбец Тип Размер

Addition Alpha 10

Address Alpha 30 LawnService Logical BathRooms Short

LeaseBeginDate Date

BedRooms Short

LeaseEndDate Date CallDateTime Date

LineNo Short

CalINo Autolncrement

LivingAreas Short CentralAir Logical

MovedInDate Date

CentralHeat Logical

MovedOutDate Date City Alpha 20 Name Alpha Comments Alpha 100 PetDeposit Money Deposip Money

Priority Alpha

Description Alpha 30 Privacy Fence Logical DishWasher Logical

PropertyNo Autolncrement

EmpAddress Alpha 30 Range Logical EmpCity Alpha 20 Refigerator Logical EmployeeNo Autolncrement

Rent Money

Employer Alpha 30 RentDueDate Short EmpState Alpha 2 SchoolDistrict Alpha 10

EmpZip Alpha 10 StartDate Date EndDate Date

State Alpha 2

GarageType Short

TaskDuration Number GasHeat Logical

TenantNo Autolncrement

Home Phone Alpha 10 WorkOrderNo Autolncrement ICEPhone Alpha 10 WorkPhone Alpha 10

LastLawnDate Date

WorkTypeCode Short LastSprayDate Date

Zip Alpha 10

10.7 Пользовательские типы данных Если платформа, для которой разрабатывается приложение, поддерживает пользовательские типы данных,

на этом этапе самое время подумать о их использовании. Пользовательский тип данных — просто способ сократить процедуру доступа к типу, уже поддерживаемому сервером. В терминологии InterBase пользовательские типы называются доменами (domains). Они позволяют просто и удобно определять подобные столбцы таблиц. При внимательном рассмотрении предыдущей таблицы определений столбцов можно выявить несколько потенциальных пользовательских типов данных, представленных в табл. 10.11.

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

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

67

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

Таблица 10.11. Возможные пользовательские типы данных Тип

пользователя Столбцы Тип Req Допустимые

значения Значение по

умолчанию RoomCountType BathRooms,

BedRooms, LivingAreas, GarageType

Short Y 0-10

AddressType Address, EmpAdders

Alpha(30) Y

CityType City, EmpCity Alpha(20) Y

ср.

CommentsType Comments (во всех таблицах)

Alpha(lOO) N

DescriptionType Description(во всех таблицах)

Alpha(30)

NameType Name, Emp1oyer Alpha(30) Y

PhoneType HomePhone, WorkPhone, ICEPone

Alpha(lO) Y

StateType ZipCode Alpha(2) Y

OK

ZipCodeType EmpZipCode Alpha(lO) Y

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

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

Таблица 10.12. Полный список полей системы RENTALMAN Столбец Тип Размер Req Допустимые

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

Addition Alpha 10 Y

HMR Address AddressType

Y

BathRooms RoomCountType

BedRooms RoomCountType

CallDateTime Timestanmp

Y

Текущие дата и

время CalINo Autolncrement

Y

CentralAir Logical

Y

Т

CentralHeat Logical

Y

Т City CityType

Comments CommentsType

Deposip Money

Y

Аренда

Description DescriptionType

DishWasher Logical

Y

Т

EmpAddress AddressType

Y

EmpCity CityType

EmployeeNo Autolncrement

Y

68

Продолжение табл 10.12

Столбец Тип Размер Req Допустимые значения

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

Employer NameType EmpState StateType EmpZip ZipCodeType

Y

EndDate Date

N

GarageType RoomCountType

GasHeat Logical

Y

Т

Home Phone PhoneType

ICEPhone PhoneType

LastLawnDate Date

N

LastSprayDate Date

N

LawnService Logical

Y

Y

LeaseBeginDate Date

Y

LeaseEndDate Date

Y

LineNo Short

LivingAreas RoomCountType

MovedInDate Date

Y

MovedOutDate Date

N

Name NameType

PetDeposit Money

Y

$0

Priority Alpha

Y L,M,H 'м' PrivacyFence Logical

Y

т


Y

Range Logical

Y

т

Refigerator Logical

Y

т Rent Money

Y

$650

RentDueDate Short

Y 1,15 1 SchoolDistrict Alpha 15 N

PUTNAM CITY

StartDate Date

Y

State StateType

TaskDuration Number

Y


Y

WorkOrderNo Autolncrement

Y

WorkPhone, PhoneType

WorkTypeCode Short

Y

Zip ZipCodeType

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

Заметьте также и то, что некоторые детали атрибутов (например, спецификации шаблонов редактирования и вывод каждого столбца) в списке опущены.

Нужно также отметить некоторые описанные здесь атрибуты баз данных, которые вы не сможете определить при конструировании базы данных системы RENTALMAN на платформе Paradox. Например, в проекте таблицы PROPERTY столбец Deposit принимает по умолчанию значение столбца Rent, так как объем вносимого за аренду недвижимости задатка обычно равен месячной ренте. При встрече с такими ситуациями вам придется устанавливать значения по умолчанию из соответствующего Delphi-приложения либо с помощью триггера.

69

10.8 Использование хранилища полей при конструировании определений Следующим этапом работы над списком полей будет его разбор на составляющие таблицы. Перенесите

законченные определения полей из списка в описанные вами структуры таблиц. Проект базы данных системы RENTALMAN медленно, но верно обретает законченную форму. Табл. 10.13-10.19 содержат новые определения каждой из таблиц системы.

Таблица 10.13. Окончательный проект таблицы TENANT




Y

Name NameType

Y

Employer NameType

EmpAddress AddressType

EmpCity CityType

EmpState StateType

EmpZip ZipCodeType

Home Phone PhoneType

WorkPhone PhoneType

ICE Phone PhoneType

LeaseBeginDate Date

Y

LeaseEndDate Date

Y

MovedInDate Date

Y

MovedOutDate Date

N

RentDueDate Short

Y 1,15 1

PetDeposit Money

Y

$0 LawnService Logical

Y

Y


Таблица 10.14. Окончательный проект таблицы PROPERTY




Y


N

Address AddressType

City CityType

State StateType

Zip ZipCodeType

Addition Alpha 15 Y

HMR

BedRooms RoomCountType

LivingAreas RoomCountType

BathRooms RoomCountType

GarageType RoomCountType

SchoolDistrict Alpha 15 N

PUTNAM CITY

70

Таблица 8.14. Окончательный проект таблицы PROPERTY Столбец Тип Размер Req Допустимые


умолчанию

Deposip Money

Y

Аренда Rent Money

Y

$650

Range Logical

Y

Т Refigerator Logical

Y

Т

Dishwasher Logical

Y

Т CentralHeat Logical

Y

Т

CentralAir Logical

Y

Т GasHeat Logical

Y

Т

PrivacyFence Logical

Y

Т Last Spray Date Date

N

LastLawnDate Date

N


Таблица 10.15. Окончательный проект таблицы CALLS Столбец Тип Размер Req Допустимые


умолчанию

CalINo Autolncrement

Y

CallDateTime Timestanmp

Y

Текущие дата и

время PropertyNo Long


Priority Alpha

Y L,M,H 'L'

WorkOrderNo Long

N


Таблица 10.16. Окончательный проект таблицы WORDERS Столбец Тип Размер Req Допустимые


умолчанию

WorkOrderNo Autolncrement

Y

PropertyNo Long

Y

EmployeeNo Long

Y

StartDate Date

Y

EndDate Date

N


Таблица 10.17. Окончательный проект таблицы WODETAIL Столбец Тип Размер Req Допустимые


умолчанию

WorkOrderNo Long

Y

LineNo Autolncrement

Y

WorkTypeCode Short

Y


71

Таблица 10.18. Окончательный проект таблицы EMPLOYEE Столбец Тип Размер Req Допустимые


умолчанию

EmployeeNo Autolncrement

Y

Name NameType

Таблица 10.19. Окончательный проект таблицы WORKTYPE Столбец Тип Размер Req Допустимые


умолчанию

WorkTypeCode Short

Y


Y

TaskDuration Number

Y

10.9 Организация таблиц по типам Следующим этапом разработки базы данных системы RENTALMAN является разделение уже

определенных таблиц на базовые и транзакционные. Базовые таблицы содержат уникальную по определению информацию. Транзакционные же таблицы получают данные, собранные автоматически или введенные пользователями. Примером базовой таблицы может служит таблица PROPERTY. Поскольку каждая запись таблицы PROPERTY представляет собой уникальный объект (часть сдаваемой в аренду недвижимости) это базовая таблица. Базовые таблицы часто используются для трансляции кодов, номеров или аббревиатур в более удобные для восприятия значащие формы. Обычно они статичны или очень мало изменяются со временем. Транзакционные таблицы, напротив, часто изменяются, и являются наименее постоянной частью базы данных. Таблица CALLS является транзакционной, так как она будет использоваться для хранения информации о исходящих от арендаторов вызовах, по мере их ежедневного поступления. Вероятно, со временем она увеличится в размерах, в то время как таблица PROPERTY не будет расти, если компания не приобретет новую недвижимость. В табл. 10.20 показано рекомендуемое разбиение таблиц системы на базовые и транзакционные.

Таблица 10.20. Организованные по типу таблицы системы RENTALMAN Базовые таблицы Транзякционные таблицы

TENANT CALLS PROPERTY WORDERS WORKTYPE WODETAIL EMPLOYEE

10.10 Таблицы типа главный/подчиненный Следующий этап разработки проекта базы данных — дальнейшее разделение предыдущего списка на

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

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

10.11 Визуальное определение связей между таблицами Следующим этапом работы над приложением RENTALMAN является создание диаграммы отношении

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

72

10.7 послужат вам примером визуального изображения связей между таблицами. На рис. 10.1 них изображена диаграмма отношений в самом формальном стиле, остальные придерживаются его менее строго.

Рис. 10.1. Диаграмма отношений для таблиц EMPLOYEE и WORDERS, исполненная в формальном стиле

Рис. 10.2. Диаграмма отношений для таблиц TENANT и PROPERTY, исполненная в формальном стиле

Рис. 10.3. Диаграмма отношений для таблиц CALLS и WORDERS, исполненная в формальном стиле

Рис. 10.4. Диаграмма отношений для таблиц WORDERS и WODETAIL, исполненная в формальном стиле

Рис. 10.5. Диаграмма отношений для таблиц WORDERS и CALLS, исполненная в формальном стиле

На рис. 10.6 и 10.7 продемонстрирован менее формальный, но более информативный стиль изображения.

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

10.12 Схемы баз данных Полезным может оказаться создание схематического изображения проекта всей базы данных приложения.

Этот ракурс взгляда на базу данных приложения позволит вам лучше уяснить ее содержимое и отношения между ее частями. На рис. 10.8 изображена схема базы данных системы RENTALMAN.

73

Рис. 10.6. Диаграмма отношений, исполненная в менее формальном стиле 10.13 Нормализация базы данных Несмотря на то что база данных RENTALMAN уже отвечает нормам третьей формы в терминах

нормализации, некоторые элементы ее проекта требуют дополнительного обсуждения. Их проработка поможет вам понять процесс нормализации (нормализация баз данных детально обсуждается в разделе 4).

Прежде всего, обратите внимание на то, что таблица TENANT не содержит атрибута PropertyNo. Это может показаться странным, так как арендаторы, конечно, получают недвижимость в аренду, как показывает диаграмма 10.8. Связь между таблицами PROPERTY и TENANT устанавливается через столбец TenantNo таблицы PROPERTY. Почему? Да потому, что один арендатор (скажем, юридическое лицо какого-либо типа) может арендовать несколько объектов, а если бы связь между этими таблицами устанавливалась через поле PropertyNo таблицы TENANT, то каждый из арендаторов не мог бы арендовать более одного объекта. Установив же связь в таблицу PROPERTY, мы позволяем арендаторам снимать неограниченное количество объектов, причем любой из объектов может быть в каждый момент времени сдан только одному арендатору. Это вполне приемлемое решение, и оно позволяет сохранять максимальную гибкость проекта, не снижая его практичности.

Другая странность этого проекта заключена в том, что информация о нанимателе арендатора хранится в таблице TENANT. Вся информация о нанимателе арендатора хранится в записи с его идентификацией. Это вопиющее нарушение третьей нормальной формы, так как поля, относящиеся к нанимателю, совершенно очевидно, зависят друг от друга. Зачем же допускать такое нарушение? Ответ очень прост. Никто и никогда не станет производить поиск в базе по полю "наниматель". Информация о нанимателе не служит никакой цели, кроме предоставления возможности контакта с арендатором по месту его работы, буде таковая необходимость появится. Вне контекста информации об арендаторе, информация о его нанимателе бесполезна. Компании, сдающей недвижимость, безразлично, сколько ее арендаторов работают на одного работодателя. И поэтому разумнее хранить информацию о нанимателе арендатора вместе с остальными данными о нем, а не создавать отдельную таблицу EMPLOYER и связывать ее с остальными. Эти факты позволяют хранить информацию о нанимателях, не создавая ненужной таблицы.

74

Рис. 10.7. Диаграмма отношений , исполненная в менее формальном стиле Другая кажущаяся любопытной особенность проекта— отсутствие столбца TenantNo в таблице CALLS. В

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

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

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

75

Рис.10.8. Схема базы данных показывает отношения между таблицами

10.14 Завершение проекта Для того чтобы завершить проектирование базы данных системы RENTALMAN и начать собственно

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

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

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

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

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

Первичный ключ, выбранный вами для каждой из таблиц, должен быть уникальным и одновременно самым вероятным маршрутом, по которому будет проводиться поиск данных. Какие запросы будут чаще всего применяться к таблице? К каким полям этой таблицы можно обращаться как к ограничениям? Например, при использовании таблицы TENANT очевидно, что самым популярным маршрутом для поиска данных в этой таблице будет поле TenantNo. И это поле, без сомнения, будет использоваться для управления ограничениями, установленными в других таблицах. Таким образом, выбор этого поля в качестве первичного ключа будет логичным. В табл. 10.21 показаны выбранные для таблиц системы RENTALMAN первичные ключи.

Таблица 10.21. Первичные ключи для базы данных системы RENTALMAN Таблица Первичный ключ Таблица Первичный ключ

TENANT TenantNo WODETAIL WorkOrderNo, LineNo PROPERTY PropertyNo EMPLOYEE EroployeeNo CALLS CaiINo WORKTYPE WorkTypeCode WORDERS WorkOrderNo

76

Внешние ключи Теперь обратимся к полям внешних ключей. Слово внешний означает, что, хотя в данной таблице эти

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

В таблице PROPERTY очевидным внешним ключом будет поле TenantNo. Дело в том, что в список всех текущих арендаторов логично включить снимаемые ими на данный момент объекты. TenantNo не может служить первичным ключом для этой таблицы, так как вряд ли это будет самым популярным маршрутом поиска данных в ней, однако в качестве внешнего ключа TenantNo себя отлично оправдывает.

Сделайте внешними ключами поля, которые могут участвовать в связи, особенно с правой стороны внешней связи. Кроме того, определите в качестве дополнительных ключей те поля, по которым пользователи будут часто искать информацию в базе. В приведенных ранее диаграммах поля, которые стоит использовать в качестве внешних ключей, отмечены латинской буквой "F", за которой идет порядковый номер ключа. Второе число выделено для того, чтобы определить порядковый номер поля в композитном дополнительном ключе при наличии такового (см. рис. 10.6).

Табл. 10.22 демонстрирует выбранные для базы данных проекта RENTALMAN внешние ключи. Таблица 10.22. Внешние ключи базы данных проекта RENTALMAN Таблица Внешний ключ Таблица Внешний ключ

PROPERTY TenantNo WORDERS PropertyNo; EmployeeNo CALLS PropertyNo; WorkOrderNo WODETAIL WorkTypeCode Ограничения Настало время обратить внимание на правила работы с базами данных, также известные под названием

ограничения. Ограничения задают выбор типов данных, которые данный столбец может содержать. Обычно ограничения проверяют, соответствует ли вводимое значение какому-либо критерию и входит ли оно в какой-либо набор значений, и лишь после этого позволяют полю принять это значение. Набор допустимых значений должен быть фиксированным. Это может быть набор значений, который вы установите во время разработки приложения. Например, в таблице PROPERTY вам, возможно, придется ограничить диапазон значений поля GarageType интервалом от 0 до 4, так как вы знаете, что все объекты либо не имеют гаража (0), либо имеют гараж на одну (1), две (2), три (3) или четыре (4) машины соответственно. Поле с фиксированным набором допустимых значений выделяется линией, которая соединяет его с прямоугольником, содержащим допустимые значения, как показано на рис. 10.6.

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

Ограничения, зависящие от внешней таблицы, обычно являются двунаправленными. Таким образом, не только ограничение управляет допустимыми значениями поля, но и если значение уже сохранено в поле, то ограничение не позволяет удалить это значение из внешней таблицы. Например, поле TenantNo таблицы PROPERTY позволяет использовать только существующие в таблице TENANT номера арендаторов. И наоборот, когда какое-либо из этих значений сохраняется в таблице PROPERTY, соответствующее значение поля таблицы TENANT становится невозможно удалить. Если это значение все же удалить, то значение TenantNo, хранящееся в таблице PROPERTY, "осиротеет" и его нельзя будет использовать для определения обитателей арендуемого объекта. Если вы, следуя указаниям, создали диаграммы отношений, вы уже должны были видеть визуальное отображение ограничений, действующих в базе данных проекта RENTALMAN. К этому времени ограничения, необходимые для работы RENTALMAN, уже должны находиться на местах. Табл. 10.13-10.19 демонстрируют фиксированные ограничения таблиц в базе данных RENTALMAN.

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

полей каждой таблицы. Просмотрите все таблицы и определите, какие поля должны (если какие-то вообще должны) иметь значения по умолчанию. Обычно установки значений по умолчанию требуют поля, ручной установки которых можно и нужно по возможности избегать. Например, в таблице PROPERTY поле Range может по умолчанию иметь значение True, так как обычно фирма устанавливает в сдаваемых в аренду помещениях электрокамин и духовку. В приведенных выше диаграммах значения полей по умолчанию представлены знаком равенства и числом, справа от определения поля, как показано на рис. 10.6. В табл. 10.10-10.17 показаны значения по умолчанию столбцов базы данных RENTALMAN.

77

11 SQL — ЯЗЫК УПРАВЛЕНИЯ ДАННЫМИ 11.1 Общие сведения В качестве сервера базы данных используются реляционные СУБД, для которых стандартным средством

доступа к данным является язык высокого уровня SQL (Select Query Language). Первая коммерческая СУБД, использующая SQL, появилась в 1981 году. SQL может использоваться для:

· манипуляции с данными (выборка и модификация); · обработки структуры базы данных (создание и удаление таблиц и индексов); · администрирования базы данных (определение списка пользователей, назначение прав доступа). Использование SQL имеет множество преимуществ. Наиболее важными являются следующие: · Он поддерживается многими поставщиками СУБД. Программы, написанные с использованием языка

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

слова, такие как SELECT, INSERT, UPDATE, DELETE, COMMIT и ROLLBACK. В данном разделе будут рассмотрены основные конструкции SQL, используемые для выборки данных и

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

11.2 Классификация команд SQL Команды SQL используются для выполнения разнообразных действий с реляционными базами данных.

Для удобства работы они разделяются на следующие группы: · Команды определения данных (Data Definition Commands) · Команды манипуляции данными (Data Manipulation Commands) · Команды выборки данных (Data Query Commands) · Команды управления транзакциями (Transaction Control Commands) · Команды управления данными (Data Control Commands) Приведем список команд языка SQL для каждой из этих групп. Команды определения данных (Data Definition Commands)

Команда Назначение ALTER TABLE Изменяет структуру таблицы. CREATE INDEX Создает индекс. CREATE TABLE Создает таблицу. CREATE VIEW Создает представление. DROP Удаляет таблицу, индекс, представление.

Команды манипуляции данными (Data Manipulation Commands) Команда Назначение DELETE Удаляет записи таблицы. INSERT Добавляет записи в таблицу. UPDATE Изменяет данные таблицы.

Команды выборки данных (Data Query Commands)

Команда Назначение SELECT Выбирает данные из таблиц.

Команды управления транзакциями (Transaction Control Commands) Команда Назначение COMMIT Делает изменения, проведенные с начала транзакции,

постоянными. ROLLBACK Откатывает все проведенные изменения к точке

сохранения или к началу транзакции. SAVEPOINT Устанавливает контрольную точку, к которой

впоследствии можно будет выполнить откат. Команды управления давними (Data Control Commands)

Команда Назначение CHECK DATABASE Проверяет целостное!» базы данных. GRANT Предоставляет привилегии. REVOKE Удаляет предоставленные ранее привилегии.

78

Изучение команд SQL начнем с формирования запросов, поскольку ввод данных обычно осуществляется

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

11.3 Формирование запросов в SQL Для формирования запросов в SQL используется конструкция SELECT. Результатом выполнения запроса

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

SELECT CUSTOMERNO, FIRSTNAME, LASTNAME FROM CUSTOMER WHERE CITY="Москва" Данный пример иллюстрирует наиболее простую форму конструкции SELECT в языке SQL: SELECT спивокВибираеювсПояей FROM списокТаблихд WHERE условиеВкборки Заметим, что результатом запроса является другая таблица, которая получается из заданных в выборке

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

При формировании запросов вы можете использовать уточненные имена полей (например, CUSTOMER.CUSTOMERNO):

SELECT CUSTOMER.CUSTOMERNO, CUSTOMER.FIRSTNAME CUSTOMER.LASTNAME FROM CUSTOMER WHERE CUSTOMER.CITY="Москва" Использование уточненных имен никогда не рассматривается как ошибка. Для выполнения более сложных выборок используется общая форма конструкций SELECT: SELECT [DISTINCT] списокВыбираемыхПолей FROM списокТаблиц [WHERE условиеВыборки] [GROUP BY условиеГруппировки [HAVING условиеВыборкиГруппы] ] [ORDER BY условиеУпорядочивания ] Теперь перейдем к иллюстрации основных особенностей этой конструкции с помощью ряда примеров. Простая выборка Выберем коды всех поставленных товаров из таблицы ORDSALE: SELECT STOCK# FROM ORDSALE При выполнении данного запроса в результат выборки будут включены все дубликаты товаров.

Реляционная СУБД не исключает дубликатов из результата конструкции SELECT, если пользователь явно не потребует это сделать с помощью ключевого слова DISTINCT (различные), как будет показано в следующем примере.

Выборка с исключением дубликатов Выберем из таблицы ORDSALE коды всех поставленных товаров, исключая избыточные дубликаты: SELECT DISTINCT STOCK# FROM ORDSALE Выборка вычисляемых значений Результирующая таблица может включать не только поля исходных таблиц, но и результат вычисления

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

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

В качестве примера выберем коды и стоимость каждого товара с учетом налога на добавленную стоимость (НДС), предполагая, что в таблице GOODS стоимость приведена без учета НДС:

SELECT STOCK#, UNITPRICE*(1+0,23) FROM GOODS Конструкция SELECT может включать арифметические выражения, а также простые имена полей. Кроме

того, вы можете добавить константы в результат выборки. Например: SELECT STOCK#, "Стоимость с учетом НДС", UNITPRICE*(1+0,23) FROM GOODS

79

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

Ограничение выборки Выберем коды покупателей, которые находятся в Москве и имеют кредит превышающий 200 000: SELECT CUSTOMERNO, FIRSTNAME, LASTNAME FROM CUSTOMER WHERE СIТY="Москва" AND CREDITLIMIT>200000 Условие, следующее за ключевым словом WHERE, может включать:

· операторы сравнения =, <>(не равно), >, >=, < и <=; · булевские операторы AND (и), OR (или) и NOT (нет); · скобки, указывающие требуемый порядок вычислений.

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

Выборка с упорядочением Выберем теперь номера и кредит покупателей, проживающих в Москве, в порядке убывания их кредита: SELECT CUSTOMERNO, FIRSTNAME, LASTNAME, CREDITLIMIT FROM CUSTOMER WHERE CITY="Москва" ORDER BY CREDITLIMIT DESC В выборках без указания критерия упорядочения результирующая таблица будет отсортирована в

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

имяПоля [упорядочение] [,имяПоля [упорядочение] ]..., где

· аргумент упорядочение может принимать значение ASC (возрастание) или DESC (убывание). По умолчанию устанавливается значение ASC.

· в качестве аргументов имяПоля могут использоваться только поля результирующей таблицы. Поэтому, например, следующая конструкция недопустима:

SELECT CUSTOMERNO, LASTNAME FROM CUSTOMER ORDER BY CITY Для идентификации полей, используемых для упорядочивания, вы можете указать не только

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

SELECT STOCK#, UNITPRICE*(1+0,23) FROM GOODS ORDER BY 2 Здесь число 2 ссылается на второй столбец результирующей таблицы. Выборка с использованием BETWEEN (между) Выберем сведения о товарах, стоимость которых находится в диапазоне от 20 000 до 100 000,

включительно: SELECT STOCK#, NAME, UNITPRICE FROM GOODS WHERE UNITPRICE BETWEEN 20000 AND 100000 Кроме того, вы можете использовать условие NOT BETWEEN (не принадлежит диапазону между),

например: SELECT STOCKS, NAME, UNITPRICE FROM GOODS WHERE UNITPRICE NOT BETWEEN 20000 AND 100000 Выборка с использованием IN (принадлежит) Выберем товары, стоимость которых равна 100 000, 200 000 или 500 000: SELECT STOCK#, NAME, UNITPRICE FROM GOODS WHERE UNITPRICE IN(100000, 200000, 500000) Оператор IN является в действительности просто краткой записью условия, представляющего собой

последовательность отдельных сравнений, соединенных операторами OR (или). Предыдущая конструкция SELECT эквивалентна следующей конструкции:

SELECT STOCK#, NAME, UNITPRICE FROM GOODS WHERE UNITPRICE=100000 OR UNITPRICE=200000 OR UNITPRICE=500000

Вы можете использовать также оператор NOT IN (не принадлежит), например: SELECT STOCK#, NAME, UNITPRICE FROM GOODS WHERE UNITPRICE NOT IN(100000, 200000, 500000) Выборка с использованием шаблонов Использование шаблонов в SQL расширяет возможности выборки данных, точные значения которых вы

не помните. В качестве примера выберем все товары, наименования которых начинаются с буквы "Т":

80

SELECT STOCK#, NAME, UNITPRICE FROM GOODS WHERE NAME LIKE "T%" Обычно оператор LIKE имеет форму: имяПоля -LIKE строковаяКонстанта Результат выполнения оператора принимает значение истина, если значение в указанном поле

соответствует образцу, указанному аргументом строковаяКонстанта (зависит от реализации SQL-сервера). Символы этой константы интерпретируются следующим образом:

_ (пробел или подчеркивание) обозначает любой одиночный символ; % (процент) обозначает любую последовательность символов. Все другие символы обозначают просто сами себя. Следовательно, в приведенном примере конструкция SELECT будет осуществлять выборку записей из

таблицы GOODS, для которых значение в поле NAME начинается с буквы "Т" и содержит далее любую последовательность из нуля или более символов.

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

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

Простое соединение Выберем список наименований всех товаров, проданных покупателям: SELECT ORDSALE.CUSTOMERNO, GOODS.NAME FROM ORDSALE, GOODS WHERE ORDSALE.STOCK#=GOODS.STOCK# Отметьте, что в данном случае ссылки на поля во фразе WHERE должны уточняться именами

содержащих их таблиц. Во избежание двусмысленности в этой выборке два поля STOCK# показаны явным образом как CUSTOMER.STOCKS и GOODS.STOCK#.

Соединение с дополнительным условием Выберем список покупателей, которым проданы компьютеры "Andy 486": SELECT ORDSALE.CUSTOMERNO FROM ORDSALE, GOODS WHERE ORDSALE.STOCK#=GOODS.STOCK# AND GOODS.NAME="Andy 486" Соединение трех таблиц Если вам необходимо ограничить предыдущую выборку только покупателями из Москвы, соедините три

таблицы: CUSTOMER, ORDSALE и GOODS: SELECT DISTINCT CUSTOMER.LASTNAME,CUSTOMER.LASTNAME FROM CUSTOMER, ORDSALE, GOODS WHERE CUSTOMER.CUSTOMERNO=ORDSALE.CUSTOMERNO AND

ORDSALE.STOCK#=GOODS.STOCK# AND GOODS.NAME="Andy 486" В данном случае вы можете выбрать вместо номера покупателя его имя. Во многих случаях выборки из

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

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

многих практических задач. Например, даже настолько простой запрос, как "Сколько имеется покупателей?", нельзя выразить, используя только введенные до сих пор конструкции. Для определения групповых значений в SQL предусматривается ряд специальных стандартных функций, которые присутствуют во всех диалектах SQL:

Функция Вычисляет COUNT Число значений в поле SUM Сумма значений по полю AVERAGE Среднее значение в поле МАХ Наибольшее значение в поле MIN Наименьшее значение в поле За исключением COUNT, каждая из этих функций оперирует совокупностью значений в одном поле

некоторой таблице (которая может быть результатом выборки из заданных базовых таблиц) и вычисляет единственное значение.

Для функций SUM и AVERAGE рассматриваемый столбец должен содержать числовые значения. В общем случае аргументу функции может предшествовать ключевое слово DISTINCT, указывающее, что дублирующие значения должны быть исключены при выполнении функции. Однако для функций МАХ и MIN ключевое слово DISTINCT должно быть опущено.

Использование функции COUNT Определим общее количество покупателей. SELECT COUNT (*) FROM CUSTOMER Использование функций совместно с условием

81

Определим количество продаж товара "Andy 486". SELECT COUNT(*) FROM ORDSALE WHERE STOCK#="Andy 486" Выберем общее количество проданных "Andy 486". SELECT SUM(QUANT) .FROM OROSALE WHERE STOCK#="Andy 486" Использование функций совместно с подзапросом Для создания более сложных запросов вы можете использовать вложенные запросы (подзапросы).

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

SELECT CUSTOMERNO FROM CUSTOMER WHERE CREDITLIMIT< (SELECT MAX(CREDITLIMIT) FROM CUSTOMER) Функция в коррелированном подзапросе В некоторых, довольно часто встречающихся на практике случаях, необходимо выбрать данные из

таблицы, основываясь на результатах дополнительных выборок из этой же таблицы. Такие выборки называются коррелированными. Для их выполнения используются псевдонимы таблиц, которые следуют непосредственно за именем таблицы в выборке. В приведенном ниже примере используются псевдонимы таблицы CUSTOMER: CUST_X и CUST_Y.

Выберем код покупателя, кредит и город для всех покупателей, у которых кредит больше или равен среднему для их конкретного города.

SELECT CUSTOMERNO, CREDITLIMIT, CITY FROM CUSTOMER CUST_X WHERE CREDITLIMIT >=(SELECT AVERAGE(CREDITLIMIT) FROM CUSTOMER CUST_Y

WHERE CUST_Y.CITY=CUST_K.CITY) Использование группировки данных В приведенных выше примерах результатом выборки всегда являлась одна запись. Рассмотрим теперь

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

SELECT STOCK#, SUM(QUANT) FROM ORDSALE GROUP BY STOCK# С концептуальной точки зрения, оператор GROUP BY (группировать по) перекомпоновывает таблицу,

представленную фразой FROM, в разделы или группы таким образом, чтобы в каждой группе все строки имели одно и то же значение поля, указанного во фразе GROUP BY. Это, конечно, не. означает, что таблица физически перекомпоновывается в базе данных. В рассматриваемом примере строки таблицы ORDSALE группируются таким образом, что в одной труппе содержатся все строки для одного вида товара.

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

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

Отметьте, что фраза GROUP BY не предполагает ORDER BY (упорядочить по). Для упорядочения результата этого примера по кодам товаров, следует поместить фразу ORDER BY STOCK# следом за фразой GROUP BY.

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

покупателя с кодом 23: SELECT STOCK#, SUM(QUANT) FROM ORDSALE WHERE CUSTOMERN0023 GROUP BY STOCK# Строки, не удовлетворяющие условию WHERE, исключаются перед группированием данных. Использование HAVING Для ограничения записей, участвующих в группировке, используется оператор HAVING, который играет

такую же роль для групп, что и оператор WHERE для записей. Иными словами, HAVING используется для того, чтобы исключать группы точно также, как WHERE используется для исключения записей. Выражение во фразе HAVING должно принимать единственное значение для группы.

Выберем коды товаров, покупаемых более чем одним покупателем: SELECT STOCK# FROM ORDSALE GROUP BY STOCKS HAVING COUNT(*)>1 Оператор HAVING не можете использоваться отдельно от оператора GROUP BY. Данный пример может быть выполнен и с помощью коррелированных запросов. Например: SELECT DISTINCT STOCK#

82

FROM ORDSALE O&S_X WHERE 1<(SELECT COUNT(*)

FROM ORDSALE O&S_Y WHERE O&S_Y.STOCK#=O&S_X.STOCK#)

Следующий вариант этого запроса, в котором вместо псевдонима O&S_X используется таблица GOODS, является, вероятно, более ясным:

SELECT STOCK# FROM GOODS WHERE 1<(SELECT COUNT (CUSTOMERNO) FROM ORDSALE

WHERE ORDSALE.STOCK#= GOODS.STOCK#) Оба этих альтернативных варианта логически более понятны и не требуют дополнительных языковых

конструкций, поэтому они более предпочтительны по сравнению с вариантом GROUP BY/HAVING. Конструкции GROUP BY свойственно серьезное ограничение, которое заключается в том, что она

работает только на одном уровне. Невозможно разбить каждую из этих групп на группы более низкого уровня, а затем применить некоторую стандартную функцию, например SUM или AVERAGE, на каждом уровне группирования.

Использование квантора существования в запросах Оператор EXISTS (существует) представляет в SQL запросах квантор существования — понятие,

заимствованное из формальной логики. В языке SQL предикат с квантором существования представлен выражением вида:

EXISTS (SELECT * FROM...) . Выражение считается истинным тогда и только тогда, когда результат вычисления подзапроса,

представленного с помощью SELECT * FROM..., является непустым множеством. Иными словами, выражение истинно тогда и только тогда, когда существует какая-либо запись в таблице, указанной во фразе FROM подзапроса, которая удовлетворяет условию WHERE этого подзапроса.

В качестве примера выберем фамилии покупателей, которым продан компьютер "Andy 486". SELECT LASTNAME FROM CUSTOMER WHERE EXISTS(SELECT *

FROM ORDSALE WHERE ORDSALE.CUSTOMERNO= CUSTOMER.CUSTOMERNO AND STOCK#="Andy 486")

В данном примере поочередно рассматривается каждое значение поля "LASTNAME" и проверяется истинность условия существования. Предположим, что первое значение поля "LASTNAME" — Зайцева, а соответствующее значение поля "CUSTOMERNO" — 23. Если множество записей из ORDSALE, содержащих "CUSTOMERNO", равный 23, и "STOCK#", равный Andy 486, не пусто, то Зайцева будет одним из результирующих значений. Аналогично выбираются и другие значения поля "LASTNAME".

Этот пример показывает иной способ формулировки запроса по сравнению с рассмотренными ранее. Оператор EXISTS реализует одну из наиболее важных возможностей языка SQL. Фактически любой запрос, который может быть выражен с использованием IN, может быть альтернативным образом сформулирован также с помощью EXISTS.

Вы можете сконструировать отрицание существования, используя совместно операторы NOT и EXISTS. В качестве примера выберем фамилии покупателей, которые не купили "Andy 486":

SELECT LASTNAME FROM CUSTOMER WHERE NOT EXISTS (SELECT *

FROM ORDSALE WHERE ORDSALE. CUSTOMERNO= CUSTOMER.CUSTOMERNO AND STOCK#="Andy 486")

Обратите внимание на то, что в подзапросе осуществляется выборка из двух таблиц CUSTOMER и ORDSALE, но во фразе FROM перечисляется только ORDSALE.

Заключенный в скобки подзапрос, входящий в выражение EXISTS, вовсе не обязательно должен использовать предложение SELECT вида SELECT *. Например, можно использовать предложение следующего вида: SELECT имя-поля FROM... . Однако, на практике почти всегда используется вид SELECT *, как было продемонстрировано в вышеприведенных примерах.

Объединение множеств Объединением двух множеств называется множество всех элементов, принадлежащих какому-либо

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

1. Они имеют одинаковое число полей (например, n); 2. Для всех i (i==l, 2, ..., n) i-e поле первой таблицы и i-e поле второй таблицы имеют в точности

83

одинаковый тип данных. Пример запроса, использующего оператор UNION В качестве примера выберем коды товаров, которые имеют стоимость, превышающую 1 000, либо

покупаются покупателем с кодом 23 (либо то и другое). SELECT STOCK# FROM GOODS WHERE UNITPRICE>1000 UNION SELECT STOCK# FROM ORDSALE WHERE CUSTOMERNO=23 Из результата выборки, использующей оператор UNION, всегда исключаются избыточные дубликаты.

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

Вы можете соединить оператором UNION любое число конструкций SELECT. Рассмотрим расширенный вариант данного примера, включив в него коды товаров ценой ниже 500. Для

этого дополним приведенный выше запрос следующей конструкцией: UNION SELECT STOCK# FROM GOODS WHERE UNITPRICE<500 Аналогичного результата можно было достигнуть, добавляя к первому из первоначальных конструкций

SELECT оператор OR UNITPRICE<500. Оператор ORDER BY в запросе с использованием оператора UNION может входить только в последнее

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

При использовании оператора UNION часто оказывается полезным включение константы в результирующую таблицу.

Например, текстовую константу можно использовать в качестве пояснения условия выборки товаров: SELECT STOCK#, "Стоимость товара> 1000 $" FROM GOODS WHERE UNITPRICE>1000 UNION SELECT STOCK#, "Товар куплен покупателем 23" FROM ORDSALE WHERE CUSTOMERNO=23 ORDER BY 2,1 11.4 Модификация данных таблиц Вы познакомились с возможностями выборки данных с помощью конструкции SELECT. Перейдем теперь

к модификации данных таблиц. В SQL для этих целей используется конструкция UPDATE, которая имеет следующий синтаксис:

UPDATE таблица SET поле=выражение [,поле=выражение]... [WHERE условие] В результате выполнения конструкции все записи в таблице, которые удовлетворяют условию,

обновляются в соответствии с оператором присваивания поле—выражение. Модификация единственной записи Изменим наименование товара "Andy 486" на "Pentium" и увеличим стоимость на 400 000. UPDATE GOODS SET NAME="Pentium" UNITPRICE=UNITPRICE+400000.00 WHERE NAME="Andy 486" Для каждой записи, которая должна быть обновлена (т. е. для каждой записи, которая удовлетворяет

условию WHERE, или для всех записей, если фраза WHERE опущена), ссылки во фразе SET на поля этой записи обозначают значения этих полей до их модификации.

Модификация множества записей Удвоим кредит всех покупателей, находящихся в Киеве: UPDATE CUSTOMER SET CREDITLIMIT=CREDITLIMIT*2 WHERE С1ТУ="Киев" Модификация с подзапросом Установим скидку в 20% для всех покупателей, проживающих в Минске: UPDATE ORDSALE SET UNITPRICE=0.8*UNITPRICE WHERE "Минск"= (SELECT CITY FROM CUSTOMER WHERE CUSTOMER.CUSTOMERNO= ORDSALE.CUSTOMERNO) В конструкции UPDATE может использоваться только одна таблица, т. е. вы не можете в рамках одного

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

одно значение, а не несколько.

84

11.5 Удаление данных Для удаления данных таблиц используется конструкция DELETE, которая имеет следующий синтаксис: DELETE FROM таблица [WHERE условие] В результате выполнения конструкции удаляются все записи в таблице, которые удовлетворяют условию. Удаление единственной записи Удалим покупателя с кодом 23: DELETE FROM CUSTOMER WHERE CUSTOMERNO=23 Удаление множества записей Удалим из таблицы ORDSALE все покупки товара с кодом 34: DELETE FROM ORDSALE WHERE STOCK#=34 Удаление всех записей Очистим таблицу ORDSALE от записей: DELETE FROM ORDSALE В результате выполнения этой операции таблица доступна для дальнейшей работы, однако она будет

пуста. Удаление всех записей не приводит к уничтожению таблицы. Удаление с подзапросом Удалим все покупки клиентов, проживающих в Киеве. DELETE FROM ORDSALE WHERE "Киев"= (SELECT CITY FROM CUSTOMER

WHERE CUSTOMER.CUSTOMERNO= ORDSALE.CUSTOMERNO) 11.6 Добавление записей Для добавления записей используется конструкция INSERT, которая имеет два варианта синтаксиса: INSERT INTO таблица [(поле [,поле]...)] VALUES (константа[,константа]...) или: INSERT INTO таблица [(поле [,поле]...)] подзапрос В первом варианте в таблицу вставляется запись, имеющая заданные значение для указанных полей,

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

Вставка единственной записи Добавим в таблицу GOODS товар "Andy 486" стоимостью 3 000 000. INSERT INTO GOODS (STOCK#, NAME, UNITPRICE, CATEGORY) VALUES 1001, "Andy 486", 3000000.00, 2) В результате создается новая запись для товара с заданным номером, наименованием, стоимостью и

категорией товара. Вставка единственной записи с опущенными именами полей Модифицируем предыдущий пример, опустив имена полей таблицы: INSERT INTO GOODS VALUES (1001, "Andy 486", 3000000.00, 1) Отсутствие полей эквивалентно перечислению списка всех полей таблицы в порядке слева направо так,

как они были определены при создании таблицы. Вставка множества записей Если по каким-либо причинам из таблицы CUSTOMER были удалены все записи, вы можете добавить в

нее всех покупателей из таблицы ORDSALE: INSERT INTO CUSTOMER (CUSTOMERNO) SELECT DISTINCT CUSTOMERNO FROM ORDSALE Здесь конструкция SELECT выполняется точно также, как обычно, но результат не возвращается

пользователю, а копируется в таблицу CUSTOMER.

85

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

работы. Для иллюстрации транзакции рассмотрим замену кода покупателя 12 на код 124. Поскольку код покупателя используется в таблицах CUSTOMER и ORDSALE, он должен быть изменен в обеих таблицах. Для этого необходимо выполнить две операции UPDATE:

UPDATE CUSTOMER SET CUSTOMERNO=124 WHERE CUSTOMERNO=12 UPDATE ORDSALE SET CUSTOMERNO=124 WHERE CUSTOMERNO=12 Замена кода покупателя, воспринимаемая конечным пользователем, как единая операция, на самом деле

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

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

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

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

Для управления транзакциями используются команды COMMIT (фиксировать) и ROLLBACK (откат). Команда COMMIT сигнализирует об успешном завершении транзакции. Она сообщает СУБД, что:

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

свершившиеся. Команда ROLLBACK сигнализирует о неудачном завершении транзакции. Она сообщает СУБД, что в

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

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

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

Конструкция COMMIT Конструкция COMMIT языка SQL имеет следующий формат: COMMIT Эта конструкция сигнализирует об успешном завершении транзакции и устанавливает точку

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

86

Конструкция ROLLBACK Конструкция ROLLBACK языка SQL имеет следующий формат: ROLLBACK Эта конструкция сигнализирует о неудачном завершении транзакции и устанавливает точку

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

Транзакции не могут быть вложены одна в другую, поскольку каждое из предложений COMMIT или ROLLBACK завершает одну транзакцию и инициирует другую.

11.8 Создание и модификация структуры данных Как правило, все системы разработки приложений клиент/сервер содержат возможность создавать

таблицы и индексы в интерактивном режиме. Альтернативно вы можете создавать их командами SQL, которые будут рассмотрены ниже.

Создание таблиц Создание таблиц в SQL осуществляется командой CREATE TABLE, которая в простейшем случае имеет

следующий синтаксис: CREATE TABLE имяТаблицы ( определениеПоля [,определениеПоля] ...) Аргумент команды определениеПоля содержит имя поля и тип данных поля. Кроме этого, для каждого

поля вы можете указать признак (NOT NULL) обязательного заполнения поля при вводе данных в таблицу, значения полей по умолчанию и ограничения на вводимые значения.

Например, фрагмент команды создания таблицы CUSTOMER будет выглядеть следующим образом: CREATE TABLE CUSTOMER (CUSTOMERNO NUMBER NOT NULL, FIRSTNAME CHAR(20), LASTNAME CHAR(20) NOT NULL, . . . CREDITLIMIT NUMBER(12,2) ) Создание индексов Индекс обеспечивает прямой доступ к строкам таблицы, снижая тем самым время доступа. Как вы могли

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

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

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

Создание индексов в SQL осуществляется командой CREATE INDEX, которая имеет следующий базовый синтаксис:

CREATE [UNIQUE] INDEX имяИндекса ON имяТаблицы полеТаблицы [ASC | DESC] [ полеТаблицы [ASC | DESC] ...] Ключевое слово UNIQUE гарантирует, что в таблице не будет двух строк с одинаковыми значениями в

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

создан индекс NAME, состоящий из полей "CITY", "FIRSTNAME" и "LASTNAME". В этом случае СУБД может использовать этот индекс при выборке по всем трем полям "CITY", "FIRSTNAME" и "LASTNAME", а также при выборке по полю "CITY". Для поиска по "FIRSTNAME" и "LASTNAME" этот индекс использоваться не может, однако вы можете для такого поиска создать дополнительный индекс из полей "FIRSTNAME" и "LASTNAME".

Для каждой таблицы можно создать несколько индексов, содержащих различные поля (или различные комбинации полей). Индексы увеличивают скорость выборки, но снижают производительность модификации данных.

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

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

ALTER TABLE имяТаблицы ADD определениеПоля [,определениеПоля] ... DROP имяПоля [,имяПоля] ... RENAME староеИмяПоля- новоеИмяПоля [,староеИмяПоля- новоеИмяПоля] ... MODIFY определениеПоля [,определениеПоля] ... В этой команде ключевые слова используются для выполнения следующих функций:

87

Ключевое слово Функция ADD Добавляет новое поле. DROP Удаляет поле. RENAME Переименовывает поле. MODIFY Модифицирует параметры поля.

Удаление таблиц и индексов В процессе разработки приложения модификация структуры данных может привести не только к

изменению структуры некоторых таблиц, но и к созданию новых и удалению некоторых из существующих таблиц. Для удаления таблицы используется команда:

DROP TABLE имяТаблицы Например: DROP TABLE CUSTOMER Как было сказано ранее, использование индексов приводит к снижению производительности

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

DROP INDEX имяИндекса Обеспечение целостности данных Целостность данных является самым важным требованием, предъявляемым к базам данных. Для связи

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

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

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

Создание первичных и внешних ключей Для создания первичных и внешних ключей вы можете использовать как команду CREATE TABLE, так и

команду ALTER TABLE. Синтаксис команды ALTER TABLE: ALTER TABLE имяТаблицк ADD PRIMARY KEY ( имяПоля, иияПоля ... ) ADD FOREIGN KEY иияВнешнегоКлюча ( имяПоля, имяПоля ... ) REFERENCES имяСсыяочнойТаблищл [ON DELETE RESTRICT | CASCADE | SET NULL] Для обеспечения целостности покупателей в базе данных создайте первичный ключ для таблицы

CUSTOMER и внешние ключи для всех таблиц, которые содержат номер покупателя. Например: ALTER TABLE CUSTOMER ADD PRIMARY KEY (CUSTOMERNO) ALTER TABLE ORDSALE ADD FOREIGN KEY CUSTNO (CUSTOMERNO) REFERENCES CUSTOMER ON DELETE RESTRICT При добавлении в таблицу ORDSALE номера несуществующего покупателя возникает ошибка SQL и

данные в таблицу не будут записаны. Фраза ON DELETE определяет механизм удаления данных в главной таблице (в данном случае CUSTOMER). Если указан параметр RESTRICT, вы можете удалить покупателя в таблице CUSTOMER только в том случае, если он не используется ни в одной из таблиц, имеющих ссылку на таблицу CUSTOMER. В этом случае для удаления покупателя из таблицы CUSTOMER вам предварительно необходимо удалить все записи в таблице ORDSALE, содержащие ссылку на этот номер покупателя.

В некоторых случаях желательно, чтобы удаление главной таблицы приводило к удалению и подчиненных. Например, счет на покупку товара состоит из двух таблиц: заголовка счета и перечня заказанных товаров. Для того, чтобы удаление заголовка счета приводило к удалению соответствующих записей из перечня товаров, используйте фразу ON DELETE CASCADE.

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

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

CREATE VIEW O_S_NOT AS SELECT *

88

FROM ORDSALE WHERE SALEDATE=NULL При создании этого представления запрос не выполняется, а просто сохраняется в каталоге. В

конструкции запроса вы можете использовать выборки из нескольких таблиц, но не можете использовать фразы UNION и ORDER BY.

Для удаления представления используется команда DROP VIEW. 11.10 Администрирование базы данных Предоставление доступа к базе данных В системах клиент/сервер доступ к базе данных могут получить только пользователи, зарегистрированные

в системе. Для регистрации новых пользователей используется команда GRANT: GRANT привилегия ТО имяПольЗователя Например: GRANT DBA TO SYSADM Предоставление доступа к отдельным таблицам Кроме предоставления общих привилегий пользователю, вы можете определить уточненные привилегии

на таблицу или даже на ее отдельные поля. Для этого вопользуйтесь следующим вариантом команды GRANT:

GRANT привилегия ON имяТаблицы | имяПредставления ТО имяПользователя | PUBLIC Ниже приведены перечень возможных привилегий и их краткое описание: Привилегия Краткое описание ALTER Привилегия на выполнение команды ALTER TABLE. DELETE Привилегия на удаление строк из таблицы. , INDEX Привилегия на создание индекса таблицы. INSERT Привилегия на вставку строк в таблицу. REFERENCES Привилегия для создания ссылки на таблицу внутри ограничения для таблицы

или поля. SELECT Привилегия для запроса по таблице. Чтобы ограничить возможности по запросу

определенных полей таблицы, создайте представление на основании этих полей и предоставьте привилегию по запросу для этого представления.

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

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

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

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

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

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

Определение прав с помощью GRANT Допуски пользователю даются с помощью команды SQL GRANT. С помощью команды REVOKE они

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

GRANT ALL ON WORKTYPE TO PUBLIC

89

Эта команда предоставляет все права (SELECT, INSERT, UPDATE, DELETE и EXECUTE) всем пользователям таблицы WORKTYPE. Аналогично, вы можете отменить эти права следующей командой:

REVOKE ALL ON WORKTYPE FROM PUBLIC Чтобы ограничить права, нужно заменить слово ALL списком конкретных разрешений. Например: GRANT SELECT, INSERT, UPDATE ON EMPLOYEE TO PUBLIC Вы можете отменить эти разрешения с помощью следующего оператора: REVOKE SELECT, INSERT, UPDATE ON EMPLOYEE TO PUBLIC Заметьте, что вместо параметра PUBLIC можно использовать список пользователей, которым

предоставляются или отменяются права. Но для этого нужно сначала создать список пользователей. В отличие от большинства платформ клиент/сервер, InterBase не поддерживает пользовательских групп (кроме, конечно, группы PUBLIC), и, в отличие от платформ Sybase и Microsoft, здесь права доступа к серверу и к базе данных не отделяются друг от друга.

Список пользователей можно создавать с помощью InterBase Server Manager. Для этого запустите Server Manager из каталога программ Delphi. Затем свяжитесь с базой данных, выбрав опцию Datebase Connect из меню File.

После этого выберите TaskUser Security. Эта опция позволяет пополнять список пользователей. Вы увидите диалоговое окно InterBase Security. Щелкните на кнопке Add User, чтобы добавить нового пользователя. Введите имя пользователя и пароль. Обратите внимание, что нельзя ввести имя пользователя строчными буквами — они будут преобразованы в прописные. Однако при вводе пароля регистр имеет значение. Вы можете использовать не только строчные, но и прописные символы, и сервер будет их различать.

Добавив информацию о новом пользователе, щелкните на кнопке ОК. для включения пользователя в список пользователей сервера. Теперь с помощью имени нового пользователя и пароля можно связаться с любой базой данных InterBase, при этом пользователь должен получить разрешение для доступа к отдельным объектам. Как отмечалось ранее, эти права предоставляются с помощью команды GRANT. Например, чтобы предоставить новому пользователю право доступа к таблице TENANT, нужно ввести команду:

GRANT ALL ON TENANT TO JEFFBACK Вы можете повторить эту команду для всех таблиц, таблиц просмотра и хранимых процедур в базе

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

пункт WITH GRANT OPTION команды GRANT. Например: FRANT EXECUTE ON PROCEDURE LISTPROP TO JEFFBACK WITH GRANT OPTION Эта команда позволяет пользователю выполнять самому /ранимую процедуру и предоставлять права

доступа к ней другим пользователям с помощью команды GRANT.

90

12 СЕРВЕР БАЗ ДАННЫХ InterBase 12.1 Введение Цель этого раздела состоит в том, чтобы ознакомить вас с основными частями системы клиент/сервер

управления базами данных InterBase фирмы Borland. Локальный сервер InterBase (LIB)— локальная однопользовательская версия системы управления базой данных InterBase— включен в версию клиент/сервер Delphi. Для выполнения SQL-запросов используют встроенную утилиту Windows— Interactive SQL (WISQL), чтобы описать основные возможности InterBase, использующего LIB-сервер.

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

Теперь, когда основные принципы ясны, время начинать. 12.2 Создание базы данных В SQL вы создаете базы данных, используя команду SQL CREATE DATABASE. Точный синтаксис

зависит от реализации, но вот синтаксис InterBase: CREATE DATABASE 'C:\DATA\IB\ORDENT' USER USERNAME PASSWORD password Поскольку утилита WISQL InterBase не может подготовить команду CREATE DATABASE к выполнению,

используйте вместо этого опцию Create Database (создать базу данных) из меню File. Чтобы сделать это, выполните следующие действия.

1. Запустите Interactive SQL (WISQL) из группы Delphi или из меню Task в InterBase Server Manager. 2. Выберите опцию Create Database из меню File. 3. Наберите С: \DATA\IB\ORDENT в поле базы данных диалога Create Database, заменяя С: \DATA\IB на

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

4. Щслкните на кнопке ОК. InterBase должен создать базу данных и подключить вас к ней. В будущем используйте опцию Connect to Database из меню File для подключения к базе данных без ее создания.

12.3 Расширение базы данных Поскольку объем данных может меняться, вам, вероятно, будет необходимо расширять базы данных,

созданные в прошлом. Используйте команду ALTER DATABASE, чтобы увеличить отводимое существующей базе данных место. Вот синтаксис InterBase:

ALTER DATABASE ADD FILE 'C:\DATA\IB\ORDENT2.GDB' Команда CONNECT На большинстве серверных платформ команда CONNECT используется для изменения окружения базы

данных, чтобы соединить и использовать определенную базу данных. Синтаксис InterBase: CONNECT "C:\DATA\IB\ORDENT.GDB" USER "SYSDBA" PASSWORD "masterkey"; Используйте команду DISCONNECT, чтобы отменить команду CONNECT, например: DISCONNECT ALL; Вы можете заменить ALL на слово DEFAULT, чтобы выполнить то же самое. В WISQL используйте

опции Connect to Database и Disconnect from Database в меню File, чтобы соединяться и отключиться от баз данных.

12.4 Уровни разграничения транзакций Уровни разграничения транзакций (Transaction Isolation Levels — TIL) влияют на вашу способность

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

InterBase поддерживает три TIL— SNAPSHOT, SNAPSHOT TABLE STABILITY и READ COMMITTED. Вы устанавливаете TIL, который хотите использовать, с помощью команды SET TRANSACTION. Вот описание каждого значения TIL:

· SNAPSHOT — на всем продолжении транзакции база данных представляется такой, какой она была в начале операции. В то время как операция активна, изменения, сделанные другими операциями, не видимы.

· SNAPSHOT TABLE STABILITY — разрешает другим транзакциям доступ "только для чтения" к таблицам, к которым применяется транзакция.

91

· READ COMMITTED — выбирается самая последняя обновленная версия записи, над которой выполняют-ся операции (модификация или удаление); транзакция может вносить изменения, если нет никаких конфликтов с другими транзакциями.

12.5 Создание таблиц После создания базы данных, вы можете начать формирование объектов базы данных. Любое понятие

реляционной базы данных можно продемонстрировать с помощью максимум трех таблиц. Для работы в этой главе начнем с создания следующих трех таблиц с помощью команды SQL CREATE TABLE. Введите в WISQL:

CREATE TABLE CUSTOMER (CustomerNumber int NOT NULL, LastName char(30), FirstName char(30), StreetAddress char(30), City char(20), State char(2), Zip char(10) ) Это действие формирует таблицу CUSTOMER. Затем создайте таблицу ORDERS, используя подобный

синтаксис: CREATE TABLE ORDERS (OrderNumber int NOT NULL, OrderDate date, CustomerNumber int NOT NULL, ItemNumber int NOT NULL, Amount float ) Теперь, когда таблица ORDERS сформирована, остается только одна таблица. Создайте таблицу ITEMS,

используя следующий синтаксис: CREATE TABLE ITEMS (ItemNumber int NOT NULL, Description char(30), Price float) 12.6 Добавление и удаление полей таблицы Используйте команду SQL ALTER TABLE, чтобы добавлять и удалять поля в существующей таблице. Не

все серверы поддерживают удаление поля после его создания (Сервер Sybase SQL, например, не поддерживает), но InterBase поддерживает. Используйте следующий синтаксис, чтобы добавить поле:

ALTER TABLE CUSTOMER ADD PhoneNumber Char(10) Используйте следующий синтаксис, чтобы удалить поле: ALTER TABLE CUSTOMER DROP PhoneNumber Вы не можете добавлять поле NOT NULL к таблице, которая уже имеет строки, поскольку это

противоречит логике: во всех строках только что добавленного столбца не может быть ничего, кроме NULL. 12.7 Ограничения Ограничение (Constraint) — механизм, с помощью которого ограничивается тип данных, который может

содержать поле. Ограничение может также использоваться для определения значения поля по умолчанию. Ограничения могут быть определены, когда таблица впервые создана, с помощью команды CREATE TABLE, или позже, с помощью команды ALTER TABLE. Вот пример ограничения первичного ключа:

ALTER TABLE CUSTOMER ADD CONSTRAINT PRIMARY KEY (CustomerNumber) Это выражение добавляет ограничение первичного ключа к таблице CUSTOMER, определяя поле

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

Ограничение внешнего ключа определяет поле в одной таблице, значения которой должны существовать в другой (внешней) таблице. Внешний ключ не идентифицирует записи главной таблицы единственным образом, как это делает первичный ключ. Он существует как первичный (уникальный) ключ во второй (подчиненной) таблице. Добавление ограничения внешнего ключа заставляет InterBase автоматически формировать вторичный индекс, используя его ключевые поля. Вот пример команды:

92

ALTER TABLE ORDERS ADD FOREIGN KEY (CustomerNumber) REFERENCES CUSTOMER Это ограничение определяет поле CustomerNumber в таблице ORDERS как внешний ключ, который

ссылается на то же самое поле в таблице CUSTOMER. Это означает, что идентификаторы заказчика, введенные в таблицу ORDERS должны сначала существовать в таблице CUSTOMER. Это также означает, что идентификаторы заказчика, которые используются в таблице ORDERS, не могут быть удалены из таблицы CUSTOMER. Эта возможность предписывать связь между двумя таблицами просто определяя ее, называется декларативной целостностью связей. Термин означает, что целостность связи между таблицами обеспечена просто ее определением (или объявлением), а не кодом программы, которую вы пишете.

Третий тип ограничения — тот, который проверяет поле на соответствие списку предопределенных значений. Вот пример такого ограничения:

ALTER TABLE CUSTOMER ADD CONSTRAINT INVALID_STATE CHECK (State in ('OK','AR','МО')) Обратите внимание на имя (INVALID_STATE), используемое для ограничения. Это выполнено для того,

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

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

базе данных, которые ограничение, как предполагается, отвергает. Например, чтобы проверить предшествующее ограничение INVALID_STATE, введите такую команду в WISQL:

INSERT INTO CUSTOMER (CustomerNumber, State) VALUES (123,'CA') поможет пользователю определить источник проблемы. Поскольку ограничение позволяет только значения ' ОК ', ' AR ' и ' МО ', это должно отклонить вашу

попытку вставить строку, выдав сообщение: 297 error: Operation violates CHECK constraint INVALID_STATE on view or table CUSTOMER.

Если ограничение, которое вы определили, функционирует не так, как ожидалось, убедитесь, что вы успешно добавили его, и что оно проверяет данные так, как вы определили.

12.9 Создание индексов Вы создаете индексы в SQL, используя команду CREATE INDEX. Вот базовый синтаксис: CREATE INDEX ORDERS02 ON ORDERS (CustanerNumber) где ORDERS02 — имя нового индекса, ORDERS — имя таблицы для формирования индекса, a

CustomerNumber — ключ индекса. В InterBase индексные имена должны быть уникальны для всей базы данных, в которой они находятся.

Вы можете создавать индекс, который запрещает дублирование, используя разновидность команды CREATE UNIQUE INDEX, например так:

CREATE UNIQUE INDEX ORDERS03 ON ORDERS (OrderNumber) Индексные ключи, по умолчанию, размещаются в порядке возрастания. InterBase также поддерживает

возможность создания индексов в порядке убывания, используя ключевое слово DESCENDING. Например, CREATE DESCENDING INDEX ORDERS03 ON ORDERS (Amount) помогает таким запросам, как SELECT * FROM ORDERS ORDER BY Amount DESCENDING выполняться более эффективно. Это похоже на использование функции DESC () во многих диалектах

Xbase. Подключение и отключение индекса InterBase поддерживает полезный механизм для отключения индекса, а также для его включения и

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

ALTER INDEX CUSTOMER03 INACTIVE Чтобы повторно активизировать его, используйте следующее выражение: ALTER INDEX CUSTOMER03 ACTIVE Отключение и затем включение индекса приводит к его реконструированию. Отключение индекса не

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

12.10 Вставка данных Команда SQL INSERT используется для добавления данных к таблице. Вы можете добавлять данные

построчно, используя оператор VALUES команды INSERT, или вставлять несколько строк сразу, считывая

93

их из другой таблицы. Используйте следующий синтаксис, чтобы добавить данные к каждой из трех таблиц. Сначала добавьте три строки к таблице CUSTOMER, выполняя следующие команды в WISQL:

INSERT INTO CUSTOMER (CustomerNumber, LastName, FirstName, StreetAddress, City, State, Zip) VALUESfl,'Doe','John','123 Sunnylane', 'Anywhere', 'OK', '73115') INSERT INTO CUSTOMER (CustomerNumber, LastName, FirstName, StreetAddress, City, State, Zip) VALUES(2,'Doe','Jane','123 Sunnylane', 'Anywhere', 'OK', '73115') INSERT INTO CUSTOMER (CustomerNumber, LastName, FirstName, StreetAddress, City, State, Zip) VALUES(3, 'Citizen', 'John', '57 Riverside', 'Reo', 'AR', '65803') Теперь добавьте три строки к таблице ITEMS следующими командами: INSERT INTO ITEMS (ItemNumber, Description, Price) VALUES(1001,'WIDGET A', 123.45) INSERT INTO

ITEMS (ItemNumber, Description, Price) VALUES(1002,' WIDGET B', 678.90) INSERT INTO ITEMS (ItemNumber, Description, Price) VALUES(1003,' WIDGET C', 86753.09) В заключение, добавьте четыре значения к таблице ORDERS, используя следующие команды: INSERT INTO ORDERS (OrderNumber, OrderDate, CustomerNumber, ItemNuinber, Amount) VALUES(101, '07/07/95', 1, 1001, 123.45) INSERT INTO ORDERS (OrderNumber, OrderDate, CustomerNumber, ItemNuinber, Amount) VALUES(102, '07/08/95', 2, 1002, 678.90) INSERT INTO ORDERS (OrderNumber, OrderDate, CustomerNumber, ItemNumber, Amount) VALUES(103, '07/09/95', 3, 1003, 86753.09) INSERT INTO ORDERS (OrderNumber, OrderDate, CustomerNumber, ItemNumber, Amount) VALUES(104, '07/10/95', 1, 1002, 678.90) Вы не обязаны задавать все поля или следовать порядку, в котором они расположены в таблице, определяя

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

INSERT INTO ITEMS (Price, ItemNumber) VALUES (123.45, 1001) Команда UPDATE Без сомнения, вы когда-нибудь захотите изменить данные, которые загрузили в таблицу. Для этого

используйте команду SQL UPDATE. Она очень похожа на команду dBASE REPLACE ALL. Вот ее синтаксис: UPDATE CUSTOMER SET Zip='90120' WHERE City='Beverly Hills' Оператор WHERE в предшествующем запросе может не позволить изменить все строки таблицы, но вы

без труда можете это сделать, опустив оператор WHERE: UPDATE CUSTOMER SET State= 'CA' Вы также можете модифицировать поле, используя другие поля в главной таблице. Вы можете даже

использовать для изменений само поле: UPDATE ORDERS SET Amount=Amount+(Amount*0.07) Команда DELETE Используйте команду DELETE для удаления строк из таблиц. Чтобы удалить все строки в таблице,

используйте следующую команду: DELETE FROM CUSTOMER Команда DELETE может также включать оператор WHERE, чтобы сузить перечень удаляемых строки.

Например: DELETE FROM CUSTOMER WHERE LastNameo'Doe' 12.11 Команды COMMIT и ROLLBACK Группа изменений в базе данных формально известна как транзакция. Команда SQL COMMIT фиксирует

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

Утилита WISQL системы InterBase начинает транзакцию автоматически (выдавая эквивалент команды SET TRANSACTION InterBase), загружаясь впервые. Когда вы выходите из утилиты, вам предлагается сохранить работу. Вы также можете в процессе работы сохранять или отменять внесенные изменения, используя опции Commit Work и Rollback Work в меню File приложения WISQL.

12.12 Команда SELECT Вы можете быстро проверить содержимое каждой таблицы, используя команду SQL SELECT. Наберите

SELECT * FROM tablename, заменяя tаblепате именем таблицы, которую вы желаете проверить (CUSTOMER, ORDERS или ITEMS). В этом месте каждая таблица должна иметь по три строки.

Команда SELECT * возвращает все поля всех строк в таблице. Вместо этого вы могли бы использовать список полей, разграниченных запятой, как в команде

SELECT CustomerNumber, LastName, State FROM CUSTOMER чтобы задать только интересующие вас

94

поля. Поля выражений Список полей команды SELECT может содержать не только имена полей таблицы. Это могут быть также

выражения, содержащие числа и функции. Вот команда SQL InterBase, которая возвращает приведенную к верхнему регистру фамилию каждого заказчика в таблице заказчиков:

SELECT UPPER(LastName), FirstName FROM CUSTOMER Составные поля Составные поля— функции, которые выполняют некоторые вычисления с набором данных. Например,

функции COUNT, SUM, AVG, MIN и MAX. Вот несколько примеров их использования. SELECT COUNT (*) FROM CUSTOMER подсчитывает, сколько заказчиков находятся в файле. SELECT MAX(Amount) FROM ORDERS сообщает сумму в долларах самого большого заказа в файле. SELECT SUM (Amount) FROM ORDERS возвращает общую сумму в долларах всех заказов в файле. Оператор WHERE Оператор SQL WHERE используется для того, чтобы ограничить набор данных, возвращаемых командой

SELECT. Вот несколько примеров: SELECT * FROM CUSTOMER WHERE State= 'OK' - возвращает список только тех заказчиков, которые проживают в штате ОК. (Оклахома). Команда SELECT * FROM CUSTOMER WHERE StreetAddress LIKE '%Sunny%' возвращает список

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

Команда SELECT FROM ORDERS WHERE Amount > 500 возвращает список тех заказов, сумма которых превышает $500.

Команда SELECT FROM ORDERS WHERE OrderDate BETWEEN '07/08/95' AND '07/09/95' возвращает только те заказы, которые произошли между 8 июля и 9 июля, 1995, включительно. Объединения Оператор WHERE также используется при соединении одной таблицы с другой для создания

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

SELECT CUSTOMER.CustomerNumber, ORDERS.Amount FROM CUSTOMER, ORDERS WHERE CUSTOMER. CustomerNumber=ORDERS.CustomerNumber Обратите внимание на включение таблицы ORDERS в оператор FROM и на использование знака

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

Внутренние и внешние объединения Тип объединения слева, упомянутый в предыдущем разделе, формально известен как внутреннее

объединение. Внутреннее объединение возвращает строки, только если условие объединения выполнено. В отличие от внешнего объединения, которое возвращает строки независимо от того, выполнено условие объединения или нет. Когда условие объединения не выполнено для данной строки во внешнем объединении, поля из внутренней таблицы возвращаются как NULL.

ANSI-синтаксис объединения ANSI-синтаксис для левого внутреннего объединения выглядит так: SELECT CUSTOMER. CustomerNuinber, ORDERS.Amount FROM CUSTOMER LEFT JOIN ORDERS ON CUSTOMER. CustomerNuniber=ORDERS. CustomerNumber Обратите внимание на то, что ключевое слово INNER не включено явно. InterBase также поддерживает

синтаксис SELECT CUSTOMER.CustomerNumber, ORDERS.Amount FROM CUSTOMER, ORDERS WHERE CUSTOMER. CustomerNumber=ORDERS. CustomerNuinber для определения левых внутренних объединений.

95

Синтаксис для левого внешнего объединения выглядит так: SELECT CUSTOMER. CustomerNuinber, ORDERS. Amount FROM CUSTOMER LEFT OUTER JOIN ORDERS ON CUSTOMER.CustomerNumber=ORDERS.CustomerNumber Для правых внешних объединений вы просто заменяете оператор LEFT оператором RIGHT. Правое

внутреннее объединение и левое внутреннее объединение — фактически одно и то же без различий в синтаксисе.

Многоуровневые объединения Многоуровневые объединения — объединения, которые включают больше двух таблиц. Таблица А

соединяется с таблицей В, которая, в свою очередь, соединяется с таблицей С. Рассмотрим следующий запрос:

SELECT C.LastName, C.FirstName, I.Discription FROM CUSTOMER C, ORDERS O, ITEMS I WHERE С. CustomerNumber=O. CustomerNumber AND O.ItemNuinber=I.ItemiNamber В этом запросе таблицы CUSTOMER и ORDERS соединены их общим ключом— полем CustomerNumber.

Затем таблицы ORDERS и ITEMS соединены их общим ключом — полем ItemNumber. В результате все три таблицы связаны вместе в одном наборе результатов.

Самообъединения Кроме объединения с другими таблицами, таблица может быть объединена сама с собой. Этот тип

объединения известен как рефлексивный, или самообъединение. Рассмотрите следующий запрос: SELECT O.CustomerNumber, O.Amount, (O.Amount/SUM(02.Amount))*100 Percentage FROM ORDERS O, ORDERS O2 WHERE O.CustomerNumber=O2.CustomerNumber GROUP BY O.CustomerNumber, O.Amount Цель этого запроса состоит в том, чтобы перечислить каждый заказ, сравнивая его сумму с общей суммой

заказов, сделанных заказчиком. Единственный способ выполнять такой тип запроса в одной команде SELECT — использовать самообъединение. Статистика для каждого заказчика собирается и группируется, затем таблица ORDERS присоединяется сама к себе, чтобы отыскать общие заказы для каждого заказчика. Сумма текущего заказа затем делится на эту общую сумму и преобразовывается в процент для размещения в наборе результатов.

Тэта-объединения Тэта-объединение соединяет две таблицы, используя другие операторы сравнения, кроме операторов

равенства, обычно оператор неравенства (о). Вот пример тэта-объединения; это обращение запроса, использовавшегося, чтобы показать самообъединение:

SELECT С.CustomerNumber, O.Amount, Sum(O2.Amount) OTHERS FROM CUSTOMER C, ORDERS O, ORDERS O2 WHERE С. CustomerNumber=O. CustomerNumber AND С.CustomerNumber<>O2.CustomerNumber GROUP BY C.CustomerNumber, O.Amount Фактически этот запрос содержит два объединения. Сначала он соединяет таблицы CUSTOMER и

ORDERS, чтобы отыскать заказы, сделанные каждым заказчиком. Затем он использует тэта-объединение, чтобы отыскать общее количество всех заказов, не сделанных каждым заказчиком. Поскольку при этом используется два различных типа объединений, чтобы связать одну и ту же таблицу, запрос содержит два разных псевдонима для таблицы ORDERS.

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

набор результатов, обычно, ошибочен — результат отсутствующих или неправильных объединений между таблицами. Вот пример:

SELECT ORDERS.OrderNutnber, ITEMS.ItemNulnber FROM ORDERS, ITEMS ORDER BY OrderMumber, ItemNumber На больших таблицах Декартово произведение может загрузить работой сервер на длительное время.

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

Подзапросы Подзапрос— команда SELECT внутри оператора WHERE другой команды SELECT. Используйте подза-

прос, чтобы возвратить список значений, необходимый для создания запроса. Вот пример:

96

SELECT * FROM CUSTOMER WHERE CustomerNuinber IN (SELECT CustomerNuinber FROM ORDERS) Операторы ANY, ALL, SOME, EXISTS и SINGULAR функционируют исключительно в подзапросах.

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

GROUP BY Поскольку SQL — язык запросов, ориентированный на множества, а не на записи, команды, которые,

группируют данные, встроены в язык и, совместно с составными функциями, являются средствами, с помощью которых выполняется реальная работа по поиску данных. Программисты на dBASE находят этот подход необычным — они приучены к работе с данными по принципу "запись за записью". Выполнение цикла по таблице для генерирования итоговой информации — способ, который обычно применяется в базах данных PC — к SQL неприменим. Одна команда SQL может сделать то, что делают 10 или даже 50 строк кода Xbase. Это волшебство происходит при использовании оператора GROUP BY команды SELECT совместно с составными функциями SQL. Вот пример использования GROUP BY:

SELECT CUSTOMER. CustomerNuinber, sum (ORDERS.Amount) TotalOrders FROM CUSTOMER, ORDERS WHERE CUSTOMER. CustomerNumber=ORDERS. CustomerNuinber GROUP BY CUSTOMER.CustomerMumber Этот запрос возвращает список всех заказчиков наряду с общей суммой заказов каждого заказчика. Как

нам узнать, какие поля включить в оператор GROUP BY. В InterBase мы должны объединить оператором GROUP BY все несоставные поля в списке полей команды SELECT. Оператор GROUP BY подразумевает использование, по крайней мере, одного составного поля в списке полей SELECT; вы не можете включать оператор GROUP BY без этого.

НАVING Оператор HAVING используется для ограничения строк, возвращенных оператором GROUP BY. Его

связь с оператором GROUP BY подобна связи между оператором WHERE и командой SELECT. Оператор HAVING работает аналогично оператору WHERE со строками в наборе результатов, вместо строк в таблицах запроса.

Вообще, HAVING менее эффективен, чем оператор WHERE, потому что он ограничивает набор результатов после того, как этот набор был организован в группы, в то время как WHERE делает это до того. Вот пример использования оператора HAVING:

SELECT CUSTOMER. LastName, COUNT (*) NumberWithNaine FROM CUSTOMER GROUP BY CUSTOMER.LastName HAVING COUNT (*) > 2 Практически единственный случай, когда использование оператора HAVING обосновано, это если он

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

ORDER BY Используйте оператор ORDER BY для того, чтобы упорядочить строки в наборе результатов. Например: SELECT * FROM CUSTOMER ORDER BY State SELECT FirstName, LastName FROM CUSTOMER ORDER BY LastName Псевдонимы полей Вы могли отметить, что я использовал логические имена полей для таких составных функций, как COUNT

() и SUM (). Такие метки известны как псевдонимы поля и служат для того, чтобы облегчить чтение запроса и его набора результатов. В InterBase SQL вы помещаете псевдоним поля непосредственно справа от соответствующего поля в списке полей команды SELECT. Например, в запросе

SELECT CUSTOMER.LastName, COUNT (*) NumberWithName FROM CUSTOMER GROUP BY CUSTOMER.LastName HAVING COUNT (*) > 2 псевдоним поля составной функции COUNT () — NumberWithName. Вы можете использовать

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

SELECT CUSTOMER. LastName LName,COUNT (*) NumberWithName FROM CUSTOMER GROUP BY CUSTOMER.LastName заменяет псевдонимом LName поле LastName в наборе результатов. Однако вы не можете использовать

псевдонимы в таких частях запроса, как операторы WHERE или GROUP BY. Вы должны использовать фактическое имя поля или значение в этих частях команды SELECT.

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

определите для нее короткое имя. Для этого обозначьте псевдоним таблицы в операторе FROM команды SELECT. Псевдоним помещается справа от фактического имени таблицы, как показано в следующем

97

примере: SELECT C.LastName, COUNT (*) NumberWithName FROM CUSTOMER С GROUP BY C.LastName Псевдоним может использоваться в списке полей команды SELECT перед тем, как он будет

синтаксически определен. Это возможно из-за того, что ссылки на объекты базы данных в запросе определяются прежде, чем выполняется запрос.

12.13 Просмотры Просмотр таблицы SQL состоит из команды SELECT, которую вы можете обрабатывать как таблицу и, в

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

Когда вы выполняете команду SELECT для просмотра, оптимизатор совмещает SELECT, используемый для создания просмотра, с выполняемым вами и оптимизирует эти два запроса как один запрос серверу.

Просмотры таблицы SQL создаются с помощью команды CREATE VIEW. Например: CREATE VIEW OKCUSTOMERS AS SELECT * FROM CUSTOMER WHERE State='OK' После того как просмотр будет создан, он может запрашиваться точно так же, как таблица, например: SELECT * FROM OKCUSTOMERS Даже если команда SELECT не включала оператор WHERE, набор результатов появится, так как оператор

WHERE встроен в просмотр. Команда SELECT, которая составляет просмотр, может делать почти то же, что и обычная команда

SELECT. Единственное, что она не может делать — это включать оператор ORDER BY. Это ограничение существует и на Sybase-, и на InterBase-платформах.

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

· Команда просмотра SELECT должна использовать только одну таблицу или ссылаться на другой моди-фицируемый просмотр.

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

· Команда просмотра SELECT не должна содержать подзапросы, предикат DISTINCT, оператор HAVING, составные функции, объединенные таблицы, определяемые пользователем функции и хранимые процедуры.

Создавая модифицируемый просмотр, вы можете сообщить серверу, чтобы он следил за соответствием строк, которые модифицируются или добавляются при просмотре, критериям выбора, наложенным просмотром. Таким образом, вы можете гарантировать, что модифицированная или добавленная запись не "выйдет из области" — не исчезнет из просмотра при изменении или добавлении. Вы делаете это с помощью оператора WITH CHECK OPTION команды CREATE VIEW. Вот синтаксис:

CREATE VIEW OKCUSTOMERS AS SELECT * FROM CUSTOMER WHERE State"'OK' WITH CHECK OPTION

Теперь любые попытки модификации или вставки записей, у которых поле State отлично от ' ОК ', потерпят неудачу.

12.14 Хранимые процедуры Хранимая процедура — скомпилированная программа SQL, часто состоящая из набора команд SQL,

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

Хранимые процедуры создаются с помощью команды CREATE PROCEDURE. Вот пример синтаксиса InterBase:

CREATE PROCEDURE listcustomers AS BEGIN SELECT LastName FROM CUSTOMERS END Если процедура получает параметры от вызывающего ее оператора, синтаксис немного изменяется. Вот

синтаксис InterBase: CREATE PROCEDURE listcustomers (State char(2), LastNameHask char(30)) AS BEGIN SELECT LastName FROM CUSTOMERS WHERE State=:State AND LastName LIKE :LastNameMask END

98

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

ключевое слово RETURNS, например: CREATE PROCEDURE listcustomers (State CHAR(2)) RETURNS(LastName CHAR(30)) AS BEGIN

FOR SELECT LastName FROM CUSTOMER WHERE State=:State INTO :LastName DO

SUSPEND; END Обратите внимание на использование синтаксиса FOR SELECT... DO для возврата строк результатов

вызывающему оператору. Команда SUSPEND приостанавливает выполнение процедуры, пока очередная строка не будет запрошена вызывающим оператором. Значения, которые были назначены выходным параметрам, возвращаются прежде, чем выполнение процедуры останавливается.

Выполняемые процедуры Выполняемая процедура немного отличается от процедуры выбора тем, что она не требует включения

команды RETURNS. Вот пример выполняемой процедуры в InterBase SQL: CREATE PROCEDURE insertcapital (Capital CHAR(30), State CHAR(2)) AS BEGIN

UPDATE CAPITALS SET Capital=Capital WHERE State=:State

END 12.15 Сценарии Сценарии SQL создаются на основе команд языка определения данных SQL с использованием хранимых

процедур. Вы можете создавать эти сценарии, используя текстовый редактор; большинство хороших редакторов SQL позволяет сохранять файлы сценариев на диске. Не забудьте, что эти сценарии должны включать все необходимые команды CONNECT и SET TERM. Они затем могут быть выполнены с помощью опции Run an ISQL Script в программе WISQL. Листинг 1 показывает пример такого файла.

Листинг 1 Хранимая процедура, помещенная в файл сценария SQL CONNECT "C:\DATA\IB\ORDENT"; SET TERM ^ ; CREATE PROCEDURE GET CUSTOMER (State CHAR(2)) RETURNS (LastName CHAR(30)) AS BEGIN FOR SELECT LastName FROM CUSTOMER WHERE State = :State INTO :LastName DO SUSPEND; END ^ SET TERM ; ^ EXIT; Обратите внимание на то, что команда CONNECT в начале файла устанавливает связь с базой данных.

Затем следует команда SET TERM, которая заменяет символ завершения команды SQL на символ возврата каретки (^), вместо используемой по умолчанию точки с запятой (;). Это предохраняет команды, внедренные в сохраненную процедуру от выполнения, когда выполняется команда CREATE PROCEDURE. В заключение, команда SET TERM снова выполняется, чтобы восстановить признак конца команды к его значению по умолчанию.

12.16 Исключения Исключения — механизм для определяемых пользователем сообщений об ошибках в сохраненных

процедурах и выключателях. В InterBase используется команда CREATE EXCEPTION для определения нового исключения и команда EXCEPTION для "вызова" или "включения" его. Листинг 2 — пример исключения InterBase и сохраненной процедуры, которая его вызывает.

99

Листинг 2 Исключение InterBase и сохраненная процедура CREATE EXCEPTION ORDER_TOO_LOW "Сумма заказа должна быть выше $5." CONNECT "C!\DATA\IB\ORDENT"; SET TERM ^ ; CREATE PROCEDURE inssertorder (OrderNuinber int, OrderDate date, CustomerNumber int, ItemNumber int,

Amount float) AS BEGIN

IF (:Amount < 5) THEN EXCEPTION ORDER TOO LOW;

ELSE INSERT INTO ORDERS VALUES (:OrderNumber, :0rder0ate, :CustomerNumber, :ItemNumber,

:Amount); END ^ SET TERM; EXIT; Эта процедура подразделяет заказы стоимостью $5 и больше. Обратите внимание на использование

синтаксиса IF. . . THEN для того, чтобы определить, является ли значение поля Amount во вставляемой строке меньше, чем $5. Команда EXCEPTION используется для того, чтобы вызвать исключение ORDER_TOO_LOW, когда значение Amount меньше, чем $5.

12.17 Триггеры В отличие от хранимых процедур, триггеры — подпрограммы SQL, которые активизируются, когда в

данной таблице вставляются, модифицируются или удаляются данные. Вы связываете триггер со специфической операцией в таблице: вставка, модификация или стирание. Вот пример триггера на InterBase SQL:

CREATE TRIGGER ORDERSDelete FOR CUSTOMER BEFORE DELETE AS BEGIN

DELETE FROM ORDERS WHERE CustomerNumber=OLD.CustomerNumber;

END Этот триггер удаляет заказы из таблицы ORDERS, если запись заказчика удалена из таблицы

CUSTOMER. Такой способ удаления известен как каскадное удаление: Удаление, сделанное в одной таблице, каскадно переходит на другие, используя общий ключ.

Обратите внимание на использование контекстной переменной OLD. Контекстная переменная OLD указывает текущее значение поля до операции UPDATE или DELETE. Контекстная переменная NEW ссылается на новое значение поля после операции INSERT или UPDATE.

Обратите внимание также на использование ключевого слова BEFORE. Триггер может быть активизирован до или после команд INSERT, UPDATE или DELETE.

В InterBase с конкретным событием таблицы может быть связано практически любое количество триггеров (точнее, до 32768). Для нескольких триггеров, связанных с одним и тем же событием таблицы, можно определять порядок запуска, используя ключевое слово POSITION. Например:

CREATE TRIGGER ORDERSDelete FOR CUSTOMER BEFORE DELETE POSITION 0 AS BEGIN DELETE FROM ORDERS WHERE CustomerNumber=OLD.CustomerNumber; END Нумерация POSITION начинается с 0 и доходит до 32 767; триггеры активизируется в порядке

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

100

12.18 Курсоры Курсоры — некий аналог текущей записи в SQL. Курсоры дают вам возможность работать со строкой

таблицы. Поскольку BDE автоматически создает и поддерживает указатели, вам вообще не понадобится создавать собственные указатели, используя SQL. Однако вы можете найти их удобными в сохраненных процедурах.

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

Объявление курсора состоит из команды SELECT и (для модифицируемых курсоров) списка модифицируемых полей. Вот синтаксис:

DECLARE с_CUSTOMER CURSOR FOR SELECTS * FROM CUSTOMER Для того чтобы вы могли найти строки, используя курсор, откройте его. Используя команду OPEN, вы

инициализируете запрос, который составляет объявление курсора: OPEN с_CUSTOMER OPEN не возвращает ничего приложению. Вы должны использовать для этого команду FETCH. Вот

синтаксис: FETCH c_CUSTOMER Эта команда извлекает строку в таблице курсора. Каждое последующее обращение к FETCH находит

следующую строку в таблице. И InterBase, и Sybase поддерживает только односторонние курсоры; вы не можете передвигаться по набору курсора назад. Для того чтобы вернуться назад, закроите и вновь откроите курсор.

Строки таблиц, возвращенные модифицируемыми курсорами, могут модифицироваться с помощью специальных версии команд UPDATE и DELETE. Модифицируемый курсор объявляется с помощью оператора FOR UPDATE OF. Вот пример такого объявления:

DECLARE с CUSTOMER CURSOR FOR SELECT * FROM CUSTOMER FOR UPDATE OF LastName Чтобы модифицировать или удалить текущую строку модифицируемого курсора, используйте выражение

WHERE CURRENT OF cursorname для определения команды, например UPDATE CUSTOMER SET LastName="Cane" WHERE CURRENT OF C_CUSTOMER или DELETE FROM CUSTOMER WHERE CURRENT OF C_CUSTOMER Заканчивая работу с курсором, используйте команду CLOSE, чтобы закрыть его. Закрытие курсора

освобождает все ресурсы системы, которые использовались им. Вот синтаксис: CLOSE С_CUSTOMER

101

13 УПРАВЛЕНИЕ ДОСТУПОМ 13.1 Общие сведения Термин управление доступом относится к совместному использованию ресурсов несколькими

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

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

13.2 Разграничение транзакций Разграничение транзакций относится к механизму, используемому системами управления базами данных,

чтобы изолировать одну транзакцию от воздействия другой. Разграничение транзакций в Delphi организовано в три различных уровня, каждый с собственными характеристиками. Эти уровни разграничения транзакции (Transaction Isolation Level — TIL) воздействуют на возможность доступа одной транзакции к изменениям базы данных, сделанными другими параллельными транзакциями.

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

13.3 Выбор соответствующего уровня разграничения транзакций Большинство серверов базы данных, включая InterBase, поддерживает три отдельных уровня

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

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

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

основных групп: · Неактуальные чтения происходят, когда незафиксированные изменения, сделанные одной

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

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

В соответствии с проектом транзакции READ COMMITTED разрешают неповторяемые чтения, потому что они могут читать изменения, сделанные другими транзакциями:

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

· Потерянные модификации происходят, когда одна транзакция неосторожно переписывает изменение, сделанное другой транзакцией.

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

102

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

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

Управление транзакциями с помощью компонента TDatabase Вы управляете транзакциями с помощью компонента TDatabase, используя свойство Translsolation и

методы StartTransaction, Commit и Rollback. 13.5 Разграничение транзакций Свойство Translsolation управляет уровнем разграничения транзакций на сервере базы данных для вашего

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

Translsolation имеет три возможных значения: tiDirtyRead, tiReadCommitted и tiRepeatableRead. Значение по умолчанию — tiReadCommited. Три возможных значения Translsolation имеют следующий смысл:

· tiDirtyRead — незафиксированные изменения других транзакций видимы; · tiReadCommitted — только зафиксированные изменения других транзакций видимы; · tiRepeatableRead — изменения других транзакций к предварительно прочитанным данным невидимы,

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

13.6 Управление транзакциями Метод StartTransaction компонента TDatabase отмечает начало транзакции— группу изменений базы дан-

ных, которые вы хотите обрабатывать как целое. Они или все будут применены к базе данных, или ни одно из них не будет применено.

Метод Commit закрепляет те изменения в базе данных, которые произошли после начала транзакции. Представьте ее как команду save базы данных.

Метод Rollback отменяет изменения базы данных, которые были сделаны после начала транзакции. Представьте ее как команду undo базы данных.

Свойство Translsolation и уровни разграничения транзакций DBMS. Уровни разграничения, обеспечиваемые свойством Translsolation компонента TDatabase, могут быть

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

В табл. 13.1 перечислены уровни разграничения транзакций, обеспечиваемые установкой Translsolation, с их реализациями на различных платформах систем управления базами данных.

Таблица 13.1. Translsolation и уровни разграничения транзакций систем управления базами данных Установка

Translsolation InterBase Oracle Sybase & Microsoft

tiDirtyRead Read committed Read committed committed Read tiReadCommitted Read committed Read committed Read committed tiRepeatableRead Repeatable Rsad Repeatable read (READ ONLY) Error (unsupported)

13.7 Управление транзакциями с помощью SQL Вы можете также управлять обработкой транзакции на сервере, используя метод Passthrough языка SQL.

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

13.7.1 Разграничение транзакций Чтобы установить желаемый уровень разграничения транзакций с помощью SQL, используйте команду

SET TRANSACTION. InterBase обеспечивает три уровня разграничения транзакций— SNAPSHOT, SNAPSHOT TABLE STABILITY и READ COMMITTED. Чтобы установить один из них как новый уровень разграничения транзакций, используйте команду SET TRANSACTION ISOLATION LEVEL в SQL.

Вот описание функций каждой установки: · SNAPSHOT фиксирует вид базы данных с момента начала транзакции. Изменения, сделанные

другими активными транзакциями, не видимы при использовании этого уровня разграничения

103

транзакций. · SNAPSHOT TABLE STABILITY блокирует таблицы, из которых эта транзакция читает и в которые

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

позволяет транзакции делать изменения, которые не вызывают конфликтов модификаций с другими транзакциями. READ COMMITTED поддерживает следующие два опциональных параметра.

· NO RECORD_VERSION (значение по умолчанию) показывает только самую последнюю версию строки. Если параметр WAIT в SET TRANSACTION был определен, транзакция ждет, пока самая последняя версия записи будет завершена или отменена, а затем повторяет чтение.

· RECORD_VERSION читает самую свежую зафиксированную версию строки, даже если более новая незафиксированная версия присутствует в базе данных.

13.7.2 Разграничение транзакций на сервере и классические проблемы разграничения

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

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

Таблица 13.2. Уровни разграничения транзакций InterBase и пять классических проблем управления

транзакциями Уровень

разграничения транзакций

Проблема Решение

SNAPSHOT Потерянные модификации

Другие транзакции не могут модифицировать строки, модифицируемые этой транзакцией

Неактуальные чтения

Не читаются изменения, сделанные другими транзакциями; другие транзакции видят предыдущую версию строки, модифицируемую этой транзакцией

Неповторяемые чтения

Можно читать только ту версию строки, которая была зафиксирована в начале транзакции

Фантомные строки Можно читать только ту версию строки, которая была зафиксирована в начале транзакции

Побочные эффекты модификаций

Не читает изменения, сделанные другими транзакциями; другие транзакции видят предыдущую версию строки, модифицируемую этой транзакцией

READ COMMITTED

Потерянные модификации

Другие транзакции не могут модифицировать строки, модифицируемые этой транзакцией


Другие транзакции видят предыдущую или зафиксированную версию строки, модифицируемую этой транзакцией


Допускаются определенными конструкциями

Фантомные строки Могут встречаться, так как этот уровень разграничения транзакций видит зафиксированные изменения других транзакций


Другие транзакции видят предыдущую или зафиксированную версию строки, модифицируемую этой транзакцией

SNAPSHOT TABLE

STABILITY

Потерянные модификации

Предотвращение модификаций другими транзакциями контролируемых таблиц


Предотвращение доступа других транзакций к модифицируемым таблицам


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

104

Фантомные строки Предотвращение доступа других транзакций к контролируемым таблицам


Предотвращение модификаций другими транзакциями контролируемых таблиц

13.7.3 Выбор правильного уровня разграничения транзакций Каждая проблема разграничения транзакций адекватно охвачена всеми тремя уровнями разграничения

транзакций InterBase. Выбор такого уровня в значительной степени зависит от потребностей вашего приложения.

Заданный по умолчанию уровень разграничения транзакций — SNAPSHOT. Для большинства приложений должен быть выбран или SNAPSHOT, или READ COMMITTED. SNAPSHOT TABLE STABILITY может блокировать Других пользователей вне таблиц на неопределенное время, хотя они могут нуждаться в доступе. Следовательно, его нужно избегать, если Вы фактически не нуждаетесь в его специализированных возможностях.

Выбор между SNAPSHOT и READ COMMITTED должен быть основан на том, должны ли вы видеть зафиксированные модификации других транзакций во время вашей транзакции. Если нет, используйте SNAPSHOT, если да— READ COMMITTED. Вообще говоря, уровень разграничения транзакций READ COMMITTED производит меньшее количество конкурентной блокировки.

13.7.4 Управление транзакциями Вы контролируете транзакции InterBase, используя команды SQL SET TRANSACTION, COMMIT и

ROLLBACK. SET TRANSACTION имеет ряд применений, включая установку уровня разграничения транзакций. COMMIT работает точно так же, как метод Conimit компонента Tdatabase, как команда 5ave базы данных. Функция ROLLBACK, как и метод Rollback компонента Tdatabase, отменяет изменения, сделанные в базе данных, начиная с последнего COMMIT.

SET TRANSACTION Используйте команду SET TRANSACTION, чтобы начать транзакцию: SET TRANSACTION Если вы хотите использовать транзакцию READ ONLY, включите ключевое слово READ ONLY: SET TRANSACTION READ ONLY Многие платформы RDBMS также поддерживают именованные транзакции. Это дает возможность

вкладывать транзакции друг в друга. В InterBase SQL команды модификации данных (включая INSERT, UPDATE и DELETE) могут также напрямую использовать именованные транзакции. Вот синтаксис InterBase для запуска именованной транзакции:

SET TRANSACTION :UpdateCustomers Заметьте, что :UpdateCustomers должна быть предварительно объявленной и инициализированной

переменной базового языка. Вот синтаксис Sybase Transact-SQL для выполнения того же действия: BEGIN TRANSACTION UpdateCustomers СОММIТ и ROLLBACK Команда SQL COMMIT делает изменения, которые произошли в течение данной транзакции,

постоянными. Представьте ее как команду save базы данных. ROLLBACK отменяет изменения, которые транзакция могла сделать в базе данных, она функционирует подобно команде undo базы данных. Обе эти команды воздействуют на изменения, сделанные только после последнего COMMIT, вы не можете отменить изменения с помощью ROLLBACK, если вы уже зафиксировали их.

Утилита WISQL в InterBase начинает транзакцию автоматически (выдавая эквивалент команды SET TRANSACTION в InterBase), когда она впервые загружается. Когда вы выходите из утилиты, она спрашивает, хотели ли бы вы зафиксировать свою работу. Вы можете зафиксировать или отменить выполненные изменения в любое время, используя опции Commit Work и Rollback Work из меню File в WISQL.

13.7.5 Системы управления доступом Понятия, лежащие в основе систем управления доступом относительно просты, если вы уменьшаете их до

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

105

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

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

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

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

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

Блокировка таблиц, строк и страниц (Sybase), иногда встречается последовательно, т.е. вы будете часто видеть блокировку нескольких строк, сопровождаемую блокировкой всей таблицы, к которой они принадлежат. Это называется каскадированием блокировки и происходит, когда ваш сервер базы данных полагает, что существует достаточно блокировок строк или страниц, чтобы оправдать их замену полной блокировкой таблицы. Sybase, например, поддерживает переход от блокировки страницы транзакции к блокировке таблицы после того, как транзакция накапливает больше чем 200 блокировок страниц в данной таблице.

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

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

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

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

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

Sybase SQL Server обеспечивает блокировку и таблиц и страниц, но не блокирует отдельные строки. Если вы пытаетесь изменить данную строку, страница, на которой она находится, блокируется на время модификации. Смысл в том, что модификации обычно происходят в группе строк, которые сконцентрированы в данной области базы данных. Блокируя эти строки страницей, одной блокировки

106

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

13.7.7 Оптимистическая система управления доступом Оптимистические системы управления конкуренцией предполагают, что большинство модификаций

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

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

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

13.7.8 Оптимистическое управление доступом в приложениях Delphi Delphi реализует версию оптимистического управления доступом, используя свойство UpdateMode

компонентов TTable и TQuery в DataSet. Как и во всех оптимистических системах конкуренции, Delphi получает копию строки с сервера, дает возможность вам изменить ее, а затем посылает изменения на сервер с помощью команды SQL UPDATE. Эта команда UPDATE содержит оператор WHERE, который определяет строку, предназначенную для изменения. UpdateMode контролирует, какие поля из таблицы перечислены в операторе WHERE.

UpdateMode может иметь три возможных значения: · upWhereAll (значение по умолчанию) — оператор WHERE включает каждое поле в таблицу; · upWhereChanged — оператор WHERE включает ключевые поля DataSet и поля, которые изменились; · upWhereKeyOnly — оператор WHERE включает только ключевые поля DataSet (используйте его

только тогда, когда вы имеете исключительное право использования таблицы базы данных). Компоненты TTable и TQuery публикуют свойство UpdateMode. Его значение ни умолчанию—

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

Предположим, что Ваше приложение Delphi только что изменило поле LastName таблицы CUSTOMER. При включенной опции upWhereAll сгенерируется следующий текст SQL (обратите внимание на длинный оператор WHERE):

UPDATE CUSTOMER SET LastMame='newlastname' WHERE CustOBerNumber=l AND LastNanie= 'Doe' AMD FirstMame= 'John' AMD StreetAddress=SSunnyLane AMD City= 'Anywhere' AND State='OK' AMD Zip= '73115' При включенной опции upWhereChanged будет сгенерирована следующая команда: UPDATE CUSTOMER SET LastName='newlastname' WHERE CustomerMuBber=l AMN LastMame='Doe' Обратите внимание, насколько эта команда короче. Обратите внимание также, что эта команда избегает

возможности перезаписи изменений другого пользователя для поля LastName, включая первоначальное значение в оператор WHERE. Если другой пользователь изменяет поле LastName между чтением строки и

107

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

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

Вы должны использовать upWhereAll, если у вас нет особой не делать этого. upWhereChanged — хороший вариант, если таблица, с которой Вы работаете, имеет большое количество полей, и upWhereAll слишком медленный. upWhereKeyOnly безопасен только тогда, когда Вы имеете исключительный доступ к таблице, — не используйте его в других случаях. Одно практическое приложение UpWhereKeyOnly— в коллекции данных из машины некоторого типа. Если вы должны модифицировать значения в таблице базы данных, используя эти данные, как они были собраны, вы, вероятно, будете единственным пользователем, модифицирующим таблицу, и быстрое выполнение UPDATE SQL может быть критическим. Если так, возможно upWhereKeyOnly—то, в что нужно, но я рекомендую вам посоветоваться по этому поводу с ад-министратором базы данных.

13.7.9 Ведение журнала регистрации транзакций Вас никогда не интересовал вопрос о том, как серверы баз данных программно защищают информацию от

разрушения при сбоях в подаче напряжения или поломке аппаратной части компьютера? Хранит ли сервер какой-либо список проведенных изменений? Как он находит список транзакций, которые следует отменить?

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

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

Сведение информации для журнала регистрации к минимуму Общая ошибка, совершаемая разработчиками приложений клиент/сервер, исходящая из баз данных с

плоской моделью файла, подобно dBASE и Paradox, в использовании конструкций программирования, вместо SQL, для выполнения групповых модификаций данных. Например, вам необходимо преобразовать все поля фамилий в таблице CUSTOMER в верхний регистр. Если вы — вышеупомянутый dBASE-разработчик, вы могли бы написать следующий код на Object Pascal, чтобы выполнить ваши модификации:

with taCUSTOMER do begin First; While not EOF do begin FieldByNamef'LastName').AsString:= Uppercase(FieidByName('LastName').AsString); Next; end; end; Этот подход был бы не только медленным, он будет иметь нежелательный эффект начала и фиксирования

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

108

модификаций. Для каждой итерации вашего цикла будет генерироваться отдельная команда SQL UPDATE, дополненная собственным оператором WHERE, чтобы разместить следующую строку в таблице. С очень большой таблицей CUSTOMER процесс, вероятно, проходил бы очень медленно.

Журнал регистрации транзакций использует компонент TQuery или TStoredProc, чтобы выполнить вашу модификацию. Та же самая модификация, написанная в SQL, выглядит следующим образом:

UPDATE CUSTOMER SET LastName UPPER(LastName) Поскольку команда будет самостоятельно обрабатываться как одиночная транзакция, или все

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

Другой способ ограничения регистрационной информации, сгенерированной транзакцией, — избегать команд SQL DELETE. Каждая строка, удаленная с помощью команды DELETE, сначала копируется в журнал регистрации, чтобы транзакция могла быть отменена, если возникнет потребность. Обработка большой таблицы очень легко засорила бы журнал регистрации. Если вы должны удалить все строки в таблице, используйте команду усечения таблицы вашего сервера вместо команды DELETE. Много серверов поддерживают команду, подобную команде dBASE ZAP, которая быстро освобождает таблицу от ее содержимого. Sybase, например, поддерживает для этой цели команду TRUNCATE TABLE. Она не только быстрее чем команда DELETE, но и не сохраняется в журнале регистрации, поэтому нет никакой регистрационного действия, связанного с ней. Если ваш сервер не поддерживает команды усечения таблицы, вы можете найти, что простое отбрасывание и создание вновь рассматриваемой таблицы — также вариант, в зависимости от способа ее использования в других местах в базе данных и другими приложениями.

Еще один способ избежать излишней регистрации— использовать SELECT INTO вместо INSERT SELECT при копировании строк из одной таблицы в другую. Строки, вставленные с помощью INSERT SELECT, сохраняются в журнале регистрации, так что больших вставок желательно избегать. SELECT INTO, — нерегистрируемая операция — она не добавляет никаких записей в журнал регистрации. Не все платформы систем управления базами данных поддерживают этот синтаксис (InterBase, например, не поддерживает), так что вам, возможно, не удастся использовать эту методику.

Синтаксис Sybase Transact-SQL для использования SELECT INTO: SELECT LastName, FirstName INTO NEWCUSTOMER FROM CUSTOMER Это создает таблицу, названную NEWCUSTOMER, и вставляет в нее поля LastName и FirstName из

таблицы CUSTOMER. Это функционально эквивалентно такому синтаксису: CREATE TABLE NEWCUSTOMER (LastName CHAR(30), FirstName CHAR(30)) INSERT INTO NEWCUSTOMER (LastName, FirstName) SELECT LastName, FirstName FROM CUSTOMER Вы можете использовать SELECT INTO, чтобы избежать создания записей в журнале регистрации, когда: · необходимо создать таблицу, а затем копировать строки из другой таблицы в нее; · все поля в новой таблице необходимо заполнить значениями из второй таблицы; · вы не заинтересованы в отмене вставки строк. 13.7.10 Дробление больших транзакций Бывают случаи, когда вы должны выполнить массовую модификацию данных некоторого вида, что

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

Во-первых, вы можете разделить один UPDATE или DELETE на несколько UPDATE или DELETE, каждый из которых использует более ограничительный оператор WHERE. Например, если таблица CUSTOMER содержит миллион записей, и нам необходимо привести к верхнему регистру каждую фамилию в каждой записи, мы могли бы сделать следующее:

SET TRANSACTION; UPDATE CUSTOMER SET LastName=UPPER( LastName) WHERE CustomerNumber between 1 and 100000; COMMIT; SET TRANSACTION; UPDATE CUSTOMER

109

SET LastName=UPPER(LastName) WHERE CustomerNumber between 100001 and 200000; COMMIT; SET TRANSACTION; UPDATE CUSTOMER SET LastNcune=UPPER(LastName) WHERE CustomerNumber between 200001 and 300000; COMMIT; Это простая методика, которая может изменить невозможную модификацию на возможную. Во-вторых вы можете ограничить число строк, к которым имеет доступ команда. Не все платформы

систем управления базами данных поддерживают этот метод (Sybase, например, поддерживает, a InterBase — нет).

Используйте команду, специфическую для сервера, которая ограничивает строки, обрабатываемые UPDATE или DELETE. Затем повторите UPDATE или DELETE столько раз, сколько необходимо, чтобы обработать все строки. Вот пример использования Transact-SQL в Sybase:

SET ROWCOUNT 50000 /* Ограничивает UPDATE 50000 строками */ WHILE (EXISTS (SELECT * FROIVI ORDERS WHERE AmountOO)) BEGIN

UPDATE ORDERS SET Amount=0 WHERE AmountoO /* Предохраняет UPDATE от бесконечного цикла */

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

после обработки. Один из способов сделать это состоит в том, чтобы проверять в операторе WHERE команды UPDATE значение, установленное в UPDATE. Другими словами, мы проверяем поле Amount, используя о 0, потому что мы присваиваем полю Amount значение 0 в UPDATE. Это позволяет UPDATE помечать каждую строку как обработанную. Это отмечание предохраняет строку от двойной модификации.

Вот пример использования команды DELETE: SET ROWCOUMT 50000 /* Ограничивает действие DELETE 50000 строками */ WHILE (EXISTS (SELECT * FROM ORDERS WHERE Amount=0)) BEGIN

DELETE FROM ORDERS WHERE Amount=0

END

110

14 СОЗДАНИЕ ПРИЛОЖЕНИЙ ДЛЯ РАБОТЫ С БАЗАМИ ДАННЫХ В СРЕДЕ DELPHI

14.1 Общие сведения Delphi представляет собой уникальную систему разработки, в которой технология

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

В этом разделе рассматривается более мощный с точки зрения работы с базами данных вариант системы — Delphi Client/Server.

Большим преимуществом приложений, разрабатываемых в среде Delphi,, стала доступность использования как реляционного, так и навигационного программирования при работе с данными. Такую возможность приложениям Delphi предоставляет ядро процессора баз данных Borland Database Engine (BDE). Использование реляционных методов позволяет манипулировать большими выборками информации и легко проводить групповые операции. Навигационные методы дают приложению преимущества быстрого доступа к отдельным полям и записям таблиц баз данных.

Структурная схема организации доступа приложения к различным базам данных отражена на рисунке 14.1. Работа с данными в Delphi осуществляется через BDE, которое обеспечивает непосредственную связь с локальными базами данных и используется при организации доступа к удаленным серверам. В основе BDE лежит технология Integrated Database API (IDAPI), уже известная программистам, которые работают с СУБД фирмы Borland. Через BDE и драйверы Borland SQL Links приложение может связываться с SQL-серверами. В то же время, BDE поддерживает и интерфейс Open DataBase Connectivity (ODBC), что позволяет получить доступ не только к любому удаленному серверу баз данных, для которого имеется драйвер ODBC, но и к любому источнику структурированных данных.

ODBC — интерфейс для свободного доступа к данным в гетерогенной среде реляционных и нереляционных баз данных. Основываясь на базовом интерфейсе SQL — Call Level Interface, ODBC обеспечивает открытый доступ к большинству данных, расположенных на персональном компьютере, миникомпьютере и к базам данных больших ЭВМ, позволяя разработчикам иметь одновременный доступ к базам данных. Стандарт ODBC полностью поддерживает технологию клиент/сервер.

В состав стандартной поставки Delphi включен локальный сервер InterBase, который позволяет проводить в Delphi автономную разработку приложений с поддержкой SQL, готовых к переносу в среду клиент/сервер. Он представляет собой облегченный вариант InterBase Workgroup Server 4.0.

В этой главе будут исследованы вопросы создания приложений Delphi для работы с базами данных. Рассматривается общая методика разработки, использование компонентов доступа к базам данных и визуальных компонентов создания программного интерфейса. Отдельные разделы посвящены особенностям создания приложений для систем клиент/сервер и для работы с SQL-серверами. Подробно описывается механизм работы BDE и SQL Links, их взаимодействие с приложением и серверами баз данных. Один раздел содержит краткие сведения о локальном сервере InterBase и его инструментарии. Также рассматриваются различные утилиты, как интегрированные в среде разработчика, так и входящие в комплект поставки в виде отдельных продуктов, необходимых при разработке приложений. Два раздела построены в форме справочника по основным свойствам и методам компонентов, предназначенных для работы с базами данных.

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

111

Рис. 14.1. Механизм организации доступа приложения к базам данных

14.2 Ядро Borland Database Engine (BDE) Как уже отмечалось, использование Delphi позволяет разработчику создавать самые разнообразные

приложения для работы с базами данных. Среди них могут быть как простейшие программки, открывающие два-три поля, так и мощные приложения, предназначенные для работы в системах клиент/сервер. Такая универсальность достигается за счет использования ядра BDE. В основе BDE лежит технология IDAPI, которая включает IDAPI-инфраструктуру и обработчик запросов.

Использование BDE позволяет приложению осуществлять доступ к данным не только локальных (Paradox и dBase), но и удаленных баз данных, расположенных на SQL-серверах (InterBase, Sybase, Oracle, Informix, MS SQL Server), а также в любых форматах, доступных через драйверы ODBC (см. рис. 4.1). BDE поддерживает многопользовательский доступ к гетерогенным базам данных, связанные запросы к нескольким разнотипным базам данных одновременно, прямой перенос данных из одного формата в другой. Программисты могут обращаться к функциям BDE с помощью языков программирования Borland C++, Borland Pascal, Visual C++, а также любых других компиляторов С и C++ для Windows.

Архитектура BDE\IDAPI основана на драйверах. Для каждого источника данных существует свой драйвер, который поддерживает не только последнюю версию источника, но и все предыдущие версии. Именно через такие драйверы осуществляется связывание и все обращения к данным. BDE поддерживает два класса драйверов. К первому классу относятся драйверы, обслуживающие SQL-серверы, причем каждый из этих серверов может использовать собственный диалект SQL. Во второй класс входят драйверы для локальных баз данных.

Архитектура BDE\IDAPI является объектно-ориентированной, поэтому ее инфраструктура легко расширяется и обобщается. В комплекте BDE содержатся более пятидесяти языковых драйверов, которые используются всеми драйверами доступа к данным и всеми общими обработчиками и сортировщиками запросов. Инфраструктура BDEVDAPI предоставляет обширный набор инструментов, которые могут

112

использоваться всеми драйверами. Диспетчер памяти предоставляет дополнительные возможности по управлению памятью. В отладочном

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

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

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

Кэш для данных BLOB позволяет производить чтение/запись произвольного места в бинарном объекте, при переполнении содержимое кэша автоматически записывается в разделяемый файл. Одновременно может быть открыто любое количество BLOB.

Генератор SQL транслирует запрос в формате QBE в эквивалентный запрос SQL, если он предназначен SQL-серверу.

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

Функции пакетной обработки включают копирование данных из одного формата в другой, переименование таблиц и т. д.

Модуль Xlate оптимизирует процесс преобразования форматов данных. Модуль таблиц в памяти обеспечивает виртуальную память, ориентированную на таблицы. Он

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

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

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

курсоров BDE и поэтому может работать с любым источником данных. Если запрос может быть выполнен напрямую, то он сразу передается серверу. Запрос QBE предварительно транслируется в SQL.

Технология Idapter является составной частью BDE и предназначена для организации доступа к базам данных, используя стандартный программный интерфейс драйверов Borland SQL Links. Idapter транслирует вызовы функций интерфейса IDAPI в вызовы стандартных методов интерфейса ODBC, что позволяет использовать практически любой драйвер стандарта ODBC в режиме драйвера IDAPI. При этом могут использоваться любые функции интерфейса IDAPI. Технология Idapter существенно увеличивает число доступных через BDE форматов данных. Поставляется совместно с IDAPI, как отдельная динамическая библиотека.

14.3. Утилита конфигурации BDE Для успешной работы с данными их источник должен иметь правильно созданный псевдоним (их может

быть несколько). Для этой цели, а также для настройки других параметров BDE, служит утилита конфигурации BDE (исполняемый файл BDECFG.EXE). Все измененные ею параметры сохраняются (по умолчанию) в файле IDAPI.CFG в каталоге IDAPI.

Свойство KeepConnections определяет, сохраняются ли неактивные соединения для временных компонентов TDatabase. Используйте DropConnections для разрыва всех неактивных соединений с базой данных. Помните, что если все текущие соединения с сервером базы данных неактивны, и вы их разрываете, то придется снова регистрироваться на сервере, когда понадобится к нему доступ. С другой стороны, можно установить для свойства KeepConnections значение False и избежать при этом необходимости каждый раз вводить имя пользователя и пароль, когда BDE восстанавливает связь с вашим компьютером. Эта особенность описывается позже в этой главе при обсуждении компонента Database.

113

14.4 Основные компоненты Delphi для работы с БД Используйте компонент TSession при необходимости проникнуть в BDE, где можно получить такую

информацию, как список псевдонимов, параметры псевдонимов и установки драйверов. Вы также можете напрямую вызывать BDE API, используя свойство Handle компонента TSession.

Вы можете использовать предопределенные переменные Session для вызова методов TSession. Вот пример вызова метода TSession:

Session.GetAliasNames(ListBoxl.Items); Этот метод производит замену содержимого ListBoxl. Items на список, который определен текущим

псевдонимом BDE. Session. GetDatabaseNames (ListBoxl. Items); Этот метод производит замену содержимого ListBoxl. Items на список всех псевдонимов BDE и

приложения. Ses sion.KeepConnections:False; Эта команда заставляет ваше приложение разорвать все неактивные временные связи с базой данных.

Заметьте, что это относится только к временным связям — тем, которые установлены самой BDE, но не тем, которые вы сами создали. База данных, которая имеет свой собственный компонент TDatabase, будет использовать его свойство KeepConnections.

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

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

14.4.1 Класс TDatabase Модуль: DB Родительский класс: TComponent Для доступа к базам данных явное использование компонента TDatabase не обязательно, но он

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

Табл. 14.1 содержит список ключевых свойств, табл. 14.2— список ключевых методов, а табл. 14.3— список ключевых событий для TDatabase.

Таблица 14.1. Ключевые события TDatabase Свойство Описание

AliasName Ссылается на используемый псевдоним BDE Connected Показывает, открыт ли компонент TDatabase DatabaseName Определяет псевдоним для приложения DriverName Определяет тип драйвера KeepConnection Определяет, сохранять ли неактивные соединения с базой данных LoginPrompt Определяет, будет ли запрашиваться пользователь для регистрации Таблица 14.2 - Ключевые методы TDatabase Метод Функция

Open Явно открывает соединение с базой данных Close Явно закрывает соединение с базой данных Таблица 14.3 - Ключевые события TDatabase Событие Описание

OnLogin Возникает, когда открывается TDatabase SQL и LoginPrompt имеет значение

True

114

Ключевые элементы Используйте свойство DatabaseName для определения псевдонима BDE или псевдонима приложения.

Когда вы определите имя псевдонима в этом свойстве (это имя может быть, например, таким же, как в свойстве Name компонента), вы увидите его в списке свойства DatabaseName компонента DataSet подобно TTable и TQuery. Вы можете выбрать его из этого списка и связать компонент DataSet с компонентом TDatabase.

AliasName определяет BDE псевдоним для использования с данным TDatabase. Он указывает на псевдоним, который вы уже определили, используя утилиту конфигурации BDE, и применяет его для установки значений по умолчанию. Обратите внимание на то, что это свойство и свойство DriverName - взаимно исключающие. Установка одного автоматически отключает другое.

Если вы решили не устанавливать AliasName, используйте вместо него свойство DriverName для определения драйвера BDE, который вы хотите задействовать. Для локальных таблиц (dBASE и Paradox) можно использовать драйвер STANDART, а для SQL-серверов—драйверы INTERBASE, SYBASE, ORACLE или MSQL. Как было замечено раньше, свойство DriverName и свойство AliasName — взаимно исключающие. Переключатель Connected открывает и закрывает связь с базой данных. Вы можете установить ему значение True в инспекторе объектов Delphi для установки связи с базой данных во время разработки программы. Когда вы открываете DataSet, который указывает на TDatabase, автоматически открывается TDatabase. При закрытии компонента Tdatabase со ссылками на компоненты DataSet закрываются все компоненты.

Для того чтобы не нужно было регистрироваться каждый раз, когда открывается база данных, установите свойство KeepConnection в True.

Если свойство LoginPrompt установлено в True, то у пользователя будет запрашиваться регистрационная информация при связи с сервером базы данных. Вы можете обойти это, используя событие OnLogin.

Для установки уровня разделения транзакций (transaction isolation level— TIL) сервера определите свойство Translsolation. Уровень TIL влияет на возможность наблюдения за действиями других пользователей и возможность других пользователей следить за вашими транзакциями.

Ваше приложение должно включать компонент Database для следующих действий. 1. Установки постоянных связей с базой данных 2. Установки локальных псевдонимов приложения базы данных 3. Изменения параметров регистрации на сервере 4. Манипуляции механизмом управления транзакциями на сервере Установка связей с базой данных Приложения Delphi связываются с SQL-серверами, используя драйверы SQL Links для BDE. Эти

драйверы обеспечивают подключение к InterBase, Sybase, Oracle и Microsoft DBMSs. Обычно вы будете использовать Database Explorer или утилиту конфигурации BDE для создания

псевдонимов, по которым ваши приложения будут подключаться к этим серверам. Псевдоним BDE не больше, чем список параметров — набор информации о подключении, которое BDE использует для связи с базой данных. Когда вы устанавливаете псевдоним, он появляется в списке DatabaseName компонента DataSet, например TTable и TQuery.

Редактируя свойство Params компонента TDatabase, вы можете переопределить установки по умолчанию, которые предлагает BDE.

Сохранение связей с базой данных Установите значение True для свойства KeepConnection компонента TDatabase для сохранения связей с

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

Изменение параметров регистрации на сервере Вы можете использовать событие OnLogin компонента TDatabase для того, чтобы избежать вывода

принятого по умолчанию диалогового окна запроса пароля во время установки связи с базой данных. OnLogin получает два параметра:

компонент TDatabase, который указывает на базу данных, с которой пытается связаться пользователь, и объект TString с необходимыми параметрами регистрации. Вот описание для типичной процедуры события OnLogin:

procedure Tforml.DatabaselLogin(Database: TDatabase; LoginParams: TString); В процедуре OnLogin вы можете использовать свойство Values для доступа к отдельным параметрам,

например: LoginParams.Values['SERVER NAME'] := 'BLUESERVER'; LoginParams.Values['USER NAME'] := 'muddy'; LoginParams.Values['PASSWORD'] := 'waters'; Для того чтобы пропустить принятого по умолчанию диалогового окна запроса пароля, вам необходимо

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

115

ввода параметров, получить их от другого компонента, или вы можете жестко "забить" их в приложении — это не имеет значения. Если OnLogin получит значения, Delphi попытается использовать их для установки связи с базой данных.

14.4.2 Класс TTable Модуль: DBTables Родительский класс: TDBDataSet TTable — прямой потомок класса DBDataSet и косвенный потомок класса DataSet. Вы обращаетесь к

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

Установка свойства Active в True идентична вызову метода Open компонента DataSet— при этом открывается DataSet. Аналогично, установка Active в False так же, как вызов метода Close DataSet, закрывает DataSet.

Вы можете проверить текущее состояние DataSet, посмотрев свойство State. Оно будет иметь одно из следующих значений:

· dslnactive — DataSet закрыт. · dsBrowse - DataSet находится в режиме Browse. По DataSet можно перемещаться, но изменения не

могут быть сделаны, пока свойство State не установлено в dsEdit. · dsEdit — DataSet находится в режиме Edit и позволяет изменять данные. 1-1 dslnsert — DataSet

находится в режиме Insert. · dsSetKey - DataSet находится в режиме SetKey. Если в этом режиме определены значения для столб-

цов, они будут использованы как значения поиска. Последующий GotoKey будет искать запись используя эти значения. '

· dsCalcFields — вызывается обработчик события OnCalcFields. Метод First перемещает в начало DataSet, метод Last перемещает в конец. Методы Prior и Next

передвигают к предыдущей и следующей строке, соответственно. Используйте свойство BOF, чтобы определить, находится ли курсор в начале DataSet. Используйте

свойство EOF чтобы определить, достиг ли курсор конца DataSet. Эти два свойства могут быть полезны при выполнении цикла по строкам в DataSet. Вот пример простой подпрограммы, которая проходит по строкам таблицы, отображая поле из каждой строки:

With taTENANT do begin First; While not EOF do begin ShowMessage('Name is: '+taTENANTName.Value); Next; end; end; 14.4.3 Класс TQuery Модуль: DBTables Родительский класс: EDBDataSet Подобно TTable, Tquery — прямой потомок класса DBDataSet и косвенный потомок класса DataSet.

Tquery используется для пересылки явных выражений SQL-механизму базы данных. SQL-механизм работает с локальными таблицами или обращается к серверу базы данных. Запрос, который возвращает множество результатов, выполняется с использованием метода TQuery Open или установкой свойства TQuery Active в значение True. Результаты обработки запросов можно поместить в таблицу, при этом вы сможете модифицировать, добавлять и удалять строки, — точно так же, как при использовании компонента TTable.

Табл. 15.4 содержит список ключевых свойств. Таблица 14.4. Ключевые свойства TQuery Свойство Описание

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

116

Database Идентифицирует Tdatabase для использования в DataSet DatabaseName Имя псевдонима, используемого для соединения с базой данных DataSource Определяет TdataSource, из которого берутся параметры запроса DBHandle Возвращает дескриптор соединения с BDE низкого уровня EOF Отражает, находится ли курсор на последней записи FieldCount Возвращает число полей в DataSet FieldDefs Перечисляет важную информацию относительно полей в DataSet Fields (Индексное) Возвращает поле DataSet Filter Определяет выражение для фильтрации записи Filtered Определяет, является ли активной фильтрация, определенная свойствами Filter или

OnFilterRecord

FilterOptions Управляет поведением фильтров Handle Возвращает дескриптор курсора BDE низкого уровня Modified Отражает, была ли изменена текущая запись в множестве переменных результатов ParamCount Отражает число параметров для запроса SQL Params Определяет параметры для использования с SQL-запросом Prepared Отражает, подготовлен ли запрос RecordCount Возвращает число строк в DataSet RequestLive Определяет, хотите ли вы, чтобы результат запроса обновлялся SessionName Определяет компонент ТSession, который используется для связи с базой данных SQL Определяет выражения SQL для выполнения на сервере

14.4.4 Класс TDataSource Модуль: DBTables Родительский класс: TComponent Компонент TDataSource связывает средства управления данными с компонентами DataSet (TTable, TQuery

и TStoredProc). Он позволяет компонентам взаимодействовать с физическими объектами базы данных. Средства управления данными ссылаются на общий TDataSource через их свойства DataSource. Он, в свою

очередь, ссылается на DataSet, который обеспечивает их данными. DataSet обеспечивает данные для TDataSource, которые затем передаются компонентам управления данными. Когда данные изменяются в компонентах управления данными, изменение передается TDataSource, который затем передает его DataSet.

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

Табл. 14.5 содержит список ключевых свойств. Таблица 14.4. Ключевые свойства TDataSource Свойство Описание

Autoedit Определяет, будет ли при изменении содержимого управления данными автоматически запускаться режим Edit

DataSet Ссылается на DataSet, который обеспечивает данные этому TDataSource

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

State Возвращает состояние связанного компонента DataSet

117

Таблица 14.5. Ключевые методы TDataSource Метод Функция

Edit Переключает соответствующий DataSet в режим Edit

14.5 Оптимизация приложений Delphi типа клиент/сервер Предлагается несколько способов оптимизации приложений Delphi типа клиент/сервер. Эти способы

образуют две большие группы: · оптимизация Delphi-приложения; · оптимизация сервера. Оптимизация сервера, в свою очередь, делится на оптимизацию методов SQL-программирования и

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

Стремитесь свести связи с сервером к минимуму Используйте связи с сервером, лишь когда это абсолютно необходимо. Нерациональное расходование

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

компонента TDatabase на все приложение. Для этого выполните следующие действия. 1. Вставьте компонент TDatabase в главную форму вашего приложения. 2. Установите свойство AliasName компонента Tdatabase так, чтобы оно указывало на BDE-псевдоним,

который будет использовать ваше приложение. 3. Задайте свойству DatabaseName имя, которое вы хотите использовать в качестве псевдонима

приложения. 4. Используя компонент TDataSet (TTable, TQuery или TStoredProc), присвойте его базе данных вместо

регулярного BDE-псевдонима то же имя, что и у TDatabase. Когда заданный таким образом TDataSet откроется, он будет использовать связь, обеспеченную

компонентом TDatabase, вместо того, чтобы создавать свою собственную. Существует одна тонкость, о которой вам следует помнить при использовании TDatabase. Если вы

открываете TDataSet, который обращается к псевдониму конкретного приложения, в то время как оно открыто редактором форм Delphi, форма, содержащая компонент TDatabase, должна быть также открыта в редакторе форм.

Открывая TDataSet (присваивая его свойству Active значение True в инспекторе объекта), который обращается к Tdatabase, вы автоматически соединяете TDatabase с сервером. Поскольку свойству KeepConnection присвоено значение True по умолчанию, последующее закрытие TDataSet не закроет связи с сервером. Вместо этого, когда вы впоследствии сохраните свой проект и выйдете из Delphi, состояние связи базы данных с сервером будет сохранено вместе с проектом. Когда проект позже будет перезагружен, система сразу же спросит у вас пароль, потому что TDatabase будет пытаться восстановить предыдущую связь с сервером.

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

14.6 Управление обработкой транзакций Обычно Delphi автоматически следит за обработкой транзакций, открывая и закрывая транзакции, когда

приложение пытается изменить базу данных. Если этот уровень контроля недостаточен, вы можете следить за транзакциями самостоятельно, используя свойство Translsolation и методы StartTransaction, Commit и Rollback.

Свойство Translsolation управляет уровнем разграничения транзакций (TIL) на сервере базы данных. Translsolation имеет три возможных значения—tiDirtyRead, tiReadCommited и tiRepeatableRead. По умолчанию установлено tiReadCommited. Три возможных значения Translsolation имеют следующий смысл:

· tiDirtyRead — наблюдаются незавершенные изменения другой транзакции; · tiReadCommited — наблюдаются только завершенные изменения другой транзакции; · tiRepeatableRead — изменения, произведенные транзакциями, предварительно прочитанных данных

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

118

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

Commit закрепляет изменения в базе данных, которые произошли с тех пор, как началась транзакция. Представьте этот метод как команду Save.

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

119

15 РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ЭЛЕКТРОННОЙ КОМЕРЦИИ

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

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

Разработку программного обеспечения большинство людей считают наукой. Причем некоторые смотрят на нее как на творческую науку, но тем не менее науку. Прежде всего, вы работаете на поприще компьютерной науки, а не компьютерного искусства. Ведь нет классов по художественной разработке программных продуктов, как нет и курсов с названием "Мастерство разработки программного обеспечения". Однако мне больше нравятся термины искусство, ремесло, чем наука. А различие между искусством и ремеслом заключается в том, что ремесло утилитарно по своему назначению — ведь то, что создано ремеслом, имеет более широкое практическое применение, чем художественные ценности.

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

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

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

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

Конвейерность производства не остановилась в рамках мебельной промышленности, а распространилась и на многие другие области. Она принесла с собой и счастье и проклятие. Безусловно, многие товары стали гораздо дешевле, чем раньше, но какой ценой? Чего бы мы хотели: чтобы те же самые товары стали дешевле или чтобы дешевые товары стали еще дешевле? А не вышло ли так, что исчезновение умелых ремесленников сделало качественные товары дороже, а не дешевле?

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

Конспект лекций ТПСЭК

Education

Transcript of Конспект лекций ТПСЭК