Технологии объектного связывания данных

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

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

Решение этой задачи основывается на поддержке современ­ными “настольными” СУБД (MS Access, MS FoxPro, dBase и др.) технологии “объектов доступа к данным” – DAO. При этом следует отметить, что под объектом понимается интегра­ция данных и методов их обработки в одно целое (объект), на чем, как известно, основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживаю­щие DAO, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически на­ходящимся в других файлах, возможно на других вычислитель­ных установках и под управлением других СУБД.

Технически технология DAO основана на уже упоминав­шемся протоколе ODBC, который принят за стандарт досту­па не только к данным на SQL-серверах клиент-серверных сис­тем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД. Непосредственно для дос­тупа к данным на основе протокола ODBC используются ини­циализируемые на тех установках, где находятся данные, спе­циальные программные компоненты, называемые драйверами ODBC, или инициализируемые ядра тех СУБД, под управлени­ем которых были созданы и эксплуатируются внешние базы данных. Схематично принцип и особенности доступа к вне­шним базам данных на основе объектного связывания иллюст­рируются на рис. 2 7.

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

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

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

Для иллюстрации на рис. 2.8 приведен пример схемы БД, организованной на основе техники объектного связывания дан­ных распределенной системы коллективной обработки данных трех подразделений некоторой организации – Планово-производственного отдела, Отдела снабжения и Отдела сбыта, – использующих совместные данные по линии ин­формационного обеспечения производства и сбыта продукции. На вычислительных установках указанных подразделений, объединенных в локальную сеть, создаются и эксплуатируются локальные базы данных, струк­турные схемы которых отражают задачи и особенности предмет­ных областей сведений, необходимых для информационного обеспечения деятельности соответствующих подразделений. Логично исключить дублирование ввода, редактирования, кор­ректировки и хранения общих данных, возложив эти фун­кции на пользователей тех локальных баз данных, где это наибо­лее естественно и обоснованно с точки зрения функциональных особенностей соответствующих подразделений и сложившихся информационных потоков, а пользователям локальных баз дан­ных других подразделений предоставить доступ к ним. Предметные области сведений по этим трем локальным базам данных очень близки и переплетены, однако, с учетом специфики подразделений, ведение и размещение таких общепотребных таблиц как “Продукция”, “Типы, номенклатура” целесообразно осуществлять в локальной базе Планово-производственного отдела, таблиц “Комплектующие”, “Сырье”, “Поставщики” в локальной базе Отде­ла снабжения, а таблиц “Заказы” и “Клиенты” в локальной базе Отдела сбыта. Струк­турную схему локальных баз этих подразделений в этом случае целесообразно построить на основе объектного связывания дан­ных. Стрелками на рисунке показаны связи типа “Один-ко-многим” (острие стрелки соответствует стороне “многие”).

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

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

Аналогичным образом обеспечивается доступ к данным, находящимся в базах данных наиболее распространенных фор­матов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE.

При этом доступ может обеспечиваться как непосредствен­но ядром СУБД, так и специальными дополнительными драй­верами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД. Такой подход реализу­ет интероперабельность построенных подобным образом рас­пределенных гетерогенных систем, т. е. “разномастность” ти­пов СУБД, поддерживающих локальные базы данных. При этом, однако, объектное связывание ограничивается только непосред­ственно таблицами данных, исключая другие объекты базы данных (запросы, формы, отчеты), реализация и поддержка которых зависят от специфики конкретной СУБД.

Доступ к базам данных других СУБД реали­зуется через технику драйверов ODBC, которые инсталлиру­ются и выполняются на тех вычислительных установках, где находятся удаленные данные. Идеология в данном случае такова. В составе настольной СУБД, поддерживающей локаль­ную базу данных, можно инсталлировать дополнительный про­граммный компонент, называемый драйвером ODBC. Инсталлируемый драйвер ODBC “регистрируется” в специальном под­каталоге системного каталога операционной системы (например, в операционной системе Windows данный подкаталог так и называется – ODBC). Так об­разуется рабочая область прямого доступа к источникам данных ODBC.

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

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

Определенной проблемой технологий объектного связыва­ния является появление “брешей” в системах защиты данных и разграничения доступа. Вызовы драйверов ODBC для осуще­ствления процедур доступа к данным помимо пути, имени фай­лов и требуемых объектов (таблиц), если соответствующие базы защищены, содержат в открытом виде пароли доступа, в результате чего может быть проанализирована и раскрыта систе­ма разграничения доступа и защиты данных.

Наши рекомендации