Электронная библиотека ГПНТБ России

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

Современные АИБС,
или Последствия «головокружения от успехов»

Анализ и критика современных систем автоматизации библиотек на примере системы «Библиотека 4.0».

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

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

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

Традиционные разработчики ПО работают с так называемыми языками программирования (Фортран, Бэйсик, Пролог, Паскаль, Си и др.). Язык программирования являет собой набор синтаксических правил. Эти правила читаются специальной программой – компилятором, преобразующим язык программирования в язык машинных команд (что и делает язык машинных команд более ненужным). Универсальность и гибкость языка программирования позволяет разрабатывать любые задачи, которые можно алгоритмизировать, чем объясняется большая популярность традиционного программирования.

СУБД представляет собой программу, которая производит различные операции над типовыми объектами БД (таблицами). Примеры СУБД – FoxPro, dBase, Clipper, ISIS и др. СУБД всегда состоит из определённого набора элементов. А синтаксические построения в СУБД в отличие от языка программирования «вертятся» вокруг языка структурированных запросов – SQL. Ограниченный набор средств разработки по понятным причинам отталкивает традиционных программистов-разработчиков от БД. Это послужило причиной возникновения своеобразного антагонизма между разработчиками БД и обычными программистами.

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

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

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

Теперь вернёмся к библиотечным реалиям. НТБ МАДИ работает с АИБС «Библиотека» (версии 4.0 и 5.0), поэтому остановимся на ней подробнее. Знакомство с ИРБИС и МАРК, в основе которых лежит тот же принцип, что и в основе «Библиотеки», позволяет считать, что всё, сказанное о принципах работы «Библиотеки», равно может быть сказано и об этих двух системах.

«Библиотека 4.0» разработана в среде Clipper в полном соответствии с рекомендациями корифеев библиотечной автоматизации. Во главу угла ими, как известно, поставлены коммуникативные форматы данных – различные версии MARC. Попробуем разобраться, что это такое.

MARC (Machine Readable Cataloging) – это метаязык (язык описания), конструкции на котором подчиняются определенному синтаксису, достаточно простому и хорошо известному. Правила составления лексем в этом формате тоже довольно просты, а словарь лексем, собственно говоря, определяет версию формата – RUSMARC, US MARC, MARC21 и т.д. «Словарь лексем» («лексикон» формата) – это определение полей, из которых состоит MARC-запись. Например, определение поля 100 как «сведения об авторе», а поля с меткой «100a» как «первый автор» есть не что иное, как определение лексемы «100a». Запись «100а» (а не, например, «100-а», «100_a», «а100» и т. п.) являет собой правило синтаксиса (словообразования) формата.

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

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

Если мы попробуем рассмотреть аналогичным образом библиографическое описание книги, то столкнемся со следующей проблемой. Записывая в первый столбец «Заглавие», а во второй – «Авторы», мы увидим, что записать в одну строку таблицы несколько авторов нельзя. Действительно, заглавию соответствует несколько авторов (сколько именно – в общем случае неизвестно), а в строке столбец «Авторы» только один. Если бы мы знали, сколько всего авторов может быть в описании, мы могли бы сделать 2, 3 столбца; штук 6 в большинстве случаев хватило бы. Но если мы записываем в базу данных инвентарные номера, то столбцов «Первый номер», «Второй номер» и т.д. нам потребовалось бы под тысячу.

Рассмотрим упрощенное математическое описание таблицы. Можно представить себе таблицу как координатную плоскость. В ней по оси X отложены заглавия, по оси Y – места хранения (мы считаем, что к каждому заглавию требуется указать некое число мест, которое заранее, т.е. в общем случае, не может быть установлено и зависит от самой книги). Тогда, чтобы ввести инвентарный номер, требуется объединить заглавие с сиглой, иными словами, взять на плоскости X–Y точку и отложить в пространство (по оси Z) инвентарный номер. В этом случае число потребных инвентарных номеров может быть любым, а сами номера зависят как от заглавия (общего описания книги), так и от места хранения (сиглы). Вспомнив, что инвентарный номер (как правило) определяется штрих-кодом книги и при выдаче объединяется с номером читателя в базе данных, мы придем к математическому описанию многомерной структуры данных.

