Часть 1  Часть 2  Часть 3  Часть 4

Продолжение.

6. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: БАЗОВЫЙ И КОМПОЗИТНЫЙ КУБЫ

6.1. Базовый куб

6.2. Композитный куб

6.2.1 Основные элементы кода

6.2.2 Расширение SELECT-листа с помощью Path Expressions

6.2.3 Семантическое обогащение ракурса с использование ассоциаций

6.2.4 Тестирование данных композитного ракурса

7. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: РАКУРС ИСПОЛЬЗОВАНИЯ

7.1 Создание аналитического ракурса

7.2 Указание строк и столбцов отчёта. Создание фильтров для селекционного экрана. Создание расчётного показателя

7.3 Тестирование аналитического ракурса

8. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: ИТОГ

6. ДЕМОНСТРАЦИОННАЯ МОДЕЛЬ: БАЗОВЫЙ И КОМПОЗИТНЫЙ КУБЫ

6.1. Базовый куб

Продолжим построение демонстрационного примера. Теперь нам требуется создать ракурс ZI_FLIGHT, использующий не основные, а транзакционные данные о конкретных авиарейсах, их датах, количествах и суммах произведённых бронирований. Эти данные содержатся в таблице SFLIGHT. Данные требуется обогатить информацией из основных данных: авиакомпании, типы воздушных судов, авиарейсы. Ракурс, в котором таблица транзакционных данных обогащается присоединением ряда справочников должен относиться уже к категории данных #CUBE. И это несмотря на то, что в качестве таблицы фактов используется таблица БД, а не другой ракурс категории #FACT. Кроме того, новый ракурс уже не будет использован как справочник в последующих ракурсах нашей модели. Итак, категория данных для нового ракурса – это #CUBE. Тем не менее, ракурс основан на таблице БД, поэтому он должен быть определён как базовый. Учитывая всё сказанное, создадим новый ракурс, указав в его заголовке набор аннотаций как на Рис.125.

Рис.125. Аннотации в заголовке ракурса ZI_FLIGHT

Аннотация @AbapCatalog.compiler.compareFilter здесь не используется, так как не предполагается наличия фильтров.

Указываем, что источником данных для ракурса является таблица SFLIGHT (см. Рис.126).

Рис.126. Указание исходной таблицы ракурса ZI_FLIGHT

Добавляем поля из этой таблицы в SELECT-лист. Сразу присваиваем этим полям семантически удобные имена. И указываем ключевые поля, соответствующие ключу таблицы SFLIGHT (см. Рис.127).

Рис.127. SELECT-лист ракурса ZI_FLIGHT

Чтобы обогатить транзакционные данные с помощью основных, используем ранее созданные ракурсы категории #DIMENSION. Добавим их с помощью ассоциаций к полям AirLine, FlightConnection и AircraftType (см. Рис.128).

Рис.128. Семантическое обогащение ракурса ZI_FLIGHT с помощью ассоциаций

Отметим, что ассоциация с ZI_FLIGHTCONNECTION идёт сразу по двум полям, так как в этом ракурсе два ключевых поля.

Не забываем сразу же включить эти ассоциации в SELECT-лист (см. Рис.129).

Рис.129. Публикация ассоциаций в SELECT-листе ракурса ZI_FLIGHT

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

Всё что остаётся теперь – это добавить семантические аннотации к полям SELECT-листа. Все эти аннотации уже знакомы и разбирались ранее: это указание на способ агрегации и на единицы измерения числовых полей, на поля, являющиеся единицами измерения. Поля, соответствующие денежным суммам, измеряются в валюте суммы. А поля, подсчитывающие количество мест в самолёте, не имеют никаких единиц измерения. Также мы снова используем аннотации @ObjectModel.foreignKey.association для «прикрепления» основных данных как средств поиска к полям SELECT-листа. Итоговый код ракурса ZI_FLIGHT показан на Рис.130.

