Содержание


Обзор DB2 LUW

Часть 2. Обзор средств для разработки приложений DB2 LUW

Обзор средств для разработки приложений СУБД IBM DB2 для платформ Linux, Unix и Windows

Comments

Серия контента:

Этот контент является частью # из серии # статей: Обзор DB2 LUW

Следите за выходом новых статей этой серии.

Этот контент является частью серии:Обзор DB2 LUW

Следите за выходом новых статей этой серии.

Подключение приложений

Общие сведения и состав пакетов драйверов

Подключение приложений к серверам DB2 осуществляется с помощью программного обеспечения, входящего в состав клиента IBM Data Server. Клиенты IBM Data Server могут также подключаться к другим серверам данных семейства IBM (например, Informix). Этим объясняется использование общего названия «Клиент IBM Data Server», а не более конкретного «Клиент DB2».

Сервер DB2 поставляется с интегрированным компонентом клиента и может служить клиентом для подключения к другому серверу DB2.

Основные варианты взаимодействия приложений с сервером DB2 включают в себя:

  • использование интерфейса CLI (Call Level Interface, интерфейс уровня вызовов) либо стандартного интерфейса ODBC, реализованного CLI-драйвером DB2 - типовой вариант для программ на языках C и C++, а также для разработки драйверов доступа для других языков и сред программирования (PHP, Python, Perl, Ruby);
  • использование интерфейса JDBC, реализованного Java-драйвером DB2 - применяется программами на Java и других языках программирования, исполняемыми в среде виртуальной машины Java (JVM);
  • работа через интерфейс OLE DB / ADO - используется приложениями, функционирующими на платформе Microsoft Windows и использующими стандартный для этой операционной системы стек технологий (включая приложения на платформе .NET);
  • разработку хранимых процедур на встроенных языках, поддерживаемых сервером DB2: SQL PL, PL/SQL;
  • разработку «внешних» хранимых процедур в виде динамических библиотек, загружаемых сервером СУБД и использующих интерфейс CLI;
  • разработку приложений с использованием «встраиваемого» SQL на языках C и C++ (C Embedded SQL, SQC), а также Java (в варианте SQLJ).

Более подробная информация о методах взаимодействия приложений с сервером DB2 приведена в настоящей статье в разделе «Разработка клиентских приложений».

Клиент IBM Data Server включает всю необходимую функциональность для подключения к серверу DB2, однако необходимость в установке полного пакета IBM Data Server возникает не всегда. К примеру, приложениям, использующим драйвер JDBC Type 4 для подключения к серверу DB2, требуется только установка драйвера JDBC.

Доступно несколько разновидностей клиентов и драйверов DB2:

  • клиент «IBM Data Server Client»: наиболее полный клиент, включает инструменты графического интерфейса пользователя и все виды драйверов;
  • клиент «IBM Data Server Runtime Client»: облегченный клиент с базовой функциональностью и драйверами;
  • пакет модулей «DB2 Runtime Client Merge Modules for Windows»: используется для внедрения клиента DB2 в состав процедуры установки других приложений в Windows;
  • драйвер «IBM Data Server Driver for JDBC and SQLJ»: позволяет приложениям Java™ подключаться к серверам DB2 без установки полного клиента;
  • драйвер «IBM Data Server Driver for ODBC and CLI»: позволяет приложениям, использующим интерфейсы ODBC и CLI, подключаться к серверу DB2 без установки полного клиента;
  • пакет драйверов «IBM Data Server Driver Package»: включает специальный драйвер для Windows с поддержкой среды .NET, в дополнение к ODBC и CLI. Ранее, этот драйвер был известен как драйвер «IBM Data Server for ODBC, CLI and .NET»

Настройки подключения к базам данных

Настройки подключения к базам данных для среды Java определяются комплектом свойств, задаваемых в так называемой строке подключения и дополнительно поддерживаемых параметрах. Синтаксис строки подключения JDBC и состав дополнительно поддерживаемых свойств описан в документации на JDBC-драйвер DB2. Пример строки подключения для драйвера типа 4: jdbc:db2://server:50000/dbname.

Настройки подключений к серверам и базам данных для приложений, использующих интерфейсы ODBC и CLI, хранятся в так называемых каталогах DB2 (DB2 directory). Каталоги DB2 — это двоичные файлы, в которых хранится информация о том, к каким базам данных можно подключиться с компьютера. Существует четыре каталога:

  • каталог системных баз данных (system database directory);
  • каталог локальных баз данных (local database directory);
  • каталог узлов (node directory);
  • каталог DCS (DCS directory).

