Средства обработки данных

Язык баз данных SQL

Язык SQL ( Structured Query Language ) является языком обработки и манипулирования данными СУБД ЛИНТЕР. Он основан на стандарте ANSI / ISO SQL -92. При реализации языка в него были внесены некоторые элементы, не специфицированные в стандарте SQL -92. Это касается конструкций, относящихся к интернационализации имен объектов базы данных (БД) - таблиц, столбцов и пр., а также набора скалярных функций, введенных в СУБД ЛИНТЕР для совместимости с SQL СУБД Oracle .

В частности, в SQL СУБД ЛИНТЕР реализованы:

1. предложение UNION;
2. полный набор операций соединения JOIN;
3. все спецификации по описанию ограничений целостности;
4. для совместимости с некоторыми известными СУБД (Oracle, DB2, Informix, Microsoft SQL Server и др.) в язык SQL введено множество встроенных функций;
5. конструкции по управлению контролем доступа к информации;
6. иерархические запросы к таблице и т.д.

Расширения стандарта включают:

1. конструкции для работы с BLOB-столбцами;
2. конструкции для работы с внешними файлами;
3. введены последовательности, совместимые с СУБД Oracle;
4. разрешено горячее тестирование таблицы, т.е. предложение TEST TABLE  ;
5. разрешено горячее архивирование объектов БД;
6. разрешено использование нескольких таблиц во FROM в операциях UPDATE и DELETE, например:
   DELETE FROM таблица JOIN список _ таблиц WHERE ...
   UPDATE таблица JOIN список _ таблиц WHERE ...
7. разрешена конструкция INTO в SELECT-операторе для совместимости с некоторыми диалектами языка SQL, например:
   SELECT список_выражений INTO список_параметров FROM ...
8. разрешена конструкция CAST NULL AS ;

9. разнообразные возможности ALTER TABLE по модификации структуры таблицы – от изменения имен (таблицы, её столбцов) до изменений важнейших характеристик самой таблицы и её столбцов (например, размеров, числа файлов, места их расположения, а для столбцов - длины данных, значений по умолчанию и т.д.);

10. конструкции для полнотекстового поиска и т.д.

Процедурный язык

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

По функциональной мощности хранимые процедуры СУБД ЛИНТЕР в некоторых аспектах даже превышают стандарт ANSI / ISO SQL -92/ PSM (Persistent Stored Modules), а именно:

• использование оттранслированных запросов и запросов с параметрами (динамически изменяемых запросов),
• управление транзакциями,
• возможность работы с курсором.

Процедурный язык включает все необходимые операции с переменными и значениями каждого типа данных СУБД ЛИНТЕР, вызовы разнообразных стандартных функций (таких, как преобразование типов, работа со строчными данными и т.д.), операцию присваивания (тот факт, что присваивание является операцией, а не отдельным оператором, позволяет строить, например, такие конструкции: a  :=  b  :=  c  :=   0;).

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

Набор операторов позволяет закодировать алгоритмы любой сложности.

Для обработки результатов SELECT-запросов в процедурах используются курсоры (CURSOR), тип которых объявляется в соответствии со структурой ответа. Цикл работы с курсором может включать его открытие оператором OPEN (как результат запроса или выполнения другой процедуры), выборку данных оператором FETCH (в любом направлении) и закрытие (CLOSE) или, если процедура возвращает курсор, возврат (RETURN).

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

Понятие «курсор» используется исключительно для выборки данных. Для выполнения любых DML и DDL запросов (запросов отличных от SELECT-запроса) используется оператор EXECUTE.

Все операции процедур по модификации данных входят в пользовательскую транзакцию. Завершением транзакции управляет пользователь, однако, процедура также может зафиксировать или откатить изменения, сделанные в ее теле (и теле ее дочерних процедур) операторами COMMIT и ROLLBACK.

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

В момент возникновения исключения управление сразу автоматически передается на соответствующую ветку блока обработки исключений (EXCEPTIONS), что избавляет от необходимости «засорения» кода процедуры многочисленными условными операторами, проверяющими результат завершения каждого оператора. Процедура может обработать исключение либо завершиться и передать исключение на верхний уровень (оператор RESIGNAL).

Процедуры могут использоваться как хранимые функции, расширяющие язык SQL.

Для загрузки текста хранимой процедуры (триггера) используются:

• spc – утилита с командным интерфейсом;
• spman – утилита с псевдографическим интерфейсом;
• lindeskx – графическая утилита администрирования;
• обычный программный интерфейс подачи SQL -запросов.

Утилиты spman и lindeskx являются полноценными средами для разработки и отладки хранимых процедур и триггеров.

Они обеспечивают:

1. создание, просмотр, редактирование исходного кода объектов отладки;
2. управление постоянными точками останова (добавление, удаление, запрет, разрешение, определение/ редактирование свойств);
3. запуск на выполнение объекта отладки по команде пользователя или наступлению события;
4. различные режимы работы:
   • выполнение с прерыванием в точках останова;
   • пошаговое выполнение;
   • выполнение до временной точки останова;
   • выполнение до возврата;
   • выполнение с трассировкой.
5. задание и просмотр отладочной информации:
   • просмотр локальных переменных;
   • отслеживаемые переменные и выражения;
   • вычисление выражений;
   • просмотр стека вызовов;
   • ведение протокола отладки.

Средства реального времени

СУБД ЛИНТЕР имеет ряд свойств, позволяющих отнести ее (с некоторыми допущениями) к системам реального времени:

1. возможность выполнения запросов в асинхронном режиме. Результат окончания выполнения асинхронной операции обрабатывается процедурой обработки ответа, которая запускается тогда, когда от ядра СУБД будет получен ответ.
2. возможность обрабатывать запросы в соответствии с установленными для них приоритетами. Более важные (приоритетные) запросы будут выполнены раньше низкоприоритетных, им будут отданы системой все возможные ресурсы и т.п.
3. поддержка аппарата событий, т.е. возможность приложения устанавливать особые ситуации в БД и обеспечивать реакцию на их возникновение. Например, какое-то приложение специальным SQL-запросом устанавливает событие A (допустим, это модификация данных в таблице). Другие приложения могут запросить, чтобы их оповестили о возникновении события A. По возникновению этого события, запросившие его приложения будут прерваны, включатся соответствующие процедуры обработки ответа (на запрос об оповещении). По окончании обработки события (например, после того, как получены изменённые данные), приложение продолжит работу с того места, где оно было прервано.
4. возможность отделения этапа трансляции запроса от этапа его выполнения, т.е. запрос можно один раз оттранслировать, а затем многократно выполнять, наполняя его каждый раз новым константным содержанием (привязка параметров). Это особенно удобно в программах сбора информации. При этом можно сочетать выполнение оттранслированного запроса и асинхронный режим его выполнения, что очень важно в системах управления технологическими процессами (например, при съёме информации с датчиков и занесения их в базу данных).
5. возможность слежения из приложения за состоянием использования ресурсов ядра СУБД, что позволяет написать приложение с супервизорскими функциями. Такое приложение производит слежение за процессами, происходящими в ядре СУБД ЛИНТЕР, и может решить, что обработка какого-то запроса требует слишком много ресурсов, и приостановить или прервать его обработку.

Полнотекстовый поиск

Понятие «полнотекстовый» (или фразовый) поиск подразумевает поиск по полному тексту или по всем текстовым полям документа (БД). Любой текстовый документ, как правило, имеет внутреннюю структуру - деление на параграфы, отступ для заголовка, для подписи, таблицы. Текстовые редакторы позволяют делать эту структуру достаточно сложной - выделять текст шрифтами и вариантами их начертания, делать списки, выравнивание и т.д. и т.п. Кроме того, различные редакторы имеют разные форматы хранения данных (.doc, .html, .rtf, .txt и др.). Некоторые документы (например, в формате .html), помимо средств визуального оформления информации, имеет разметку внутренней структуры - заголовок, тело документа, ключевые слова. Поэтому в задачу полнотекстового поиска входит понимание внутренней структуры и «расшифровка» разных форматов документов с помощью специальных средств - конверторов или фильтров.

СУБД ЛИНТЕР со средствами фразового поиска рекомендуется использовать в проектах, где основными определяющими факторами являются скорость поиска и извлечения текста по фразе в больших хранилищах информации (например, WWW-сервер). Средства фразового поиска дают возможность упростить схему хранения данных в приложении и избежать создания некоторых дополнительных таблиц.

Система фразового поиска обеспечивает:

