Ййй

Заглавная страница

Клиентский API БД СКП

Содержание

Введение
Этот документ описывает модель данных БД СКП, на которой основывается ПО верхнего уровня. Физическая реализация БД СКП (таблицы) инкапсулируется. БД СКП предоставляет API в виде набора хранимых процедур и некоторых других конструкций. ПО верхнего уровня работает только с этим API. Такая архитектура реализует естественную декомпозицию задачи, повышает взаимную независимость процессов разработки БД СКП и ПО верхнего уровня, и гарантирует создание прозрачного и хорошо документированного интерфейса взаимодействия этих подсистем. Кроме того, наличие такого уровня абстрактной модели БД СКП является требованием ТЗ.

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

Атрибуты
Атрибуты – это данные, относящиеся ко всей ЕП в целом. Обычно атрибуты скалярны, т.е. на одну ЕП определено только одно значение атрибута. Но возможны ситуации, когда атрибуты имеют размерность больше 1, причем длина вектора зависит от истории конкретной ЕП и от формулировки информационного запроса. Например, средняя температура смотки г/к рулона – это скаляр для г/к рулона и вектор из 2 элементов для полуторного х/к рулона (поскольку полуторный х/к рулон образуется из 2 г/к рулонов). В технологии КП существуют циклы (плавка проходит одни и те же агрегаты многократно). Известны нормативы, определяющие маршрут, но на практике часто требуется отступление от этих нормативов. Это приводит к тому, что размерность таких атрибутов, как расход газа на продувку конвертера, определяется историей конкретной плавки, т.е. уникальна для каждой ЕП.

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

Сигналы
Сигналы – это данные, привязанные не только к ЕП, но и ко времени и металлургической длине. В процессе сбора для каждого значения сигнала фиксируется время оцифровки этого значения. Затем значения сигналов привязываются к ЕП и металлургической длине. Эта нетривиальная задача выполняется на уровне АСУТП и других систем нижних уровней. Поэтому не исключены ошибки и отсутствие этой привязки. ПО верхнего уровня исходит из предположения, что время сбора каждого значения сигнала известно всегда, а привязка значений к ЕП и металлургической длине может отсутствовать.

Для конкретной ЕП из базы можно получить вектор значений произвольной размерности. Примеры: температура конца прокатки, скорость вращения нижнего рабочего валка в черновой клети №2.

В некоторых ситуациях сигнал рассматривается как последовательность пар аргумент-значение. Но в общем случае значения аргумента представляют собой самостоятельный сигнал (например, металлургическая длина в ЛПЦ-2), а значения собираемых сигналов, таких как «температура конца прокатки», привязываются к значениям металлургической длины.

Статистики
Статистики – это особый вид атрибутов. Они представляют собой вторичные данные, рассчитанные по первичным (собранным) атрибутам и сигналам, а также по другим статистикам. Перечень статистик, а также формулу расчета каждой из них определяют пользователи системы через соответствующий WEB-интерфейс. Формула может включать произвольные арифметические выражения и вызов предопределенных агрегирующий функций, таких как среднее, максимум, сумма, последнее значение и т.п. Статистики – сигналы не определяются. Однако, по причинам, описанным выше, размерность статистики – атрибута для конкретной ЕП может превышать 1.

Значения статистик могут храниться в БД, а могут вычисляться «на лету», причем оба подхода могут использоваться одновременно. Детали реализации скрыты в БД, вычисление и извлечение значений статистик происходит прозрачно для пользователей в рамках описываемого API. Клиентское ПО исходит из предположения о том, что запросы к статистикам кэшируются, т.е. при многократном запросе значения одной и той же статистики для одной и той же ЕП второй и последующие запросы выполняются быстро.

Статистики очень тесно связаны с запросами. Поэтому дальнейшее описание статистик приведено после описания запросов.

Синтетики
Синтетики (синтетические параметры) – это особый вид атрибутов. Они, также как и статистики, являются вторичными данными, но, в отличие от статистик, жестко определены на уровне БД. Ни пользователи, ни администраторы не имеют доступа к алгоритмам вычисления синтетических параметров. Эти алгоритмы определяются разработчиками.

Деревья параметров
Параметры отображаются пользователям в виде деревьев. Существует 2 вида деревьев: каталоги и ПСД. В каталогах на всех промежуточных уровнях содержатся некоторые произвольные группы параметров и сами параметры, а листьями являются только параметры. Уместен аналог с файловой системой (папки – это группы параметров, а файлы – параметры). Пример группы – «параметры черновой группы клетей ЛПЦ-2». В ПСД и корнем, и промежуточными вершинами, и листьями являются параметры, связанные моделируемым причинно-следственным отношением.

Все деревья параметров создаются и модифицируются в конструкторе деревьев администратором системы и пользователями, наделенными соответствующими полномочиями. Исключением из этого правила является полное дерево параметров, которое является каталогом, формируется автоматически и содержит 2 уровня: цех и тип агрегата. На третьем уровне (в качестве листьев) располагаются все параметры, собираемые на данном типе агрегатов. Например, все параметры УНРС1-5 располагаются в поддереве «КП / УНРС» полного дерева. Место статистик в полном дереве определяется местом ключевого параметра запроса, который используется для вычисления данной статистики. Поскольку для каждого параметра известно, на каком типе агрегатов он собирается, для реализации этого механизма распределения достаточно задать линейный порядок для всех типов агрегатов. Последний возникает естественным образом в редакторе справочника типов агрегатов и соответствует логике производства.

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

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

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

Результатом запроса является выборка (таблица). Выборки могут как храниться, так и формироваться «на лету» - в рамках описываемого API это происходит прозрачно для клиентов. Клиентское ПО исходит из предположения о том, что выборки кэшируются, т.е. при многократном исполнении одного и того же запроса вторая и последующие итерации выполняются быстро.

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


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

Рассмотрим это более подробно.

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

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

И наконец, значения выражения можно экспортировать из запроса. Этим путем в системе создаются статистики – глобальные атрибуты ЕП. При экспорте пользователь должен указать ряд свойств создаваемой статистики, таких как название, единица измерения и т.п. Некоторые свойства новой статистики определяются системой автоматически. Это относится, прежде всего, к переделу, на котором «собирается» параметр: он соответствует ключевому параметру запроса. Когда какой-либо субъект запрашивает значение статистики для некоторой ЕП, БД выполняет порождающий эту статистику запрос для этой ЕП (т.е. формирует одну строку выборки) и возвращает вычисленное значение выражения. Подробнее этот вопрос описан ниже.

Ограничения задаются в виде набора условий на значения параметров или выражений. ЕП попадает в выборку только при соблюдении всех условий. Пользователь выбирает параметр/выражение и задает сами ограничения в виде простых отношений типа (X > 20.02.08). В каждом таком отношении фигурирует значение параметра/выражения (X), условие (из предопределенного набора) и константа соответствующего типа. На один параметр/выражение можно наложить несколько ограничений. Они объединяются по И. Более сложные условия создаются при помощи дополнительных выражений или статистик (см. ниже).

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

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

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

Для каждой ЕП, удовлетворяющей условиям отбора, имеется мультимножество значений ключевого параметра (множество с повторяющимися элементами). Объединение этих мультимножеств для всех ЕП выборки порождает множество строк результирующей таблицы. Фактически, когда ключевой параметр является атрибутом ЕП, упомянутые мультимножества всегда имеют только 1 элемент. Но если ключевой параметр является сигналом (а также атрибутом процесса или события, многократно повторявшегося для данной ЕП), имеет место общий случай, описанный выше.

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

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

Приведем несколько примеров.

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

2. Другой пример – расход газа на продувку конвертера для конкретной плавки. Поскольку продувок несколько, ключевым параметром указывается расход газа (атрибут), а дополнительным – время продувки. Ограничением выступает номер плавки.

3. Для формирования выборки суммарного веса дефектов по плавкам за период следует сделать ключевым параметром номер плавки, включить в выборку вес дефектов (это атрибут х/к рулона), выбрать для него агрегирующую функцию «сумма» и задать два ограничения на дату/время выплавки.

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

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

Допустим, требуется построить выборку плавок марки 08Ю, для которых в ПХЛ были обнаружены дефекты КП. Ключевой параметр – номер плавки. Условия отбора:

