Файл: Технология «клиент-сервер» (Модернизация устаревших информационных систем).pdf

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

Хранимая процедура - это сохраненный набор инструкций языка Transact-SQL, выполняемый как единое целое. Хранимая процедура является специальной программой из совместно откомпилированных команд Transact-SQL, сохраняемой в базе данных SQL Server и выполняемой по вызову клиента. В хранимых процедурах могут выполняться любые инструкции Transact-SQL, в том числе инструкции добавления, изменения и удаления данных (INSERT, UPDATE и DELETE). Хранимая процедура может принимать и возвращать параметры.

Триггеры представляют собой объекты базы данных, связанные с таблицей. Во многом они похожи на хранимые процедуры и часто упоминаются как "особый вид хранимых процедур". Основное различие между триггером и хранимой процедурой в том, что триггер связан с таблицей и работает только при работе выражения INSERT, UPDATE или DELETE.

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

1.1.4. Модернизация устаревших информационных систем

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

В каждой организации, переживающей процесс модернизации информационной системы, возникают свои проблемы. В одной пользователи требуют сохранить привычный пользовательский интерфейс (те, кто давно программирует на Delphi, наверное, помнят популярную задачу из серии «угоди пользователю, привыкшему к DOS», - как в форме ввода данных заставить клавишу Enter делать то, что обычно делает клавиша Tab); в другой нужно суметь не просто перенести в новую базу унаследованные данные, но и изменить их в соответствии с вновь возникшими потребностями (например, исправить ошибки, допущенные много лет назад при проектировании данных, или объединить данные из нескольких разных источников); в третьей организации сохранилось и используется большое количество отчетов, созданных с помощью старой настольной СУБД, и нужно обеспечить возможность их использования в новой информационной системе; в четвертой процесс ввода новых данных происходит непрерывно, и это накладывает ограничения на то, как именно производить процесс замены СУБД и клиентских приложений.

В целом варианты модернизации информационной системы можно условно разделить на следующие категории:

1. Замена СУБД с сохранением структуры базы данных и пользовательских приложений (или относительно небольшой их модернизацией).

2. Замена и СУБД, и пользовательских приложений с сохранением структуры базы данных.

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

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

Первая категория представляла собой драйверы различных серверных СУБД для средств разработки, ориентированных в целом на использование настольных баз данных (например, драйверы Oracle для Clipper, преобразовывающие функции Clipper в вызовы функций клиентского API Oracle - Oracle Call Interface); обычно эти драйверы поставлялись в виде библиотек, компилируемых вместе с приложением. «Потомки» подобного программного обеспечения существуют и сейчас - одним из них является, например, библиотека Borland SQL Links, изначально предназначенная для использования приложений Paradox с серверными СУБД.

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

Если говорить о первом варианте модернизации, в этом отношении больше всего повезло пользователям Microsoft Access - процесс замены базы данных Microsoft Access на MSDE (или Microsoft SQL Server) происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как в данном случае все эти СУБД (Access, MSDE и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных из Access содержатся в комплекте поставки и других серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server.

Что касается замены других версий настольных СУБД на серверные, здесь могут возникнуть определенные проблемы. Например, при переносе данных из dBase или Paradox в какую-нибудь серверную СУБД обслуживающее их приложение, написанное на Delphi, вполне может отказаться работать даже после корректной перенастройки библиотек доступа к данным, особенно если оно содержит сведения о метаданных. Возможны также различные неприятности, связанные с использованием строчных и прописных букв в наименованиях полей, применением русских наименований полей (и вообще локализованных версий, поддерживающих национальные традиции написания чисел и дат и нередко превращающих числовые данные и даты в при переносе в другую СУБД в нечто невообразимое), несовместимости некоторых типов данных (это особенно часто происходит при переносе таблиц Paradox в другие СУБД). Наконец, если в серверной СУБД определены какие-либо бизнес-правила, нет никакой гарантии, что они идеально соблюдались в настольной СУБД, из которой переносятся данные, и в этом случае некоторое количество «ручного» труда по разбору данных, не соответствующих этим правилам, вам или вашим пользователям гарантировано.

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

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

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

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

Надежность

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

Сервер баз данных осуществляет модификацию данных на основе механизма транзакций, который придает любой совокупности операций, объявленных как транзакция, следующие свойства:

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

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

Масштабируемость

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

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

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

Безопасность

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

Гибкость

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

Пользовательского интерфейса;

Правил логической обработки (бизнес-правил);

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

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

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