Технология Клиент-Сервер 2000'4
	Home Поиск Издания Контакты k-press.ru

Продолжается подписка на наши издания! Вы не забыли подписаться?

СДЕЛАНО В РОССИИ

В 1980 году в Советском Союзе было принято решение о разработке отечественной системы управления базами данных. К 1983 году в Воронежском СКТБ “Системпрограмм” в рамках государственного заказа был разработан и успешно завершен проект реляционной СУБД БАРС под управлением операционной системы реального времени РАФОС (прототип RT-11) для машин семейства СМ ЭВМ. Таким образом, датой рождения первой отечественной реляционной СУБД можно считать именно 1983 год.

С 1985 года разработчиками системы была принята концепция мобильности, совместимости и открытости, результатом реализации которой стало к 1990 году создание семейства совместимых СУБД для большинства используемых в то время вычислительных платформ. Данная система была представлена под названием СУБД ИНТЕРЕАЛ и охватывала широкий спектр программно-аппаратных платформ: от ЭВМ Электроника-85 и управляющих модулей на базе Intel 8086 до вычислительных комплексов на базе СМ1702, Электроника 82, и их прототипов семейства VAX.

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

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

Примечательной особенностью системы является разработка комплекса средств защиты СУБД ЛИНТЕР и сертификация в 1997 году Гостехкомиссией России ее соответствия на 2-ой класс по показателям защищенности от несанкционированного доступа к информации. Эта возможность реализована для операционных систем Windows NT, Unix и NetWare. Необходимо отметить, что на данный момент столь высокий уровень защиты информации не обеспечивает ни одна из СУБД.

Современные направления развития технологий ЛИНТЕР находятся в полном соответствии с актуальными задачами профессиональных СУБД. В их числе: развитие языков доступа к данным, технологий хранения данных, реализация объектно-реляционных технологий баз данных, поддержка распределенных БД, реализация концепций информационных систем, ориентированных на анализ данных, обеспечение защиты данных в условиях распределенной обработки. Одной из ключевых задач является обеспечение надежной работы СУБД в режиме «24часа х 365дней».

ЛИНТЕР - реляционная система управления базами данных. В соответствии с моделью хранения, данные логически представлены в виде двумерных таблиц, что обеспечивает высокую степень независимости пользовательских программ от физического представления данных.

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

СУБД ЛИНТЕР позволяет выполнять следующие действия:

• использовать полный набор возможностей стандартного языка SQL (American National Standard X3.135–1992, коротко ANSI SQL 92), а также расширения возможностей стандарта;
• удалять/изменять/добавлять объекты базы (данные, индексы, таблицы, хранимые процедуры, триггеры);
• вводить/изменять/удалять ограничения целостности данных;
• блокировать/деблокировать доступ к таблице/записи;
• сохранять/восстанавливать базу данных целиком или некоторые её объекты выборочно, устанавливать расписание и систему сохранения;
• транслировать запросы (с параметрами и без) и использовать уже оттранслированные запросы для ускорения работы приложения;
• работать с большими (до 2-ух гигабайт) байтовыми объектами (BLOB);
• осуществлять импорт и экспорт наиболее популярных форматов хранения данных;
• использовать (в приложениях и хранимых процедурах) различные режимы обработки транзакций;
• создавать и использовать гибкую и надежную систему безопасности и секретности информации;
• создавать, отлаживать и запускать хранимые процедуры и триггеры;
• использовать возможности реального времени (приоритеты выполнения транзакций, асинхронное выполнение запросов, отслеживание процессов, проходящих в системе, приостанов и полное прерывание работы указанной транзакции и пр.).

Последние два пункта особенно важны при подготовке многозадачной прикладной системы и дают возможность пользователю настроить ЛИНТЕР на конкретные приложения и максимально ускорить работу системы.

Итак, СУБД ЛИНТЕР – открытая многопользовательская реляционная система, использующая для доступа к данным язык запросов SQL. Число таблиц в базе данных может находиться в промежутке между 1 и 65535. Каждая таблица может содержать 250 столбцов и 1.000.000.000 строк. Максимальная длина строки 4.000 байт. Количество ключей в таблице ограничено только количеством столбцов. Максимальная длина ключа – 1024 байта. Минимальный уровень блокирования данных – запись. Максимальное число таблиц в запросе (на одном уровне) – 32.

В СУБД ЛИНТЕР реализовано два вида индексов: B*-дерево и словный индекс. Данные и индексы таблицы хранятся в сжатом виде, кроме того, есть эффективный механизм переиспользования табличного пространства.

