Дела технологические
Принципы организации обмена данными в КИС

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

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

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

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

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

Для того, чтобы обеспечить режим работы всех пользователей в реальном масштабе времени, надо объединить их компьютеры в локальную сеть. База данных размещается на одном (как правило, самом мощном) компьютере, который называется "сервер базы данных (БД)" или просто "сервер". Название происходит от английского serve - подавать. Компьютер, за которым сидит каждый конкретный пользователь, получающий из базы или заносящий туда информацию, называется "рабочая станция", "клиентский компьютер" или просто "клиент". Тут, я думаю, объяснять происхождение термина не нужно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Существенное преимущество клиент-серверным технологиям дало появление стандартного языка запросов SQL-92, который поддерживают современные версии всех основных СУБД (Oracle, MS SQL Server, SyBase, Informix). В самом начале своей истории клиент-серверные системы имели индивидуальные языки запросов, затем они начали поддерживать первые версии SQL (клиент-серверные СУБД, поддерживающие этот язык, получили название SQL-Серверов). Однако в первых версиях стандартный диалект этого языка была настолько беден, что невозможно было писать программы, не использующие каких-то индивидуальных различий (PL SQL для Oracle, Transact SQL для MS SQL Server и т.п.). С появлением SQL-92 стало возможным создание КИС, работающих только на его основе. Что это означает для пользователя? Да только то, что он свободен в выборе СУБД. Сегодня ему достаточно MS SQL? Прекрасно! Работаем на нем. Завтра объемы возросли и захотелось поставить Oracle? Отлично! Ставим (это один из вариантов так называемого масштабирования системы). Прикладное ПО (собственно КИС) менять при этом не придется. Экономия, однако!

Еще один момент, который сильно подвинул с рынка файл-серверные программы, - это распространение Windows-приложений. Тут уже в ход пошли чисто экономические соображения. Файл-серверные СУБД для DOS вылизывались много лет. Многие из них были очень даже неплохо оптимизированы, обеспечивали хорошую надежность и быстродействие. Но к тому времени, когда прикладники начали писать программы под Windows, массами овладела идея единого интерфейса доступа к различным базам данных (ODBC, BDE и т.п.). А оптимизировать подо все сразу непросто, если не сказать невозможно. Поэтому все современные интерфейсы доступа к БД оптимизированы под клиент-серверную технологию, а с файл-серверными базами работают плохо и медленно. Поэтому выбор для программистов-прикладников невелик: либо работай с клиент-сервером, либо пиши медленные программы, либо не используй стандартные средства доступа, а создавай свои. Последний выход весьма и весьма неплох, но на него нужно большое время и деньги. Это обстоятельство и забило очередной гвоздь в гроб файл-сервера. Впрочем, пока далеко не последний гвоздь.

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

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

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

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

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

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

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

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

Терминал-сервер сейчас самое лучшее средство для работы с базой данных по низкоскоростным сетям, а попросту по телефонным проводам. Представьте, что у Вас компания с множеством филиалов. База данных компании установлена на сервере в Москве, а оператор филиала сидит во Владивостоке. Связь с сервером компании устанавливается по телефону (это может быть и прямой звонок, но через Интернет - гораздо дешевле), но при этом эффективное быстродействие для владивостокского оператора будет таким же, как в не слишком быстрой локальной сети. Неплохо? Я считаю, да!

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

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

Гл. эксперт компании "КОМПАС", к.т.н. Игорь Якобсон

e-mail: sensr@kompac.spb.su