Каталог системных баз данных содержит ссылки на все базы данных (как локальные, так и удаленные), к которым можно подключиться. Для локальных баз данных отображается указатель на каталог локальных баз данных. Для удаленных баз данных отображается указатель на запись в Каталоге узлов. Для просмотра содержимого каталога системных баз данных используйте команду LIST DB DIRECTORY.

Каталог локальных баз данных содержит информацию о базах данных, хранящихся на локальном компьютере, к которым можно подключиться. Чтобы просмотреть содержимое этого каталога, используйте команду LIST DB DIRECTORY ON ПутьКБазамДанных.

В каталоге узлов содержится информация о способах подключения к удаленным серверам баз данных. К примеру, если используется протокол TCP/IP, в записи узла TCP/IP будет указан IP-адрес сервера, на котором хранится база данных DB2, к которой устанавливается подключение, а также порт экземпляра, который содержит эту базу данных. Чтобы просмотреть содержимое этого каталога, используйте команду LIST NODE DIRECTORY.

Каталог DCS содержит дополнительные параметры подключения к базам данных DB2 for z/OS, DB2 for i и DB2 for VM/VSE. Каталог DCS используется только продуктом DB2 Connect для обеспечения подключений к соответствующим типам баз данных.

Настройка подключения к базам данных осуществляется путем создания записей в соответствующих каталогах. Для локальных баз данных записи каталогов создаются и удаляются автоматически при создании и удалении соответствующих баз данных, ручное управление такими записями обычно не требуется. Для баз данных на других серверах настройка подключения обычно осуществляется в два этапа:

  • Создается элемент каталога узлов, содержащий параметры сетевого соединения с сервером баз данных. Для узлов TCP/IP данная операция выполняется командой CATALOG TCPIP NODE.
  • Создается элемент каталога системных баз данных, содержащий ссылку на каталог узлов и имя базы данных, обслуживаемой соответствующим сервером, с помощью команды CATALOG DATABASE.

Разработка клиентских приложений

Доступные языки и стандарты

DB2 предоставляет среду разработки приложений, основанную на стандартах и прозрачную для всего семейства DB2. Стандартизация SQL на всей линейке продуктов DB2 обеспечивает общий набор прикладных программных интерфейсов для доступа к базе данных.

Кроме того, каждый продукт DB2 предоставляет средства прекомпиляции SQL (т.е. поддержку встраивания SQL-операторов в программы на различных языках программирования), а также прикладные программные интерфейсы (API), с помощью которых разработчики могут встраивать статические и динамические SQL-запросы в разрабатываемые приложения.

Доступные в DB2 языки и стандарты включают в себя:

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

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

Организация разработки на стороне сервера описана в разделах «Разработка на стороне сервера СУБД» и «Процедурные языки СУБД».

Разработка на встраиваемом SQL

Приложения на встраиваемом SQL — это приложения, в которых язык SQL встроен в язык хоста, например, C, C++ или COBOL. Приложение на встраиваемом SQL может содержать как статический, так и динамический SQL (см. далее). Встраивание операторов SQL в приложение осуществляется с помощью специальных программных конструкций, расширяющих применяемый язык программирования (обычно это конструкция EXEC SQL, адаптируемая под особенности конкретного языка программирования).

Приложения на встраиваемом SQL обрабатываются специальной программой-прекомпилятором, в результате чего формируются два промежуточных файла: файл связей, содержащий текст встроенных (статических) SQL-операторов и сопутствующую служебную информацию, и файл с программой на оригинальном языке программирования (без встроенных SQL-операторов), которая содержит исходную логику приложения и специальные вызовы клиента DB2 для выполнения операторов SQL. Вызов программы-прекомпилятора осуществляется с помощью команды DB2 PRECOMPILE (сокращенное наименование - PREP).

Программа на оригинальном языке программирования далее должна быть скомпилирована штатными средствами (например, обработана компилятором и редактором связей C/C++), а файл связей должен быть загружен в базу данных DB2 (командой BIND) перед выполнением программы.

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

