View on GitHub

Db2-Russian

IBM Db2 по-русски

Разработка на стороне сервера Db2

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

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

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

Хранимая процедура — это объект базы данных, содержащий операторы 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. При необходимости триггер может вызвать пользовательские функции, реализованные на других языках программирования, например на языке Java.

Начиная с версии 11.5, Db2 поддерживает публикацию запросов, вызовов хранимых процедур и функций в виде RESTful Web-сервисов, подробнее см. в документации.

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

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

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

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

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

Аналогичным образом организована работа с программными объектами, разработанными на языке Java. Несмотря на то, что скомпилированные библиотеки Java являются машинно-независимыми и не требуют адаптации для различных сред исполнения сервера СУБД, в системном каталоге базы данных соответствующие объекты регистрируются с указанием имени библиотеки и имени точки входа (класса, метода). Исходный код программных объектов на языке Java в системном каталоге базы данных не размещается.

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

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 описаны в документации.

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

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

Для DB2 версий 10.5 и 11.1 существуют следующие ограничения поддержки PL/SQL:

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

Модульное тестирование хранимых процедур

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

Для организации модульного тестирования программного кода на языках SQL PL и PL/SQL может использоваться инструмент db2unit

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

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