1. Марка стали (атрибут плавки) = 08Ю

2. Виновник дефекта (атрибут х/к рулона) = КП

Эти условия объединяются по И. Но для каждой плавки существует несколько х/к рулонов, для каждого из которых может быть зафиксировано несколько дефектов с различным виновником. В выборку будут включены только те плавки марки 08Ю, для которых существуют х/к рулоны, для которых существуют дефекты с виновником КП.

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

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

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

Допустим, требуется усложнить предыдущий пример и отобразить только те плавки 08Ю, для которых в ПХЛ обнаружено значительное количество дефектов КП. Один из возможных путей:

1. Создать статистику – атрибут х/к рулона «Много дефектов КП», определяемую выражением (Виновник дефекта = КП) И (Вес дефекта > 5).

2. Основной запрос сформулировать следующим образом:


 * Марка стали (атрибут плавки) = 08Ю
 * Много дефектов КП (атрибут х/к рулона) = 1.

В выборку попадут только те плавки 08Ю, из которых сделаны г/к рулоны, из которых сделаны х/к рулоны, для которых выполняется выражение (Виновник дефекта = КП) И (Вес дефекта > 5).

Если ключевым параметром запроса является сигнал, строки выборки соответствуют значениям этого сигнала. При этом в запрос могут быть безболезненно добавлены также сигнал «время сбора» основного сигнала и сигнал «металлургическая длина», привязанный к основному сигналу. Но как только в этом запросе появляется еще один независимый сигнал, строки таблицы теряют смысловую целостность. Отдельные значения независимых сигналов могут быть связаны между собой только через время и металлургическую длину.

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

Но возможен и другой вариант. Создается один запрос с ключевым параметром «металлургическая длина». В качестве дополнительных параметров в него добавляются температура конца прокатки и величина обжатия. Т.к. дискретизация этих кривых абсолютно независима друг от друга, для каждого значения металлургической длины потребуется вычислять значение либо обжатия, либо температуры. Эта задача решается любым методом аппроксимации. Сами значения металлургической длины требуют в этом случае перерасчета (масштабирования).

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

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


 * диапазона времени;
 * идентификатора ЕП;
 * заданного количества строк с заданного момента времени;

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

Время в дополнительных ограничениях привязывается к тому типу агрегатов, на котором собирается ключевой параметр. Т.е. если выполняется запрос на слябы, удовлетворяющие определенным критериям, диапазон времени запроса задается во времени по УНРС.

В качестве средства визуализации произвольных отчетов предполагается использовать Crystal Reports. При этом необходимо, чтобы он взаимодействовал с БД через тот же клиентский API. Фактически, это означает, что вместо встроенного средства создания выборок Crystal Reports требуется использовать конструктор запросов, описываемый в данном пункте.

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

1. На момент создания нового отчета Crystal Reports в базе должен существовать запрос, который будет источником данных для этого отчета. Для каждого запроса БД автоматически создает в некоторой схеме выборку из 10 строк на момент создания запроса. Эта таблица выбирается в пользовательском интерфейсе Crystal Reports и служит прообразом всех будущих выборок. С одной стороны, она содержит реальные данные, поэтому на ее основе удобно создавать требуемое оформление. С другой стороны, она содержит гарантированно небольшую порцию данных, поэтому нагрузка на БД по ее созданию и хранению минимальна.

2. Когда отчет Crystal Reports создан и сохранен в серверной папке, пользователи начинают просматривать его. Просмотр возможен только через WEB-интерфейс системы. На странице просмотра отчета имеются элементы управления, задающие диапазон дат или конечную дату и размер выборки. Перед отображением отчета серверный сценарий страницы обращается к БД за выборкой, сохраняет ее целиком в локальном объекте, заменяет источник данных отчета на локальный экземпляр выборки и подключает отчет к WEB-элементу визуализации. Таким образом, при отображении отчета БД однократно формирует требуемую выборку, данные копируются на сервер приложений во временный объект и существуют там до тех пор, пока идет их визуализация.

Имя таблицы-прообраза совпадает с псевдонимом запроса (alias). Оно формируется по имени папки, в которой сохранен запрос и введенному пользователем имени запроса путем перевода всех знаков кириллицы в нижний регистр и замены всех пробелов и знаков пунктуации символами подчеркивания (эти преобразования обусловлены техническими ограничениями Crystal Reports XI).

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

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

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

Также из табличного представления предусматривается удобный переход к графической форме:


 * пользователь отмечает параметры, которые необходимо отобразить на вертикальных осях графика (для каждого из них создается собственная вертикальная ось);
 * затем пользователь отмечает параметры, по которым необходимо сформировать подписи к горизонтальной оси (для каждого из них создается собственный график).

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

1. Список параметров. Для каждого указаны:


 * агрегирующая функция;
 * включен ли он в выборку;
 * ограничение (опционально).

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

2. Список локальных статистик. Для каждой указаны:


 * выражение;
 * включена ли она в выборку;
 * название столбца в выборке (если включена);
 * ограничение (опционально).

3. Порядок сортировки строк выборки (список параметров и локальных статистик)

4. Порядок расположения параметров и локальных статистик в выборке

Вторая группа входных данных для алгоритма выполнения запроса – дополнительные ограничения. Они задаются в одной из следующих форм:


 * диапазон времени;
 * идентификатор ЕП;
 * объем выборки и конечный момент времени.

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

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

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

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

Для запросов ЕП:

1. Перебираем все параметры запроса (как входящие в выборку, так и нет).

2. Перебираем все локальные статистики запроса
 * Извлекаем вектор значений очередного параметра для текущей ЕП (см. следующие пункты)
 * Если заданы ограничения
 * проверяем их на всех элементах вектора
 * если ни одно значение вектора не удовлетворило ограничениям, возврат пустой таблицы
 * Если параметр включен в выборку или используется в выражении
 * Выполняем агрегацию
 * Сохраняем полученное значение в соответствующем столбце


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

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

Для запросов сигналов:

1. Выполняем все действия по аналогии с запросом ЕП, но в 2 внешних циклах обрабатываем только атрибуты и локальные статистики, не ссылающиеся на сигналы. В результате либо текущая ЕП будет отвергнута, либо будет сформирована строка ее атрибутов. Эта строка будет основой для всех строк выборки по текущей ЕП: значения атрибутов повторяются для всех значений сигнала.

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

3. Для каждой строки этой таблицы

4. Возвращаем полученный набор строк
 * Заполняем атрибуты и локальные статистики, вычисленные на первом шаге.
 * Перебираем столбцы выборки, оставшиеся на данный момент незаполненными
 * Если в столбце задана локальная статистика, ссылающаяся на значения сигналов, вычисляем ее.
 * Если в столбце заданы ограничения, проверяем их и, возможно, отбрасываем текущую строку.
 * Записываем полностью сформированную строку в выходную таблицу.

Извлечение вектора значений атрибута
Дано: идентификатор текущей ЕП, идентификатор параметра-атрибута, который надо извлечь.

1. Если и текущая ЕП, и извлекаемый параметр относятся к одному и тому же типу ЕП (плавка, сляб…), просто извлекаем все значения этого параметра для этой ЕП. Т.е., фактически, анализируем карточку текущей ЕП.

2. Если текущая ЕП и извлекаемый параметр относятся к разным типам ЕП, строим генеалогию ЕП от текущей по направлению к тому переделу, на котором собирается извлекаемый атрибут. Например, если ЕП – это плавка, а извлекается параметр х/к рулона, строим дерево, у которого корень – это плавка, первый уровень вершин – г/к рулоны, второй уровень – х/к рулоны. Затем для каждого листа этого дерева извлекаем значения параметра аналогично предыдущему пункту.
 * Если параметр – атрибут ЕП, берем одно значение.
 * Если параметр – атрибут процесса или события, берем все его значения, определенные для текущей ЕП.

При построении генеалогии нельзя выходить за рамки исходного и целевого переделов. Например, если текущая ЕП – это г/к рулон, а требуется извлечь атрибут х/к рулона, нельзя включать в генеалогическое дерево плавку, поскольку это приведет к извлечению значений атрибута для всех х/к рулонов, сделанных из этой плавки. Фактически, для того, чтобы корректно отработать этот момент, достаточно перед построением генеалогии правильно выбрать направление (предки или потомки), и в дельнейшем не менять его.

