Лекции для студентов

Теория СУБД

ИСТОРИЯ РАЗВИТИЯ ИНТЕРФЕЙСОВ ДОСТУПА К БАЗАМ ДАННЫХ

Базы данных существу­ют не в вакууме, а в ок­ружении множества технологий. Люди об­щаются с БД через терминалы с помощью унифициро­ванного языка, программы использу­ют унифицированные технологии дос­тупа. Все эти стандарты возникли не на пустом месте: они являются частью той истории, которую я сейчас расскажу.

АВТОМАТИЗАЦИЯ ПРОИЗВОДСТВА. ODBC

Сорок лет назад нормальное ис­пользование базы данных в подавля­ющем большинстве случаев можно было представить примерно так: опе­ратор сидит за терминалом СУБД и вручную делает выборки. В скором времени автоматизация производства проникла и сюда: с началом внедре­ния автономных программных комп­лексов базы данных услуги человека-работника стали ненужными. На тот момент стандарты описывали лишь логику построения РБД и язык SQL, призванный стать унифицированным интерфейсом между человеком и СУРБД, но не между программой и СУРБД. Как и всегда в подобных ситу­ациях, в мире воцарился хаос: каж­дый производитель пытался протолк­нуть свой программный интерфейс доступа и навязать его потребителю. Устав от этого бардака, наиболее со­знательные производители объеди­нились в группу SAG (SQL Access Group), которая занялась разработкой унифицированного CLI (Call Level Interface, а проще — "библиотека функций"), позволяющего приложе­ниям работать с базами данных. Раз­работка оказалась удачной и была стандартизирована ISO и EIC. Стан­дарт ISO/EIC DBC CLI не слишком удо­бен и гибок по современным нормам, перегружен низкоуровневыми рутин­ными операциями, но он впервые поз­волил программистам писать системы, взаимодействующие с РБД, и малой кровью переносить их между базами различных производителей.

В 1992 году небезызвестная компа­ния Microsoft с небольшим опоздани­ем обратила внимание на популяр­ность и востребованность технологий, связанных с реляционными базами данных. Завоевать этот сегмент рынка засильем своих технологий к тому времени уже не представлялось воз­можным, поэтому новый продукт ком­пании основывался на ISO/EIC CLI и получил название ODBC — Open Database Connectivity. Проект ODBC отличался от своего предка расши­ренным набором функций и разделе­нием на два компонента: ODBC-драй-веры, предоставляющие непосред­ственный доступ к БД, и ODBC-диспет-чер (менеджер) который с одной сто­роны управляет драйверами, а с дру­гой взаимодействует с прикладным ПО. Такой подход позволяет ODBC-приложениям полностью абстрагиро­ваться от специфики конкретной РДБ, легко переключаясь между ними даже в процессе работы.

КОФЕ. СОЛНЦЕ. БАЗЫ ДАННЫХ

Java-технологии компании Sun Microsystems тоже не оставили в сто­роне доступ к РБД. Разработка компа­ний JavaSoft и InterSolv была призва­на удовлетворить потребность в DataBase Connectivity применительно к java-приложениям. Как и следовало , этот проект во многом опирался на опыт создания ODBC и получил похожее название — JDBC (Java DataBase Connectivity). Первые реализации JDBC по сути представля­ли собой java-обертку вокруг ODBC-библиотек. Я не хочу сказать, что это решение убого или не достойно вни­мания: подобная технология активно применяется в наши дни и ее принято называть "мост JDBC-ODBC". Однако позже появились системы, в которых java-технологии занимали чуть ли не ведущую архитектурную позицию, и вместе с ними появились и "чистые" реализации JDBC, которые представ­ляли собой java-классы, способные самостоятельно общаться с СУРБД, то есть без помощи дополнительных ODBC-драйверов. И пусть это реше­ние проигрывало по производитель­ности JDBC-ODBC-мостам, но оно бы­ло незаменимо в системах, имеющих на борту JVM (Java Virtual Machine), но не располагающих родными ODBC-драйверами.

DAO И RDO

