Различия
Здесь показаны различия между выбранной ревизией и текущей версией данной страницы.
|
ru:manual:report:create_optimumqqq [2013/11/28 12:58] admin удалено |
— (текущий) | ||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| - | ====== Оптимизация времени построения отчетов ====== | ||
| - | Business Studio предоставляет мощный инструмент для получения необходимой информации из бизнес-модели -- Мастер отчетов. Мастер позволяет создавать пользователю отчеты без глубокого погружения в компьютерную область знаний и предоставляет больше времени на решении насущных задач. При этом в зависимости от поставленных задач к отчету и объемов данных, время выполнения отчета может быть значительным и являться критичным. | ||
| - | |||
| - | Ниже описаны основные рекомендации, которые помогут разрабатывать правильные отчеты с точки зрения ожидания их выполнения. Для решения задачи минимизации времени построения отчета необходимо знать и понимать: | ||
| - | |||
| - | - Как выстроены данные о бизнес-модели и как это влияет на скорость получения данных из базы. | ||
| - | - Каким образом отчет получает данные. | ||
| - | - Какие наиболее оптимальные пути получения необходимых данных. | ||
| - | |||
| - | ===== Объектная модель и скорость получения данных ===== | ||
| - | |||
| - | Работа Business Studio построена на СУБД MS SQL. Все данные о бизнес-модели хранятся в ней определенным образом. Структуры данных и их связи между собой описаны в Объектной модели (см. главу [[/ru/manual/report/object_model|Объектная модель]]). | ||
| - | |||
| - | Параметры (данные), которые использует пользователь в своей работе, делятся на: | ||
| - | |||
| - | - **Хранимые** -- значения параметра постоянно хранится в базе данных. | ||
| - | - **Нехранимые** -- значение параметра рассчитывается каждый раз, когда происходит обращение к параметру объекта. | ||
| - | |||
| - | Расчет нехранимых параметров означает, что в оперативную память компьютера загружаются все необходимые для их расчета хранимые параметры, а возможно, и другие расчетные (нехранимые) параметры. | ||
| - | |||
| - | Расчет некоторых параметров может быть ресурсоемким. В зависимости об объема данных, мощности компьютера и других программных условий. | ||
| - | |||
| - | Например, для физического лица в базе хранится отдельно параметры: | ||
| - | |||
| - | * Фамилия | ||
| - | * Имя | ||
| - | * Отчество | ||
| - | |||
| - | В то же время, в базе не хранятся параметры физлица такие как: | ||
| - | |||
| - | * ФИО | ||
| - | * Фамилия И.О. | ||
| - | |||
| - | Они рассчитываются каждый раз, когда необходимо их узнать. | ||
| - | |||
| - | Порядок в скорости получения данных следующий: | ||
| - | |||
| - | - Самой быстрой операцией является вывод хранимых параметров. | ||
| - | - Следующей по скорости является операция получения данных параметров типа "Список" у Классов. Получение таких списков происходит отдельным запросом к базе данных, что означает дополнительные затраты времени. Такие запросы реализованы программным кодом. | ||
| - | - Самой медленной из 3х операций является получение нехранимых параметров, так как при каждом обращении необходимо затратить время на их расчет. | ||
| - | |||
| - | ===== Хранимые фильтры ===== | ||
| - | |||
| - | Очень часто построение отчетов связано с привязками, использующими хранимые фильтры (работа с фильтрами описана в главе [[/ru/manual/filter|Фильтры]]). Поэтому время формирования отчета во многом зависит от выбранных настроек фильтра и поэтому при рассмотрении вопросов времени построения отчетов так много внимания уделяется условиям фильтров. | ||
| - | |||
| - | Создание хранимого фильтра по справочнику представляется пользователю в виде задания условий на выборку данных из большого списка параметров этого справочника. На самом деле в таком фильтре собирается множество параметров разных связанных справочников. Это обеспечивает удобство и простоту работы по созданию фильтра для пользователя. Платой за это является неоптимальность получения данных, что в ряде случаев является критичным для времени построения отчетов. | ||
| - | |||
| - | ==== Процесс выборки данных фильтром ==== | ||
| - | |||
| - | Допустим, что у хранимого фильтра заданы условия по хранимым и нехранимым параметрам. Процесс выборки данных из базы будет следующий: | ||
| - | |||
| - | - Из базы выбираются все объекты согласно условиям по хранимым параметрам. В итоге формируется "Список 1", который загружается в оперативную память компьютера. | ||
| - | - Выполняется расчет нехранимых параметров, имеющих условия выборки, для объекта из "Список 1". Если объект не удовлетворяет условию фильтра, то он удаляется из памяти. | ||
| - | * Для расчета нехранимых параметров в оперативную память загружаются все необходимые хранимые параметры. Возможно, что для расчета необходимо использовать другие расчетные данные (нехранимые параметры). На практике это означает, что довольно часто в оперативную память загружается большой объем данных, порой целые справочники. | ||
| - | * Пункт 2 выполняется для каждого объекта из "Список 1". В итоге получаем список, полностью удовлетворяющий всем заданным условиям. | ||
| - | |||
| - | [{{ ru:manual:report:create_optimum:create_filter.png?nolink |Рисунок 1. Процесс выборки данных фильтром}}] | ||
| - | |||
| - | Следствие из выше указанного алгоритма: | ||
| - | |||
| - | * по возможности создавать условия по хранимым параметрам избегая условий по нехранимым; | ||
| - | * создавать условия по хранимым параметрам так, чтобы они делали как можно меньшим "Список 1". | ||
| - | |||
| - | ==== Особенности работы с памятью ==== | ||
| - | |||
| - | В случае, если в результатах необходимо показать значения нехранимых параметров, то для всех объектов из "Списка 1" производится необходимый расчет значений -- в очередной раз в оперативную память компьютера будут загружаться все необходимые параметры для расчета. | ||
| - | |||
| - | На скорость выполнения фильтров может так же влиять то обстоятельство, что необходимые параметры или справочники могут уже находиться в оперативной памяти. Они могли быть загружены при выполнении каких-либо предыдущих операций. Поэтому , один и тот же фильтр может иметь различное время выполнения для ситуаций: | ||
| - | |||
| - | * Фильтр запустили на выполнение сразу после запуска Business Studio (максимальное время выполнения). | ||
| - | * Фильтр запустили на выполнение после какого-то времени работы с Business Studio (время может быть меньше чем максимальное). | ||
| - | |||
| - | Некоторые нехранимые параметры для своих расчетов требуют загрузки в оперативную память компьютера множество параметров (иногда более 90% данных всей базы). Например, параметр "Связи процессов по объектам" у Процессов. | ||
| - | |||
| - | ==== Наложение фильтра на привязки со списками ==== | ||
| - | |||
| - | В случаях, когда необходимо вывести фильтрованные значения нехранимого списка, то рекомендуется вывести этот нехранимый список в привязке типа "Список" или "BAND" и наложить на него фильтр. В этом случае при фильтрации никаких запросов к базе данных происходить не будет. | ||
| - | |||
| - | ==== Отображение нехранимых параметров в фильтре ==== | ||
| - | |||
| - | Некоторые фильтры в своих условиях не содержат нехранимые параметры, которые можно видеть в объектной модели. Решение о выводе или не выводе таких параметров принимает разработчик. Например, параметр "Полный путь", который встречается во многих справочниках. | ||
| - | |||
| - | ===== Рекомендации по выбору оптимальных путей создания привязок ===== | ||
| - | |||
| - | Исходя из выше изложенного, можно сказать, что минимальное время на построение отчета зависит от времени выборки данных фильтрами и привязками, на которое влияет: | ||
| - | |||
| - | - Выбор "правильных" элементов объектной модели для фильтрации. | ||
| - | - Настройки конфигурации условий запросов к данным между фильтрами и привязками отчета. | ||
| - | |||
| - | В зависимости от решаемой задачи, предлагается придерживаться следующих рекомендаций. | ||
| - | |||
| - | ==== Рекомендация 1 - Создавать фильтры по хранимым параметрам и спискам ==== | ||
| - | ---- | ||
| - | **__Рекомендация__: создавать фильтры по возможности по хранимым параметрам и спискам.** | ||
| - | ---- | ||
| - | Если одни и те же данные можно получить фильтрацией по хранимому или нехранимому параметру ), то необходимо создавать условия по хранимому. | ||
| - | |||
| - | **Пример 1.1. Необходимо увидеть все декомпозированные процессы.** | ||
| - | |||
| - | Задача требует показать все процессы, ниже которых есть какие-либо процессы. Узнать это можно по одному из параметров процессов: | ||
| - | |||
| - | * Количество потомков -- нехранимый параметр (условие -- кол-во потомков не равно 0). | ||
| - | * Подпроцессы -- хранимый параметр (условие -- подпроцессы в списке есть). | ||
| - | |||
| - | Работа фильтра с условием по параметру **"Количество потомков"** | ||
| - | |||
| - | - В оперативную память будут загружены **ВСЕ** процессы бизнес-модели. | ||
| - | - Для каждого процесса выполняется расчет параметра "Количество потомков". | ||
| - | - Из всех процессов в оперативной памяти будут выбраны те процессы, которые удовлетворяют условиям по параметру "Количество потомков". | ||
| - | |||
| - | Работа фильтра с условием по параметру **"Подпроцессы"** | ||
| - | |||
| - | - В оперативную память будут загружены процессы, удовлетворяющие условию по параметру "Подпроцессы". | ||
| - | |||
| - | Как видно из описанного выше, условия в фильтре следует выставлять по хранимому параметру "Подпроцессы". | ||
| - | |||
| - | При решении поставленной задачи так же следует обратиться к [[#рекомендация_3_сужать_область_поиска_по_хранимым_параметрам|Рекомендации 3]] -- сузить поиск задав условия для хранимых параметров. А именно: | ||
| - | |||
| - | - Отбросить процессы, не являющиеся нотациями процессов: Папка, Внешняя ссылка, Служебный. | ||
| - | - Отбросить процессы, которые не будут иметь подпроцессы в силу своей природы: Действия, Решения. | ||
| - | |||
| - | С точки зрения минимизации времени получения данных, на закладке "Условия" в фильтре по процессам следует выставить такие условия, как приведены ниже. | ||
| - | |||
| - | <startTableBox> | ||
| - | ^ Параметр ^ Тип ^ Оператор ^ Значение ^ Не ^ Потомки ^ | ||
| - | | Подпроцессы | Подфильтр | = | | | | | ||
| - | | - Процесс | Значение | = | | + | | | ||
| - | | Тип процесса | Список значений | = | · Папка · Внешняя ссылка · Служебный · Действие · Решение | + | | | ||
| - | <endTableBox| Таблица Х. Условия фильтра> | ||
| - | |||
| - | ==== Рекомендация 2 – Создавать фильтры по "Элементам списков" и Связям ==== | ||
| - | ---- | ||
| - | **__Рекомендация__: создавать фильтры по возможности по "Элементы списков" и справочникам связей, чем по параметрам типа "Список", где** | ||
| - | |||
| - | * **Элементы списков -- Корневой раздел в Объектной модели** (см. [[/ru/manual/report/object_model#элементы_списков|Элементы списков]] статьи [[/ru/manual/report/object_model|Объектная модель]]); | ||
| - | * **Связи -- справочники в Объектной модели** (Классы -- Общие связи). | ||
| - | |||
| - | ----- | ||
| - | Как было указано ранее, параметры типа "Список" являются сами по себе фильтрами. Поэтому вывод списков у объектов в "Класс" или фильтр по таким спискам, приводят к созданию подзапросов SQL, что приводит к дополнительным затратам времени на получение необходимой выборки данных. В то же время "Элементы списков" по сути являются просто Справочниками, так же как и справочники в "Классы". Фильтрация по справочнику -- чистый запрос SQL, он работает быстрей. | ||
| - | |||
| - | Эта рекомендация работает почти во всех случаях, когда нужно найти что-то по связям чего-то с чем-то. В случае, если надо найти отсутствие этих связей, то необходимо делать поиск через "Классы". | ||
| - | |||
| - | **Пример 2.1 Необходимо получить список процессов, у которых на закладке "Нормативно-справочные документы" есть хотя бы один документ.** | ||
| - | |||
| - | У задачи есть 2 решения: | ||
| - | |||
| - | - Создать фильтр по классу "Процессы" и выставить условия по списку "Нормативно-справочные документы". | ||
| - | - Создать фильтр по элементу списков "БизнесМодель.СписокНСДПроцессов" (Элементы списков - БизнесМодель.СпискиНСД). | ||
| - | |||
| - | С точки зрения минимизации времени получения данных, правильным будет второй путь. "БизнесМодель.СписокНСДПроцессов" содержит только информацию о существующих связях процессов с документами -- одна строка показывает связь одного документа с одним процессом. Поэтому условий у фильтра никаких не будет. Следует просто вывести на показ название процесса (параметр Владелец). При этом следует понимать, что за одним процессом может быть закреплено несколько документов. Поэтому может быть несколько строк, у которых процессы одинаковые. Это приведет к дублированию информации. Чтобы этого не происходило, необходимо на закладке "Группировка" выставить группировку по параметру "Владелец". | ||
| - | |||
| - | Т.е. все что необходимо сделать в фильтре, это выставить группировку. | ||
| - | |||
| - | ==== Рекомендация 3 –Сужать область поиска по хранимым параметрам ==== | ||
| - | ---- | ||
| - | **__Рекомендация:__ Во всех фильтрах как можно больше сужать область поиска по хранимым параметрам.** | ||
| - | ---- | ||
| - | Исходя из того, что: | ||
| - | |||
| - | * Самыми быстрыми операциями являются операции с хранимыми параметрами. | ||
| - | * Чем меньше данных будет выбрано для обработки, тем быстрее произойдет обработка данных. | ||
| - | |||
| - | Поэтому, необходимо задавать условия по хранимым фильтром так, чтобы в результаты фильтра попадало больше целевой информации, чтобы свести к минимуму количество операций для её последующей обработки: расчету нехранимых параметров, дополнительной фильтрации. | ||
| - | |||
| - | **Пример 3.1. Необходимо найти все процессы первого уровня.** | ||
| - | |||
| - | Ключевым условием в данном случае является поиск значения нехранимого параметра "Уровень". Это означает, что для всех процессов модели необходимо провести расчет этого параметра и выбрать подходящие по условию. | ||
| - | |||
| - | Количество таких расчетов можно сократить, если из списка сразу исключить те процессы, которые не могут иметь искомое значение уровня. Это процессы с типом: Действие, Решение, Внешняя ссылка, Служебный. Тип процесса является хранимым параметром, поэтому это подходит для задач сужения области поиска. | ||
| - | |||
| - | С точки зрения минимизации времени получения данных, правильными будут вот такие условия поиска в фильтре по справочнику "Процессы". | ||
| - | |||
| - | <startTableBox> | ||
| - | ^ Параметр ^ Тип ^ Оператор ^ Значение ^ Не ^ Потомки ^ | ||
| - | | Тип процесса | Список значений | = | · Действие · Решение · Внешняя ссылка · Служебный | + | | | ||
| - | | Уровень | Значение | = | 1 | | | | ||
| - | <endTableBox| Таблица Х. Условия фильтра> | ||
| - | ==== Рекомендация 4 – Не включать опции привязок если это не требуется ==== | ||
| - | ---- | ||
| - | **__Рекомендация__: если известно, что данные в сложной привязке не будут иметь дублирования или пустых строк, то не рекомендуется на всякий случай выставлять опции:** | ||
| - | * **Удалять повторяющиеся строки,** | ||
| - | * **Удалять пустые строки.** | ||
| - | |||
| - | -------- | ||
| - | |||
| - | Каждая такая опция означает дополнительное время на анализ данных. А если мы заранее знаем, что в списке нет дубликатов или пустых значений, то время будет потрачено зря. | ||
| - | |||
| - | Исходя из изложенного выше, следует следующая рекомендация. | ||
| - | |||
| - | ==== Рекомендация 5 – Выполнять операции на уровне фильтров (они быстрее), чем на уровне привязок ==== | ||
| - | ---- | ||
| - | **__Рекомендация__: По возможности настраивать хранимый фильтр, чтобы полученные данные не содержали дублирования (группировка) или пустых значений (условия). Чтобы не делать исключение дубликатов и пустых строк в настройках привязок.** | ||
| - | ---- | ||
| - | Это так потому, что скорость подобных операций при выполнении SQL-запроса выше и меньше информации передается по сети между SQL-сервером и компьютером пользователя. | ||
| - | |||
| - | По возможности необходимо делать настройки фильтра таким образом, чтобы исключить дублирование в выводе информации. Например, делать не просто вывод параметров на показ, а выводить их с группировкой. Это позволит сократить время на последующую обработку полученных данных для избавления от дубликатов. | ||
| - | |||
| - | Как правило, группировка будет актуальна при работе со списками элементов, потому как они содержат информацию по различным связям и именно там встречаются записи с одинаковыми параметрами. В то же время, повторяющихся элементов в Справочниках ("Классы"), обычно не бывает. | ||
| - | |||
| - | **Пример 5.1. Получить список всех процессов, у которых есть исполнители.** | ||
| - | |||
| - | [[##рекомендация_2_создавать_фильтры_по_элементам_списков_и_связям|Согласно рекомендации 2]] решаем, что искать такие процессы правильно по справочнику "Связи субъекта с процессом " (Классы -- Общие связи -- БизнесМодель.СвязиПроцессов). Условия фильтра будут такие, как приведены ниже. | ||
| - | |||
| - | <startTableBox> | ||
| - | ^ Параметр ^ Тип ^ Оператор ^ Значение ^ Не ^ Потомки ^ | ||
| - | | Тип связи | Подфильтр | = | | | | | ||
| - | | Категория | Значение | = | Исполнитель процесса | | | | ||
| - | <endTableBox| Таблица Х. Условия фильтра> | ||
| - | Потому, что данный справочник содержит информацию по каждой связи процесса с субъектом, может быть дублирование информации. Т.е. одна строка содержит информацию только по одному процессу и одному связанному с ним субъекту. Это ситуация, когда у процесса более 1-го исполнителя. | ||
| - | |||
| - | Поэтому, для отображения данных по результату выполнения фильтра, необходимо на закладке "Группировка" установить галочку напротив параметра "Процесс". | ||
| - | |||
| - | Если бы группировки в фильтре не было, то было бы необходимо в настройки сложной привязки типа "Фильтр" устанавливать опцию "Удалять повторяющиеся строки", что привело бы к загрузке в оперативную память списка с дубликатами процессов. | ||
| - | |||
| - | ==== Рекомендация 6 - На закладке "Показ" в фильтре выводить хранимые параметры на показ ==== | ||
| - | ---- | ||
| - | ** __Рекомендация__: в фильтре на вкладке «Показ» выставлять галочки для тех хранимых параметров, которые нужны для расчета нехранимых. Это значительно сильно ускорит их расчет, ведь они будут загружены одним запросом, вместо того, чтобы загружаться каждый раз отдельно для каждого расчета.** | ||
| - | ---- | ||
| - | Загруженные параметры в память могут использоваться для разных операций. Поэтому лучше необходимые данные загрузить в память один раз и из базы данных, чем обращаться к базе по чуть-чуть каждый раз. Поэтому, если знаем (или предполагаем), что какой-то нехранимый параметр, который имеет условие, для своего расчета требует данные хранимых параметров из справочника, то лучше выставить галочки для этих параметров на закладке "Показ". | ||
| - | |||
| - | Таким же образом следует поступать, если фильтр в отчете должен показывать свои нехранимые параметры. | ||
| - | |||
| - | **Пример 6.1. В отчете вывести физических лиц с именем "Александр" в виде "Фамилия И.О."** | ||
| - | |||
| - | Задача решается путем создания фильтра по физическим лицам с условием: | ||
| - | |||
| - | <startTableBox> | ||
| - | ^ Параметр ^ Тип ^ Оператор ^ Значение ^ Не ^ Потомки ^ | ||
| - | | Имя | Значение | ~ | Александр | | | ||
| - | <endTableBox| Таблица Х. Условия фильтра по справочнику "Физические лица"> | ||
| - | |||
| - | В отчете в настройках сложной привязки типа "Фильтр" выбирается на показ параметр "Фамилия И.О.", который является нехранимым. Поэтому, для ускорения создания отчета в настройках фильтра на закладке "Показ" необходимо установить галочки для параметров: | ||
| - | * Фамилия | ||
| - | * Имя | ||
| - | * Отчество | ||
| - | |||
| - | ==== Рекомендация 7 – Параметр условий "Потомки" использовать в справочниках стандартной иерархии ==== | ||
| - | ----- | ||
| - | **__Рекомендация__: в условиях фильтра использовать параметр "Потомки" не рекомендуется для справочников с нестандартной иерархией (Процессы и Субъекты). Этот параметр можно использовать для справочников со стандартной иерархией (все остальные иерархические справочники).** | ||
| - | ---- | ||
| - | Работа по признаку "Потомки" в Процесса и Субъектах ведется так же как и работа с нехранимыми параметрами и этот нехранимый параметр является высоко затратным для расчетов. У других справочников работа с "Потомки" -- как работа с хранимыми параметрами. | ||
| - | |||
| - | **Пример 7.1. От субъекта получить список сотрудников (Фамилия) нижележащих субъектов. ** | ||
| - | |||
| - | В отчете по субъекту эту задачу можно решить 2мя путями: | ||
| - | |||
| - | - Через создание привязки типа "Список" по параметру "Все сотрудники". | ||
| - | - Через создание привязки типа "Фильтр": | ||
| - | |||
| - | * Фильтр создается по справочнику "Связи ФизЛиц с Субъектами" с условием: | ||
| - | |||
| - | <startTableBox> | ||
| - | ^ Параметр ^ Тип ^ Оператор ^ Значение ^ Не ^ Потомки ^ | ||
| - | | Субъект | Подфильтр | = | | | + | | ||
| - | <endTableBox| Таблица Х. Условия фильтра> | ||
| - | |||
| - | * Соответствия фильтра: | ||
| - | <startTableBox> | ||
| - | ^Название условия фильтра ^ Параметр класса ^ Параметр фильтра^ | ||
| - | | | [Объект] | Субъект | | ||
| - | <endTableBox| Таблица Х. Соответствия фильтра в настройке сложной привязки> | ||
| - | |||
| - | |||
| - | С точки зрения минимизации времени получения данных, правильным будет первый путь так второй путь предполагает работу с параметром "Потомки" справочника с нестандартной иерархией. Работа с нехранимым параметром "Все сотрудники" выполняется быстрее, так как этот параметр оптимизирован по быстродействию разработчиком. | ||
| - | |||
| - | В подобных ситуациях если в классах уже есть параметры, предоставленные разработчиком, то рекомендуется использовать их, а не создавать свои условия. Они уже оптимизированы по времени выполнения. | ||
