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

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

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

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

Решение этой задачи основывается на поддержке современ­ными «настольными» СУБД (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для осуще­ствления процедур доступа к данным помимо пути, имени фай­лов и требуемых объектов (таблиц), если соответствующие базы защищены, содержат в открытом виде пароли доступа, в результате чего может быть проанализирована и раскрыта систе­ма разграничения доступа и защиты данных.