Для БД Microsoft Access был раз­работан специализированный БД-процессор Microsoft JET. Он предос­тавлял пользовательским приложениям интерфейс, отличающийся от ODBC ярко выраженной объектно-компонентной моделью, что позволи­ло выполнить полноценную интер­фейсную привязку не только к низко­уровневым языкам вроде C/C++, но и к менее гибким наподобие Visual Basic. Технология получила имя DAO -Data Access Object. Из-за тенденции унификации интерфейс DAO был рас­ширен на многие БД помимо MS Access. Однако однозначная заточен-ность под JET вынуждала транслиро­вать JET-команды в ODBC-инструкции (при доступе к не-Access БД), что сни­жало производительность. Пришлось разработать первичный binding ODBC в DAO-интерфейс, получивший назва­ние RDO (Remote Data Objects). Те­перь при доступе к БД через ODBC больше не требуется производить за­медляющую JET-ODBC-трансляцию. DAO-доступ через RDO принято назы­вать DAO-ODBCDirect.

OLEDB

Понятно, что технология Object Linking and Embedding (OLE), которую агитаторы Microsoft когда-то активно продвигали в массы, не могла не по­влиять на интерфейсы DBC. OLE DB предлагает концепцию, несколько от­личающуюся от описанных выше ме­тодов. Здесь содержимое БД предс­тавлено в виде данных документа и публичного интерфейса приложения, способного обработать этот документ (собственно, это и есть стандартная для OLE модель). С одной стороны, это мало похоже на привычные моде­ли с запросами данных и возвратами результатов, а с другой — позволяет осуществлять привязки OLE DB к не-SQL (и даже к не-реляционным) базам данных. СУБД должна предоставить свой публичный OLE-интерфейс для работы с данными, и тогда можно бу­дет использовать через OLE-DB. Есть и другой (весьма популярный для SQL РБД) метод — OLE DB-надстройка над механизмами ODBC.

ADO

Серверы интерфейсной автомати­зации тоже оставили свой след на многострадальном теле DBC. В эпоху расцвета CORBA, DCOP и прочего Microsoft продвигала свое видение операционно-объектного интерфейса по имени COM (Common Object Methods). Детище концепций COM/DCOM получило имя ADO -ActiveX Data Objects. ADO не оснащено средствами для работы с различными БД напрямую. Вместо этого использу­ются объектные платформы DAO/RDO и OLE DB, обретающие COM-привязки в лице ADO-интерфейса.

ADO+ AKAADO.NET

Конечно же, не обошлось без пришествия .NET в стан DBC. На са­мом деле (по крайней мере, если ве­рить заявлениям Microsoft) ADO.NET и ADO имеют лишь одинаковые назва­ния и их программные интерфейсы слегка похожи. ADO.NET базируется на полностью переработанном движ­ке, имеющем существенные отличия в плане возможностей. Во-первых, это, ясное дело, интеграция с .NET Framework. Во-вторых — тесная интег­рация с XML. Этим, похоже, сейчас бо­леют все и впихивают этот самый злосчастный XML куда надо и не на­до. И третьей отличительной чертой ADO.NET от ADO является поддержка модели доступа к несвязанным дан­ным. На практике это означает, что приложение может отсоединяться и присоединяться к БД практически в произвольном порядке, что больше похоже на транзакции в WWW-сессии, чем на старый стиль запроса и полу­чения данных в рамках одного неде­лимого соединения.

НЕ MICROSOFT'ОМ ЕДИНЫМ. BDE

В 1990 году компания dBase (а вместе с ней и БД dBase, и Paradox) перешли в собственность Borland. В то время даже БД, заявленные как работающие с одинаковыми формата­ми, были несовместимы друг с другом из-за уймы мелких различий. Таким образом, у Borland в наличии оказа­лись две несовместимых БД, на раз­витие и поддержку которых требова­лись удвоенные усилия. Выходом из создавшейся ситуации была разра­ботка модели ODAPI 1.0 — Open Database Application Programming Interface, позволявшей единообразно обращаться к БД dBase и Paradox посредством механизма QBE (Query By Example). Вскоре были разработа­ны дополнения, подрастившие ODAPI до версии 1.1 и позволившие общать­ся в том же стиле с Interbase, Oracle, Sybase и MS SQL. В версии 2.0 ODAPI превратилась в IDAPI (перестала быть "открытой" и стала "интегрирован­ной"), проект заметили, им заинтере­совались крупные корпорации вроде IBM, Novell и Wordperfect. Появилось локальное SQL-ядро, позволяющее работать с локальными файлами БД без самой СУБД, и IDAPtor — мост меж­ду IDAPI и ODBC. Дожив до версии 3.0, IDAPI стала 32-разрядной и сме­нила имя на BDE (Borland DataBase Engine). С тех пор BDE так и не изме­нила логической структуры, а только обросла новыми драйверами и моста­ми взаимодействия с современными DBC-технологиями.