• варианты поиска слов: по началу, окончанию, подстроке, целому слову, поиск с использованием символов шаблона;
• поиск по словам, набранным с ошибками (нечеткий поиск). Поддерживаются три основных типа ошибок (перестановка, пропуск, замена буквы).

Средства поддержки БД

Тестирование БД

Утилиты testdb и testdbx производят проверку физической целостности структуры БД. Эта проверка может потребоваться, например, после отключения питания оборудования во время выполнения длинной транзакции.

Даже если СУБД не производила никаких действий, все равно рекомендуется производить проверку БД после каждого некорректного завершения работы ядра.

Рекомендуется следующая последовательность действий:

1. сразу же после такого завершения работы ядра создать архив БД средствами ОС;
2. запустить и сразу же остановить работу ядра СУБД с копией БД;
3. запустить testdb в режиме проверки;
4. в случае обнаружения ошибок утилиту testdb необходимо запустить заново в режиме исправления ошибок;
5. потом еще раз в режиме тестирования.

Выгрузка данных

Для сохранения структуры и данных в текстовом формате используется программа dbstore . Причем могут сохраняться не только собственно данные, но и объекты БД (таблицы, пользователи, представления, синонимы и др.). Вы можете указать в командной строке, какой объект требует сохранения, и он будет сохранен в виде sql–файла, который впоследствии можно передать утилите inl для создания этого объекта заново. Данные таблиц сохраняются отдельно в формате lod–файлов для последующей загрузки их в БД посредством утилиты loarel .

Утилита может сохранять в виде набора файлов всю БД – включая ее таблицы, триггеры, последовательности, пользователей и т.п. При этом будут созданы shell–программы для последовательного восстановления сохраненных данных в другую БД.

Утилита migration позволяет сделать те же самые действия, но имеет графический интерфейс. Она совмещает в себе функциональные возможности dbstore и loarel .

Загрузка данных

Утилита loarel может быть использована для загрузки данных, сохраненных в lod–файлах в таблицы БД. Входной файл может быть результатом экспорта данных различных программ (например, MS Access).

Конвертирование данных из формата dbf

Утилита dbf2lin выполняет прямое преобразование данных из формата dbf в ЛИНТЕР .

Резервное копирование и восстановление

Утилита «горячего» архивирования lhb позволяет архивировать БД целиком или отдельные ее объекты, не останавливая работу СУБД. Утилита позволяет также выполнять инкрементное архивирование и архивирование по сценарию, что обеспечивает большую гибкость при работе программы.

Утилита lhbx выполняет точно такие же действия, но имеет графический интерфейс.

Сетевые средства

Сетевые утилиты позволяют работать с БД удаленно с других машин или, соответственно, с серверами на других машинах. Для передачи данных используется протоколы TCPIP, SPX, NetBios.

В состав сетевых утилит входит сетевой сервер dbs_wnt и сетевой клиент dbc_wnt . Сетевой сервер представляет собой программу, которая, будучи запущена на одной машине с ядром СУБД, обеспечивает доступ к указанному ядру СУБД (и, соответственно, к БД этого ядра) через сеть.

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

Для организации работы через сеть необходимо запустить один процесс dbs_wnt на машине, где работает ядро СУБД. На клиентских машинах необходимо запускать процессы сетевых клиентов dbc_wnt . Запуск сервера осуществляется обычно программой linadm посредством указания при запуске БД check-boxа - start network listener. Запуск клиентского драйвера осуществляется из linadm нажатием на иконку Network agent.

Для конфигурации dbc_ent необходимо настроить файл конфигурации nodetab . Он может быть отредактирован в процессе установки или после из утилиты linadm путём выбора пункта «список баз»

Программные интерфейсы

CALL-интерфейс

Это интерфейс самого нижнего уровня для С /C++. В основе всех остальных интерфейсов лежит именно Call-интерфейс. Он имеет самый маленький размер из всех описанных ниже интерфейсов. Он самый быстрый. Но он требует кропотливой работы программиста для заполнения всех необходимых данных. Также разбор ответов программист должен выполнять самостоятельно.

Call-интерфейс можно использовать и из других языков программирования, но для этого придется вызывать его функции в стиле языка C.

В дистрибутиве этот интерфейс поставляется в исходных кодах и в виде уже откомпилированной библиотеки. Это файлы inter.h , intlib.c из каталога intlib. В пользовательских программах необходимо использовать inter.h и inter325.lib для соответствующего компилятора.

