Оптимизация времени построения отчетов

Business Studio предоставляет мощный инструмент для получения необходимой информации из бизнес-модели - Мастер отчетов.

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

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

• как выстроены данные о бизнес-модели и как это влияет на скорость получения данных из базы;
• каким образом отчет получает данные;
• какие наиболее оптимальные пути получения необходимых данных.

Работа Business Studio построена на СУБД MS SQL. Все данные о бизнес-модели хранятся в ней определенным образом. Структуры данных и их связи между собой описаны в Объектной модели (см. главу Руководство пользователя → Взаимосвязи объектов в Объектной модели Business Studio).

Параметры (данные), которые использует пользователь в своей работе, делятся на:

• Хранимые - значение параметра постоянно хранится в базе данных;
• Нехранимые - значение параметра рассчитывается каждый раз, когда происходит обращение к параметру объекта.

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

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

Например, для физического лица в базе данных хранятся отдельно параметры:

• "Фамилия"
• "Имя"
• "Отчество"

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

• "ФИО"
• "Фамилия И.О."

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

Порядок в скорости получения данных следующий:

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

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

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

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

1. из базы выбираются все объекты согласно условиям по хранимым параметрам. В итоге формируется "Список 1", который загружается в оперативную память компьютера;
2. выполняется расчет нехранимых параметров, имеющих условия выборки, для объекта из "Список 1". Если объект не удовлетворяет условию фильтра, то он удаляется из памяти.
   • для расчета нехранимых параметров в оперативную память загружаются все необходимые хранимые параметры. Возможно, для расчета необходимо использовать другие расчетные данные (нехранимые параметры). На практике это означает, что довольно часто в оперативную память загружается большой объем данных, порой целые справочники;
   • пункт 2 выполняется для каждого объекта из "Список 1". В итоге получаем список, полностью удовлетворяющий всем заданным условиям.

Рисунок 1. Процесс выборки данных фильтром

Следствие из выше указанного алгоритма:

• по возможности следует создавать условия по хранимым параметрам, избегая условий по нехранимым параметрам;
• необходимо создавать условия по хранимым параметрам так, чтобы они делали "Список 1" как можно меньшим.

В случае, если в результатах необходимо показать значения нехранимых параметров, то для всех объектов из "Списка 1" производится необходимый расчет значений - в очередной раз в оперативную память компьютера будут загружаться все необходимые параметры для расчета.

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

• фильтр запустили на выполнение сразу после запуска Business Studio (максимальное время выполнения);
• фильтр запустили на выполнение после какого-то времени работы с Business Studio (время может быть меньше, чем максимальное).

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

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

Некоторые фильтры в своих условиях не содержат нехранимые параметры, которые можно видеть в Объектной модели (Главное меню → Отчеты → Объектная модель). Решение о выводе или не выводе таких параметров принимает разработчик. Например, параметр "Полный путь", который встречается во многих справочниках.

Исходя из выше изложенного, можно сказать, что минимальное время на построение отчета зависит от времени выборки данных фильтрами и привязками, на которое влияет:

1. выбор "правильных" элементов объектной модели для фильтрации;
2. настройки конфигурации условий запросов к данным между фильтрами и привязками отчета.

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

Создавать фильтры следует по возможности по хранимым параметрам и спискам.

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

Пример. Необходимо увидеть все декомпозированные процессы.

Задача требует показать все процессы, ниже которых есть какие-либо процессы. Узнать это можно по одному из параметров процессов:

• "Количество потомков" - нехранимый параметр (условие - кол-во потомков не равно 0);
• "Подпроцессы" - хранимый параметр (условие - подпроцессы в списке есть).

Работа фильтра с условием по параметру "Количество потомков":

1. в оперативную память будут загружены ВСЕ процессы бизнес-модели;
2. для каждого процесса выполняется расчет параметра "Количество потомков";
3. из всех процессов в оперативной памяти будут выбраны те процессы, которые удовлетворяют условиям по параметру "Количество потомков".

Работа фильтра с условием по параметру "Подпроцессы":

1. в оперативную память будут загружены процессы, удовлетворяющие условию по параметру "Подпроцессы".

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

При решении поставленной задачи также следует обратиться к Рекомендации 3 - сузить поиск, задав условия для хранимых параметров. А именно:

1. отбросить процессы, тип которых не относится к следующим: Папка, Внешняя ссылка, Служебный;
2. отбросить процессы, которые не будут иметь подпроцессы в силу своей природы: Действия, Решения.

С точки зрения минимизации времени получения данных, на вкладке Условия в фильтре по процессам следует выставить следующие условия:

Создавать фильтры следует по возможности по "Элементам списков" и справочникам связей, а не по параметрам типа "Список", где:

• "Элементы списков" - корневой раздел в Объектной модели (см. статью Руководство пользователя → Элементы списков);
• Связи - справочники в Объектной модели (Классы → Общие связи).