Система поддерживает четыре режима обработки транзакций: Optimistic, Pessimistic, Autocommit, Read-only.

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

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

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

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

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

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

ЛИНТЕР работает на многих программно-аппаратных платформах: UNIX SYSTEM V, SINIX, Digital UNIX, UNIXWare, USIX, FreeBSD, Linux, OS/9000, OS-9, QNX, Novell NetWare, VAX/VMS, OpenVMS, MS DOS, MS WINDOWS 3.xx/9x, MS WINDOWS NT, OS/2, SUN Solaris (SUN SPARC, INTEL), AIX (RS/6000), IRIX (SGI), причем, практически на всех платформах базовый вариант СУБД работает внешне одинаково. Кроме инвариантности интерфейса относительно поддерживаемых операционных систем, ЛИНТЕР мобилен также и по программному интерфейсу. Это означает, что при переносе прикладной информационной системы на другую платформу не возникает проблем, связанных с программными интерфейсами.

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

Почти все процессы, участвующие в обработке запросов на сервере (собственно ядро ЛИНТЕР, SQL-транслятор, транслятор хранимых процедур, сортировка, сетевой драйвер сервера) настраиваются на использование дополнительной памяти. Использование дополнительной памяти этими компонентами серьёзно увеличивает эффективность работы системы.

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

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

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

Основным понятием концепции является сетевое или логическое ЛИНТЕР-имя, которое представляет собой восьмисимвольный идентификатор, хранящийся в специальном файле ЛИНТЕР-имен - nodetab. В этом файле ЛИНТЕР-имена связаны с сетевыми параметрами узла запуска ядра ЛИНТЕР.

Кроме того, ЛИНТЕР-имя однозначно определяет в текущей операционной среде базу данных, для которой будет запущено независимое ядро СУБД ЛИНТЕР. Части выполняемого запроса, которые необходимо выполнить именно в данной базе будут переправляться по указанному в nodetab адресу с использованием ЛИНТЕР-имени.

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

В SERVERS хранится имя, по которому работает СУБД внутри и которое будет передано вовне для определения, на какой из удалённых серверов нужно пересылать запрос за недостающими данными. В SERVERS не хранится связь имени с сетевой конфигурацией. Таким образом, при изменениях конфигурации (через файл nodetab) трансляция имен внутри базы данных останется неизменной.

Создание/удаление узла распределённой базы данных производится специальным SQL-запросом CREATE/DROP NODE.

Теперь о технологии распределённости в СУБД ЛИНТЕР.

Главная компонента аппарата распределённости - loltp - процесс, который работает с удаленным сервером. Он принимает запрос от локального ядра во внутреннем формате и формирует из него SQL-запрос к удалённому серверу. Соответственно, при этом используется сетевой клиентский драйвер.

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

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

Итак, ЛИНТЕР при исправлении неполных/неверных данных может либо вернуть их в то состояние, в котором они находились до изменений (откат изменений), либо продолжить модификацию данных следуя журналу транзакций (прокрутка вперёд).

В СУБД ЛИНТЕР каждое приложение может использовать расширение протокола обработки плоских транзакций - промежуточные точки синхронизации транзакции savepoint. Установка промежуточной точки синхронизации реализуется предложением set savepoint <name>. Все savepoint являются именованными. Все savepoint одной транзакции упорядочены во времени, каждая из этих точек отмечается в журнале транзакций.

Приложение пользователя посредством savepoint может более тонко обработать ситуации отклонения работы транзакции от предполагаемого и откатить только часть работы транзакции, породившую отклонение, а не транзакцию целиком. Это позволяет избегать потери производительности системы при обработке отклонений работы транзакций. Соответственно приложение пользователя также может инициировать промежуточную фиксацию важных для него частей транзакции. Данные операции реализуются предложениями:

rollback to savepoint <savepoint name>
commit to savepoint <savepoint name>

Операция «commit to savepoint» снимает все промежуточные точки синхронизации, начиная от начала текущей транзакции до данной savepoint, и фиксирует работу транзакции от ее начала до данной точки. Операция «rollback to savepoint» снимает промежуточные точки синхронизации, начиная от данной savepoint, и откатывает все операции, которые были выполнены после операции установки savepoint.

Иерархия транзакций в СУБД ЛИНТЕР

В СУБД ЛИНТЕР каждое приложение может использовать как обычные плоские транзакции, так и иерархические.

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

Классические плоские транзакции представляют собой последовательность запросов, завершающуюся оператором фиксации/отката (Commit/Rollback), никаких других вариантов в них не предусмотрено. Несомненно, это слишком категоричный и, следовательно, не всегда приемлемый принцип. Особенно в системах с нечёткой логикой.