Современные программные API, такие как JDBC и ODBC, всегда используют динамический SQL, независимо от того, включает SQL-оператор только заранее известные объекты или нет. В целом, для обработки SQL-оператора как динамического используется две команды:

  • PREPARE: готовит, или компилирует SQL-оператор, рассчитывая план доступа, который будет применяться для извлечения данных;
  • EXECUTE: выполняет SQL-оператор.

Команды PREPARE и EXECUTE также можно выполнить разом, с помощью одного оператора: EXECUTE IMMEDIATE.

Разработка с использованием ODBC, CLI, OLE DB или ADO

Интерфейс уровня вызовов (Call Level Interface, CLI) был разработан компанией компаниями X/Open и SQL Access Group. Этот интерфейс создавался как спецификация вызываемого интерфейса SQL для разработки переносимых (совместимых с множеством операционных систем) приложений на C/C++, независимых от поставщика СУБД.

На основе предварительного проекта интерфейса уровня вызовов X/Open корпорация Microsoft разработала открытые средства связи с базами данных (Open Database Connectivity, ODBC), а позже международный комитет ISO принял большинство спецификаций интерфейса уровня вызовов X/Open в качестве стандарта SQL/CLI.

Интерфейс CLI DB2 основан на ODBC и Международном стандарте для SQL/CLI. Реализация CLI DB2 соответствует спецификации ODBC версии 3.51 и может использоваться в качестве драйвера ODBC при загрузке диспетчером драйверов ODBC.

CLI/ODBC имеет следующие характеристики:

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

Для выполнения приложения CLI/ODBC достаточно иметь драйвер CLI DB2. Для разработки приложения CLI/ODBC необходимы драйвер CLI DB2 и соответствующие библиотеки разработки.

OLE DB — это набор интерфейсов, предоставляющий доступ к данным из различных источников. Он разрабатывался корпорацией Microsoft как замена ODBC, но был расширен для поддержки более широкого набора источников, в том числе нереляционных баз данных, текстовых документов и электронных таблиц. Реализация OLE DB осуществляется с применением технологии объектной модели программных компонентов (Component Object Model, COM), также разработанной компанией Microsoft.

Пользователи OLE DB могут получить доступ к базам данных DB2 с помощью компонента DB2 OLE DB Provider от компании IBM. Для пользователей ADO (ActiveX Data Objects) в составе драйверов DB2 поставляется провайдер ADO.NET для DB2, который является надстройкой над драйвером OLE DB.

Разработка в среде Java

Интерфейс соединения с базами данных на Java (Java Database Connectivity, JDBC) — это программный API Java, определяющий стандарты средств для работы с базами данных и доступа к ним. Программный код JDBC достаточно легко переносится между продуктами нескольких поставщиков СУБД. Обычно в код необходимо вносить только изменения, касающиеся выбора драйвера JDBC для загрузки и используемой строки соединения.

В настоящее время работа с базами данных с использованием драйверов JDBC обеспечивается в том числе и для языков программирования, отличных от Java, но исполняемых средствами виртуальной машины Java JVM (Java Virtual Machine), включая Groovy, Scala, Closure, Jython.

SQLJ — это стандарт встраивания SQL в Java-программы. Он используется преимущественно со статическим SQL, хотя совместим с JDBC. Хотя обычно SQLJ-программы являются более компактными по сравнению с программами JDBC, и обеспечивают более высокую производительность, этот стандарт не получил широкого применения. Программы SQLJ необходимо обрабатывать препроцессором (транслятором SQLJ) прежде, чем их можно будет скомпилировать компилятором Java.

IBM pureQuery — это разработанный компанией IBM подключаемый модуль на базе среды Eclipse для управления реляционными данными как объектами. Модуль pureQuery может автоматически генерировать код для установки объектно-реляционного отображения (object-relational mapping, ORM) между объектно-ориентированным программным кодом и объектами реляционной базы данных. Сгенерированные объекты Java и содержащиеся в них SQL-операторы поддаются дальнейшей настройке (доработке). С помощью pureQuery во время выполнения можно выбрать режим статического или динамического SQL. Использование режима статического SQL позволяет значительно увеличить производительность выполнения нагрузок транзакционного (OLTP) типа за счет исключения стадии компиляции и оптимизации запросов.

Разработка на стороне сервера СУБД

Виды программных объектов базы данных

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

В DB2 поддерживаются следующие виды программных объектов:

  • хранимые процедуры;
  • пользовательские функции (UDF, User Defined Functions);
  • триггеры.