зитивные моменты предшественника, исправить недостатки и привнести но­вые достоинства. Одним из ключевых моментов можно считать интерес Borland к UNIX-платформам и абсо­лютную платформенно-архитектур-ную непереносимость BDE (в Kylix нет BDE). Также dbExpress имеет легкую модульную архитектуру, открытую к дополнениям (основа весит 500 Kб против почти десятимегабайтного мо­нолита BDE). Конфигурация вынесена из реестра в удобочитаемые тексто­вые файлы, а большинство основных интерфейсных объектов обзавелось немалым количеством механизмов тонкой настройки.

ODBC НА ПРАКТИКЕ

Голая теория и употребление за­умных аббревиатур — это, безусловно, хорошо. Но хотелось бы знать, как именно происходит ODBC-доступ кли­ентских приложений к базам данных. Выглядит это приблизительно так: каждый производитель РБД, заявля­ющий ODBC-поддержку под опреде­ленную операционную систему, пре­доставляет вместе со своим продук­том ODBC-драйвер. На самом деле, это даже никакой не драйвер (потому что он не является частью ядра операци­онной системы), а самая обычная ди­намическая библиотека (к примеру, DLL в MS Windows или SO в Linux), код которой будет исполняться в пространстве обычного пользова­тельского процесса. Эта библиотека обязана включать в себя набор стан­дартизованных ODBC-функций (и мо­жет включать дополнительные воз­можности), с точками вызова которых и будет линковаться приложение. Эти функции обязаны сохранять деклари­рованные имена и аргументные типы, а их алгоритмы "знают", как добиться требуемого результата от базы дан­ных конкретного производителя. Та­ким образом, не меняя исходного кода и алгоритма работы приложения, а просто линкуя его с различными

BDE УМЕР. ДА ЗДРАВСТВУЕТ DBEXPRESS!

Несмотря на своевременное появ­ление, удачные идеи и популярность среди программистов, BDE объектив­но сдает свои позиции более слабому и легковесному конкуренту — ODBC. На сегодняшний день BDE повсеместно считается устаревшей, тяжеловесной и неудобной в администрировании технологией. Borland официально за­явила о прекращении развития и под­держки BDE в пользу более прогрес­сивного преемника — dbExpress. Новый механизм призван сохранить все по ODBC-библиотеками, мож­но безболезненно мигрировать из од­ной РБД в другую.

ДИСПЕТЧЕРИЗАЦИЯ ODBC-ХОЗЯЙСТВА

Предложенный метод абстрагиро­вания от конкретных РБД безусловно хорош, но постоянная перелинковка ODBC-библиотек при переключении между различными базами — не самое интересное и заманчивое решение. Существуют методы, позволяющие подгружать динамические библиотеки на лету, но это довольно сложная об­ласть программирования. Для реше­ния такой проблемы было выпущено такое решение, как ODBC-диспетчеры (или менеджеры). Диспетчер предс­тавлен своей собственной ODBC-биб-лиотекой, которая, на самом деле, яв­ляется заглушкой и перегружает свои вызовы на вызовы конкретного ODBC-драйвера по требованию при­ложения. Естественно, что библиоте­ка диспетчера расширена функциями, позволяющими переключаться между базами не вдаваясь в подробности динамической линковки "на лету". Также существует управляющий софт, который конфигурируется дис­петчером, сообщает ему параметры и местоположение конечных ODBC-драйверов. Таким образом, приложе­нию достаточно быть слинкованным с ODBC-библиотекой диспетчера, и ему сразу после этого становятся доступ­ны все ODBC-драйверы, прописанные в системе. При этом приложение даже не оперирует понятием драйвера, а использует так называемые DSN (Data Source Name). Практически все современные ODBC-драйверы, постав­ляемые с базами данных, рассчитаны на управление диспетчером (что, ко­нечно, не мешает в случае надобнос­ти линковаться с ними напрямую).

ФОРТОЧКИ И ODBC

В современных операционных системах от Microsoft компонент ODBC-диспетчера и некоторый набор

