Прикладна система на базі засобів Microsoft, Oracle, Бази даних, статті

Використання технологій Microsoft в системі “FinExpert сховище даних” компанії IDM

У 2002 році корпорація Microsoft випустила SQL Accelerator For BI – набір інструментів для побудови рішень, що використовують OLAP та інформаційні сховища. Нагадаємо, що в його склад входять сервер баз даних SQL Server, аналітичні OLAP-служби для багаторозмірний аналізу Analysis Services, служби збору, перетворення і завантаження даних Data Transformation Services (DTS), а також засоби пошуку закономірностей в даних і графічні інтерфейси. Але для реалізації конкретної бізнес-завдання при застосуванні SQL Accelerator все одно потрібна участь програмістів, що ми і хочемо показати на прикладі системи “Сховище даних “від компанії IDM.


Технологічна основа


Як сервер бази даних сховища використовується Microsoft SQL Server 2000 SP3, хоча ніщо не заважає задіяти й інші СУБД. Як OLAP-сервера застосовуються служби Analysis Services зі складу SQL Server. На етапі завантаження даних в проміжні таблиці сховища використовується технологія DTS. Для генерації звітів застосовується генератор звітів Seagate Crystal Reports 8.5 і компоненти Microsoft Office Web Components (OWC). Загальна архітектура системи будується за модульним принципом і ділиться на кілька підсистем (див. Малюнки 1, 2).


Для побудови додатків підтримки прийняття рішень в системі застосовуються Analysis Services з пакету SQL Server. При необхідності можлива підтримка і інших продуктів класу OLAP – наприклад, ORACLE Express. Однак для цього вже потрібна додаткова розробка. Поки ж технологія інтеграції додатків IDM в Microsoft Analysis Services дозволяє вибрати один з варіантів використання:



Самі OLAP-куби розробляються в стандартному інструменті Microsoft – Analysis Manager – із застосуванням мови MDX. При реалізації конкретного проекту можна вибрати, наприклад, структуру даних типу “зірка”, оскільки цей підхід дозволяє мінімізувати розмір вихідної бази даних. Прийнятна швидкість роботи з кубом досягається за рахунок максимально повного агрегування даних і вибору змішаного (HOLAP) способу зберігання даних куба.


При перенесенні даних в проміжні таблиці бази даних ми використовували DTS. В процесі розробки пакетів нам довелося зіткнутися з низкою проблем, і перш за все з “прихильністю” готового DTS-пакета до імен серверів, баз даних, таблиць та шляхам файлів. Звичайно, цю проблему можна вирішити, описавши по одному джерелу даних для бази джерела і приймача, а для інших таблиць використовувати копії (Клони) цих джерел. Але в такому разі пакет зможе обробляти тільки одну таблицю в кожен момент часу. При великих же обсягах даних видається більш доцільним описувати кілька фізичних джерел даних (до п’яти), так щоб усі таблиці розподілялися рівномірно по цим відкритим джерелам, в залежності від середніх (прогнозованих) обсягів містяться в них даних. При цьому навантаження на кожне відкрите з’єднання з базою даних повинна бути по можливості однаковою. На практиці такий підхід дозволяє збільшити швидкість пересилання даних приблизно в 3-4,5 рази – залежно від ступеня розпаралелювання.


Використання DTS на віддалених майданчиках мало два очевидних недоліки:



Для усунення цих недоліків процедура вивантаження даних була “винесена” в самостійне консольний додаток, написаний на Visual Basic 6. Таким чином, тепер для вивантаження потрібно тільки наявність Microsoft Data Access Components (MDAC). Приблизний зовнішній вигляд налаштувань вивантаження даних наведено в Лістингу 1. Як можна помітити, в реєстрі прописуються фактично фрагменти SQL-пропозиції, що дозволяє задавати список таблиць і правил вивантаження без перекомпіляції програми або без модифікації DTS-пакета.


При реалізації системи “Сховище даних” в якості основного засобу розробки ми використовували Microsoft Visual Basic 6 з комплекту Microsoft Visual Studio 6 SP5. Деякі компоненти, наприклад COM-інтерфейси, були реалізовані на VC + + 6 за допомогою ATL.