Хранимая процедура — это объект базы данных, содержащий операторы SQL и бизнес-логику. Хранимые процедуры предоставляют централизованное местоположение для хранения программного кода, и соответственно, несколько разных приложения могут пользоваться одними и теми же хранимыми процедурами.

Для вызова хранимой процедуры используется оператор CALL. В DB2 хранимые процедуры можно разрабатывать на нескольких языках, среди которых SQL PL, PL/SQL, Java, C, C++ и COBOL.

Пользовательская функция (UDF) — это объект базы данных, позволяющий пользователям расширить язык SQL собственной логикой. Функция всегда возвращает значение или значения, как результат включенной в функцию бизнес-логики.

Чтобы вызвать функцию, используется обращение по имени функции в составе DML-оператора (SELECT, INSERT, UPDATE, DELETE) или с оператором VALUES. В DB2 пользовательские функции можно разрабатывать на нескольких языках, среди которых SQL PL, PL/SQL, Java, C/C++.

Триггер — это объект базы данных, который автоматически выполняет операцию с таблицей или представлением. Заданное действие с объектом, для которого определен триггер (например, вставка, обновление, удаление записей), вызывает запуск триггера, других средств для вызова триггеров не предусмотрено. Разработка триггеров в DB2 может осуществляться на языках SQL PL и PL/SQL. При необходимости триггер может вызвать пользовательскую функцию, реализованную на других языках программирования, пример и особенности такой организации обработки представлены в статье «Enforcing Business Logic using DB2 Triggers, Java UDFs, and the JavaMail API».

Организация выполнения программных объектов

Хранимые процедуры и пользовательские функции обобщенно часто называют подпрограммами (англоязычный термин - routines). Подпрограммы делятся на внутренние, или SQL-подпрограммы, и внешние подпрограммы. Данное деление обусловлено наличием технических различий в организации работы подпрограмм, разработанных на языках, непосредственно компилируемых на стороне сервера СУБД (SQL PL, PL/SQL), и на языках, компилируемых в машинный код разработчиком (C, C++, COBOL).

К внутренним подпрограммам относятся хранимые процедуры и пользовательские функции, разработанные на языках PL/SQL и PL SQL. Операторы создания программных объектов внутренних подпрограмм содержат непосредственно программный код, сохраняемый в системном каталоге и обрабатываемый сервером СУБД. Использование языков программирования, обрабатываемых сервером СУБД, позволяет безопасно и эффективно организовать выполнение внутренних подпрограмм непосредственно в рамках рабочих процессов сервера СУБД, в рамках доверенной и защищенной среды исполнения программного кода с применением всех механизмов контроля доступа СУБД.

Код внешних подпрограмм разрабатывается на компилируемых языках и преобразуется средствами среды разработки в динамически загружаемые библиотеки (DLL) для среды исполнения (аппаратной архитектуры и операционной системы) сервера СУБД. Созданная динамическая библиотека затем копируется на сервер СУБД. При создании программного объекта в базе данных указывается имя динамической библиотеки, имя функции в данной библиотеке (идентификатор точки входа) и описывается набор входных и выходных параметров, при этом сам программный код отсутствует в системном каталоге базы данных.

Для исключения возможного негативного влияния кода динамических библиотек на функционирование ядра сервера СУБД, загрузка и исполнение внешнего машинного кода осуществляется в рамках дополнительно создаваемых процессов (db2fmp, Fenced Monitor Process). Существует возможность загрузки полностью доверенного кода сторонних процедур непосредственно в процесс сервера СУБД, но этой возможностью следует пользоваться с большой осторожностью, и её применение требует наличия особых привилегий при работе с базой данных (CREATE NOT FENCED).

Аналогичным образом организована работа с программными объектами, разработанными на языке Java. Несмотря на то, что скомпилированные библиотеки Java являются машинно-независимыми и не требуют адаптации для различных сред исполнения сервера СУБД, в системном каталоге базы данных соответствующие объекты регистрируются с указанием имени библиотеки и имени точки входа (класса, метода). Исходный код программных объектов на языке Java в системном каталоге базы данных не размещается. Ознакомиться с разработкой хранимых процедур на языке Java можно, изучив статью «Solve common problems with DB2 UDB Java stored procedures», опубликованную на сайте IBM developerWorks.

Административные программные интерфейсы

