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

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

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

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

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

Объекты, из которых состоит модель бизнес-архитектуры хранятся в реляционной СУБД. Классы объектов, их параметры и связи описаны в Объектной модели (см. главу Руководство пользователя → Взаимосвязи объектов в Объектной модели 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.