Рис.130. Код ракурса ZI_FLIGHT

6.2. Композитный куб

6.2.1 Основные элементы кода

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

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

В нашем примере исключение избыточности выражается в том, что ракурсы ZI_FLIGHTCONNECTION и ZI_FLIGHT имеют полностью различные поля в SELECT-листах (за исключением пары ключевых полей AirLine и FlightConnection). Теперь требуется построить композитный ракурс, представляющий все возможные поля. Поскольку он будет содержать в своей основе транзакционные данные, то это должен быть ракурс категории #CUBE. Техническое имя нового DDL-источника будет ZI_FLIGHTBYAIRPORT. Исходя из сказанного, в заголовке нового ракурса потребуются следующие аннотации, показанные на Рис.131.

Рис.131. Аннотации в заголовке ракурса ZI_FLIGHTBYAIRPORT

Аннотация @Analytics.dataExtraction.enabled в данном примере исключена, так как мы формируем избыточный набор данных, а требования к экстракции, как правило, таковы, что избыточность и дублирование должны быть исключены.

Источником данных будет ракурс, содержащий транзакционную информацию (см. Рис.132).

Рис.132. Указание источника данных ракурса ZI_FLIGHTBYAIRPORT

В данном ракурсе не потребуется определять какие-либо ассоциации, так как все необходимые ассоциации уже были заданы в ракурсах базового уровня. И поскольку они были опубликованы там в соответствующих SELECT-листах, то могут быть повторно использованы в новом ракурсе благодаря функциональности path expressions.

Теперь можно упростить формирование SELECT-листа следующим образом. Необходимо установить курсор на строку 9 и нажать CTRL+SPACE, вызвав Code Completion (см. Рис.133).

Рис.133. Быстрое заполнение SELECT-листа с помощью Code Completion

В открывшемся списке выбрать «Insert all elements». Таким образом, в SELECT-лист будут автоматически добавлены все поля из ракурса ZI_FLIGHT. Причём уже с семантически понятными именами, которые были в нём определены. Более того, будут автоматически опубликованы «по наследству» и все ассоциации, ранее опубликованные в ZI_FLIGHT (см. Рис.134).

Рис.134. SELECT-лист, заполненный полями и ассоциациями, унаследованными от ракурса-источника

6.2.2 Расширение SELECT-листа с помощью Path Expressions

Мы исходим из требования предоставить для аналитических приложений максимально широкий набор полей. Все аналитики, по которым можно будет детализировать данные в отчётах, нужно объявить ключевыми полями. В этом есть аналогия с классическим понятием OLAP-куба, в котором все аналитики таблицы фактов являются ключевыми полями. А согласно требованиям синтаксиса CDS, все ключевые поля должны быть перечислены подряд в начале SELECT-листа. Поэтому числовое поле FlightPrice перемещаем в списке ниже. А все аналитики прописываем как ключевые поля (см. Рис.135).

Рис.135. SELECT-лист, скорректированный с учётом аналитических требований

Добавим также в список доступных аналитик поля AirportFrom и AirportTo. Этих полей нет в ZI_FLIGHT. Но они есть в ассоциации _FlightConnection, опубликованной в ZI_FLIGHT. Поэтому мы добавим эти поля, воспользовавшись возможностями path expressions. Под новые поля добавим две пустых строки в SELECT-лист после поля FlightDate. Вызовем список Code Completion в первой добавленной строке и начнём набор символов _Fl…  Появится имя нужной ассоциации (см. Рис.136).

Рис.136. Создание Path Expression: поиск ассоциации с помощью Code Completion

Выберем это имя. Затем нужно набрать точку, после которой снова вызвать Code Completion. Теперь уже появится список полей из SELECT-листа ассоциации _FlightConnection. В нём выбираем нужное поле (см. Рис.137).

Рис.137. Создание Path Expression:включение в SELECT-лист поля из выбранной ассоциации с помощью Code Completion

