Гайдамакин Н. А. 13 страница* На практике другой локальной базой может быть и база данных сервера централизованной многопользовательской корпоративной системы.
Решение этой задачи основывается на поддержке современными «настольными» СУБД (MS Access, MS FoxPro, dBase и др.) технологии «объектов доступа к данным» — DAO. При этом следует отметить, что под объектом понимается интеграция данных и методов их обработки в одно целое (объект), на чем, как известно, основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживающие DAO, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически находящимся в других файлах, возможно на других вычислительных установках и под управлением других СУБД. Технически технология DAO основана на уже упоминавшемся протоколе ODBC, который принят за стандарт доступа не только к данным на SQL-серверах клиент-серверных систем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД. Непосредственно для доступа к данным на основе протокола ODBC используются инициализируемые на тех установках, где находятся данные, специальные программные компоненты, называемые драйверами ODBC, или инициализируемые ядра тех СУБД, под управлением которых были созданы и эксплуатируются внешние базы данных. Схематично принцип и особенности доступа к внешним базам данных на основе объектного связывания иллюстрируются на рис. 5.6.
Рис. 5.6. Принцип доступа к внешним данным на основе протокола ODBC Прежде всего, современные настольные СУБД обеспечивают возможность прямого доступа к объектам (таблицам, запросам, формам) внешних баз данных «своих» форматов. Иначе говоря, в открытую в текущем сеансе работы базу данных пользователь имеет возможность вставить специальные ссылки-объекты и оперировать с данными из другой (внешней, т. е. не открываемой специально в данном сеансе) базы данных. Объекты из внешней базы данных, вставленные в текущую базу данных, называются связанными, и, как правило, имеют специальные обозначения для отличия от внутренних объектов. При этом следует подчеркнуть, что сами данные физически в файл (файлы) текущей базы данных не помещаются, а остаются в файлах «своих» баз дачных. В системный каталог текущей базы данных помещаются все необходимые для доступа сведения о связанных объектах — внутреннее имя и внешнее, т. е. истинное имя объекта во внешней базе данных, полный путь к файлу внешней базы и т. п. Связанные объекты для пользователя ничем не отличаются от внутренних объектов. Пользователь может также открывать связанные во внешних базах таблицы данных, осуществлять поиск, изменение, удаление и добавление данных, строить запросы по таким таблицам и т. д. Связанные объекты можно интегрировать в схему внутренней базы данных, т. е. устанавливать связи между внутренними и связанными таблицами. Технически оперирование связанными объектами из внешних баз данных «своего» формата мало отличается от оперирования сданными из текущей базы данных. Ядро СУБД при обращении к данным связанного объекта по системному каталогу текущей базы данных находит сведения о месте нахождения и других параметрах соответствующего файла (файлов) внешней базы данных и прозрачно, т. е. невидимо для пользователя открывает этот файл (файлы), а далее обычным порядком организует в оперативной памяти буферизацию страниц внешнего файла данных для непосредственно доступа и манипулирования данными. Следует также заметить, что на основе возможностей многопользовательского режима работы с файлами данных современных операционных систем, с файлом внешней базы данных, если он находится на другой вычислительной установке, может в тот же момент времени работать и другой пользователь, что и обеспечивает коллективную обработку общих распределенных данных. Для иллюстрации на рис. 5.7 приведен пример схемы БД, организованной на основе техники объектного связывания данных распределенной системы коллективной обработки данных трех подразделений некоторой организации — службы ДОУ, отдела кадров и бухгалтерии.* На вычислительных установках перечисленных подразделений, объединенных в локальную сеть, создаются и эксплуатируются локальные базы данных, структурные схемы которых отражают задачи и особенности предметных областей сведений, необходимых для информационного обеспечения деятельности соответствующих подразделений. При этом часть данных, распределенных по таким таблицам, как «Сотрудники», «Подразделения», «Штатные категории» и др., являются общепотребными для всех или для группы подразделений. Логично исключить дублирование ввода, редактирования, корректировки и хранения таких общих данных, возложив эти функции на пользователей тех локальных баз данных, где это наиболее естественно и обоснованно сточки зрения функциональных особенностей соответствующих подразделений и сложившихся информационных потоков, а пользователям локальных баз данных других подразделений предоставить доступ к ним. Так, к примеру, таблицы данных по сотрудникам и подразделениям наиболее естественно заполнять данными и хранить в локальной базе кадрового подразделения, обеспечивая доступ к ним пользователей локальных баз службы ДОУ и бухгалтерии. Структурную схему локальных баз этих подразделений в этом случае целесообразно построить на основе объектного связывания данных. На рис. 5.7 связанные, т. е. физически находящиеся в других базах данных, таблицы выделены специальной раскраской и обрамлением. Стрелками на рисунке показаны связи типа «Один-ко-многим» (острие стрелки соответствует стороне «многие»). * Данный пример является чисто иллюстративным и никаким образом не может претендовать на отражение каких-либо реальных баз данных.
Рис. 5.7. Пример схем локальных баз данных со связанными объектами На рис. 5.8 приведен еще один пример схемы локальных баз данных, использующих совместные данные по линии информационного обеспечения производства и сбыта продукции. Предметные области сведений по этим трем локальным базам данных очень близки и переплетены, однако, как и в предыдущем примере, с учетом специфики подразделений, ведение и размещение таких общепотребных таблиц как «Продукция», «Типы, номенклатура» целесообразно осуществлять в локальной базе Планово-производственного отдела, таблиц «Комплектующие», «Сырье», «Поставщики» в локальной базе Отдела снабжения, а таблиц «Заказы» и «Клиенты» в локальной базе Отдела сбыта. Опять-таки данные по таблице «Сотрудники» могут быть получены на основе объектного связывания из локальной базы Отдела кадров.
Рис. 5.8. Пример схем локальных баз данных со связанными объектами Нетрудно заключить, что подобный принцип построения распределенных систем при больших объемах данных в связанных таблицах приведетк существенному увеличению трафика сети, так как по сети постоянно передаются, даже не наборы данных, а страницы файлов баз данных, что может приводить к пиковым перегрузкам сети. Поэтому представленные схемы локальных баз данных со взаимными связанными объектами нуждаются в дальнейшей тщательной проработке с точки зрения интенсивности, направленности потоков данных в сети между локальными базами исходя из информационных технологий, обусловленных производственно-технологическими и организационными процессами. Не менее существенной проблемой является отсутствие надежных механизмов безопасности данных и обеспечения ограничений целостности. Так же как и в модели файлового сервера, совместная работа нескольких пользователей с одними и теми же данными обеспечивается только функциями операционной системы по одновременному доступу к файлу нескольких приложений. Аналогичным образом обеспечивается доступ к данным, находящимся в базах дачных наиболее распространенных форматов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE, а так же к табличным данным электрон При этом доступ может обеспечиваться как непосредственно ядром СУБД, так и специальными дополнительными драйверами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД. Такой подход реализует интероперабельность построенных подобным образом распределенных гетерогенных систем, т.е. «разномастность» типов СУБД, поддерживающих локальные базы данных. При этом, однако, объектное связывание ограничивается только непосредственно таблицами данных, исключая другие объекты базы данных (запросы, формы, отчеты), реализация и поддержка которых зависят от специфики конкретной СУБД. Доступ к базам данных других СУБД (см. рис. 5.6) реализуется через технику драйверов ODBC, которые инсталлируются и выполняются на тех вычислительных установках, где находятся удаленные данные. «Идеология» в данном случае такова. В составе настольной СУБД, поддерживающей локальную базу данных, можно инсталлировать дополнительный программный компонент, называемый драйвером ODBC.* Инсталлируемый драйвер ODBC «регистрируется» в специальном подкаталоге системного каталога операционной системы.** Так образуется рабочая область прямого доступа к источникам данных ODBC.
* В операционной системе Windows драйверы ODBC реализуются посредством файлов DDL (библиотеки динамической компоновки). ** В операционной системе Windows данный подкаталог так и называется — ODBC.
Для непосредственного доступа к источникам данных ODBC ядро СУБД по системному каталогу внутренней локальной базы данных определяет местонахождение источника, по протоколу взаимодействия приложений (API) осуществляет вызов (запуск) на вычислительной установке удаленных данных драйвера ODBC и направляет ему по протоколу ODBC SQL-ичструкщт на доступ и обработку данных. При этом режим такого доступа регулируется рядом параметров (интервал вызова процедур, максимальное время обработки запроса, количество однократно пересылаемых по сети записей из набора данных, формируемых по запросам, время блокировок записей и т. д.). Данные параметры записываются в специальный реестр операционной системы при инсталляции и регистрации соответствующего драйвера ODBC. При таком подходе каждая локальная СУБД на своей вычислительной установке выполняет роль SQL-сервера, т. е. машины данных, в случае обращения на доступ извне (из других вычислительных установок) к данным из «ее» файлов данных. Так как непосредственную обработку данных в данном случае выполняет «родная» СУБД, знающая все особенности логической и физической структуры «своих» файлов данных, то обеспечивается, как правило, более эффективная обработка, а самое главное, проверяются и выполняются ограничения целостности данных по логике предметной области источников данных. Определенной проблемой технологий объектного связывания является появление «брешей» в системах защиты данных и разграничения доступа. Вызовы драйверов ODBC для осуществления процедур доступа к данным помимо пути, имени файлов и требуемых объектов (таблиц), если соответствующие базы защищены, содержат в открытом виде пароли доступа, в результате чего может быть проанализирована и раскрыта система разграничения доступа и защиты данных. 5.4. Технологии реплицирования данных Во многих случаях узким местом распределенных систем, построенных на основе технологий «Клиент-сервер» или объектного связывания данных, является недостаточно высокая производительность из-за необходимости передачи по сети большого количества данных. Определенную альтернативу построения быстродействующих распределенных систем предоставляют технологии реплицирования данных. Репликой называют особую копию базы данных для размещения на другом компьютере сети с целью автономной работы пользователей с одинаковыми (согласованными) данными общего пользования. Основная идея реплицирования заключается в том, что пользователи работают автономно с одинаковыми (общими) данными, растиражированными по локальным базам данных, обеспечивая с учетом отсутствия необходимости передачи и обмена данными по сети максимальную для своих вычислительных установок производительность. Программное обеспечение СУБД для реализации такого подхода соответственно дополняется функциями тиражирования (реплицирования) баз данных, включая тиражирование как самих данных и их структуры, так и системного каталога с информацией о размещении реплик, иначе говоря, с информацией о конфигурировании построенной таким образом распределенной системы. При этом, однако, возникают две проблемы обеспечения одного из основополагающих принципов построения и функционирования распределенных систем, а именно — непрерывности согласованного состояния данных: • обеспечение согласованного состояния во всех репликах количества и значений общих данных; • обеспечение согласованного состояния во всех репликах структуры данных. Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов: • принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено); • принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации). Принцип непрерывного размножения обновлений является основополагающим при построении так называемых «систем реального времени», таких, например, как системы управления воздушным движением, системы бронирования билетов пассажирского транспорта и т. п., где требуется непрерывное и точное соответствие реплик или других растиражированных данных во всех узлах и компонентах подобных распределенных систем. Реализация принципа непрерывного размножения обновлений заключается в том, что любая транзакция считается успешно завершенной, если она успешно завершена на всех репликах системы. На практике реализация этого принципа встречает существенные затруднения, связанные с тупиками, как и в технологиях синхронизационных захватов систем «Клиент-сервер». Предположим, что на одной вычислительной установке пользователь обновляет данные в своей реплике. На время осуществления транзакции (транзакций) соответствующие записи в базе данных этой реплики ядром локальной СУБД заблокированы от изменения другими пользователями. Вместе с тем транзакция может быть зафиксирована и, следовательно, разблокированы соответствующие данные только тогда, когда данная транзакция послана и также завершена на других репликах системы. Предположим также, что в другой реплике системы, находящейся на другом компьютере сети, в это же время другой пользователь проводит свои обновления (транзакции) с теми же записями, которые, естественно, в этот момент также заблокированы от изменений для других пользователей. Так образуется тупик. Одна транзакция не может быть зафиксирована в своей реплике, потому что заблокированы соответствующие записи в другой реплике. А разблокировка этих записей в другой реплике также невозможна до тех пор, пока не разблокируются соответствующие записи в первой реплике, т. е. когда завершится транзакция в первой реплике. Создается тупиковая ситуация. Для обнаружения (распознавания) тупиков в реплицированных системах применяются такие же алгоритмы, которые были разработаны в мониторах транзакций централизованных систем «Клиент-сервер», — строится и поддерживается аналогичный граф ожидания транзакций и применяются аналогичные алгоритмы распознавания и разрушения тупиков, основанные в основном на технике приоритетов. В целом ряде предметных областей распределенных информационных систем режим реального времени с точки зрения непрерывности согласования данных не требуется. Такие системы автоматизируют те организационно-технологические структуры, в которых информационные процессы не столь динамичны. Если взять, к примеру, автоматизированную информационную систему документооборота, то традиционная «скорость» перемещения и движения служебных документов соответствует рабочему дню или в лучшем случае рабочим часам. В этом случае обновление реплик распределенной информационной системы, если она будет построена на технологии реплицирования, требуется, скажем, только лишь один раз за каждый рабочий час, или за каждый рабочий день. Такого рода информационные системы можно строить на основе принципа отложенных обновлений. Накопленные в какой-либо реплике изменения данных специальной командой пользователя направляются для обновления всех остальных реплик систем. Такая операция называется синхронизацией реплик. Возможность конфликтов и тупиков в этом случае при синхронизации реплик существенно снижается, а немногочисленные подобные конфликтные ситуации легко разрешить организационными мерами. Решение второй проблемы согласованности данных, а именно — согласованности структуры данных, осуществляется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики. Суть этой техники заключается в том, что одна из реплик базы данных системы объявляется главной. При этом изменять структуру базы данных можно только в главной реплике. Эти изменения структуры данных тиражируются на основе принципа отложенных обновлений, т. е. через специальную синхронизацию реплик. Частичность отступления от принципа отсутствия центральной установки заключается в том, что в отличие от чисто централизованных систем, выход из строя главной реплики не влечет сразу гибель всей распределенной системы, так как остальные реплики продолжают функционировать автономно. Более того, на практике СУБД, поддерживающие технологию реплицирования, позволяют пользователю с определенными полномочиями (администратору системы) преобразовать любую реплику в главную и тем самым полностью восстановить работоспособность всей системы. Процесс синхронизации реплик в современных СУБД включает обмен только теми данными, которые были изменены или добавлены в разных репликах. С этой целью в системном каталоге базы данных создаются специальные таблицы текущих изменений и организуется система глобальной идентификации (именования) всех объектов распределенной системы, включая раздельное поименование одинаковых объектов (вплоть до записей таблиц) в разных репликах.* Такой подход несколько увеличивает объем базы данных, но позволяет существенно ограничить транспортные расходы на синхронизацию реплик. * Так называемая техника глобальных уникальных идентификаторов (GUID).
Важным, с точки зрения гибкости и эффективности функционирования распределенных информационных систем, построенных на технологиях реплицирования, является возможность создания так называемых частичных реплик и включения в реплики как реплицнруемых, так и нереплицируемых объектов. Частичной репликой называется база данных, содержащая ограниченное подмножество записей полной реплики. Распространенным способом создания частичных реплик является использование фильтров, устанавливаемых для конкретных таблиц полной (главной) реплики. Частичные реплики позволяют решить некоторые проблемы, связанные с разграничением доступа к данным и повышают производительность обработки данных. Так, к примеру, в реплику базы данных для определенного подразделения целесообразно реплицировать только те записи таблицы «Сотрудники», которые относятся к данному подразделению, исключив тем самым доступ к другим записям. Техника частичных реплик также снижает затраты на синхронизацию реплик, так как ограничивает количество передаваемых по сети изменений данных. Возможность включения в реплики объектов базы данных, которые не подлежат репликации, позволяет более гибко и адекватно настроить схему и прочие объекты БД (запросы, формы и отчеты) на специфику предметной области, особенности ввода данных и решаемые информационные задачи по конкретному элементу распределенной системы. На рис. 5.9 иллюстрируется подход к организации общей схемы распределенной информационной системы по делопроизводству некоторой организационной структуры на основе технологий репликации данных.
Рис. 5.9. Пример подхода к организации схемы распределенной информационной системы по делопроизводству на основе техники реплицирования Технологии репликации данных в тех случаях, когда не требуется обеспечивать большие потоки и интенсивность обновляемых в информационной сети данных, являются экономичным решением проблемы создания распределенных информационных систем с элементами централизации по сравнению с использованием дорогостоящих* «тяжелых» клиент-серверных систем. * Хотя, конечно же, более надежных и функциональных.
На практике для совместной коллективной обработки данных применяются смешанные технологии, включающие элементы объектного связывания данных, репликации и клиент-серверных решений. При этом дополнительно к проблеме логического проектирования, т. е. проектирования логической схемы организации данных (таблицы, поля, ключи, связи, ограничения целостности), добавляется не менее сложная проблема транспортно-технологического проектирования информационных потоков, разграничения доступа и т.д. К сожалению, пока не проработаны теоретико-методологические и инструментальные подходы для автоматизации проектирования распределенных информационных систем с учетом факторов как логики, так и информационно-технологической инфраструктуры предметной области. Тем не менее развитие и все более широкое распространение распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автоматизированных информационных систем. Вопросы и упражнения 1. Что «распределено» в распределенных информационных системах и каковы основные принципы создания и функционирования распределенных информационных систем? 2. Поясните суть техники «представлений» в базах данных и задачи, которые решаются на основе техники «представлений». 3. Какой из основных принципов распределенных информационных систем принесен в «жертву» в системах «Клиент-сервер»? Поясните преимущества и недостатки такого подхода. 4. На какие компоненты подразделяется программное обеспечение систем «Клиент-сервер»? Какие функции выполняются каждым компонентом? 5. Поясните принципы и схемы RDA, DBS и AS-моделей систем «Клиент-сервер» и дайте их сравнительную характеристику. Какие системы называются системами с «тонкими» («толстыми») клиентами, с 2- или 3-уровневой (2- или 3-звенной) архитектурой? 6. Охарактеризуйте роль и место монитора транзакций в СУБД cиcтем «Клиент-сервер». 7. Какие издержки совместной обработки общих данных предотвращает монитор транзакций в системах «Клиент-сервер»? 8. Дайте определение сериальному плану выполнения транзакций и охарактеризуйте основные подходы к механизмам построения таких планов. 9. Поясните суть двухфазного протокола синхронизационных захватов объектов и механизм возможного образования тупиковых ситуаций. 10. Как распознаются и разрушаются тупиковые ситуации в технике двухфазного протокола синхронизационных захватов? 11. В чем заключается гранулирование объектов захватов и почему такой подход обеспечивает более эффективные стратегии построения сериальных планов выполнения транзакций? 12. Каковы достоинства и недостатки техники временных меток при синхронизационных захватах объектов? 13. В чем заключается суть и механизм объектного связывания данных при построении распределенных информационных систем из разрозненных локальных баз данных? 14. Существует ли системный каталог распределенной базы данных, построенной на основе технологии объектного связывания, и каким образом выражается логическая схема такой базы данных? В чем достоинства и недостатки такого подхода? 15. Какие (функции, кроме традиционных, выполняют локальные («настольные») СУБД при использовании технологий объектного связывания? 16. Охарактеризуйте главную идею и основные подходы к построению распределенных информационных систем в технологиях реплицирования данных. 17. Поясните принцип отложенных обновлений и процессов синхронизации реплик. 18. Чем главная реплика отличается от остальных? Как наличие главной реплики соотносится с принципами распределенных систем? 19. Что обеспечивается возможностью создания частичных реплик? 6. Документальные информационные системы В развитии программного обеспечения СУБД в 70-е—80-е годы превалировало направление, связанное с фактографическими информационными системами, т. е. с системами, ориентированными на работу со структурированными данными. Были разработаны основы и модели организации фактографических данных, отработаны программно-технические решения по накоплению и физическому хранению таких данных, реализованы специальные языки запросов к базам данных и решен целый ряд других задач по эффективному управлению большими объемами структурированной информации. В результате основу информационного обеспечения деятельности предприятий и организаций к началу 90-х годов составили фактографические информационные системы, вобравшие в себя в совокупности колоссальный объем структурированных данных.* * В этом смысле очень характерным является рекламный девиз корпорации Oracle: «Мы храним триллионы бийт».
Вместе с тем создание и эксплуатация фактографических информационных систем требует либо изначально структурированных данных, таких, например, как отчеты датчиков в АСУ ТП, финансовые массивы бухгалтерских АИС и т. д., либо предварительной структуризации данных, как, например, в информационной системе кадрового подразделения, где все данные по сотрудникам структуризируются по ряду формализованных позиций. При этом зачастую структуризация данных требует больших накладных, в том числе и организационных расходов, что, в конечном счете, приводит к материальным издержкам информатизации. Кроме того, входные информационные потоки в целом ряде организационно-технологических и управленческих сфер представлены неструктурированными данными в виде служебных документов и иных текстовых источников. Извлечение из текстов данных по формализованным позициям для ввода в фактографические системы может приводить к ошибкам и потере части информации, которая в исходных источниках имеется, но в силу отсутствия в схеме базы данных адекватных элементов не может быть отражена в банке данных фактографических АИС. В результате, несмотря на интенсивное развитие и распространение фактографических информационных систем, огромная часть неструктурированных данных, необходимых для информационного обеспечения деятельности различных предприятий и организаций, остается в неавтоматизированном или слабо автоматизированном* виде. К таким данным относятся огромные массивы различной периодики, нормативно-правовая база, массивы служебных документов делопроизводства и документооборота. * Представлена в электронном виде в текстовых файлах, но без средств систематизации, обработки, анализа и эффективного поиска 6.1. Общая характеристика и виды документальных информационных систем.
Потребности в системах, ориентированных на накопление и эффективную обработку неструктурированной или слабоструктурированной информации привели к возникновению еще в 70-х годах отдельной ветви программного обеспечения систем управления базами данных, на основе которых создаются документальные информационные системы. Однако теоретические исследования вопросов автоматизированного информационного поиска документов, начавшись еще в 50-х—60-х годах, к сожалению, не получили такой строгой, полной и в то же время технически реализуемой модели представления и обработки данных, как реляционная модель в фактографических системах. Не получили также стандартизации (как язык SQL) и многочисленные попытки создания универсальных так называемых информационно-поисковых языков, предназначенных для формализованного описания смыслового содержания документов и запросов по ним. В итоге, несмотря на то, что первые системы автоматизированного информационного поиска документов появились еще в 60-х годах, развитые коммерческие информационно-поисковые системы, ориентированные на накопление и обработку текстовых документов, получили распространение лишь в конце 80-х — начале 90-х годов.
|