Для проектування (опису) структури баз даних і генерації SQL-сценаріїв створення баз даних застосовувалося CASE-засіб CA ERWin 4.1 в поєднанні з репозитарієм для колективної розробки ModelMart 4.1.


“НОУ-ХАУ” від компанії IDM


Однією з основних завдань системи є забезпечення отримання цілісної картини з розрізнених наборів даних. Як відомо, більшість підприємств на просторах колишнього СНД не мають єдиних корпоративних довідників, тому, навіть якщо зібрати інформацію з підрозділів в центрі, її не можна буде адекватно зіставити, і вже тим більше консолідувати. Ця проблема вирішується за допомогою підсистеми підстановки відповідностей.


Процес підстановки відповідностей передбачає заміну всіх полів посилань (relationships fields) розрізнених записів, що надійшли з різних майданчиків, а отже, заснованих на різних версіях довідників (Можливо, продукованих різними системами), на посилання на записи так званих корпоративних довідників сховища. Процедура підстановки відповідностей виконується у вигляді пакета (на всій безлічі записів проміжної таблиці), проте має відпрацювати для кожного посилання кожного запису, імпортованої в проміжні таблиці сховища.


Очевидно, що при такій постановці завдань найбільш логічним видається використання так званих предметних ідентифікаторів записів, тобто пошук ID записи довідника по набору предметних полів, однозначно ідентифікують сутність, яку представляє запис довідника. Наприклад, для контрагента такими наборами можуть бути “код контрагента” або набір “код банку” + “номер рахунку в цьому банку”. Для того щоб дана операція була можливою, кожна запис повинна містити надмірну інформацію, якою і є предметні поля з довідника.


З технічної точки зору процес підстановки відповідностей являє собою виконання масованих модифікацій записів проміжних таблиць. Для кожного посилання між двома таблицями описується правило підстановки відповідності, яке визначає, по відповідності яких полів проміжної таблиці і довідника в яке поле проміжної таблиці потрапляє ключ запису довідника. Крім того, враховуються так звані “ручні” правила відповідностей, які являють собою свого роду виключення із загального правила. “Ручні” правила обробляються для кожного правила в першу чергу і мають більш високий пріоритет, ніж автоматичні.








Рисунок 3. Приклад OLAP-куба, розробленого для конфігурації “Торговий дім”

Процес підстановки автоматичних відповідностей поділяється на два етапи. На першому етапі з довідника в тимчасову таблицю витягуються стовпці, задіяні в правилі. Потім, залежно від налаштувань системи, видаляються дублікати по полям відповідностей (може бути залишена запис з числа дублікатів з мінімальним значенням PK – це визначається настройкою). Крім того, з тимчасової таблиці видаляються записи, одне або більше полів яких порожні (Малюнок 4). На другому етапі здійснюється підстановка відповідностей в проміжну таблицю (Малюнок 5). Підстановка виконується для записів, для яких відпрацювали всі попередні правила. Ознака успішної відпрацювання чергового правила для певного запису проміжної таблиці – збільшення на одиницю значення в службовому полі confset цього запису.








Малюнок 17. Призначення файлової групи для розділяється таблиці.

Реалізація схеми поділу в системі спричинила за собою необхідність розробки власної схеми генерації автоматичний первинних ключів, оскільки поля з ознакою IDENTITY для поділюваних таблиць не підтримуються. Ця схема реалізується за допомогою тригерів і декількох допоміжних таблиць. При реалізації такої схеми основна увага приділялася підвищенню швидкодії при виконанні пакетної вставки великих масивів даних. Для цього використовувалися тимчасові таблиці зі структурою, яка відповідає структурі “базової” таблиці, за винятком поля – сурогатного первинного ключа: для нього був вибраний стандартний автоінкремент SQL Server з динамічно заданим діапазоном. В Лістингу 6 наведено приклад тригера для генерації автоінкрементне первинного ключа.


Син помилок важких