DB2 предоставляет множество административных программных интерфейсов (API), которыми разработчики могут воспользоваться для построения собственных утилит или инструментов. Фактически с помощью административных API могут быть автоматизированы любые действия по управлению сервером баз данных, включая создание и удаление баз данных, экспорт и импорт информации, управление полномочиями, резервное копирование и восстановление, и многое другое. Подробное описание административных программных интерфейсов приведено в документации DB2 в разделах «Administrative APIs» и «Administrative routines and ADMIN_CMD procedure».

Процедурные языки СУБД

SQL PL

Язык SQL PL является процедурным расширением языка SQL и был разработан компанией IBM на основе стандарта SQL/PSM (Persistent Stored Modules). Модули, разработанные на языке SQL PL, автоматически транслируются средствами сервера СУБД в специальный байткод, исполняемый виртуальной машиной SQL Unified Runtime Engine (SURE) на серверах DB2.

Детальное описание языка SQL PL приведено в документации на DB2 в разделе «SQL Procedural Language (SQL PL)».

PL/SQL

Язык PL/SQL является процедурным расширением языка SQL и был разработан компанией Oracle на основе концепций языка Ada.

В DB2 поддерживаются все основные конструкции PL/SQL и большая часть стандартной библиотеки процедур PL/SQL. Существующие (на данный момент, весьма незначительные) ограничения поддержки PL/SQL описаны в документации на DB2.

Модули, разработанные на языке PL/SQL, при их определении в базах данных DB2 автоматически транслируются в байткод для исполнения виртуальной машиной SQL Unified Runtime Engine. Исполнение сформированного байткода виртуальной машиной SURE ничем не отличается от варианта, подготовленного для модулей на языке SQL PL.

Описание особенностей реализации языка PL/SQL в среде DB2 приведено в документации на DB2 в разделе «PL/SQL support».

Ограничения поддержки PL/SQL для DB2 описаны в разделе «Restrictions on PL/SQL support». Для DB2 версий 10.5 и 11.1 существуют следующие ограничения поддержки PL/SQL:

  • при работе с многораздельными базами данных, создание программных объектов PL/SQL может выполняться только на разделе системного каталога DB2 (catalog partition);
  • использование типа данных NCLOB не поддерживается в операторах или контекстах PL/SQL для не-Unicode баз данных;
  • тип данных XMLTYPE и связанные с ним операции не поддерживаются (в DB2 реализованы собственные средства для работы с данными XML - DB2 pureXML);
  • при работе с многораздельными базами данных, не поддерживается доступ к переменным курсора с других узлов базы данных. Доступ к переменным курсора допускается только с узла координатора;
  • в автономных процедурах и функциях не поддерживается использование вложенных типов данных, содержащих переменные, объявленные на уровне пакетов PL/SQL.

Кроме того, при миграции существующего кода, разработанного для СУБД Oracle Database, необходимо учитывать, что DB2 LUW предоставляет не все пакеты PL/SQL и не все встроенные системные представления Oracle. Использование неподдерживаемых пакетов, представлений и синтаксических конструкций может быть выявлено в автоматизированном режиме с использованием бесплатного инструмента IBM Database Conversion Workbench (IBM DCW). Для значительной части неподдерживаемых пакетов существует готовая реализация либо рекомендации по замене, которые могут быть использованы при миграции приложений.

Модульное тестирование

Модульное тестирование – составная часть процесса тестирования программного обеспечения, имеющая целью выполнение проверок на уровне компонентов. При разработке программного обеспечения на стороне базы данных компонентами, подвергаемыми модульному тестированию, являются программные объекты баз данных: хранимые процедуры, функции, триггеры.

Для организации модульного тестирования программного кода на языках SQL PL и PL/SQL может использоваться инфраструктура db2unit. Работа с db2unit хорошо описана в статье, опубликованной на сайте developerWorks: Процедуры модульного тестирования программ на языке SQL PL с использованием инфраструктуры db2unit в среде DB2 LUW. Приведу также ссылку на оригинал статьи по db2unit на английском языке, так как вёрстка переведённого варианта была выполнена с ошибками, и некоторые примеры кода оказались нечитаемыми.

