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

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

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

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

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

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

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

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

Для иллюстрации на рис. 5.7 приведен пример схемы БД, организованной на основе техники объектного связывания дан­ных распределенной системы коллективной обработки данных трех подразделений некоторой организации—службы ДОУ, отдела кадров и бухгалтерии. На вычислительных установках пе­речисленных подразделений, объединенных в локальную сеть, создаются и эксплуатируются локальные базы данных, структурные схемы которых отражают задачи и особенности предметных областей сведений, необходимых для информационного обеспечения деятельности соответствующих подразделений. При этом часть данных, распределенных по таким таблицам, как «Сотрудники», «Подразделения», «Штатные категории» и др., являются общепотребными для всех или для группы подразделений. Логично исключить дублирование ввода, редактирования, кор­ректировки и хранения таких общих данных, возложив эти функции на пользователей тех локальных баз данных, где это наиболее естественно и обоснованно сточки зрения функциональных особенностей соответствующих подразделений и сложившихся информационных потоков, а пользователям локальных баз данных других подразделений предоставить доступ к ним. Так, к примеру, таблицы данных по сотрудникам и подразделениям наиболее естественно заполнять данными и хранить в локальной базе кадрового подразделения, обеспечивая доступ к ним пользователей локальных баз службы ДОУ и бухгалтерии. Струк­турную схему локальных баз этих подразделений в этом случае целесообразно построить на основе объектного связывания данных. На рис. 5.7 связанные, т. е. физически находящиеся в дру­гих базах данных, таблицы выделены специальной раскраской и обрамлением. Стрелками на рисунке показаны связи типа «Один-ко-многим» (острие стрелки соответствует стороне «многие»).

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

-

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

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

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

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

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

Инсталлируемый драйвер ODBC «регистрируется» в специальном под­каталоге системного каталога операционной системы. Так об­разуется рабочая область прямого доступа к источникам данных ODBC.

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

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

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

В операционной системе Windows данный подкаталог так и называется—ODBC.

Дата добавления: 2014-01-03