В начале списка Code Completion перечислены все ассоциации, которые опубликованы в _FlightConnection. Поскольку эта ассоциация определена в ZI_FLIGHT, то смотрим код этого ракурса и видим, что под именем _FlightConnection «скрывается» ракурс ZI_FLIGHTCONNECTION. Поэтому здесь в начале списка Code Completion перечислены те три ассоциации, которые есть в ZI_FLIGHTCONNECTION. Нужно учесть это и не ошибиться: добавить не ассоциацию _AirportFrom, а именно поле AirportFrom из списка полей в _FlightConnection. Это поле выделено на Рис.137. Аналогично добавляется поле AirportTo. После добавленных полей нужно поставить запятые, как разделители в SELECT-листе.

Теперь в коде появляется сообщение об ошибке (см. Рис.138).

Рис.138. Ошибка в порядке ключевых полей ракурса ZI_FLIGHTBYAIRPORT

Это то условие синтаксиса CDS, о котором уже говорилось: все ключевые поля должны быть перечислены подряд и идти в начале SELECT-листа. А наши два новых поля разрывают последовательность ранее указанных ключевых полей. Но поскольку новые поля добавлены тоже как будущие аналитики в отчётах, то и они должны быть объявлены ключевыми. Что сразу устраняет ошибку (см. Рис.139).

Рис.139. Оформление списка ключевых полей ракурса ZI_FLIGHTBYAIRPORT

6.2.3 Семантическое обогащение ракурса с использование ассоциаций

Теперь можно начать семантическое обогащение ракурса ZI_FLIGHTBYAIRPORT, добавляя семантические аннотации к его полям. А также добавляя аннотацию @ObjectModel.foreignKey.association ко всем возможным аналитикам (а в нашем примере ассоциации с основными данными созданы для всех аналитик, кроме FlightDate и Currency). Все эти аннотации уже известны и пояснений не требуют (см. Рис.140). Можно только заметить, что для полей с денежными суммами уже не используется аннотация @Semantics.amount.currencyCode, так как эта информация есть в исходном ракурсе ZI_FLIGHT

Рис.140. Семантическое обогащение SELECT-листа с помощью аннотаций

Дополнительно добавим аннотации с новыми названиями полей для аэропортов отправления и прибытия (см. Рис.141).

Рис.141. Указание новых названий для пунктов отправления и назнапчения

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

Теперь при проверке и активации появляются новые ошибки (см. Рис.142).

Рис.142. Ошибки, связанные с использованием «не своих» ассоциаций

И действительно: указанные ассоциации недоступны напрямую в ракурсе ZI_FLIGHT, по которому сформирован наш SELECT-лист. Но эти две ассоциации определены в ракурсе ZI_FLIGHTCONNECTION, доступном из ZI_FLIGHT через ассоциацию _FlightConnection. Чтобы устранить данную ошибку, достаточно в явном виде опубликовать нужные ассоциации в нашем SELECT-листе. Возможности path expressions делают это элементарным (см. Рис.143).

Рис.143. Повторное использование (публикация) ассоциаций через Path Expressions

Нужно отметить, что таким способом мы не только устранили ошибку. Но и опубликовали ассоциации _AirportFrom и _AirportTo для дальнейшего использования напрямую из ракурса ZI_FLIGHTBYAIRPORT. То есть теперь, если мы в каком-то новом ракурсе будем формировать SELECT-лист из ZI_FLIGHTBYAIRPORT, то эти  две ассоциации будут доступны напрямую, без добавления промежуточного path expression (такого как _FlightConnection). Пример показан на Рис.144

Рис.144. Возможность прямого использования повторно опубликованных ассоциаций

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

На этом подготовка кода для ракурса ZI_FLIGHTBYAIRPORT завершена, его можно сохранить и активировать.

6.2.4 Тестирование данных композитного ракурса

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