Примеры работы с указанным интерфейсом расположены в каталогах samples/c и samples/call.

Для работы с данными типа DECIMALS и DATE используются специальные библиотеки decimals и tick . Они объединены в библиотеку dectic 32. lib . Заголовочные файлы находятся в каталоге intlib.

LinAPI-прикладной интерфейс

Аналогично CALL–интерфейсу интерфейс LinAPI предназначен для использования его в программах на языках программирования C (C++). В отличие от CALL–интерфейса каждое действие с БД или ответами выполняется отдельной функцией. Разделены понятия соединения и курсора. Введено понятие statement (оператор) как некой внутренней структуры, позволяющей выполнять претранслированные запросы и хранящей в себе информацию о претранслированном запросе.

Примеры программ с использованием LinAPI интерфейса можно найти в каталоге samples/linapi.

Сама библиотека находится в каталоге intlib. Это файлы linapi.h (заголовочный) и lapi325.lib (для соответствующего компилятора).

Встроенный SQL ( C / C ++)

Встроенный SQL предназначен для объединения возможностей языка программирования высокого уровня С/C++ с возможностями языка баз данных SQL СУБД ЛИНТЕР. Он позволяет выполнять любой Sql-оператор из прикладной программы. Для этого Sql-операторы непосредственно встраиваются в текст программы на C/C++ в соответствии с синтаксическими правилами встроенного языка. В результате получение исполняемого кода программы распадается на следующие этапы:

1. Прекомпиляция с использованием прекомпилятора (препроцессора), входящего в состав СУБД ЛИНТЕР, исходного текста программы (отдельного модуля), содержащего конструкции встроенного SQL. Прекомпилятор заменяет конструкции встроенного SQL либо операторами языка С/C++, либо вызовами соответствующих функций библиотеки прекомпиляторного интерфейса. Результатом прекомпиляции является исходный текст программы, содержащей только конструкции языка C/C++.
2. Компилирование полученного текста программы (модуля) стандартным С/C++-компилятором, результатом чего будет объектный код программы (модуля). Если программа (модуль) не содержит конструкции встроенного SQL, то они компилируются только компилятором C/C++.
3. Компоновка всех объектных модулей программы совместно с библиотекой встроенного SQL (поставляемой в дистрибутиве СУБД ЛИНТЕР) и системными библиотеками. Результатом будет исполняемый код программы.
4. При компоновке программы используется библиотека pci.lib из каталога intlib.
5. Примеры программ и makefile можно посмотреть в каталоге samples/pcc.

ODBC – интерфейс

Данный интерфейс реализует спецификацию 3.51 интерфейса Microsoft ODBC.

В составе ЛИНТЕР поставляется 2 ODBC драйвера – lindbbc.dll и linodbcw.dll – соответственно, ANSI- и UNICODE-драйверы. По умолчанию они устанавливаются в системе под именами Linter 5.9 и Linter 5.9 Unicode (для версии 5.9) соответственно.

Если при попытке соединения с сервером вы получили ошибку 25024 или 2202 при обращении к функциям каталога, то БД не была подготовлена для использования ODBC интерфейса (отсутствует соответствующий словарь). Для возможности работы вы должны выполнить запросы из файла dict/catalog.sql.

Для этого лучше всего воспользоваться утилитой inl :

inl –u SYSTEM/MANAGER -f dict/catalog.sql 

JDBC – интерфейс

В дистрибутиве ЛИНТЕР поставляется 3 драйвера JDBC – JDBC спецификаций 1,2 и 3. Кроме того, поставляются классы JNDI для JDBC 2 и 3.

Для работы с ЛИНТЕР из Java-программ необходимо, во-первых, запустить jdbc-драйвер для БД, с которой нужно работать из JAVA–программы.

Для этого необходимо запустить ядро СУБД и программу linapid . По умолчанию эта программа обслуживает запросы по порту 1070. Данная программа запускается программой linadm (нажатием на иконку JDBC-listener)

Для того чтобы включить возможность доступа к ЛИНТЕР из Java– программы, необходимо включить в переменную среды CLASSPATH клиентскую часть JDBC–драйвера LinJdbc.jar (для JDBC 1), расположенную в каталоге classes дистрибутива ЛИНТЕР. Например :