В общем случае генеалогия имеет вид графа с циклами. Пример: плавка, 3 г/к рулона, 2 полуторных х/к рулона. Если текущая ЕП – это х/к рулон, а необходимо извлечь атрибут плавки, генеалогия приведет в плавку двумя путями – через каждый из г/к рулонов, из которых сделан х/к рулон. Общее правило обработки циклов: прекращать текущую ветвь обхода в глубину. Иными словами, все вершины рассматриваются однократно. При обнаружении уже посещенной вершины идем назад.

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

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

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

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

Иными словами, каждая статистика реализуется как запрос с выражением. Любой запрос может содержать выражения. Статистиками становятся только те выражения, которые явно выбраны пользователем, создавшим запрос. Это называется экспортом локальной статистики запроса.

Существенны следующие моменты:


 * При наличии в запросе встроенных ограничений значения статистики определяются не для всех ЕП.
 * Если у пользователя нет доступа к папке, в которой хранится запрос, экспортирующий некоторую статистику, он не может получить значение этой статистики.
 * При просмотре деревьев параметров пользователь может отключить отображение статистик, недоступных ему.
 * Один запрос может экспортировать несколько статистик.
 * Для сокращения объема вычислений не предусматривается возможность создания статистик-сигналов, поэтому экспортировать статистику можно только из запроса ЕП.
 * Поскольку статистики зависят от запросов, а запросы, в свою очередь, могут зависеть от статистик, в БД должен быть надежный механизм, исключающий возникновение циклов в графе зависимостей.

Выражение для вычисления статистики задается в виде строки в синтаксисе языка PL/SQL со следующими исключениями:


 * Параметры-операнды и локальные статистики задаются в виде «SKP_COLUMN:псевдоним».
 * Агрегирующие и другие функции, определенные в БД СКП, задаются в виде «SKP_FUNC:функция».

Будем называть этот синтаксис «переходным языком выражений». Для перевода выражения с переходного языка на PL/SQL достаточно заменить все вхождения SKP_PARAM и SKP_FUNC на соответствующие языковые конструкции. Полноценный грамматический разбор и интерпретация выражения реализуется встроенными средствами БД.

Обратное преобразование с PL/SQL на переходный язык может быть нетривиально, поэтому выражения в БД должны храниться на переходном языке.

В конструкторе запросов предусматривается автоматизация ввода имен функций и псевдонимов столбцов. Более того, внешнее представление выражения (то, каким его видит пользователь) будет отличаться от описанного выше. Это будет зависеть от WEB-средства редактирования формул, на базе которого будет построен конструктор запросов.

Если локальная статистика экспортируется из запроса, пользователь должен задать:


 * агрегирующую функция по умолчанию;
 * название параметра;
 * единицу измерения;
 * предельный диапазон изменения.

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

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

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

У каждого пользователя системы имеется один субъект-пользователь и набор субъектов-групп, в которые он входит.

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

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

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

Доступ к папкам регулируется через механизм ассоциирования субъектов. Т.е. привилегии доступа к объектам назначаются на уровне папок, а не на уровне объектов.

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

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

1. Первый пользователь открывает некий объект для редактирования в конструкторе. При этом на его странице отображается текущее состояние этого объекта.

2. Второй пользователь делает то же самое.

3. Второй пользователь вносит изменения в объект и сохраняет их.

4. Первый пользователь вносит изменения в объект и сохраняет их.

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

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

Описанные проблемы разрешаются следующим образом:

1. В свойствах объекта хранится дата/время и субъект последнего сохранения изменений.

2. В начале процесса редактирования в БД создается временная копия объекта. Во временной копии запоминается время ее создания и идентификатор родительского объекта.

3. Все изменения объекта вносятся только во временную копию. Родительский объект остается без изменений и во время редактирования работает по-старому.

4. В случае прекращения сеанса пользователя в БД остается неиспользуемая временная копия объекта. Такие копии автоматически удаляет сборщик мусора, запускаемый с некоторой периодичностью. Критерий отбора – большой возраст копии.

5. При сохранении изменений (нажатии на кнопку "Сохранить" в конструкторе) проверяется, изменился ли объект за время редактирования (сравнивается время создания временной копии и время последнего сохранения изменений в родительском объекте). Если объект был изменен кем-то во время редактирования, выдается сообщение, содержащее время и автора последних изменений.

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

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

Инциденты
Инциденты – это некоторые события, зафиксированные в системе, которые требуют внимания со стороны специалистов комбината.

Создатель инцидента
Каждый инцидент создается одним из следующих субъектов:

1. Система верификации. Инциденты верификации данных – аномалии в полученных данных, имеющие технический либо организационный характер. Фиксируются, когда полученные данные о производстве противоречат здравому смыслу. Система верификации реализует широкий спектр проверок входных данных системы СКП от значений null в обязательных атрибутах ЕП до некорректных номеров ЕП и т.п.

2. Система мониторинга технологии. Инциденты контроля технологии фиксируются, когда любой нормируемый параметр любой ЕП не укладывается в нормативные границы.

3. Система статистического контроля процессов. Инциденты статистического контроля процессов фиксируются по картам Шухарта.

4. Пользователь. Инциденты могут создаваться пользователями.

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

Статус инцидента
При возникновении инцидента ему автоматически присваивается статус «открыт». В этом состоянии он «навязчиво» отображается на интерфейсах определенного круга пользователей. Далее один из пользователей назначает инциденту ответственного. Это может быть только конкретный пользователь (не группа). Возможен вариант автоматического назначения определенных инцидентов заданным пользователям сразу при возникновении. После назначения ответственного инцидент становится «навязчиво» виден только назначенному субъекту (остальные имеют возможность просматривать его при желании). После рассмотрения инцидента фиксируется его причина и мера по ее устранению, а инцидент переводится в состояние «закрыт», перестает отображаться в списках актуальных инцидентов, но остается доступен для просмотра впоследствии. Если инцидент создан пользователем, он может быть удален только этим же пользователем. Удаление «чужих» инцидентов, в том числе сгенерированных автоматически, через пользовательский интерфейс не предусматривается.

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

Другие свойства инцидентов
Также для инцидентов определены:


 * дата и время возникновения;
 * тип инцидента (формализованное определение наблюдаемого отклонения, реализуется как ссылка на справочник);
 * привязку к ЕП (набор ЕП, связанных с данным инцидентом);
 * параметр, по которому зафиксирован инцидент;
 * степень серьезности (по пятибалльной шкале);
 * причина (формализованный текст из справочника причин, реализуется как ссылка на справочник);
 * мера (формализованный текст из справочника мер, реализуется как ссылка на справочник);

Предусматривается поиск инцидентов по создателю, типу, статусу, прочим свойствам, а также содержимому журнала.

Архитектура системы


Рис. 1. Взаимодействие сервера БД и сервера приложений

API сервера приложений на рис.1 представляет собой набор вычислительно сложных функций интеллектуальной обработки данных, которые более эффективно реализуются на C ++ (математическая начинка системы). Как минимум, он содержит процедуры сжатия данных (с потерей информации и без них). Сжатие должно работать прозрачно для клиентов, делающих выборки данных, поэтому СУБД обращается к процедурам сжатия/распаковки «по собственной инициативе».



Рис. 2. Взаимодействие БД СКП и ПО верхнего уровня

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

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

Блок нерегламентированных отчетов реализуется как просмотрщик отчетов Crystal Reports (в ASP.NET имеется соответствующий web-control). Сами отчеты (RPT-файлы) создаются квалифицированным персоналом комбината в Windows-приложении Crystal Reports XI Developer Edition и могут передаваться на хранение в СУБД, что делает их доступными для остальных пользователей. Источниками данных для отчетов служат выборки, созданные в конструкторе запросов.

Подсистема мониторинга не показана на рис. 2, поскольку она реализуется в СУБД. Инциденты, зафиксированные этой подсистемой, просматриваются и дополняются в блоке «журнал инцидентов».

Блок анализа причин может потребовать реализацию в виде «толстого клиента».