Альтернативный вариант организации модульного тестирования программных объектов баз данных DB2 опирается на использование внешних библиотек и сред, способных обращаться к базам данных - например, инфраструктуры JUnit, обычно используемой для приложений Java. При использовании внешнего инструмента для выполнения разработанных модульных тестов потребуется, помимо тестовой базы данных и самих тестов, настроенная среда для выполнения контрольных примеров, подключаемая к тестовой базе данных (в случае JUnit - виртуальная машина Java, настройки подключения к базе данных и инфраструктура запуска тестов - в простейшем варианте, стартовый скрипт).

Модульные тесты часто встраивают в процессы непрерывной интеграции программного обеспечения. Комплектность и результаты выполнения модульных тестов могут использоваться разработчиками, менеджерами проекта и руководством как комплексный индикатор состояния готовности и качества разрабатываемого программного обеспечения.

Работа с данными XML

XML — это технология, лежащая в основе инструментов и технологий Web 2.0, а также SOA. Технология DB2 pureXML предоставляет расширенные возможности для хранения и оперирования XML-документами в DB2.

Сервер данных DB2 является гибридным: он дает возможность сохранять в исходном формате как реляционные, так и иерархические (XML) данные. Старые версии DB2 и прочие представленные на рынке серверы данных могли хранить XML-документы, однако методы хранения и обработки, используемые в DB2 начиная с версии 9, повысили производительность и гибкость работы с данными XML.

Данные XML в DB2 могут быть сохранены в колонках специального типа, с обеспечением автоматического структурного разбора и (при необходимости) контроля соответствия структуры документа заданной XML-схеме. Хранение XML-документов в разобранном виде позволяет:

  1. организовать доступ к полям XML-документов, в том числе при выполнении SQL-операторов для фильтрации записей по заданным условиям и формирования результатов запросов;
  2. ускорить выборку данных за счет создания индексов над хранимыми XML-документами, не ограничиваясь механизмами полнотекстового поиска, а с учетом структуры документа, и, тем самым, семантики данных;
  3. обеспечить возможность формирования XML-документов SQL-запросами;
  4. обеспечить выборку данных в табличной форме путем обращения к XML-документам.

Для хранимых данных XML обеспечивается сжатие, что существенно сокращает необходимый объем дискового пространства для хранения XML-документов и снижает интенсивность ввода-вывода.

В целом по сравнению с традиционными подходами по хранению XML-документов и их фрагментов в BLOB-полях, а также по полной декомпозиции XML-документов в набор записей реляционных таблиц, технология DB2 pureXML предоставляет серьезные преимущества в производительности, гибкости и доступных функциях.

Работа с данными JSON

В DB2 версии 10.5 была добавлена поддержка работы с данными JSON, как распространенным в настоящее время стандартом работы Web-приложений с иерархическими данными.

Хранение данных JSON осуществляется в двоичном формате BSON, с поддержкой расширений поддерживаемых типов данных, разработанных для MongoDB. Работа с данными JSON обеспечивается как с использованием инструментов командной строки (для управления и выборки данных JSON), так и с использованием программных интерфейсов DB2:

  • интерфейса для работы с данными JSON, встроенного в JDBC-драйвер DB2;
  • интерфейса любого драйвера, реализующего протокол MongoDB (включая штатные драйверы MongoDB, а также распространенные библиотеки для Java, C/C++, Perl, Python, Ruby и PHP).

Для работы с данными JSON из командной строки используется утилита db2nosql. Она поддерживает как выполнение административных операций (например, создание необходимых таблиц для хранения данных JSON), так и операции поиска, выборки, вставки, импорта и экспорта данных.

Программные интерфейсы для работы с JSON в составе JDBC-драйвера DB2 обеспечивают удобную работу с документами JSON, поддерживая операции поиска, выборки, вставки, модификации и удаления данных.

Использование реализации протокола MongoDB на стороне сервера DB2 позволяет применять все разработанные инструменты для работы с документами JSON, используемые пользователями MongoDB.

Большинство современных Web-приложений работает как с иерархическими, так и с реляционными данными, поэтому использование встроенной в DB2 поддержки JSON и XML позволяет исключить необходимость развертывания нескольких различных серверов баз данных для решения задач хранения данных.

Обеспечение совместимости с другими СУБД и миграция баз данных

В IBM DB2 LUW реализовано множество функций для обеспечения совместимости с другими видами СУБД и облегчения переноса приложений, разработанных для других типов СУБД, на платформу IBM DB2. Полное описание функций обеспечения совместимости DB2 приведено в разделе документации «DB2 compatibility features».

