Эта часть статьи - продолжение работы с Business View. Мы рассмотрим использование этого источника данных в случае необходимости использования прямого SQL-запроса.

Построим Business View на другом соединении и основании данных, чтобы в нашем распоряжении были все возможности Transact-SQL. Не будем подробно останавливаться на создании отдельных объектов, так как в первой части этой статьи они были рассмотрены подробно. Приведем здесь только основные скриншоты.

Подключаться мы будем к базе данных MS SQL Server 2005 TEST, знакомой нам по статьям, описывающим решение задачи с "сотрудниками по дням недели".

Здесь решим подобную задачу, добавив к нашим знаниям о Business View информацию о том, каковы возможности использования прямого SQL-запроса.

 

Итак, получаем Соединение данных TEST, которое сохраняем в специально созданной папке TEST.

Добавляем Основание данных TEST, используя подключение Соединение данных TEST.

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

Мы будем рассматривать более сложный пример, когда нам нужны связи OUTER, с одной стороны, от справочника Employee, а другой стороны, от запроса, возвращающего последовательный список дат в определенным периоде (о нем мы подробно говорили в статье "Кросстаб. Готовим данные."). В Business View все стандартные средства установки связей будут препятствовать установке полного пересечения множеств (декартову произведению). Поэтому нам необходимо самостоятельно обеспечить такое сочетание. Здесь мы тоже воспользуемся запросом. Добавляем Команду в наше Основание данных TEST. Тем же самым пунктом меню, как добавляли и таблицы - Вставка / Вставить таблицы данных. Только выбираем в нашем соединении не конкретную таблицу, а элемент дерева "Добавить команду ". Переименовываем ее, используя Обозреватель свойств, в "Сотрудники_по_дням_недели". Отмечу, что пробелы в наименовании недопустимы.

Соединяем получившуюся "табличку" связями с таблицей фактов Action.

Каждую связь настраиваем отдельно. Нам нужны те самые "внешние" OUTER соединения.

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

Далее необходимо создать бизнес-элемент, тот объект, который в дальнейшем при создании отчета будет "табличкой" при подключении к источнику данных.

Размещаем поля и переименовываем их:

Сотрудники_по_дням_недели.DT                                 Дата действия

Сотрудники_по_дням_недели.EmployeeId                  Идентификатор сотрудника

Сотрудники_по_дням_недели.EmployeeName            ФИО сотрудника

Action.ActionId                                                               Идентификатор действия

Сохраняем бизнес-элемент как "Действия по сотрудникам и дням недели". Отмечу еще раз, что это должен быть понятный бизнес-термин.

Создаем бизнес-представление Business View, в которое включаем бизнес-элементы, в нашем случае один бизнес-элемент, который мы назвали "Действия по сотрудникам и дням недели".

Называем бизнес-представление BV_Действия сотрудников. Здесь можно собирать все элементы, которые будем создавать в разрезе сотрудников - и отчеты по статистике, и, например, индивидуальные отчеты сотрудника, за день, за месяц и т.д. В этом случае дизайнеры отчета будут знать, что есть представление, куда обращаться, если нужны данные по сотруднику.

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

Прописываем источник данных для отчета

Далее строим кросс-таблицу, используя созданные элементы, названные по-русски, уже как "поля".

 

Ну, и получившийся отчет

Запрос в нем будет выглядеть так:

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

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