Спецификация клиентского API БД СКП
Действуют следующие соглашения:


 * Если входной аргумент процедуры равен null, извлекаются все данные, удовлетворяющие остальным условиям отбора. Т.е. null означает «любой».
 * Для строк и времени используется само значение null непосредственно.
 * Для целых и вещественных чисел используется 0.
 * В тех случаях, когда 0 входит в допустимый диапазон значений переменной, признак «null» или «все» передается отдельным аргументом, следующим непосредственно за основным аргументом.
 * Для каждого (входного и выходного) аргумента процедуры и для каждого столбца возвращаемой таблицы четко зафиксировано, может ли значение быть null. Если он при каких-то условиях может быть null, в описании этого аргумента или столбца приведена конструкция ИМЯ=null. Если этой конструкции нет, значит null-значение для этого аргумента или столбца недопустимо и должно вызывать исключение. Исключение возникает естественным образом при использовании значения в языковых конструкциях.
 * Если процедура, возвращающая таблицу, обнаруживает, что таблица пуста, возвращается пустая таблица. Исключение «no data found» не генерируется. Это сделано для того, чтобы позволить корректно работать процедурам, возвращающим несколько таблиц.

CLI_CMN_GET_PU_TYPE_TBL
Аргументы:


 * PID_DS = null  - идентификатор источника данных

Возвращает таблицу всех видов ЕП, определенных в системе.

CLI_CMN_GET_PU_TYPE_NAME
Аргументы:


 * ID_PU_TYPE

Возврат:


 * Имя вида ЕП (Строка)

CLI_CMN_GET_SHOP_TBL
Возвращает таблицу цехов.

CLI_CMN_GET_SHOP_NAME
Аргументы:

Возврат:
 * ID_SHOP


 * Имя цеха (Строка)

CLI_CMN_GET_MACHINE_TYPE_TBL
Возвращает таблицу типов агрегатов.

CLI_CMN_GET_MACHINE_TYPE_NAME
Аргументы:

Возврат:
 * ID_MACHINE_TYPE


 * Имя типа агрегата (Строка)

CLI_CMN_GET_MACHINE_TBL
Аргументы:

Возвращает таблицу агрегатов указанного цеха и типа.
 * ID_SHOP=null
 * ID_MACHINE_TYPE=null

CLI_CMN_GET_MACHINE_NAME
Аргументы:

Возврат:
 * ID_MACHINE


 * Имя агрегата (Строка)

CLI_CMN_GET_DATA_TYPE_TBL
Возвращает таблицу типов данных.

0. CLI_CMN_GET_DATA_TYPE_NAME
Аргументы:

Возврат:
 * ID_DATA_TYPE


 * Имя типа данных (Строка)

CLI_CMN_GET_ENUM_TYPE_TBL
Возвращает таблицу перечислимых типов.

CLI_CMN_GET_ENUM_TYPE_NAME
Аргументы:

Возврат:
 * ID_ENUM_TYPE


 * Имя перечислимого типа (Строка)

CLI_CMN_GET_ENUM_CONSTANT_TBL
Аргументы:

Возвращает таблицу перечислимых констант. Если аргумент ID_ENUM_TYPE не равен null, возвращается таблица констант этого типа.
 * ID_ENUM_TYPE=null

CLI_CMN_GET_ENUM_CONSTANT_NAME
Аргументы:

Возврат:
 * ID_ENUM_CONSTANT


 * Имя перечислимой константы (Строка)

CLI_CMN_GET_UNIT_TBL
Возвращает таблицу единиц измерения.

CLI_CMN_GET_UNIT_NAME
Аргументы:

Возврат:
 * ID_UNIT


 * Имя единицы измерения (Строка)

CLI_CMN_GET_CLAUSE_TBL
Возвращает таблицу условий.

CLI_CMN_GET_CLAUSE_NAME
Аргументы:

Возврат:
 * ID_CLAUSE


 * Имя условия (Строка)

CLI_CMN_GET_AGGREGATE_FUNC_TBL
Возвращает таблицу агрегирующих функций.

0. CLI_CMN_GET_AGGREGATE_FUNC_NAME
Аргументы:

Возврат:
 * ID_AGGREGATE_FUNC


 * Имя агрегирующей функции (строка).

CLI_CMN_GET_ACCESS_TYPE_TBL
Возвращает таблицу типов доступа.

CLI_CMN_GET_ACCESS_TYPE_NAME
Аргументы:

Возврат:
 * ID_ACCESS_TYPE


 * Имя типа доступа (Строка)

CLI_CMN_GET_SUBJECT_TYPE_TBL
Возвращает таблицу типов субъектов.

CLI_CMN_GET_SUBJECT_TYPE_NAME
Аргументы:

Возврат:
 * ID_SUBJECT_TYPE


 * Имя типа субъекта (Строка)

CLI_CMN_GET_SUBJECT_TBL
Аргументы:

Возвращает таблицу субъектов.
 * ID_SUBJECT=0
 * ID_SUBJECT_TYPE=0

Действуют следующие правила отбора субъектов:


 * Если ID_SUBJECT=0 и ID_SUBJECT_TYPE=0, возвращаются все пользователи и все группы.
 * Если ID_SUBJECT=0 и ID_SUBJECT_TYPE=1, возвращаются все пользователи.
 * Если ID_SUBJECT=0 и ID_SUBJECT_TYPE=2 возвращаются все группы.
 * Если ID_SUBJECT <> 0 и ID_SUBJECT_TYPE=0, возвращается указанный пользователь и все его группы.
 * Если ID_SUBJECT <> 0 и ID_SUBJECT_TYPE=1, возвращается указанный пользователь.
 * Если ID_SUBJECT <> 0 и ID_SUBJECT_TYPE=2, возвращаются все группы указанного пользователя.

CLI_CMN_GET_SUBJECT_NAME
Аргументы:

Возврат:
 * ID_SUBJECT


 * Имя текущего субъекта (строка)

CLI_CMN_GET_SUBJECT_ID
Аргументы:

Возврат:
 * PSUBJECT_NAME


 * ID_SUBJECT

Если пользователя с указанным именем нет в базе, он создается, а его профиль инициализируется значениями по умолчанию.

CLI_PROCESS_EVENT_LOAD
Аргументы:


 * PID_PROCESS – идетификатор процесса
 * PID_EVENT_TYPE = null –идентификатор типа события

Возвращает:


 * PEVENT_TYPE_NAME - имя типа события

Возвращает таблицу PRES  - параметры событий произошедших во время процесса:


 * ATNAME – название параметра
 * ATVAL - значение параметра
 * ATMEASURE – единица измерения параметра
 * ATID – идентификатор параметра
 * ATEVENT_TYPE_NAME – имя типа события
 * ATID_PARAM – идентификатор параметра
 * ATID_EVENT – идентификатор события
 * ATEVENT_START – время начала события
 * ATEVENT_END – время окончания события
 * ATIS_MAIN – признак "основной параметр"
 * ATDBTYPE – тип данных параметра

CLI_CMN_GET_PU_TYPE_TBL_DIV
Аргументы:

Возвращает таблицу с колонками:
 * PDIVISION – Идентификатор подразделения, для которого требуется отобразить типы продукции

При PDIVISION == (0, null) возвращает весь список из справочника типов ЕП.
 * ID_PU_TYPE – идентификатор типа ЕП
 * NAME – название типа ЕП

CLI_GET_CHILD_PROCESS
Аргументы:

Возвращает PRES таблицу детей процессов с колонками:
 * PPROCESS_ID – идентификатор процесса


 * PID_PROCESS – идентификатор процесса ребенка

Дети процесса - это процессы, кторые происходят с той же ЕП, что и исходный процесс и аграгаты которых являются детьми агрегата исходного процесса.

CPI_P_GET_PARAM_TBL
Аргументы:

Возвращает таблицу параметров.
 * ID_PARAM=null
 * ID_PU_TYPE=null
 * ID_SHOP=null
 * ID_MACHINE_TYPE=null

CPI_P_GET_PARAM_NAME
Аргументы:

Возврат:
 * ID_PARAM


 * Имя параметра (Строка)

CLI_P_GET_PARAM_TYPE_TBL
Возвращает таблицу типов параметров.

CLI_P_GET_PARAM_TYPE_NAME
Аргументы:

Возврат:
 * ID_PARAM_TYPE


 * Имя типа параметра (Строка)

CLI_Q_GET_QUERY_TBL
Аргументы:

Возвращает таблицу запросов. Пара параметров ID_SUBJECT и ID_ACCESS_TYPE позволяет ограничивать выборку только теми запросами, к которым у субъекта имеется указанный доступ.
 * ID_QUERY=null
 * ID_FOLDER=null
 * IS_STAT=null
 * IS_TEMP=null
 * ID_SUBJECT=null
 * ID_ACCESS_TYPE=null

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

Аргументы:

Возвращает успех/ неуспех.
 * ID_QUERY
 * ID_FOLDER
 * NAME
 * ID_TREE=null
 * ID_KEY_ PARAM =null

CLI_Q_DEL_QUERY
Аргументы:

Возвращает успех/неуспех. Может применяться как ко временным, так и к постоянным запросам, причем без вызова CLI_Q_EDIT_QUERY_START.
 * ID_QUERY.

CLI_Q_GET_QUERY_PARAM_TBL
Аргументы:

Возвращает таблицу параметров запроса.
 * ID_QUERY
 * ID_QUERY_PARAM=null

Различные сочетания ID_PARAM и EXPRESSION приведены в следующей таблице:

CLI_Q_SAVE_QUERY_PARAM
Аргументы:


 * ID_QUERY_PARAM=null
 * ID_QUERY=null
 * ID_PARAM=null
 * EXPRESSION=null
 * ID_CONSTRAINT_CLAUSE=null
 * CONSTRAINT_OPERAND=null
 * NAME
 * ID_UNIT=null
 * LIMIT_LOW=null
 * LIMIT_HIGH=null
 * DISPLAY
 * DISPLAY_ORDINAL=null
 * SORT_PRIORITY=null
 * ID_AGGREGATE_FUNC=null

Если параметр ID_QUERY_PARAM равен null, в запрос ID_QUERY добавляется новый параметр. В противном случае модифицируется существующий параметр запроса с идентификатором ID_QUERY_PARAM (параметр ID_QUERY игнорируется).

Если в DISPLAY_ORDINAL передан null, порядок столбцов несущественен и назначается БД произвольно.

Возвращает идентификатор сохраненного параметра запроса.

CLI_Q_DEL_QUERY_PARAM
Аргументы:

Удаляет параметр запроса ID_QUERY_PARAM, или все параметры из запроса ID_QUERY, если ID_QUERY_PARAM равен null. Если ID_QUERY_PARAM не равен null, аргумент ID_QUERY игнорируется.
 * ID_QUERY_PARAM=null
 * ID_QUERY=null

Возвращает успех/неуспех.

CLI_Q_EXEC_QUERY_FOR_PU
Аргументы:

Возвращает таблицу-выборку.
 * ID_QUERY
 * ID_PU – внутренний идентификатор ЕП

CLI_Q_EXEC_QUERY_FOR_PERIOD
Аргументы:

Возвращает таблицу-выборку.
 * ID_QUERY
 * DATETIME_FROM
 * DATETIME_TO

CLI_Q_GET_VALUES_FOR_PU
Аргументы:

Возвращает вектор-выборку – все значения параметра для данной ЕП (в виде строк).
 * ID_PARAM – идентификатор параметра любого типа
 * ID_PU – идентификатор ЕП любого типа

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

CLI_T_GET_TREE_TBL
Аргументы:

Возвращает таблицу деревьев.
 * ID_TREE=null.
 * ID_FOLDER=null
 * IS_CED=null

CLI_T_GET_CHILD_TBL
Аргументы:

Возвращает таблицу дочерних узлов. Если задан ID_SUBJECT, возвращаются только те узлы, которые соответствуют параметрам, доступным на чтение этому субъекту. Статистики могут быть недоступны субъекту, если порождающий их запрос находится в недоступной субъекту папке.
 * ID_TREE_NODE – идентификатор промежуточного узла дерева или корня.
 * ID_SUBJECT

CLI_T_SAVE_TREE
Аргументы:

Возвращает идентификатор нового дерева.
 * Строка таблицы деревьев (см. п. CLI_T_GET_TREE_TBL). Если ID_TREE=null, создается новое дерево.

CLI_T_DEL_TREE
Аргументы:

Возвращает успех/неуспех.
 * ID_TREE – идентификатор дерева.

CLI_T_DEL_SUBTREE
Аргументы:

Возвращает успех/неуспех.
 * ID_TREE_NODE – промежуточная или корневая вершина.

CLI_T_GET_NODE
Аргументы:

Возвращает информацию об узле в виде одной строки таблицы узлов (см. п. CLI_T_GET_CHILD_TBL).
 * ID_TREE_NODE – идентификатор промежуточного узла дерева или корня.

CLI_T_SAVE_NODE
Аргументы:

Возвращает идентификатор сохраненного узла.
 * Строка таблицы узлов. В зависимости от значения поля ID_TREE_NODE, функция либо создает новый узел (идентификатор равен null), либо модифицирует существующий (в противном случае). Значение поля DESCENDANTS_COUNT игнорируется.
 * ID_TREE_NODE – идентификатор родительского узла.

CLI_T_GET_PARENT
Аргументы:

Возвращает идентификатор родительского узла или null, если узел является корневым.
 * ID_TREE_NODE – идентификатор промежуточного узла дерева или корня.

CLI_T_SET_PARENT
Аргументы:

Возвращает успех/неуспех.
 * ID_TREE_NODE – перемещаемая промежуточная вершина (не может быть null).
 * ID_NEW_PARENT – промежуточная или корневая вершина этого же дерева (не может быть null).

0. CLI_T_GET_ROOT
Аргументы:

Возвращает идентификатор корневого узла.
 * ID_TREE_NODE – идентификатор промежуточного узла дерева или корня.

CLI_I_GET_INCIDENT_TBL
Возвращает таблицу инцидентов, удовлетворяющих заданным условиям.

Аргументы:


 * ID_INCIDENT=null
 * INCIDENT_DESCR=null
 * ID_PARAM=null
 * DATETIME_FROM=null
 * DETETIME_TO=null
 * ID_INCIDENT_TYPE=null
 * SEVERITY_MIN=null
 * SEVERITY_MAX=null
 * ID_INICIDENT_STATUS=null
 * ID_INCIDENT_REASON=null
 * ID_INCIDENT_ELIMINATION=null
 * ID_SUBJECT=null
 * ID_INCIDENT_ROLE=null
 * KEYWORDS=null
 * ID_SHOP=null
 * ID_MACHINE_TYPE= null
 * ID_MACHINE=null
 * ID_PU_TYPE=null
 * PU_LST=null
 * FIRST_NUMBER=null
 * RECORD_COUNT=null
 * SORT_PARAM=null
 * SORT_ORDER=null
 * PPARAM_NAME=null – фильтр по названию параметра
 * ID_CARD=null
 * TBLCOUNT

Параметр INCIDENT_DESCR определяет ключевые слова, которые должны быть в описании инцидента. Параметр KEYWORDS позволяет искать по всему содержимому истории.

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

Параметр PU_LST задает список заводских номеров ЕП типа ID_PU_TYPE в виде строки. ЕП в этом списке отделяются друг от друга запятой.

Пара параметров FIRST_NUMBER и RECORD_COUNT позволяют клиентам загружать данные небольшими порциями, что необходимо для эффективной работы WEB-интерфейсов. Через выходной параметр TBLCOUNT возвращается общее количество хранимых инцидентов, удовлетворяющих заданным условиям отбора.

Входной строковый параметр SORT_PARAM может принимать значения из списка столбцов выходной таблицы. Если он равен null, сортировка идет по RISE_DATETIME.

Параметр SORT_ORDER может принимать одно из значений "ASC" или "DESC", что означает сортировку по возрастанию и убыванию поля SORT_PARAM соответственно. По умолчанию сортировка осуществляется по убыванию.

Параметр ID_CARD позволяет отбирать только те инциденты, которые связаны с заданной контрольной картой.

Возвращается таблица со следующими полями:


 * ID_INCIDENT
 * INCIDENT_DESCR
 * ID_PARAM=null
 * RISE_DATETIME
 * ID_INCIDENT_TYPE
 * SEVERITY
 * ID_INCIDENT_STATUS
 * ID_INCIDENT_REASON=null
 * ID_INCIDENT_ELIMINATION=null
 * ID_SHOP
 * ID_MACHINE=null
 * ID_PU_TYPE=null
 * PU_LIST=null
 * ID_REPORTER
 * ID_OWNER=null
 * ID_CARD=null
 * CARD_START=null
 * CARD_END=null