Наиболее развитыми на данный момент являются средства обеспечения совместимости с СУБД Oracle Database, которые включают в себя:

  1. поддержку языка PL/SQL для разработки хранимых процедур, пользовательских функций и триггеров;
  2. наличие в DB2 командного процессора clpplus, совместимого с командным процессором Oracle SQL*Plus;
  3. реализацию значительной части стандартной библиотеки PL/SQL (частично - в виде дополнения DB2 Add-On Modules for Oracle Database Compatibility, устанавливаемого после создания базы данных);
  4. наличие встроенной в DB2 поддержки большинства типов данных Oracle;
  5. поддержка синтаксиса Oracle для многих операций DB2, например:
    • поддержка хранения и работы с меткой времени в данных типа DATE,
    • поддержка неявного преобразования типов данных при выполнении сравнений (например, поддержка сравнения строк и чисел без явного приведения типа данных),
    • поддержка внешних объединений (outer joins) в синтаксисе Oracle, с использованием оператора (+),
    • поддержка иерархических запросов в синтаксисе Oracle,
    • поддержка псевдо-колонки ROWNUM,
    • поддержка таблицы DUAL,
    • поддержка синтаксиса Oracle для обращения к объектам других баз данных, доступных через сетевое соединение (определенное через так называемый «database link»): Схема.Объект@Ссылка;
  6. наличие набора представлений системного словаря, совместимых с системным словарем СУБД Oracle (включая представления ALL_*, DBA_* и USER_*);
  7. усовершенствования механизмов управления конкурентным доступом DB2, облегчающие перенос приложений, разработанных для СУБД Oracle (так называемая «Currently committed» семантика, используемая по умолчанию для всех новых баз данных DB2, начиная с версии 9.7);
  8. использование в режиме совместимости с Oracle так называемой поздней компиляции запросов (deferred prepare), что позволяет корректно определить типы данных параметров запроса на основе переданных реальных значений параметров.

Для облегчения переноса на DB2 приложений, разработанных для СУБД MySQL и PostgreSQL, поддерживается выражений LIMIT и OFFSET в командах SELECT, UPDATE и DELETE.

Для использования функции совместимости DB2 с другими СУБД их необходимо активизировать с помощью переменной реестра DB2 DB2_COMPATIBILITY_VECTOR. Возможные значения и результат их применения описаны в документации. Для использования большинства функций совместимости необходимо установить переменную DB2_COMPATIBILITY_VECTOR в необходимое значение (например, для работы в режиме максимальной совместимости с СУБД Oracle установить значение ORA), перезапустить сервер СУБД, и затем создать новую базу данных, в которой будут размещаться данные и код программных объектов.

Для упрощения решения задачи миграции баз данных в среду DB2 был создан свободно распространяемый инструмент IBM Database Conversion Workbench (IBM DCW), который реализует следующие функции:

  • выгрузку описаний структуры и программного кода из исходных баз данных;
  • анализ совместимости выгруженных описаний с DB2 LUW, формирование отчетов о совместимости;
  • автоматизированную корректировку скриптов для создания базы данных;
  • создание необходимых объектов в целевой базе данных;
  • перенос информации из исходной базы данных в целевую базу данных.

Описание основных операций с использованием инструмента IBM DCW приведено в статье «IBM Database Conversion Workbench: Overview».

Для облегчения миграции приложений на встроенном SQL, разработанных для СУБД Oracle Database с использованием Oracle Pro*C, IBM DB2 поддерживает дополнительные средства и функции обеспечения совместимости. Особенности процесса переноса приложений Oracle Pro*C на платформу IBM DB2 изложены в статье «Accelerating migration from Oracle database-based Pro*C applications to DB2 embedded SQL C», опубликованной на сайте IBM developerWorks.

Изменение структуры баз данных

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

Многие операции изменения структуры таблиц требуют физической реорганизации хранения данных в изменяемой таблице. Например, при радикальном изменении типа данных колонки таблицы (число - строка, или наоборот) необходимо прочитать каждую запись таблицы, изменить её структуру и записать обратно.

Изменения структуры таблицы, которые не требуют физической реорганизации, сохраняют таблицу доступной для чтения и записи, но будут учтены при проведении следующей плановой реорганизации. Пример: добавление колонок в существующую таблицу обрабатывается без прекращения доступа приложений к данной таблице и не требует обновления всех записей таблицы.

