Генератор звітів Crystal Reports і дизайнер Юніверсом Universe Designer. Побудова звіту з кросстабліцей. Джерело даних – Юніверс., Різне, Інтернет-технології, статті

В попередній статтіми розглянули кілька варіантів написання SQL-запитів з формування даних для поширеного звіту, разом кросстабліцу. У даній статті пропонується ще один варіант рішення, в основі якого лежить використання технології SAP Business Objects – Юніверс – проміжного шару метаданих, за допомогою якого користувачі виконують запити до бази даних.

З теорії:


Юніверс – Це файл, який містить наступне:



  • Параметри з'єднання для одного або декількох компонентів доступу до бази даних.

  • Структурами SQL називаються об'єкти, які відображають дійсні структури SQL в базі даних, наприклад стовпці, таблиці та функції баз даних. Об'єкти згруповані в класи.

  • Схема таблиць та об'єднань використовується в базі даних.

  • Об'єкти будуються з структур баз даних, які включені в схему.

  • Схема доступна тільки для користувачів Designer. Вона не доступна для перегляду користувачів Web Intelligence і Desktop Intelligence.

  • Користувачі Web Intelligence підключаються до Юніверс для виконання запитів у базі даних. Вони можуть аналізувати дані і створювати звіти за допомогою об'єктів, не переглядаючи і не знаючи нічого про основні структурах даних в базі даних.

Необхідно додати, що побудова звіту за допомогою генератора звітів CrystalReports на основі Юніверс також можливо для тих користувачів, хто є частиною системи SAP Business Objects Enterprise.


Отже, Юніверс – проміжний шар, які представляє дані в розрізі бізнес-логіки, а не збереження бази даних. Спочатку реляційні СУБД орієнтовані саме на зберігання і обробку інформації, і часто побудова звітів по таким структурам – надзвичайно складне завдання. Має сенс ввести проміжний рівень, в якому дані представляються у вигляді більш зручному для бізнес-користувача. У попередній статті ми використовували пряме з'єднання з базою даних, а зараз розглянемо Юніверс.


Звіт за тиждень по співробітниках.


Нагадаємо постановку задачі. Є деякі події, які фіксують співробітники. Факт здійснення події записується таким чином: фіксується дата вчинення, який співробітник оформив подія, і що конкретно сталося – тобто, тип події. У нашому прикладі тип події не грає ролі, нам необхідно бачити, скільки фактів здійснення події зафіксував той чи інший співробітник у який день тижня.


1. Події фіксуються тільки в момент вчинення, тобто, деякі дні можуть бути відсутні в таблиці, якщо не відбувалося подій. До звіту повинні увійти всі дні тижня.


2. Співробітники можуть не бути на роботі або не фіксувати події. У звіті має бути відображено весь список співробітників.


3. До звіту необхідно передати два значення – початок періоду і закінчення періоду. У прикладі, повторюся, розглянемо тижневий звіт.

Таблиця 1. Форма звіту.

Як і в попередньому прикладі, використовуємо тренувальну базу даних TEST, створену на MS SQL Server 2005. Таблички Action і Employee – частина деякої бази даних, що містять необхідні нам дані. Зв'язки між табличками здійснюються за допомогою зовнішнього ключа Employee.EmployeeId – Employee.EmployeeId.


Дані.

Таблиця 2. Action. Таблиця фактів (подій), що відбулися за певний час.















DateAction


Дата події


TypeActionId


Ідентифікатор типу події


EmployeeId


Ідентифікатор співробітника


Description


Якесь опис

Таблиця 3. Employee. Таблиця Співробітників, які фіксують факт здійснення Події












EmployeeId


Ідентифікатор співробітника


EmployeeName


ПІБ співробітника (спростимо для прикладу)


DepartmentId


Ідентифікатор відділу


І також ми будемо використовувати запит, який повертає нам список дат нашого діапазону.

Як інструмент використовуємо Universe Designer SAP BusinessObjects 12.3.0.601.


Частина 1. Побудова Юніверс.


1. Налаштовуємо з'єднання для нашої БД (Рис 1).

2. Створюємо новий Юніверс, використовуючи побудоване з'єднання (Рис 2).

Залишимо стандартні настройки стратегій (вкладка Стратегії).


3. Розміщуємо таблиці на панелі структур Дизайнера Юніверсом і налаштовуємо зв'язку між ними (Рис 3).