Многомерная структура в СУБД реализуется путем использования нескольких таблиц. Две таблицы – «Заглавия» и «Сиглы» – позволяют решить задачу, если мы установим связь между записями в первой и второй таблице. По-английски связь – relation, откуда и название получающейся БД – реляционная (РБД). Теория реляционных БД сложна и многогранна. Трудно вообразить задачу, решение которой нельзя было бы представить в виде РБД.

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

Теперь можно ответить на вопрос, зачем и почему понадобился язык MARC. Этот формат позволяет записать библиографическое описание «в строку», т. е. «свернуть» многомерную запись библиографического описания любого вида издания в линейную запись, которую потом легко преобразовать обратно, т.е. «развернуть» в многомерную структуру РБД. В этой линейной записи каждая библиографическая запись существует независимо от других. Теперь видно, что MARC – это транспортный (коммуникативный) формат, который может и должен использоваться для передачи данных между изолированными системами или в качестве источника данных для сервисного ПО. Но он не может использоваться в качестве ядра БД. Почему же корифеи автоматизации заставляют думать, будто создатели MARC (американцы) хотели видеть, как их формат будут использовать в рамках РБД?

Обратимся к «Библиотеке 4.0», как более известной, чем «Библиотека 5.0». Схема представления данных у них идентична почти во всем: разница только в используемых кодовых таблицах. Для хранения данных этими системами используются файлы баз данных DBF, содержащие уже известные нам таблицы, поля которых во всех строках обладают одинаковой (фиксированной) шириной. Строки таблиц, где хранятся данные «Библиотеки», состоят по существу из двух столбцов. Первый – номер записи, а второй – строка записи в формате MARC (на самом деле там разделены паспортная и основная части записи, всего получается 3 столбца). Строки в формате MARC имеют различную длину, поэтому для хранения данных используется несколько таблиц (файлов). А по существу дела все ядро этой БД хранится в одной таблице. С позиций РБД это вопиющее недоразумение. Чем же продиктовано такое странное, с точки зрения традиционных представлений об архитектуре БД, решение?

В тот период, когда разрабатывалась БД «Библиотека», в СУБД Clipper было практически невозможно формирование сложной системы, состоящей из многих таблиц со сложными отношениями (связями) и работающей безотказно. Нужно было создать универсальный продукт, который можно было бы, в соответствии с существующими требованиями к АИБС, адаптировать к условиям конкретных библиотек. Возьмись тогда разработчики за создание полноценной РБД, им пришлось бы нелегко. Обилие таблиц и связей послужило бы благоприятной почвой для многочисленных программных ошибок, «панельность» СУБД не смогла бы помочь. Зато потребовалась бы большая скорость работы дисковых накопителей, выше оказались бы и требования к оперативной памяти (ведь хранить многомерную структуру в памяти надо было бы почти целиком). Далее увидим, что это преимущество призрачно. По сути дела, принятое решение позволило разработчикам упростить лишь одну операцию – экспорта и импорта данных, которую теоретики АИБС как раз и поставили во главу угла. Насколько оправдано это решение?

Операция «свертки» и «развертки» строки MARC-записи – простая задача для традиционного программиста, так как она может быть реализована на любом языке программирования с помощью простых, традиционных алгоритмов. Но для СУБД эта задача нетривиальна, поскольку эти операции не могут быть описаны с помощью языка SQL. Этот язык оперирует с таблицами. Значит, операция чтения-записи (основная при работе с БД!) требует от разработчика применять «ненативный» (не заложенный в СУБД), особый способ доступа к записям. Именно этим объясняется известная характеристика ИРБИС, как «тяжелой и неповоротливой» АИБС.

Теперь рассмотрим, как АИБС «Библиотека» работает с записями. Мы выяснили, что есть таблица с двумя столбцами. Когда требуется обработать какую-то книгу, например имеющую в системе № 15, соответствующая ей строка MARC извлекается из файла DBF. Затем подпрограмма разбора MARC-строки формирует структуру данных (это понятие хорошо знакомо традиционным программистам…), которую помещает во временную таблицу со столбцами «MARC-поле» и «Значение». С этой таблицей и работает пользователь, просматривая или редактируя записи. Когда требуется загрузить следующую запись, внесенные изменения «сворачиваются» в строку MARC-записи, временная таблица удаляется, а полученная «свернутая» строка заносится в нужное поле (ячейку) DBF-файла. Отсюда видно, что основное число операций связано не с работой СУБД (формированием и исполнением SQL-запросов), а с обработкой записей на традиционном языке программирования. Получается, что СУБД работает не по своему прямому назначению.

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