В рамках одной транзакции может быть выполнено неограниченное количество изменений структуры таблицы без выполнения её реорганизации, при этом доступ к данным таблицы может быть приостановлен до выполнения следующей реорганизации. Реализованная в DB2 отслеживания изменений структуры таблицы, требующих её реорганизации, более детально описана в следующем техническом документе, а также в разделе «Altering tables» документации DB2.

Обратите внимание, что командный процессор DB2 по умолчанию подтверждает транзакцию после каждой выполненной команды - это часто приводит к отказам выполнения второй и последующих операций изменения структуры таблицы (будет возвращено сообщение о необходимости выполнить реорганизацию). Поэтому перед выполнением серии операций изменения структуры таблицы необходимо отключить автоматическое подтверждение транзакций командным процессором (например, с помощью команды UPDATE COMMAND OPTIONS USING c OFF).

IBM DB2 также поддерживает полную реорганизацию структуры таблиц без приостановки доступа к реорганизуемым таблицам, с помощью административной процедуры ADMIN_MOVE_TABLE. Описание порядка работы с данной функцией приведено в документации DB2. Административная процедура ADMIN_MOVE_TABLE осуществляет копирование данных из исходной таблицы в новую (с требуемой структурой), выполняя отслеживание изменений данных в ходе копирования и применяя изменения к созданной копии, а затем заменяет исходную таблицу вновь созданной копией. Одним из вариантов применения данной процедуры является перемещение существующей таблицы в другое табличное пространство. Примеры использования данной функции опубликованы в статье «Distributed DBA: Table movement made easy».

В отличие от таблиц, изменение программных объектов (представлений, хранимых процедур, пользовательских функций и триггеров) осуществляется путем их полного пересоздания. Программные объекты могут зависеть от структуры таблиц и от других программных объектов (например, представления могут обращаться к таблицам, другим представлениям и пользовательским функциям). Зависимости между объектами базы данных отслеживаются DB2, и в случае удаления объектов (либо блокировки доступа к ним) зависимые программные объекты отмечаются как некорректные (требующие перекомпиляции либо исправления). IBM DB2 поддерживает автоматическую перекомпиляцию зависимых объектов (automatic revalidation, см. документацию), выполняемую при первом обращении к объекту, требующему перекомпиляции. По умолчанию для всех новых баз данных, созданных в DB2 версии 9.7 и более поздних, используется режим автоматической перекомпиляции.

Рекомендуемым методом изменения программного объекта является замена его описания с помощью оператора CREATE OR REPLACE. Применение данного оператора сохраняет выданные привилегии на доступ к объекту, в то время как удаление и повторное создание объекта потребует повторной выдачи всех ранее установленных полномочий. IBM DB2 поддерживает режим мягкого удаления (soft invalidation, см. документацию), используемый по умолчанию, который позволяет удалять и заменять программные объекты базы данных даже в тот момент, когда они используются работающими приложениями.

Выполнение необходимых операций реорганизации таблиц и перекомпиляции программных объектов могут быть автоматизированы с использованием административной процедуры ADMIN_REVALIDATE_DB_OBJECTS. Данная процедура определяет объекты базы данных, которые необходимо реорганизовать либо перекомпилировать, и выполняет соответствующие операции. Инструкции по использованию данной процедуры приведены в документации DB2.

Заключение

В данной статье были рассмотрены вопросы организации подключения приложений к серверам баз данных DB2, перечислены разновидности клиентов и драйверов DB2, описан порядок настройки подключения к базам данных. Кратко рассмотрены вопросы разработки приложений баз данных с использованием встраиваемого SQL, интерфейсов CLI/ODBC и OLE DB/ADO, а также интерфейсов JDBC в среде Java. Также рассмотрена разработка хранимых процедур, пользовательских функций и триггеров, включая вопросы организации выполнения программных объектов в зависимости от технологии их реализации (внутренние и внешние подпрограммы). Затронуты вопросы организации работы с данными XML и JSON, обеспечения совместимости с другими типами СУБД и изменения структуры баз данных.


Ресурсы для скачивания


Похожие темы


Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management, Большие данные и аналитика
ArticleID=1018178
ArticleTitle=Обзор DB2 LUW: Часть 2. Обзор средств для разработки приложений DB2 LUW
publish-date=10212015