В случае, если параметр ID_CARD != null, параметры CARD_START и CARD_END определяют диапазон времени, за который надо построить эту КК, чтобы увидеть данный инцидент.

CLI_I_SAVE_INCIDENT
Аргументы:

Возвращает идентификатор сохраненного инцидента.
 * ID_INCIDENT=null входной и выходной параметр. Если при вызове он равен null, функция создает новый инцидент. В противном случае модифицируется существующий инцидент.
 * INCIDENT_DESCR
 * ID_PARAM=null
 * ID_INCIDENT_TYPE
 * SEVERITY
 * ID_INCIDENT_STATUS
 * ID_INCIDENT_REASON=null
 * ID_INCIDENT_ELIMINATION=null
 * ID_INCIDENT_REPORTER
 * ID_INCIDENT_OWNER=null
 * ID_SHOP
 * ID_MACHINE=null
 * ID_PU_TYPE=null
 * PU_LIST=null
 * ID_CARD=null
 * CARD_START=null
 * CARD_END=null

CLI_I_DEL_INCIDENT
Аргументы:

Возвращает успех/неуспех.
 * ID_INCIDENT.

CLI_I_GET_INCIDENT_TYPE_TBL
Возвращает таблицу типов инцидентов.

CLI_I_GET_INCIDENT_TYPE_NAME
Аргументы:

Возврат:
 * ID_INCIDENT_TYPE


 * Имя типа инцидента (Строка)

CLI_I_GET_INCIDENT_STATUS_TBL
Возвращает таблицу статусов инцидентов.

CLI_I_GET_INCIDENT_STATUS_NAME
Аргументы:

Возврат:
 * ID_INCIDENT_STATUS


 * Имя статуса инцидента (Строка)

CLI_I_GET_INCIDENT_REASON_TBL
Возвращает таблицу причин инцидентов.

Аргументы:


 * ID_INCIDENT_REASON = null
 * ID_PARAM=null
 * ID_INCIDENT_TYPE=null
 * DISABLED=null

Поля ID_PARAM и ID_INCIDENT_TYPE не могут быть null одновременно.

CLI_I_GET_INCIDENT_REASON_TEXT
Аргументы:

Возврат:
 * ID_INCIDENT_REASON


 * Текстовое описание причины инцидента (Строка)

0. CLI_I_SAVE_INCIDENT_REASON
Аргументы:

Возвращает идентификатор сохраненной причины инцидента.
 * ID_INCIDENT_REASON=null
 * ID_PARAM=null
 * ID_INCIDENT_TYPE=null
 * DISABLED
 * TEXT

0. CLI_I_GET_INCIDENT_ELIMINATION_TBL
Возвращает таблицу мер по инцидентам.

Аргументы:


 * ID_PARAM=null
 * ID_INCIDENT_ELIMINATION = null
 * ID_INCIDENT_TYPE=null
 * ID_INCIDENT_REASON=null
 * DISABLED=null

Все поля ID_INCIDENT_REASON, ID_PARAM и ID_INCIDENT_TYPE не могут быть null одновременно: мера всегда привязывается к одному из них.

CLI_I_GET_INCIDENT_ELIMINATION_TEXT
Аргументы:

Возврат:
 * ID_INCIDENT_ELIMINATION


 * Текстовое описание меры по инциденту (Строка)

CLI_I_SAVE_INCIDENT_ELIMINATION
Аргументы:

Возвращает идентификатор сохраненной меры по инциденту.
 * ID_INCIDENT_ELIMINATION=null
 * ID_PARAM=null
 * ID_INCIDENT_TYPE=null
 * ID_INCIDENT_REASON=null
 * DISABLED
 * TEXT

CLI_I_GET_INCIDENT_ROLE_TBL
Возвращает таблицу ролей субъектов в инцидентах.

CLI_I_GET_INCIDENT_ROLE_NAME
Аргументы:

Возврат:
 * ID_INCIDENT_ROLE


 * Имя роли инцидента (Строка)

CLI_I_GET_INCIDENT_EVENT_TBL
Аргументы:

Параметр SORT_ORDER может принимать одно из значений "ASC" или "DESC", что означает сортировку по возрастанию и убыванию даты события соответственно. По умолчанию сортировка осуществляется по возрастанию.
 * ID_INCIDENT
 * ID_INCIDENT_EVENT=null
 * SORT_ORDER=null

Возвращает таблицу записей журнала инцидентов.

CLI_I_ADD_INCIDENT_EVENT
Аргументы:

Возвращает идентификатор новой записи журнала инцидентов (ID_INCIDENT_EVENT) и таблицу, содержащую действия, совершенные пользователем при добавлении записи:
 * ID_INCIDENT
 * ID_SUBJECT
 * UCOMMENT=null
 * SEVERITY
 * ID_INCIDENT_STATUS
 * ID_INCIDENT_REASON=null
 * ID_INCIDENT_OWNER=null
 * PID_INCIDENT_ELIMINATION=null

CLI_I_GET_INCIDENT_ACTION_TBL
Аргументы:

Возвращает таблицу, содержащую действия, совершенные пользователем при добавлении записи в журнал инцидента:
 * ID_INCIDENT_EVENT

CLI_I_CHECK_PU_LIST
Проверяет на допустимость список номеров ЕП, привязываемых к инцидентам.

Аргументы:

Возвращает успех/неуспех. В случае ошибки текстовое сообщение указывает на ЕП, которая не найдена в базе.
 * ID_PU_TYPE – тип ЕП (список номеров ЕП не имеет смысла, если не определен тип ЕП).
 * PU_LIST – список заводских номеров ЕП (разделены запятыми).

CLI_F_GET_FOLDER_TBL
Возвращает таблицу папок.

CLI_F_GET_FOLDER_NAME
Аргументы:

Возврат:
 * ID_FOLDER


 * Имя каталога (строка).

CLI_F_GET_FOLDER_SUBJECTS_TBL
Аргументы:

Возвращает таблицу субъектов папки.
 * ID_FOLDER
 * ID_ACCESS_TYPE=null

CLI_F_GET_SUBJECT_FOLDERS_TBL
Аргументы:

Возвращает таблицу папок, доступных данному субъекту.
 * ID_SUBJECT
 * ID_ACCESS_TYPE=null

CLI_F_ADD_FOLDER_SUBJECT
Добавляет к папке новый субъект.

Аргументы:

Возврат:
 * ID_FOLDER
 * ID_SUBJECT
 * ID_ACCESS_TYPE


 * Успех/неуспех

CLI_F_DEL_FOLDER_SUBJECT
Удаляет доступ указанного субъекта к папке.

Аргументы:

Возврат:
 * ID_FOLDER
 * ID_SUBJECT
 * ID_ACCESS_TYPE


 * Успех/неуспех

CLI_F_SAVE_FOLDER
Добавляет новую папку или модифицирует существующую.

Аргументы:

Возврат:
 * ID_FOLDER
 * NAME


 * Успех/неуспех

CLI_F_DEL_FOLDER
Удаляет папку.

Аргументы:

Возврат:
 * ID_FOLDER


 * Успех/неуспех

CLI_PU_LOADLIST
Аргументы:

Возвращает таблицу со следующими полями:
 * PSTDATE – начальная дата/время
 * PENDDATE – конечная дата/время
 * PPUTYPE – вид продукции (см. CLI_CMN_GET_PU_TYPE_TBL)


 * PNAME – вид продукции
 * PNUM – заводской номер ЕП
 * PTCREATED – дата/время создания ЕП
 * PTDESTROYED – дата/время уничтожения ЕП
 * PROUTE – маршрут ЕП (строка)
 * PID – идентификатор ЕП (внутренний ИД базы, ссылающийся на ЕП любого типа)

CLI_PU_TREE_LOAD
Аргументы:

Возвращает таблицу со следующими полями:


 * CHILD_ID - идентификатор ЕП
 * PARENT_ID – идентификатор родителя ЕП

CLI_PU_TYPE_LOADLIST
Аргументы:

Возвращает таблицу со следующими полями:


 * PTNAME – название вида продукции
 * PTID - идентификатор вида продукции

CLI_PU_GET_ROUTE
Аргументы:


 * PID - идентификатор ЕП

Возвращает: маршрут из агрегатов, по которым прошла ЕП

CLI_PU_LOAD
Аргументы:


 * PID - идентификатор ЕП

Возвращает:


 * PNAME - вид продукции
 * PNUM - заводской номер ЕП
 * PTCREATED - дата/время создания ЕП
 * PTDESTROYED - дата/время уничтожения ЕП

Возвращает таблицу RESAT – параметры ЕП со следующими полями:


 * ATNAME – название параметра
 * ATVAL - значение параметра
 * ATMEASURE – единица измерения параметра
 * ATID – идентификатор параметра

Возвращает таблицу RESPR – процессы, в которых учувствовала ЕП со следующими полями:


 * PRNAME – имя процесса
 * PRSTART – время начала процесса
 * PRFINISH – время окончания процесса
 * PRID – идентификатор процесса
 * PSTEEL_GRADE – марка стали

Возвращает таблицу RESEV – события, которые произошли с ЕП со следующими полями:

Возвращает таблицу RESPARENT – родители ЕП  со следующими полями:
 * EVNAME – тип события
 * EVSTART – время совершения события
 * EVID – идентификатор события
 * EVID_EVENT_TYPE – идентификатор типа события
 * EVID_EVENT_TYPE_CLASS_ID – идентификатор класса типа события
 * EVID_PROCESS – идентификатор процесса к которому относиться событие
 * EVFULL_NAME – имя события с конкретным агрегатом


 * PNAME - вид продукции
 * PNUM - заводской номер ЕП
 * PTCREATED - дата/время создания ЕП
 * PTDESTROYED - дата/время уничтожения ЕП
 * PNOTE – описание ЕП
 * PID – идентификатор ЕП
 * PPUTYPE – идентификатор вида продукции

Возвращает таблицу RESCHILD – дети ЕП  со следующими полями:


 * PNAME - вид продукции
 * PNUM - заводской номер ЕП
 * PTCREATED - дата/время создания ЕП
 * PTDESTROYED - дата/время уничтожения ЕП
 * PNOTE – описание ЕП
 * PID – идентификатор ЕП
 * PPUTYPE – идентификатор вида продукции

CLI_PU_PROCESS_LOAD
Аргументы:


 * PRID - идентификатор процесса

Возвращает:


 * PRNAME – имя процесса
 * PRSTART – время начала процесса
 * PRFINISH – время окончания процесса
 * PRPU_ID - идентификатор ЕП

Возвращает таблицу RESAT – параметры процесса со следующими полями:


 * ATNAME – название параметра
 * ATVAL - значение параметра
 * ATMEASURE – единица измерения параметра
 * ATID – идентификатор параметра

Возвращает таблицу RESEV события процесса со следующими полями:


 * EVNAME – имя события
 * EVSTART – начало события
 * EVID – идентификатор события
 * EVID_EVENT_TYPE – идентификатор типа события
 * EVID_EVENT_TYPE_CLASS – идентификатор класса типа события

Возвращает таблицу RESSG – перечень параметров-сигналов, которые со следующими полями:


 * SGNAME – название параметра
 * SGMEASURE - единица измерения параметра
 * SGID - идентификатор параметра

CLI_PU_EVENT_LOAD
Аргументы:


 * EVID – идентификатор события

Возвращает:


 * EVNAME - имя события
 * EVSTART – время начало события
 * EVFINISH – время окончания события
 * EVID_PROCESS – идентификатор процесса к которому относится событие
 * EVPROCESS_NAME – имя процесса - агрегат
 * EVPU_ID – идентификатор ЕП
 * EVPU_TYPE – тип ЕП

Возвращает таблицу RESAT  - параметры события со следующими полями:


 * ATNAME – название параметра
 * ATVAL - значение параметра
 * ATMEASURE – единица измерения параметра
 * ATID – идентификатор параметра
 * ATID_PROCESS – идентификатор процесса
 * ATPU_ID – идентификатор ЕП
 * ATIS_MAIN – признак "основной параметр"
 * ATDBTYPE – тип данных параметра

CLI_PU_SIGNAL_LOAD
Аргументы:

Возвращает:
 * SGID – идентификатор параметра-сигнала
 * PID – идентификатор ЕП
 * PPROCESSID – идентификатор процесса в котором собирался сигнал

Возвращает таблицу RESSG – значение сигнала со следующими полями:
 * SGNAME – название параметра-сигнала
 * PID_AGGREGATE_TYPE - идентификатор типа агрегата
 * PMEASURE – единица измерения
 * PID_MEASURE – идентификатор единицы измерения


 * SGVAL – значение сигнала
 * TSTAMP – время сбора этого значения сигнала

CLI_PU_SINFO
Аргументы:

Возвращает:
 * PID – идентификатор ЕП


 * PINFO – возвращает строку заводской номер ЕП и общее количество дефектов

0. CLI_PU_GET_ROUTE_EX
Аргументы:


 * PID - идентификатор ЕП

Возвращает таблицу PRES_ROUTE – маршрут движения по агрегатам в фактическом порядке следования


 * PRID – идентификатор процесса
 * SHORT_NAME – короткое имя агрегата
 * FULL_NAME – полное имя агрегата

0. CLI_PU_EVENT_CLASS_LOAD
Аргументы:


 * PPU_ID - идентификатор ЕП
 * PEVENT_CLASS – класс типа события
 * PAGGREGATE_TYPE_ID – тип агрегата, 0 означает все

Возвращает таблицу PRES – все параметры событий указанного класса


 * ID_AGGREGATE – идентификатор агрегата
 * ID_EVENT_TYPE – идентификатор типа события
 * AGGREGATE_NAME – имя агрегата
 * ID_EVENT – идентификатор события
 * ID_PARAM – идентификатор параметра
 * PARAM_VALUE – значение параметра
 * PARAM_NAME – имя параметра
 * AGGREGATE_TYPE – тип агрегата
 * EVENT_TIME_START – время события
 * ID_PROCESS – идентификатор процесса к которому относится событие

CLI_I_GET_INCIDENT_COUNT_PU
Аргументы:


 * PPU_ID - идентификатор ЕП

Возвращает PINCIDENT_COUNT – кол – во инцидентов

CLI_I _PU_GET_HEAD_INFO
Аргументы:

Возвращает:
 * PPU_ID - идентификатор ЕП


 * PPU_TYPE_ID – идентификатор типа ЕП
 * PPU_TYPE_NAME – тип ЕП
 * PPU_NUM – заводской номер ЕП

CLI_PU_LOADLIST_EX
Аргументы:

Значения PSHIFT и PBRIGADE имеют смысл только, когда задан агрегат.
 * PSTDATE – начальная дата/время
 * PENDDATE – конечная дата/время
 * PPUTYPE – вид продукции (см. CLI_CMN_GET_PU_TYPE_TBL)
 * PNUMBER – Заводской номер ЕП (поиск по части номера)
 * PAGGREGATE – ID агрегата (см. CLI_CMN_GET_MACHINE_TBL)
 * PSTEELGRADE - марка стали (поиск по части марки)
 * PSHIFT - смена (в формате 1- первая, 2 – вторая, 4 – третья, комбинируются плюсом)
 * PBRIGADE – бригада (аналогично PSHIFT, четвертая бригада – 8)
 * PQUALITY – Качество (пока не исп.)

Возвращает таблицу со следующими полями:


 * PNAME – вид продукции
 * PNUM – заводской номер ЕП
 * PTCREATED – дата/время создания ЕП
 * PTDESTROYED – дата/время уничтожения ЕП
 * PROUTE – маршрут ЕП (строка)
 * PID – идентификатор ЕП (внутренний ИД базы, ссылающийся на ЕП любого типа)

CLI _PU_GET_PROCESS_NAME
Аргументы:

Возвращает:
 * PID_PROCESS - идентификатор процесса


 * PPROCESS_NAME– имя агрегата

CLI _PU_LIQUIDUS_TEMP
Аргументы:

Возвращает таблицу PRES:
 * PPU_ID - идентификатор ЕП


 * PAGGREGATE_NAME– имя агрегата
 * PID_AGGREGATE – идентификатор агрегата
 * PSAMPLE_NUMBER – номер пробы
 * PID_PROCESS – идентификатор процесса
 * PLIQUIDUS_TEMP – температура ликвидуса
 * PLIQUIDUS_TEMP_MIN – температура ликвидуса минимальная
 * PLIQUIDUS_TEMP_MAX - температура ликвидуса максимальная

CLI_PU_LOADLIST_LPC3
Аргументы:

Для всех параметров, которые задаются минимумом и максимумом, если параметр-минимум не задан, принимается 0. Если параметр-максимум не задан или 0, условие не накладывается на выборку.

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

В результате возвращается таблица, которая содержит:


 * PID – Ид. ЕП
 * PNAME – Название типа ЕП
 * PNUM – Номер ЕП
 * PTCREATED – Время создания
 * PCUSTOMER - Потребитель
 * PTECHNOLOGY – Технология (НТД)
 * PDEST – Назначение после прокатки
 * PROLLN – Номер прокатки
 * PSTRATEGY – Стратегия прокатки
 * PSTACK – Номе садки
 * PSTEELGRADE – Марка стали
 * PFURNACE – Номер печи
 * PPIECE – Номер штуки в печи
 * PSLTH – Толщина сляба
 * PSLWI – Ширина сляба
 * PSLLE – Длина сляба
 * PSLWE – Вес заготовки
 * PROTH – Толщина проката
 * PROWI – Ширина проката
 * PROLE – Длина проката
 * PSCHEM – Схема прокатки

CLI_R_GET_REPORT_TBL
Аргументы:

Пара параметров ID_SUBJECT и ID_ACCESS_TYPE позволяет ограничивать выборку только теми отчетами, к которым у субъекта имеется указанный доступ.
 * ID_REPORT=null
 * ID_FOLDER=null
 * ID_QUERY=null
 * ID_SUBJECT=null
 * ID_ACCESS_TYPE=null

Возвращает таблицу отчетов (она имеет следующие поля):


 * ID_REPORT
 * ID_FOLDER
 * NAME
 * FILE_NAME

CLI_R_SAVE_REPORT
Аргументы:

Возвращает идентификатор сохраненного отчета.
 * ID_REPORT=null
 * ID_FOLDER
 * NAME

При создании нового отчета поля ID_REPORT и FILE_NAME генерируются автоматически. В дальнейшем они никогда не меняются.

CLI_R_DEL_REPORT
Аргументы:

В случае успешного удаления отчета возвращает имя файла, который надо удалить (поле FILE_NAME).
 * ID_REPORT

CLI_DT_GET_DTREE_TBL
Аргументы:

Возвращает таблицу деревьев решений.
 * ID_DTREE=null
 * ID_FOLDER=null
 * METHOD=null


 * ID_DTREE – идентификатор дерева решений
 * ID_FOLDER – идентификатор папки, в которой сохранено дерево
 * NAME – имя дерева (строка)
 * ID_DTREE_NODE=null - идентификатор корневой вершины
 * METHOD - указывает на метод (регрессия/классификация) – целое.

CLI_DT_SAVE_DTREE
Аргументы:

Возвращает идентификатор нового дерева.
 * ID_DTREE=null (если ID_DTREE=null, создается новое дерево).
 * ID_FOLDER
 * NAME
 * ID_DTREE_NODE=null
 * METHOD

CLI_DT_DEL_DTREE
Аргументы:

Возвращает успех/неуспех.
 * ID_DTREE – идентификатор дерева решений.

CLI_DT_GET_NODE
Аргументы:

Возвращает таблицу следующей структуры:
 * ID_DTREE=null – идентификатор дерева решений.
 * ID_DTREE_NODE=null – идентификатор узла дерева решений.


 * ID_DTREE
 * ID_DTREE_NODE
 * NAME=null – имя узла (строка)
 * ID_PARAM=null – идентификатор параметра, который связан с данным узлом дерева решений.
 * THRESHOLD=null – константа для проверки в узле (вещественная).
 * CLASS=null – исход классификации (целое). Значение этого поля назначается клиентским приложением (как правило, используются 0 и 1).
 * PREDICTION=null - исход классификации (вещественное)
 * ID_CHILD_LEFT=null – левый потомок (идентификатор узла дерева решений).
 * ID_CHILD_RIGHT=null – правый потомок

CLI_DT_SAVE_NODE
Аргументы:

Если ID_DTREE_NODE=null, создается новый узел. Для создания корневого узла дерева указываются аргументы ID_DTREE != null и ID_PARENT=null. Для создания промежуточного узла дерева указываются аргументы ID_DTREE = null и ID_PARENT != null.
 * ID_DTREE=null
 * ID_DTREE_NODE=null
 * ID_PARENT=null
 * NAME=null
 * ID_PARAM=null
 * THRESHOLD=null
 * CLASS=null
 * PREDICTION=null
 * ID_CHILD_LEFT=null
 * ID_CHILD_RIGHT=null

Возвращает идентификатор сохраненного узла.

CLI_DT_DEL_NODE
Аргументы:

Возвращает успех/неуспех.
 * ID_DTREE_NODE – идентификатор узла дерева решений.

CLI_DT_GET_PARENT
Аргументы:

Возвращает идентификатор родительского узла или null, если узел является корневым.
 * ID_DTREE_NODE – идентификатор узла дерева решений.

CLI_DT_GET_CLASS_TBL
Аргументы:

Возвращает таблицу следующей структуры:
 * ID_DTREE=null
 * CLASS=null


 * ID_DTREE
 * CLASS
 * NAME

CLI_DT_GET_CLASS_NAME
Аргументы:

Возвращает имя класса (строка).
 * ID_DTREE
 * CLASS

0. CLI_DT_SAVE_CLASS
Аргументы:

Возвращает успех/неуспех.
 * ID_DTREE
 * CLASS
 * NAME

0.1. CLI_C_GET_CARD_TBL
Аргументы:

Пара параметров ID_SUBJECT и ID_ACCESS_TYPE позволяет ограничивать выборку только теми картами, к которым у субъекта имеется указанный доступ.
 * ID_CARD=null
 * ID_FOLDER=null
 * ID_QUERY=null
 * ID_PARAM=null
 * ID_SUBJECT=null
 * ID_ACCESS_TYPE=null

Возвращает таблицу контрольных карт (она имеет следующие поля):


 * ID_CARD
 * ID_FOLDER
 * ID_QUERY
 * ID_PARAM
 * SUBGROUP_SIZE
 * MAX_SUBGROUPS
 * LOWER_BOUND_X
 * LOWER_BOUND_R
 * UPPER_BOUND_X
 * UPPER_BOUND_R
 * CENTER_X
 * NAME

0.2. CLI_C_GET_CARD_NAME
Аргументы:

Возвращает имя карты (строка).
 * ID_CARD

0.3. CLI_C_SAVE_CARD
Аргументы:

Возвращает идентификатор сохраненной контрольной карты.
 * ID_CARD=null
 * ID_FOLDER
 * ID_QUERY
 * ID_PARAM
 * SUBGROUP_SIZE
 * MAX_SUBGROUPS
 * LOWER_BOUND_X
 * LOWER_BOUND_R
 * UPPER_BOUND_X
 * UPPER_BOUND_R
 * CENTER_X
 * NAME

0.4. CLI_C_DEL_CARD
Аргументы:

Возвращает успех/неуспех.
 * ID_CARD

CLI_DIR_GET
Возвращает справочник, название которого указано в параметре PTITLE.

Возвращаемая таблица PRES содержит:

ID – Идентификатор строки справочника;

NAME – Наименование

TAG – Обозначение

DESCR – Описание

IDDS –

CLI_DIR_GET_LPC3_NTD
Возвращает справочник «НТД ЛПЦ3».

Возвращаемая таблица PRES содержит одно поле NAME – название НТД.

CLI_DIR_GET_LPC3_CUSTOMER
Возвращает справочник «Потребители ЛПЦ3».

Возвращаемая таблица PRES содержит одно поле NAME – название потребителя.

CLI_DIR_GET_STEELGRADES
Возвращает справочник «Марки стали».

Возвращаемая таблица PRES содержит одно поле NAME – название марки стали.

Категории -:База СКП - клиентское представление