Властивості зв'язку (Рис 4).

Додаємо похідну таблицю, щоб реалізувати наш запит діапазону дат (Рис 5).

4. Налаштовуємо зв'язку між цими таблицями (Рис 6-7).

Зв'язок по EmployeeId налаштована аналогічно.


5. Створюємо класи і об'єкти для наших даних



  • Співробітник


o EmployeeId (Вимірювання)


o EmployeeName (Атрибут)


  • Робочий тиждень


o DT (Вимірювання)


  • Значення


o Кількість операцій (фактів) (Значення)

Використовуємо Функцію Лічильник як приклад, вона може бути обрана, наприклад, Ні – тобто, не застосовувати агрегування для цього значення.


6. Перейменуємо об'єкти в термінах, зрозумілих користувачам (Рис 11).

7. Зберігаємо і експортуємо Юніверс (Рис 12-13).

8. Наш Юніверс побудований і розміщений (експортований) на сервері. Всі необхідні нам поля "перетворені" в об'єкти, зрозумілі користувачеві.


Частина 2. Побудова звіту на основі Юніверс.


1. Налаштування джерела даних.


При виборі Юніверс як джерела даних необхідно увійти в систему Enterprise, ввівши логін і пароль користувача. Вибираємо тип джерела даних – Юніверс (Рис 14).

Виконуємо вхід в систему Enterprise (Рис 15).

2. Налаштовуємо запит.


Вибираємо наші об'єкти, перетягуючи їх на панель результату. Для співробітника вибираємо і вимір, і атрибут – ПІБ співробітника (Рис 16).

Звернемо увагу, що в цьому випадку користувач пише не запит, а оперує об'єктами Юніверс, які називаються зрозумілими користувачеві термінами бізнес-логіки. Натискаємо ОК, і розміщуємо отримані поля у звіті (Рис 17).

3. Перегляд звіту (Рис 18).

Звернемо увагу, що не весь список співробітників представлений у звіті. При складанні кросстабліци ми отримаємо таку картину (Рис 19).

Нас не влаштовує 2 моменти:


1. Наявність "порожній" рядки


2. Відсутність всього списку співробітників.


Через що таке відбувається? Якщо ми подивимося список рядків, що повертається запитом (Рис 18), видно, що є порожні записи (у полі співробітник міститься null), які й дають нам порожню рядок в кросстабліце. Це ті самі поєднання для дат і співробітників, для яких не знайшлося відповідності в таблиці фактів.


SQL-запит виглядає так:

Ми бачимо, що контексти, за якими будується запит в Юніверс, не враховують того, що нам необхідно CROSS JOIN з'єднання між таблицями співробітників і таблицею днів тижня, більш того, в правилах Юніверс має намір уникати декартова твори множин. Тобто, необхідно додати в Юніверс таблицю, що враховує такий запит.


Частина 3. Внесення змін до Юніверс.


1. Додавання похідної таблиці.


Додаємо похідну таблицю на підставі запиту (Рис 20).

Називаємо таблицю терміном бізнес-логіки. Користувачі Юніверс будуть бачити саме цю назву.


2. Встановлюємо зв'язку (Рис 21).

І формуємо об'єкти (Рис 22).

Тепер нам необхідно замінити таблиці в звіті – замість Employee і Тижня поставити Співробітники по днях тижня.


Важливо! Після зміни Юніверс не забудьте повторно розгорнути (експортувати) цей Юніверс на сервері.


Частина 4. Змінюємо звіт.


1. Міняємо запит (Рис 23).

2. Звіт набуває такий вигляд (Рис 24).

По 1 співробітнику вже видно, що перераховані всі варіанти дат. І тільки по тих сполучень, де в таблиці фактів є фіксування дій, у стовпці Операція (факт) відображається значення.


3. Кросстабліца приймає такий вигляд (Рис 25).

Запит для цього звіту виглядає так:

У цьому випадку контекст, який використовується в Юніверс, бере внутрішнє з'єднання незмінним, і тільки потім підключає таблицю дій.


Отже, ми домоглися мети, використовуючи джерело даних Юніверс. Ще раз відзначимо, що користувачеві не потрібно писати запит, потрібно тільки звернутися до Юніверс і використовувати об'єкти, які є в ньому. Запит буде побудований на основі контекстів, визначених у Юніверс його розробниками.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*