Например, приложению нужно произвести три действия A, B и D в одной транзакции. Причём действия A и D являются необходимыми, а вот для действия B есть «запасной вариант» - действие C. Так что приложение пытается в первую очередь выполнить действие B, и только если по какой-либо причине результаты отработки B «не устраивают» или возникла ошибка, то изменения, сделанные B, откатываются, и приложение предпринимает резервное действие C.

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

При этом действуют следующие правила:

1. Подчинённые (вложенные) транзакции являются плоскими транзакциями или плоскими транзакциями с savepoint. И могут работать зависимо или независимо друг от друга в любом из режимов (от оптимистичного до read-only).
2. Каждая из подчинённых транзакций может быть фиксирована/откачена независимо от других подчинённых транзакций.
3. Подчинённые транзакции «видят» изменения, сделанные прочими подчинёнными транзакциями (имеющими общего предка). Полностью изолированы только транзакции различных иерархий.
4. Фиксация/откат головной транзакции приведёт к фиксации/откату всех подчинённых и не завершённых (на данный момент) транзакций.

В ЛИНТЕР реализовано несколько возможностей, которые позволяют отнести его к системам реального времени.

Во-первых, это возможность подачи запросов в асинхронном режиме. Отметим, что имеется в виду полнокровная асинхронность с определением процедуры обработки ответа, которая включится только тогда, когда программа будет прервана пришедшим от ЛИНТЕР ответом на запрос.

Во-вторых, ЛИНТЕР может обрабатывать запросы в соответствии с установленными для них приоритетами. Более важные (приоритетные) будут выполнены раньше низкоприоритетных, им будут отданы системой все возможные ресурсы.

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

В-четвёртых, возможность отделения этапа трансляции запроса от этапа его выполнения, т.е. запрос можно один раз оттранслировать, а затем многократно выполнять, изменяя при этом только параметры запроса.

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

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

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

• подсистема управления доступом к информации,
• подсистема поддержания высокой готовности информации.

В СУБД ЛИНТЕР реализован ряд методов управления доступом к информации:

Авторизация пользователей производится при установлении соединения с системой. Проверке подлежит регистрационное имя пользователя и его пароль. Если процесс авторизации пользователя прошел успешно, то все дальнейшие запросы к СУБД по установленному соединению однозначно связываются с данным пользователем.

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

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

Таких привилегий (категорий пользователей) три:

Администратор базы данных – категория DBA. Это управляющий созданием БД, ее конфигурированием, регистрацией пользователей, групп, ролей, записью регистрационной информации и т.п.

Привилегированные пользователи БД – категория RESOURCE. Это пользователи, которые имеют право на создание собственных объектов БД и управление привилегиями доступа к ним.

Пользователи БД – категория CONNECT оперируют с объектами БД в рамках выделенных им привилегий доступа.

• SELECT - на выборку данных,
• INSERT - на добавление данных,
• DELETE - на удаление данных,
• UPDATE - на обновление данных,
• ALTER - на изменение параметров таблицы,
• INDEX - на создание/удаление индексов,
• ALL - включает все вышеперечисленные права доступа.

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

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

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

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

Метки доступа могут быть назначены всем субъектам базы и объектам: начиная от таблиц и до полей записей включительно.

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

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

Контроль доступа с удаленных станций или сопоставление пользователя с устройством позволит учитывать различный уровень защищенности самих клиентских станций. При правильной политике безопасности ЛИНТЕР не допустит использование канала связи, в котором ценная информация может быть получена пользователем, не обладающим соответствующими правами доступа.

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

Протоколирование работы или система слежения ЛИНТЕР применяется для контроля функционирования подсистемы защиты, обнаружения попыток несанкционированного доступа, исправления их последствий и предотвращения их в будущем.

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

Контроль за хранением информации со стороны СУБД ЛИНТЕР позволяет учитывать различный уровень защищенности внешних устройств постоянного хранения информации для размещения таблиц данных и временных рабочих файлов.

Доступ к устройству в ЛИНТЕР может быть разрешен/запрещен различным группам пользователей. Кроме того, устройству назначается метка доступа, характеризующая его уровень защищенности и ограничивающая степень секретности содержащейся на нем информации.

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

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

Тот факт, что язык запросов SQL ЛИНТЕР основан на международном стандарте, говорит о высокой совместимости системы. Кроме того, в SQL ЛИНТЕР введены многие элементы, обеспечивающие совместимость с другими системами, главным образом с СУБД Oracle.

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

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