CLASSPATH=%CLASSPATH%;c:/linter/classes/LinJDBC.jar 

Примеры использования jdbc расположены в каталоге linter/samples/jdbc.

Для использования драйвера доступа к ЛИНТЕР в JAVA-программе необходимо задать драйвер "jdbc.LinJdbc.LinterDriver", а для подключения к серверу необходимо указывать строку соединения "jdbc:Linter:localhost:1070:local", где localhost - IP адрес машины, где запущен сервер linapid, 1070 – порт.

Для использования драйверов JDBC 2 и 3 необходимо использовать linjdbc-1.2.jar и linjdbc-1.4.jar

Имя драйвера для них - com.relx.jdbc.LinterDriver, формат строки соединения – "jdbc:linter:linapid:::” – назначения полей совпадают с полями для драйвера спецификации 1.

Perl интерфейсы

В состав СУБД ЛИНТЕР входят два интерфейса для Perl. Один из них оригинальный, второй является драйвером для стандартного средства доступа к БД DBI.

Обычно модуль интерфейса от Perl к СУБД ЛИНТЕР поставляется в дистрибутиве в готовом к использованию, откомпилированном виде. Это два файла LinPerl.dll и LinPerl.pm в каталоге intlib/perl.

Использовать этот модуль возможно двумя способами:

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

PERL5LIB=%PERL5LIB%;c:/linter/intlib/perl

2. скопировать файлы LinPerl.dll и LinPerl.pm в один из каталогов поиска библиотек perl.

Перед использованием любых функций обращения к Linter в свою Perl-программу вы должны добавить строку:

use LinPerl; 

Получить информацию о синтаксисе и наименованиях функций можно с помощью команды

perldoc LinPerl 

В составе дистрибутива в каталоге samples/perl размещены примеры использования интерфейса ЛИНТЕР к Perl.

Если у Вас есть необходимость пересобрать интерфейс ЛИНТЕР к Perl, то необходимо запустить программу–конфигуратор configure. Программа определит наличие Perl и необходимых заголовочных файлов в системе. После этого надо перейти в каталог linter/perl и подать команду make.

Интерфейс DBI поставляется как в виде готового модуля, так и с возможностью пересборки. Он представляет собой файлы Linter.dll в каталоге intlib/perl и Linter.pm в каталоге intlib/perl/DBD.

В каталоге samples/dbi содержатся примеры использования.

Конфигурирование переменной PERL5LIB выполняется аналогично с первым интерфейсом, только при копировании модулей необходимо учитывать, что Linter.pm должен копироваться в каталог драйверов DBI.

PHP - интерфейс

Прежде всего, необходимо отметить, что в настоящее время существует как минимум три несовместимых по внутренним интерфейсам версии PHP. Это старая версия 3, и более поздние 4 и 5 версии. Мало того, в четвертой и пятой версии PHP любое расширение (extension) языка, а именно им является интерфейс ЛИНТЕР, должно быть пересобрано под конкретную версию сборки языка.

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

На машине должен быть установлен PHP или в виде исполняемого файла или в виде модулей web-сервера Apache или IIS.

Скомпилированные интерфейсы находятся в каталоге intlib/php дистрибутива ЛИНТЕР и размещены по отдельным каталогам для различных версий.

В каталоге linter/samples/php содержатся примеры использования интерфейса PHP к ЛИНТЕР.

DBExpress интерфейс

DBExpress интерфейс реализован в виде разделяемой библиотеки lindbex.dll, расположенной в каталоге bin дистрибутива. Он предназначен для использования стандартных классов в среде Delphi и С++.

Для корректного функционирования драйвера, БД должна содержать ODBC-каталог (см. описание catalog.sql в разделе ODBC-драйвер).

Для использования драйвера в программе достаточно создать стандартный объект TSQLConnection и прописать у него в свойствах LibraryName и VendorLib полный путь к драйверу lindbex.dll.

Tcl/Tk интерфейс

Интерфейс представляет собой исполняемый модуль интерпретатора Tcl со встроенным интерфейсом доступа к ЛИНТЕР под названием linsh (для Tk он называется linwish ) расположенный в каталоге bin. Они (и компоненты для их сборки) поставляются отдельно по запросу пользователя.

Python интерфейс

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

import LinPy