Как было указано ранее, параметры типа "Список" являются сами по себе фильтрами. Поэтому вывод списков у объектов в "Класс" или фильтр по таким спискам приводят к созданию подзапросов SQL, что приводит к дополнительным затратам времени на получение необходимой выборки данных. В то же время "Элементы списков" являются просто справочниками, так же как и справочники в Классах. Фильтрация по справочнику - чистый запрос SQL, он работает быстрей.

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

Пример. Необходимо получить список процессов, у которых на вкладке Нормативно-справочные документы есть хотя бы один документ.

У задачи есть 2 решения:

1. Создать фильтр по справочнику "Процессы" и выставить условия по списку "Нормативно-справочные документы".
2. Создать фильтр по элементу списков "БизнесМодель.СписокНСДПроцессов" (Элементы списков → БизнесМодель.СпискиНСД).

С точки зрения минимизации времени получения данных правильным будет второй путь. "БизнесМодель.СписокНСДПроцессов" содержит только информацию о существующих связях процессов с документами - одна строка показывает связь одного документа с одним процессом. Поэтому условий у фильтра никаких не будет. Следует просто вывести на показ название процесса (параметр "Владелец"). При этом следует понимать, что за одним процессом может быть закреплено несколько документов. Поэтому может быть несколько строк, у которых процессы одинаковые. Это приведет к дублированию информации. Чтобы этого не происходило, необходимо на вкладке Группировка выставить группировку по параметру "Владелец".

Т.е. все что необходимо сделать в фильтре, это выставить группировку.

Во всех фильтрах следует как можно больше сужать область поиска по хранимым параметрам.

Следует учитывать, что:

• Самыми быстрыми операциями являются операции с хранимыми параметрами.
• Чем меньше данных будет выбрано для обработки, тем быстрее произойдет обработка данных.

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

Пример. Необходимо найти все процессы первого уровня.

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

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

С точки зрения минимизации времени получения данных правильными будут вот условия поиска в фильтре по справочнику "Процессы", приведенные в Таблице 2.

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

• Удалять повторяющиеся строки;
• Удалять пустые строки.

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

Исходя из изложенного выше, следует следующая рекомендация.

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

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

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

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

Пример. Получить список всех процессов, у которых есть исполнители.

Согласно рекомендации 2 решаем, что искать такие процессы правильно по справочнику "Связи субъекта с процессом" (Классы → Общие связи → БизнесМодель.СвязиПроцессов). Условия фильтра будут такие, как приведены в Таблице 3.

Данный справочник содержит информацию по каждой связи процесса с субъектом. Поэтому может быть дублирование информации. Т.е. одна строка содержит информацию только по одному процессу и одному связанному с ним субъекту. Это ситуация, когда у процесса более 1-го исполнителя.

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

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

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

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

Таким же образом следует поступать, если фильтр в отчете должен показывать свои нехранимые параметры.

Пример. В отчете вывести физических лиц с именем "Александр" в виде "Фамилия И.О."

Задача решается путем создания фильтра по физическим лицам с условием, приведенным в Таблице 4.

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

• "Фамилия"
• "Имя"
• "Отчество"

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

Работа по признаку "Потомки" в справочниках "Процессы" и "Субъекты" ведется так же, как и работа с нехранимыми параметрами. Этот нехранимый параметр является высоко затратным для расчетов. У других справочников работа с "Потомки" аналогична работе с хранимыми параметрами.

Пример. От субъекта получить список сотрудников (Фамилия) нижележащих субъектов. 

В отчете по субъекту эту задачу можно решить двумя путями:

1. Через создание привязки типа "Список" по параметру "Все сотрудники".
2. Через создание привязки типа "Фильтр":

• Фильтр создается по справочнику "Связи ФизЛиц с Субъектами" с условием, приведенным в Таблице 5.

• Соответствия фильтра приведены в Таблице 6.

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

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

Вставка полей RTF занимает больше времени, чем вставка обычных текстовых полей.
Для ускорения процесса формирования отчётов можно:

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

Пример. К процессу нужно приложить документ, содержащий значительное количество информации

В данном случае рекомендуем сделать следующее:

• Всю информацию поместить в документ MS Word (*.doc, *.docx).
• Создать бумажный\электронный документ и в поле "Файл бумажного документа" указать ссылку на этот документ.
• Поместить данный документ на вкладку "Нормативно-справочные документы" процесса.

В отчёте нужно создать следующую привязку:

• Тип привязки "BAND".
• Источник данных "Объект" - "Нормативно-справочные документы".
  Чтобы её найти, поставьте галку "Показывать всё" в левом верхнем углу окна.
• Параметр объекта "Файл"

Такой вариант отчёта будет формироваться быстрее, чем вариант с выводом содержимого полей RTF.