При этом реализованы следующие типы драйверов

• Pure Java client - клиент полностью написан на Java. Налицо преимущества этого типа - реализация классов на Java позволяет получить набор реализующих классов и использовать их в клиентском апплете. К недостаткам этого типа можно отнести невысокую производительность из-за медлительности java.net.*.
• Native-Java client - кроме классов, реализующих интерфейс JDBC, для работы необходимо иметь динамически подключаемую библиотеку трансляции вызовов к СУБД ЛИНТЕР. К недостаткам этого типа можно отнести необходимость инсталляции этой библиотеки, зато это даст существенный выигрыш в скорости (в 3-5 раз по сравнению с использованием драйвера типа Pure Java client).

Основные сетевые протоколы, поддерживаемые системой: TCP/IP, IPX/SPX, DECNet.

Имеются средства конвертации данных из DBF-формата, имеются программные интерфейсы для работы с ЛИНТЕР из Clipper, FoxPro.

Отметим так же совместимость ЛИНТЕР с СУБД Oracle на уровне Pro*C и OCI. Благодаря библиотеке OraLin, приложение, работающее с СУБД Oracle, будет с таким же успехом работать (после перекомпоновки, а в Windows, в случае использования динамически подгружаемых библиотек, и без неё) и с ЛИНТЕР, совершенно не заметив подмены. Таким образом, благодаря этому, для многочисленных пользователей Oracle переход к использованию СУБД ЛИНТЕР не составит большого труда.

Имеется также средство - LinTcl, которое расширяет возможности Tcl/Tk (Tcl - Tool Command Language, Tk -Tool kit) для работы с СУБД ЛИНТЕР, что позволяет использовать Tcl/Tk для быстрого написания информационных приложений в операционных средах, в которых работает Tcl/Tk (Unix, Windows NT/95/98).

Язык Intcom предназначен для создания прикладных информационных систем и ориентирован на прикладного программиста. Являясь 4GL, Intcom содержит средства для организации экранного интерфейса (ориентация на стандарт CUA - Common User Access) и доступа к базам данных ЛИНТЕР
(на основе стандарта ANSI/ISO SQL-92).

Intcom, как и система ЛИНТЕР, мобильный язык. Программа, разработанная на нем, будет одинаково работать на любой платформе, где функционирует ЛИНТЕР.

Инструментальное средство ЛАКУНА предназначено для быстрой разработки приложений типа клиент-сервер, ориентированных на обработку данных с использованием СУБД ЛИНТЕР. Разработка приложений средствами ЛАКУНЫ выполняется в интерактивном режиме с хранением кода в служебных таблицах базы. В окончательном виде приложение представляет собой набор структур данных (документов) и правил (процедур) их обработки.

Проектирование приложений существенно упрощается за счет следующих отличительных особенностей инструментального средства ЛАКУНА:

• удобной интерактивной системой создания форм;
• использованием 4GL-языка VisualScript;
• встроенными возможностями обработки стандартных действий пользователя (удаление, добавление, обновление, печать данных);
• мощной справочной системой, в подавляющем большинстве случаев не требующей от разработчика написания дополнительного кода;
• универсальным генератором отчетов и другими возможностями ИС.

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

Для совместимости ЛАКУНЫ с приложениями, спроектированными вне ее, имеется возможность построения структуры документов по готовым таблицам базы данных.

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

Часто используемые элементы алгоритмов могут оформляться в виде хранимых процедур с передаваемыми параметрами. Доступ к таким процедурам возможен из любого приложения, работающего с базой данных, в которой эти процедуры хранятся. Обращение к процедурам допустимо из любого места ЛАКУНЫ, где разрешено использование вычисляемых выражений (формул). Именно благодаря возможности написания и хранения пользовательских алгоритмов обработки событий и процедур, дополняющих и расширяющих стандартные операции ЛАКУНЫ, разработка каждого следующего приложения может выполняться более эффективно.

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

Система ЛАКУНА обеспечивает разграничение доступа к различным элементам приложения и таблицам базы данных при помощи присвоения каждому пользователю имени и соответствующих прав доступа.

ЛАКУНА состоит из двух основных систем: системы разработки приложений и системы исполнения приложений (среда run-time).

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

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

Как в системе разработки, так и в системе исполнения приложений имеются два вида подсказки для пользователя: статусные строки и контекстная помощь. Они предопределены для ЛАКУНЫ, однако разработчик приложения может настраивать статусные строки и систему контекстной помощи с помощью специальных функций.

Copyright © 1994-2016 ООО "К-Пресс"