ODBC-драйверов уже входит в постав­ку дистрибутива. Доступ к диспетчеру осуществляется через панель управ­ления посредством элемента "Источ­ники данных (ODBC)" (папка "Админи­стрирование"). При установке все ODBC-драйверы прописываются в системе, их список можно посмотреть во вкладке диспетчера "Драйверы". На базе установленных драйверов можно заводить DSN'ы — описатели соединения с базой данных, указыва­ющие, помимо драйвера, специфич­ные для базы параметры. Именно эти­ми DSN'ами и будет потом опериро­вать конечное приложение. Под акка-унтом администратора можно заво­дить системные DSN'ы, которые будут доступны всем пользователям. Неп­ривилегированный пользователь мо­жет заводить пользовательские DSN'ы, доступные только ему. Осталь­ные вкладки предназначены для от­ладочной трассировки, оптимизации подключений, совместного использо­вания пользовательских DSN'ов и других специфических целей.

В качестве примера мы быстро и непринужденно настроим доступ к ба­зам MySQL и PostgreSQL. Первым де­лом оправляемся на сайты произво дителей и скачиваем оттуда ODBC-драйверы вида myodbc-xxx.zip и psqlodbc-xxx.zip, после чего устанав­ливаем их с помощью setup'а и msi-сценария соответственно. Производи­тели оправдали свои заявления о поддержке ODBC и действительно предоставили нам работающие драй­веры. Запускаем диспетчер и убежда­емся, что наши драйверы появились в соответствующей вкладке. Теперь на вкладке "Системный/пользовательс­кий DSN" жмем "Добавить", выбира­ем наш свежеустановленный MySQL/PostgreSQL-драйвер и заявля­ем, что "Готово". Теперь осталось настроить параметры соединения. Для обеих баз достаточно указать символьное имя DSN'а (которым бу­дут оперировать приложения), сете­вой адрес для соединения (который вполне может быть и localhost'ом) и конкретное имя базы данных (одна СУРБД может обслуживать несколь­ко баз одновременно). Также можно указать пользователя "по умолча­нию", его пароль и порт, на котором висит база, если он отличается от стандартного. Вот и все. Теперь поль зовательские приложения могут по­лучать доступ к этим базам.

ODBC ДЛЯ ПИНГВИНА

В GNU/Linux нет встроенного ODBC-диспетчера, зато внешних — нес­колько. Немного опережая других, ли­дирует проект UNIX-ODBC (понятно, почему название именно такое). Схе­ма его функционирования во многом похожа на схему его аналога из Windows. Настраивать его можно как с помощью различных графических frontend’ов, так и руками — через кон­фигурационные файлы, формат кото­рых прост и понятен. С frontend’ами, я думаю, ты разберешься сам, а я пока­жу, как настраивать собственноручно. Настраивать будем все тот же доступ к базам MySQL и PostgreSQL. Для на­чала скачаем/соберем/установим из пакета ODBC-драйверы, представлен­ные динамическими библиотеками lib-myodbc.so и psqlodbc.so, размещение которых произвольно и особой роли не играет. Теперь пропишем их в кон­фигурации ODBC-диспетчера, обычно это файл /etc/odbcinst.ini :

]

Description = ODBC for MySQL Driver = /usr/lib/libmyodbc.so FileUsage = 1

[PostgreSQL]

Description = ODBC for PostgreSQL

Driver = /usr/lib/psqlodbc.so

FileUsage = 1

Теперь осталось создать DSN'ы на базе прописанных

драйверов. DSN'ы обычно хранятся в файле

/etc/odbc.ini :

[MAWD]

Driver = MySQL

SERVER = my.host.ru

DATABASE = newantispam

UID =

PWD =

PORT =

[elfbilling] Driver = PostgreSQL Database = elfbilling Servername = 172.16.1.1 Description = ELF Billing UID = PWD = Port = 5432

И вот уже соединения настроены. Проверить их можно тут же с по­мощью маленького SQL/ODBC-клиен-та, который обычно входит в пакет UNIX-ODBC и называется isql. Формат его вызова таков:

isql isql elfbilling vasya lovesexgod

Если выскочило приглашение ко вводу SQL-запроса, значит, соедине­ние прошло удачно.

Как видишь, ничего сложного в настройке UNIX-ODBC нет, если пони­мать, что делаешь (а без этого я сове­тую вообще ничего не делать).