Як показує практика, дані найчастіше доводиться отримувати з дуже недосконалих систем і СУБД. Причина проста і прозаїчна – як правило, основним критерієм при покупці OLTP-системи є її функціональність. А найбагатша функціональність зазвичай буває у тих систем, які розробляються давно і несуть неабиякий вантаж застарілих технічних рішень. До того ж для коректної обробки даних бажано дотримуватися ряд вимог щодо даних системи-оригіналу:



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


Далі, як відомо, максимальна кількість таблиць в одному SQL-запиті для SQL Server 2000 одно 256. Здавалося б, це досить багато. Однак не слід забувати, що якщо в запиті беруть участь уявлення, то в число використовуваних в ньому таблиць входять усі таблиці, які застосовуються в даному поданні. В нашому випадку при використанні поділюваного подання ситуація ускладнюється тим, що при досить нормалізованої схемою даних кількість таблиць у запиті доводиться множити на кількість років, за яке зберігається інформація в розділі. Якщо в запиті одна і та ж таблиця підключається декілька разів, з різними псевдонімами, то вона “зчитується” також кілька разів. В результаті для складних таблиць даних з великою кількістю довідників “впертися” в обмеження в 256 таблиць можна буквально за два-три роки.


В принципі з такою проблемою ми зіткнулися тільки в звітах, які будуються безпосередньо по базі даних сховища та інтегрують дані за досить тривалий період або містять стовпці, обчислювані окремими підзапиту за періодами. Вихід з такого положення досить простий: для кожного такого звіту створюється процедура, що зберігається, в якій покроково наповнюється якась тимчасова таблиця. Після закінчення виконання процедура повертає викликав модулю набір рядків, що містить рядки цієї тимчасової таблиці. Таким чином, один великий запит ми розбиваємо на ряд дрібних, в кожному з яких менше 256 таблиць.


У цій статті ми спробували узагальнити досвід, отриманий при вирішенні класичної завдання OLAP – сховище даних протягом кількох останніх років. Сподіваємося, що вона буде цікава як фахівцям компаній, розробляють готові рішення, так і співробітникам ІТ-підрозділів корпорацій. Для тих, хто хотів би більше дізнатися про вирішуваних бізнес-задачах і функціональності системи, рекомендуємо звернутися до статей, наведеними у списку “Література”. Для поповнення теоретичного багажу в галузі технологій OLAP & Warehousing можна звернутися до ресурсів сайту www.olap.ru .


Література



  1. Банасевіч А., Гурленко А. Сховища даних та OLAP / / Корпоративні системи, Київ, 2002, № 4, с. 44-51.
  2. Банасевіч А., Кудінов А. Від Informix – до SQL Server/ / Відкриті системи, січень 2002, рубрика СУБД, с. 55-61.
  3. Муравйов В., Банасевіч А. Використання технологій INFORMIX в ERP-системі FinExpert. 8.0 / / INFORMIX Magazine / російське видання, літо 2001, рубрика “Проекти і програми”, с. 23-27.
  4. Прес-реліз “Сховища даних і технології OLAP для обробки інформації” / / Office, 2002, № 5 (52), с. 77 (див. також www.finexpert.com/News/Presrel/ hdolappr.html ).
  5. Муравйов В., Банасевіч А. Технологічні рішення в управлінні підприємством / / Корпоративні системи, 2000, № 4, рубрика “Галузеві рішення”, с. 27-31.
  6. Прес-реліз “Cистема FinExpert ™ 8.0 компанії IDM переведена на платформу СУБД Microsoft SQL Server 2000”, www.microsoft.com/rus/General/Press/ 2001/june/FinExpert.htm .
  7. Використання сучасних технологій корпорації Microsoft в системі автоматизації управління підприємством FinExpert ™ 8.0 / / Матеріали спільного семінару компаній IDM і Microsoft на виставці “Управління підприємством-2001 “, 6.12.2001.
  8. Семінар Троїстого союзу компаній / / Матеріали спільного семінару компаній IDM, Microsoft і KPMG на виставці “Управління підприємством-2000”, 2.11.2000, idm.kiev.ua/news/index.html (Див. також IDM, KPMG і Microsoft провели спільний семінар, itc-ua.com/article.phtml?ID=4251 ).
  9. Server 2000 Books Online, Microsoft.

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


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

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

Ваш отзыв

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

*

*