Процесс стандартизации доступа к БД приобрел наибольшую активность в конце 80-х – начале 90-х годов. В 1992 г. возникли сразу два конкурирующих стандарта – ODBC и IDAPI, и оба они основаны на интерфейсе уровня вызовов (Call-Level Interface, CLI). Первый из них – Открытый интерфейс доступа к базам данных (Open DataBase Connectivity, ODBC) был введен и активно продвигался компанией Microsoft. Целью Microsoft было предоставление приложениям Microsoft Windows доступа к базам данных, основанным на SQL, посредством стандартизованного интерфейса (рис. 4.3).
Рис. 4.3. Архитектура ODBC
Несколькими месяцами позже, в ноябре 1992 г., группа компаний под руководством Borland (включающая также IBM, Novell и WordPerfect) объявила аналогичный стандарт интерфейса, получивший название Интерфейса прикладного программирования для интегрированных систем баз данных (Integrated Database Application Programming Interface, IDAPI) (рис. 4.4). Стандарт IDAPI концептуально аналогичен ODBC. Но IDAPI изначально был ориентирован помимо Microsoft Windows и на другие платформы и предоставлял в дополнение к SQL-доступу также навигационный доступ к серверам баз данных.
Теперь к их числу следует добавить корпоративный стандарт JDBC, разработанный Sun Microsystems и основанный на Х/Ореn SQL CLI. Этот стандарт специфицирует Java API для систем баз данных, основанных на языке SQL. Он оформлен в виде специального пакета Java, содержащего соответствующий набор спецификаций классов и интерфейсов. В конце 1997 г. компания Sun Microsystems выпустила новый продукт Java Blend, который является надстройкой над JDBC для решения той же задачи. При этом разработчик освобождается от необходимости знания SQL и все спецификации формулирует средствами Java.
Рис. 4.4. Архитектура IDAPI
Данные технологии позволяют взаимодействовать с БД из приложений, поддерживающих тот или иной интерфейс, например, из офисных приложений Microsoft (Word, Excel и т.д.) через ODBC можно организовать взаимодействие практически с любым источником данных.
При взаимодействии с “настольными” СУБД типа MS Access также можно использовать технологию связывания и внедрения объектов (OLE). Это позволяет организовать взаимодействие с БД малоквалифицированным пользователям, которые обычно и используют СУБД такого класса.
Приложения, поддерживающие протокол OLE 2.1, делятся на следующие шесть категорий:
1. Приложение контейнера (Container application). Самостоятельное приложение, такое как Access 97, в которое можно внедрить или связать с ним объект, созданный любым другим 16-разрядным или 32-разрядным приложением, поддерживающим протокол OLE 2+. Приложения контейнера не могут создавать объекты OLE для внедрения или связывания с другими поддерживающими протокол OLE 2.0 приложениями. Приложения контейнера называют также приложения клиента (client applications).
2. Приложение сервер объекта (Server-only application). Самостоятельное приложение, в котором создан объект OLE, связанный или внедренный в другое приложение. В приложение-сервер нельзя внедрить или связать с ним объект OLE.
3. Приложение мини-сервер (Mini-server application). Мини-серверы (апплеты OLE – OLE applets) аналогичны серверам, за исключением того, что их можно запустить только из приложения-контейнера OLE. Примером может служить мини-сервер OLE 2.1 MSGraphS. Мини-серверы называют также просто компонентами или компонентами ActiveX.
4. Приложение полный сервер (Full-server application). Самостоятельное приложение, способное создавать объект OLE и позволяющее связывать или внедрять данные в другие приложения, В документ такого приложения можно внедрить или связать с ним объект, созданный другими серверами OLE. Например, Excel 97, Word 97 и Project 97 являются полными серверами OLE 2.1.
5. Приложения, поддерживающие автоматизацию OLE (OLE Automation-compliant applications). Автоматизация OLE (OA) позволяет приложениям-контейнерам OLE 2+ управлять внедренным или связанным объектом посредством программных инструкций, посылая их приложению, создавшему объект OLE. В таком случае говорят, что сервер автоматизации OLE создает управляемый объект OLE (programmable object). Access 97 является сервером автоматизации OLE, но не обычным, потому что объект Access 97 нельзя внедрить в 32-битовое приложение-контейнер. Это же относится и к Microsoft Outlook. Excel 97 и Project 97 представляют собой одновременно и контейнеры и серверы, поддерживающие автоматизацию OLE. Приложения-клиенты автоматизации OLE, такие как Access 97, используя свой язык программирования, посылают инструкции управляемым объектам.
6. Элементы управления ActiveX (ActiveX Controls). Одним из достоинств Visual Basic как программной среды Windows являлась возможность расширять его за счет специальных элементов управления, называемых VBXs (Visual Basic extensions). Microsoft и независимые поставщики программной продукции поставляют множество своих специальных элементов управления для Visual Basic 3.0, и более ранних версий, в том числе электронные таблицы, графические редакторы и генераторы отчетов. В 1995 году фирма Microsoft создала замену VBX, называемым элементы управления OLE. Первым продуктом, который использовал 16-разрядные элементы управления OLE, был Access 2.0. В 16-разрядной версии Visual Basic 4.0 используются и 16-разрядные элементы управления OLE, и VBX. Но уже Access 95 и 32-разрядная версия Visual Basic 4.0 использует только элементы управления OLE.
OLE 2.+ и ActiveX вводят новую методологию программирования, называемую автоматизацией, достоинство которой заключается в возможности изменять значения свойств объекта и применять его методы, пользуясь стандартным синтаксисом Access VBA. Автоматизация является основой построения элементов управления ActiveX и других объектов серверов OLE.
Однако в наиболее общих случаях для организации взаимодействия с БД можно использовать компоненты доступа к данным (Data Access Object - DAO) среды Visual Basic (это справедливо и для VBA – средства создания макросов в продуктах компании Microsoft). Эти компоненты позволяют использовать ODBC для доступа к данным, предоставляя пользователю высокоуровневую надстройку над этим интерфейсом.