Чтобы организовать поиск по БД, разработчикам АИБС «Библиотека» пришлось создать специальную подпрограмму, которая производит «развертку» записей из формата MARC, преобразование их во временную таблицу, извлечение индексируемого поля из временной таблицы и добавление его в таблицу индексов (этот процесс называется актуализацией). Ясно, что при использовании РБД эти индексы не нужны, так как сами поля записей являют собой искомую информацию. В РБД индексы служат уже не для поиска информации, а для его ускорения. Таким образом, выходит, что медлительные и тяжеловесные индексы «Библиотеки» в целом компенсируют призрачный выигрыш от экономии памяти и дискового пространства.

При автоматизации работы с библиографическими записями ориентация на коммуникативный формат потребовала хранения первичных данных в этом формате – для легкого обмена этими записями между библиотеками. Но ориентация созданной системы на этот формат привела к тому, что даже читатели (контингент) вынуждены быть записанными не в РБД, а все в той же системе поставленной с ног на голову базы данных, которую не назовешь ни базой данных, ни программой. Сведения о читателях, никак не связанные с премудростями библиографической записи, вдруг тоже стали храниться в «машиночитаемом формате каталогизации»! И при чем здесь коммуникативные форматы?

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

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

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

Характерный пример порочности традиционной архитектуры АИБС – многочисленные вариации на тему «Система учета книгообеспеченности», вызванные отсутствием какой-то одной популярной системы.

Традиционный путь, в основе которого лежит РБД, несомненно, не ставит коммуникативный формат во главу угла. Действительно, комплекс РБД, включающий в себя библиографию, книговыдачу, книгообеспеченность и прочее, не будет по своей природе обладать возможностью быстро и легко «делиться» своими данными с другими системами для совместной, корпоративной работы. Однако и система на базе MARC сама по себе не обладает такой возможностью. Для этого, как известно, между системами существует протокол обмена данными: Z39.50. Именно он требует, чтобы данные на обеих сторонах были в формате MARC. Значит, если РБД будет «отдавать» протоколу записи в формате MARC, формально она не будет ничем отличаться от традиционной MARC-ориентированной системы. А чтобы получить из РБД записи в формате MARC, требуется создать программу, которая будет производить «свертку» записей из таблиц РБД в «строку» MARC. Для опытного традиционного программиста такая задача решается за время, измеряемое несколькими часами, потому что не содержит в себе ничего сложного. Дальнейшее же использование полученной программы позволит очень легко получать из РБД данные в коммуникативном формате. А эти данные легко можно «отдать» по протоколу Z39.50. Это объясняется появлением в современных интерпретируемых языках удобного сочетания средств для работы как с системными источниками данных (например ODBC), так и с коммуникационными протоколами (например IP).

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

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

Современные СУБД, такие, как MS Access или MS Visual FoxPro, обладают средствами визуального программирования, благодаря которым не составляет особого труда создать даже самую сложную систему в рамках СУБД, отыскав и исправив в ней все её недочеты. Это всё и есть то, что называется требованием адаптивности. Разработка становится интеллектуальной, а не технической задачей: система на каждом шагу помогает разработчику, поэтому создание АИБС на базе современной СУБД – это уже нечто совсем иное, нежели 30 лет назад.

Использование в качестве ядра системы РБД SQL-сервера на базе, например, MS SQL Server 2000 позволит сотням пользователей одновременно редактировать (не читать, а редактировать!) записи в системе объемом в многие миллионы записей, объединяющей сотни таблиц. Для работы этой системы потребуется компьютер, стоимостью приблизительно 1000 долларов США.

Современные СУБД, прошедшие долгий отбор на основе конкуренции, обладают свойствами, намного превосходящими специальные требования к АИБС. Это и само собой разумеющаяся надежность, безграничность числа хранимых записей, огромное быстродействие, портабельность, адаптивность, расширяемость, интуитивность и схематизированность, работа с самыми разными периферийными устройствами (принтерами, сканерами, фотокамерами и т.п.). Взаимодействие со сторонним программным обеспечением (благодаря технологии ActiveX, OLE, использованию динамических библиотек и т. п.), наличие отлично документированного внутреннего языка программирования с огромным числом библиотек-приложений, огромная техническая поддержка среди коллег – всё это отличает указанные СУБД от тех, что использовались 30 лет назад.

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