Технически университет-София

Факултет по компютърни системи и управление

Катедра „ Програмиране и компютърни технологии”

MScIS Павел Николаев Сарачев

Методи и средства за съхраняване и анализ на

хетерогенни данни и информация на малък и

среден бизнес

АВТОРЕФЕРАТ

На дисертационен труд

За присъждане на образователна и научна степен „Доктор”

Шифър 5.3 , професионално направление: „Комуникационна и

компютърна техника”

научна специалност: ”Автоматизирани системи за обработка на

информация и управление”

Научен ръководител: доц. д-р инж. Иван Панков

София, 2013 г.

2

Дисертационния труд е обсъден и насочен за защита на заседание на

катедрения съвет на катедра “Програмиране и компютърни технологии”, факултет

“Компютърни системи и управление” към ТУ-София на заседание, проведено на

10.06.2013.

Обем на дисертацията : Основният текст на дисертационният труд е изложен на 154

страници, в който са включени: фигури-66 бр.; таблици-9 бр.; списък на съкращенията;

приноси, приложения на дисертацията; публикации; библиография-79 бр.

Структурата на дисертацията е : предговор, четири глави, заключение и общи изводи,

приноси, списък на публикациите по дисертационния труд, списък на цитирани

литературни източници и документи за внедрени и използвани части от

дисертационната разработка.

Номерацията на фигурите в Автореферата е самостоятелна.

Материалите по защитата са на разположение на интересуващите се в

канцеларията на факултета „Компютърни системи и управление“, стая 1443а на

Технически Университет – София.

Защитата на дисертационният труд ще се състои на 21.10.2013 година от

14:30 часа, в зала 1434 на Техническия Университет – София, на заседание на

Научното жури.

Автор: MScIS Павел Николаев Сарачев

Тема: „Методи и средства за съхраняване и анализ на хетерогенни данни и

информация на малък и среден бизнес “

Тираж: 50 бр.

Печатна база на ТУ-София

3

OБЩА ХАРАКТЕРИСТИКА НА ДИСЕРТАЦИОННИЯ ТРУД

1. Актуалност на проблема

Новите разработки, открития и тенденции в информационните технологии

доведоха до развитие на нови форми на комуникация и взаимодействие както в

научните среди, така и в икономиката и социалния живот. Този еволюционен процес се

отразява неизменно и на фирмите от малкият и среден бизнес(МСБ).

Научна значимост и новост

Динамичните характеристики на информационните процеси изискват прилагане на

нови и гъвкави информационни технологии, базирани на складова aрхитектура и

бизнес анализ (DWH/BI) .

С представеният труд ще бъдат разработени нови технологии и подходи за съхранение,

обработка и анализ на хетерогенни данни и информация, които ще дадат възможност на

фирмите от МСБ да използват DWH/BI-системи в тяхната дейност.

2. Цел и задачи на дисертационния труд

На основата на осъществените проучвания и анализи и като се има предвид

значението на МСБ в икономиката на ЕС и Република България в настоящата

дисертация се определя следната основна цел:

Изследване на възможностите и приложимостта на технологии от тип Data

Warehouse/ Business Intelligence ( складова архитектура и бизнес анализ (DWH/BI)

при обработка на данни, свързани с дейностите на МСБ.

За постигането на основната цел на дисертационната работа е необходимо да бъдат

решени следните основни задачи:

1. Избор на метод за изчисляване на общите разходи в дългосрочен план за DWH/BI-

системи с оглед ефективно планиране на необходимите инвестиции.

2. Изследване и оценка на възможностите за прилагане на DWH/BI- технологии в малки

и средни фирми, съблюдавайки тяхната специфика.

3. Проучване на съвременното състояние и основните насоки при разработването,

използването и развитието на DWH/BI-технологии.

4. Разработване на методология за въвеждане на DWH/BI-технологии в малки и средни

фирми включваща:

• избор на инфраструктура;

• концепция за генерична архитектура за данни;

• стандартизация на Extraction Transformation Load (ETL)-

звличане,трансформация, въвеждане в базата данни и презентация на информацията.

5. Приложение на разработената методология състоящо се от:

• модели на данни: генеричен модел за метаданни, генеричен

модел за промени, генеричен модел за човешки ресурси и мултидименсионен

модел с агрегати;

• реализация на стандартни (ЕТL) -процеси;

• приложение на основните модули от бизнес анализ (BI): отчетен модул, табличен

модул и Online Analytical Processing( On line процеси за анализ на данни) (OLAP).

3. Структура на дисертационната разработка Дисертационната разработка е със следната структура:

Предговор, четири глави, заключение и общи изводи, приноси, списък на

публикациите по дисертационния труд, списък на цитирани литературни източници и

документи за внедрени и използвани части от дисертационната разработка.

В увода e обоснована актуалността и основните мотиви за работа по темата.

В първа глава e направен обзор на литературните източници, свързани с:

4

• характерни особености на МСБ в ЕС и техните проблеми от информационен

аспект;

• методи за оценка и анализ на инвестициите за закупуване на софтуер,

разработване на система за обработка на данни и варианти при нейната експлоатация

и поддръжка ;

• архитектура на информационни системи, базирани на складова архитектура и

бизнес анализ;

• -подходи при избора на софтуерна платформа (комерсиален софтуер и софтуер с

отворен код);

В резултат на проведения литературен анализ са направени изводи, въз основа

на които са очертани нерешените проблеми. Вследствие на направените изводи са

формулирани целта и задачите на настоящата работа

Втора глава е посветена на теоретичните основи при разработване на DWH-система.

Един от основните аспекти на подобен тип системи е изграждането на модели на

данни, в това число :

-бизнес модел;

-логически модел и неговите алтернативи: Entity-Relationship Model

(ERM) - модел същност-връзка - за стандартизирано моделиране на релационни

данни , мултидименсионалните модели (МДМ), генеричен модел, трезорен модел;

• физически модел;

• извличане, трансформиране и пренасяне на данните (ETL) процеси;

При изготвяне на бизнес анализи(BI) са разгледани различни технологии, като са

оценени техните предимства и недостатъци:

• Online Analytical Processing (OLAP);

• Multidimensional Online Analytical Processing (MOLAP);

• Relation Online Analytical Processing (ROLAP);

• HOLAP

В трета глава е разработена методология при изграждане на DWH/BI за малък и

среден бизнес, включваща следните етапи:

1. Избор на инфраструктура и софтуерна платформа при варианти: с отворен код,

комерсиален софтуер, аутсорсинг );

2. Моделиране на данни обхваща следните стъпки:

-създаване на метаданни посредством нов комбиниран подход, базиран на

принципите на генерично и трезорно моделиране.

-модел за структурни промени в метаданните;

-изграждане на ETL процеси с възможности за повишена сигурност в процеса на

актуализиране на данни

- критерии при разработването на BI : сигурност, цялостност, опростеност,

устойчивост,свързаност, точност, стандартизация.

Четвърта глава е посветена на приложението на разработената методика в глава

трета. Разработени са :

• модел „Управление на човешките ресурси” в няколко варианта: генеричен

трезор, звезда, снежинка;

• модел „Управление на договорните отношения” ;

• модели за ETL процеси и тяхната реализация с различни платформи: Oracle

Warehouse Builder (комерсиален софтуер) и Pentaho Data Integration (софтуер с

отворен код),

• модел за BI посредством Oracle Application Express и Pentaho BI;

5

• извършена е съпоставка и оценка на предимствата и недостатъците на двете

софтуерни платформи( с комерсиален и отворен код) по отношение на бързодействие,

разходи, надеждност и секретност на фирмена информация.

В заключението се съдържат основните резултати, получени от дисертационната

разработка. Разработената методология позволява:

• избор на софтуерна инфраструктура;

• универсално-трезорна архитектура за модели на данните и мета данните с

използване на комбиниран метод при изграждане на модела на метаданни;

• стандартизация при ETL процеси;

• стандартизация на BI-приложението за презентация на информацията.

В приложението към дисертацията са посочени два проекта, в които е приложена

разработената методика от дисертационната работа.

4. Характеристика на научната методика

Основната идея на дисертационния труд е свързана с :

• избор на метод за изчисляване на общите разходи в дългосрочен план за

DWH/BI-системи;

• разработване на методика при създаване на основните компоненти на DWH/BI

системи : модели на метаданни , ETL процеси и BI-приложения за презентация на

информацията.

Предложеният метод VOFI позволява изчисляване на общите разходи в дългосрочен

план за DWH/BI-системи, което не се отчита от разпространения метод ТСО. Поради

това методът VOFI дава реална представа за необходимите разходи и инвестиции в

информационни системи на фирми от МСБ в близък и дългосрочен план.

Разработената методика при създаване на DWH/BI позволява:

• стандартизиране на ETL процеси позволява мултиплицирани приложения за

фирми от МСБ, с което значително се съкращава необходимите ресурси (време и

материални разходи) при разработване и внедряване на DWH/BI системи;

• стандартизиране на BI-приложения за презентация

• изграждане на гъвкави модели на метаданни, базирани на комбинации между

мрежов и йерархичен концептуални модели и сведени до релационен. Така могат да

бъдат отразени някои характерни особености на бизнес информация на фирми от

МСБ ;

• повишаване на надеждността и защита на данни в процеса на актуализация на

информацията.

5. Апробация на дисертацията

Части от дисертационната разработка са използвани в 2 проекта:

1. Международен проект: Управление на автопарк от лизинг компания

HPI Fleet & Mobility GmbH1;

2. Международен проект: Централизирано управление на потребители

в база данни от финансовата борса на Германия Deutsche Borse

Group.

Приложено е писмо за внедряване от фирма „Triwdata” GmbH , Германия

Обем на дисертацията : Основният текст на дисертационният труд е изложен на 154

страници, в който са включени: фигури-66 бр.; таблици-9 бр.; списък на съкращенията;

приноси, приложения на дисертацията; публикации; библиография-79 бр.

6

II. СЪДЪРЖАНИЕ НА ДИСЕРТАЦИЯТА

Предговор Новите разработки, открития и тенденции в услугите и технологиите водят до

развитието на нови форми на комуникация и взаимодействие, както в научните среди,

така и в икономиката и социалния живот. Този еволюционен процес се отразява

неизменно и на фирмите от малкия и среден бизнес(МСБ). В Европейския Съюз

съществуват около 23 мил. МСБ-фирми с 74 мил. работни места, които представляват

99% от заетостта.Този тип фирми са двигателят на европейската икономика. Те са

основен източник на работни места, създаване на предприемачески дух и иновации в

европейския съюз(ЕС) и по този начин са от съществено значение за насърчаване на

конкурентоспособността и заетостта. Поради тази причина ЕС следи и подпомага

развитието на МСБ.

С представеният труд са разработени нови техники и подходи за съхранение,

обработка и анализ на хетерогенни данни и информация, които дават възможност на

фирмите от МСБ за приложение на DWH/BI-системи.

Глава 1

Преглед на приложението на DWH/BI-системи в управлението на МСБ

1.1 Характерни особености на МСБ в ЕС и техните проблеми от информационен

аспект

МСБ се характеризира с качествени особености и черти като:

•••• ограничени материални и човешки;

•••• плоска управленска йерархия;

•••• липса на адекватни системи за управление;

•••• интуитивно управление и липса на стратегически подход.

Системите за подготовка, планиране и подкрепа на тези дейности трябва да отговорят

на новите динамични пазарни и структурни изисквания. Това са системи, които

включват методи и средства за съхранение и обработка на данни, както и за

представянето и разпространението на извлечената от тях информация. Тези системи са

от изключително значение, както за големия, така и за малкия и среден бизнес.Тяхното

внедряване е свързано със значителни инвестиции. Поради това факторът „оценка” на

подобна инвестиция и времето, за което те могат да бъдат възстановени са особено

актуални.Това предполага да бъде препоръчана методика за оценка на инвестицията и

рисковете за МСБ.

1.2 Инвестиционен контрол за информационни системи В зависимост от начислението им, разходите се характеризират по следния начин:

• вариращи разходи - variable costs - варират при промяна на обема на

производството;

• твърди разходи - fixed costs - остават константни при промяна на обема на

производството;

• директни разходи - direct costs - могат да се начислят директно към даден

продукт;

• индиректни разходи - indirect costs - не могат да се начислят директно към даден

продукт.

1.2.1 Разходи и инвестиции в информационни системи за МСБ

Mетодът за изчисление Total Cost of Ownership(TCO) описва възможните разходи

през целия жизнен цикъл на ИС като ги разделя в двете основни категории :

• директните разходи (в бюджета) са капитал, такси и разходи за информационни

технологии и решения за организацията и потребителите, хардуер, софтуер и ъпгрейд,

7

планиране, администрация, управление и поддръжка на сървъри, периферия и

компютърна мрежа;

• индиректните разходи (извън бюджета) са пряко зависими от ефективността на

системата и предоставяните услуги.

Въпреки че методът TCO се счита за стандарт, неговата теоретична основа

притежава определени недостатъци като: игнориране на лихви за собствен и чужд

капитал, данъци и промяна на цените.

Методът Visualization of Financial Implications (VOFI) взема под внимание

капиталовото бюджетиране и отстранява недостатъците на ТСО. Извършено е

примерно изчисление по двата метода: разходите по метода TCO са на обща стойност

55 638 лв. , а по метода VOFI- 60 877 лв., Обяснението за разликата е, че при VOFI

са отчетени и отразени всички разходи.

1.3 Архитектура на информационни системи от тип DWH/BI Подходите при решаване на информационните проблемите и програмно

осигуряване в организациите често се свеждат до избор на програмна платформа от тип

Enterprise-Resource-Planning (ERP) със следните характеристики:

• модулно покритие на стандартизирани бизнес процеси;

• ограничена възможност за промяна или разширение на модулите в зависимост

от нуждите на потребителя;

• значителни разходи за лицензиране, инсталация и разширение на системата.

Прилагането на ERP-системи от фирмите на МСБ е свързано с огромна финансова

тежест, която те не могат да си позволят.

Терминът Data Warehouse (DWH) се въвежда за първи път през 1992 г. като „субект,

който е ориентиран, интегриран, вариращ с времето (обхваща различни периоди от

време) и постоянен обем от данни, за подкрепа на мениджмънта на фирмата“. Тази

дефиниция датира не е загубила от своята значимост и до днес. Концептуално един

DWH може да бъде представен с неговата архитектура. DWH-архитектурата обхваща

описанието на елементите и услугите, които един DWH съдържа . Типична структура е

представена на фиг. 1.1.

Фигура 1.1.

8

- Data Sources“ – източник на данни Flat Files- файлове генерирани от различни

програми под формата на XML, HTML, CSV и т. н., които се използват в дадената

организация или импортирани от други организации;

- ”Staging Area“ - терминал на данните, които са пречистени и въведени в желания

формат преди да се вкарат в DWH. Централната секция представена в фиг. 1.1 е състои

от бази данни със следните три вида данни:

Metadata“- метаданни - описват данните за реалните бизнес или технически обекти и

процеси;

”Raw Data“ - сурови данни - необобщени данни на реалните обекти, често представени

в трета нормална форма, обогатени с технически метаданни и възможност за история.

Summary Data“ - обобщени данни - състои се от обобщените данни на реалните обекти.

За разлика от "Raw Data\ тези данни са агрегирани до зададено агрегационно ниво;

Data Marts“. оптимизирани копия на DWH за различни тематични анализи

”Users“-извършват BI-процесите;

За изграждането на представената архитектура са характерни следните софтуерни

модули:

• база данни, в която се запазват данните на организацията;

• ETL софтуер, с който данните се извличат, обработват и вкарват в базата данни;

• софтуер за отчети и анализ, с който данните и информацията се представят и

разпространяват в електронна форма.

В дисертацията подробно са разгледани предимствата и недостатъците на

комерсиален софтуер и софтуер с отворен код :

-комерсиален софтуер: Oracle 11g, Oracle Warehouse Builder (OWB), Oracle Application

Express (APEX) , , ETL архитектури;

- софтуер с отворен код: PostgreSQL, Pentaho BI;

1.6 Изводи от първа глава

1. Фирмите от МСБ осъществяват 99% от заетостта в Европейския Съюз като по този

начин представляват основния фактор за европейската и световна икономика. Въпреки

този факт фирмите от МСБ разполагат с ограничени ресурси и са особено чувствителни

към промените в конюнктурата и динамиката на вътрешните и външните пазари, което

допълнително налага използването на модерни информационни системи за

подпомагане на тяхното управление.

2. Информационните системи за управление на фирмата от своя страна са свързани със

значителни инвестиционни и административни Поради тази причина е предложен

методът Visualization of Financial Implications (VOFIТ) По този начин фирмите могат да

придобият ясна представа за себестойността на информационните системи и да вземат

адекватно решение за свързаните с тях инвестиции.

3. Информационното и програмно осигуряване, предимно при големи фирми и

организации, често се свежда до избор на програмна платформа от тип Enterprise-

Resource-Planning (ERP). Информационните системи от тип ERP се отличават със

стандартни модули за бизнес процесите, ограничена възможност за промяна и високи

лицензни такси. Поради тези характеристики се налага използването на гъвкави

нформационни технологии от типа DWH/BI.

4. Изборът на софтуер е ключов фактор при изграждането на всяка DWH/BI-система.

Функциите и моделът на лицензиране трябва максимално ефективно да подкрепят

информационните корпоративни дейности като по този начин да спомагат за

намаляване на разходите и бързото вземане на адекватни решения свързани с

9

управлението на фирмата. Подробно бяха разгледани продуктите на Oracle Corporation

и като алтернатива с отворен код продуктите на PostgreSQL и Pentaho.

Глава 2 Теоретични основи на DWH/BI-системи

Изграждането на една DWH/BI-система е комплексен процес, който преминава

през концепцията и реализацията на модели от типа: бизнес, логически и физически

модел.

2.1 Бизнес модел В рамките на DWH бизнес моделът се представя като един концептуален модел за

това как хората от бизнеса гледат на реалните обекти или процеси, с които се

извършват бизнес-сделките.Той отразява дейностите, които бизнеса иска да наблюдава,

измерва и управлява в даден контекст. Тези дейности се свеждат до отговор на бизнес

въпроси като: Колко сте произвели?. Достатъчно ефикасен ли е производствения

процес?. Колко сте продали или закупили?.Какви количества са доставени и отговарят

ли те на поставените изисквания?Кои са клиентите, които са купили или не са купили

пределен продукт? Кой продавач или дистрибутор е продал най-много или малко?

Кои продукти се продават или не се продават? Кога са осъществени продажбите?

2.2. Логически модел Логическият модел е независим от техническата инфраструктура и представлява един

интерфейс между бизнес модела и физическия модел. Неговата цел е да се изяснят

нужните данни за DWH без да се посочват технически подробности, които на този етап

не са от съществено значение. Много често той се разработва с помощта на софтуер за

моделиране.

2.2.1. Релационeн модел и 3NF Трета нормална форма(3NF) за моделиране на данни представя т. нар. Entity-

Relationship Model (ERM) - модел същност-връзка - за стандартизирано моделиране на

релационни данни . На фигура 2.1 е представен един логически ERM модел, който

дефинира данните на описания горе бизнес модел. Представеният логически ERM-

модел е доста опростен. Всеки обект е един клас представен в базата данни от една

таблица, но въпреки това той не е особено лесно разбираем. Не рядко подробни ERM-

модели са толкова обемисти, че не могат да се изобразят на формат А0. Това е

причината, че с изключение на опитни администратори или консултанти на база данни,

никой друг не е в състояние да вникне във взаимодействията на класовете, което от

своя страна е условието, за да могат да се анализират тези данни. Към това трябва да се

прибави и продължителността и комплексното изчисление на евентуални запитвания,

възникващи поради многобройните връзки между класовете. Какви са тогава

Предимствата на ERM-моделите са :

-данните се описват последователно, без излишно повторение и историзация- Online

Transaction Processing (OLTP) - онлайн транзакционно обработване. ОLTP

максимизира трафика и паралелизма на insert и update трансакции при запазване на

съгласуването на данните и намаляване на повторяемостта.

2.2.2 Мултидименсионален модел За разлика от ERM-моделите, мултидименсионалните модели (MDM) са

оптимизирани за запитването на данните т. нар. query трансакции. Един логически

MDM-модел, който притежава тази характеристика и съдържа абсолютно същата

информация като ERM-моделът на фиг. 2.1е представен на фиг. 2.2. Противно на

симетричните таблици при ERM, MDM-таблиците са значително по-малко на брой и не

са симетрични. Обикновено в средата е разположена т. нар. Fact Table - факт-таблица -

10

заобиколена от един комплект от ension Tables - дименсионни таблици. Поради тази

Форма MDM-моделите биват оприличени със звезди - Star Schema.

Фигура 2.1.

.

Фигура 2.2.

Мултидименсионалното моделиране представя една оптимизирана за запитване и

анализ на данните алтернатива на 3NF. Въпреки своите предимства при този подход

съществуват и известни недостатъци. Предимно те се изразяват в гъвкавостта на

модела на данните, когато бизнес модела бива променен.

11

2.2.3 Универсален модел Фокусът на изследователски проект ProcessBase е да се разработи модел на

данните за жизнения цикъл на информацията, който отговаря на индустриалните

изискванията за моделиране на процесите и обмен на данните. Резултати от проекта са

няколко ISO стандарта, между които са ISO 10303 Product Data Representation and

Exchange\ известен още и като STEP и "ISO 15926 Industrial automation systems and

integration—Integration of life-cycle data for process plants including oil and gas production

facilities. Тези два стандарта предоставят универсални модели на данните и библиотеки

за тяхното развитие. Целта на универсалното моделиране е части от модела или целия

модел да се използват наново без да са нужни промени в него. За да се постигне тази

цел бизнес модела се разделя на бизнес правила и независим от тях универсален модел

на данните. Универсалното моделиране представя една много гъвкава алтернатива на

мултидименсионалното моделиране. Моделът изготвен с него е способен с много

малки или често без никакви промени да се приспособи на всякакви бизнес промени.

Неговата стандартизация му позволява да се комбинира с други универсални модели,

както и да се обменя между различните организации.

Недостатъците на универсалното моделиран са: голям брой от класове и релации, -

огромни и сложни модели на данните. Изключителната нормализация на

универсалните модели води до значително ограничаване на скоростта на запитване.

2.2.4 Трезорен модел Data Vault(DV) - трезорен модел - е сравнително нова архитектура, разработена в

края на 90-те г.. Архитектурата е оптимизирана за съхранение и обработка на т. нар.

raw data - сурови данни и се състои от трите основни типа обекти: Hubs, Satellites и

Links - Хъбове, Сателити и Връзки. Хъбовете се състоят от уникални списъци на бизнес

ключове. Пример за хъб може да послужи класа Product, чиято таблица съдържа

всичките ProductNr - номера на продукти, които са известни в системата, както и

няколко технически атрибути, които се записват от ETL-процесите и могат да се

използват за техния контрол. На фиг. 2.2. са представени основните елементи на DV-

архитектурата. Промените в логическия модел се отразяват на всички следващи

процеси и елементи на DWH/BI. Поради тази причина всичките раздели се моделират

напълно и се проверяват многократно, преди да се започне с физическия модел.

Фигура 2.3.

12

2.3 Физически модел Физическият модел представлява техническото развитие на логическия модел.

Неговата реализация е зависима от съответната база данни и може да се осъществи след

пълното изготвяне на логическия модел. Той е много по-подробен от логическия модел

и съдържа технически елементи, които са важни за коректното изпълнение на DWH/BI-

процесите и тяхната оптимизация, но не са от значение за бизнеса. Съпоставка на

логически и физически модел е представена на фиг. 2.4.

Фигура 2.4

В лявата страна на графиката са изброени елементите Entities, Relationships,

Attributes и Unique Identifiers - обекти, връзки, атрибути и уникални определители на

логическия модел, които бяха разгледани в глава 2.2. В дясната страна на графиката са

посочени елементите на физическия модел с помощта, на които елементите от

логическия модел се реализират с програмния език Structured Query Language (SQL).

Въпреки че SQL е стандартизиран от American National Standards Institute(ANSI) и

International Organization for Standardization(ISO) всеки софтуерен производител има

свои спецификации и отклонения от стандарта.

2.4 Извличане, трансформиране и пренасяне на данните (ETL) Успешната реализация на физическия модел е предпоставката за моделирането и

реализацията на ETL-процесите Extraction Transformation Load - извличане,

трансформиране и пренасяне на данните. Една схематична концепция е представена на

фиг. 2.5

Фигура 2.5.

13

Извличане на данните ETL-процесите започват с извличането на данните. Данните се намират предимно в

релационни бази данни или под формата на ”Flat Files“ -плоски файлове предимно

CSV, XML, HTML, XLS и TXT. Те се извличат от източниците и се подготвят за

следващото обработване. Извличането става комплектно или инкрементално.

Комплектното извличане се извършва предимно при инициалното зареждане на

данните или в случай, че източниците на данни се променят изцяло. За разлика от това,

при инкременталното извличане се взимат единствено новите данни или тези, които са

се променили от тяхното последно извличане. При това не се извършват никакви

промени на данните, с изключение на елементарни конверсии като например от decimal

към integer, от EBCDIC към ASCII и т. н. По-съществените промени на данните се

извършват в следващите две стъпки на ETL-процесите. Трансформиране на данните

В повечето случаи качеството на данните не удовлетворява изискванията на

конкретната организация. За целта се прилагат техники, които се дефинират като

”Cleaning“ - прочистване на данните. Освен това се елиминират повтарящи се данни,

извършват се допълнителни проверки на формата и се проверява логиката на данните.

Тези процеси протичат полуавтоматично и изискват често намесата на високо

квалифицирани служители. Поради тази причина Data Cleaning\ и Conforming“

представляват 60% до 70% от разходите на един DWH проект. При различни източници

на данни са възможни вариации на техните обозначения, въпреки идентичното им

значение. Conforming\ е процесът, при който тези вариации се отстраняват. Данни с

еднакво значение трябва да имат еднакви обозначения. Обозначенията на данните

трябва да отговарят на т. нар. конвенция на имената - name convention - която е валидна

за цялата организация.

Доставяне на данните В последната фаза на процесът данните се доставят - ”Deliver“ - в базата данни. Те

са интегрирани в ETL софтуер, който предлага набор от инструменти за реализацията

и автоматизирането на комплексните ETL операции. Чрез т. нар. ”Scheduling“

процесите се планират и управляват по определено разписание. Тяхното изпълнение не

може да бъде винаги гарантирано поради изключения или обстоятелства -”Exceptions

Handling“ - които не могат да бъдат предвидени и водят до прекъсване на процесите. В

такива случаи се определят правила, които следят тяхното изпълнение и автоматично

ги рестартират или алармират отговорните за тях специалисти.

2.5 Бизнес анализ (BI)

2.5.1 Модул за отчети Динамичната икономическа обстановка, интензивността на конкуренцията и пазарите,

водят до налагането на бърз и гъвкав мениджмънт. Това довежда до нуждата от онлайн,

интегрирана и обстойна информация, която от своя страна не може да бъде набавена

без подкрепата на технически системи. Тези системи са заложени в основата на IT-

инфраструктурата на всички модерни организации и се наричат Reporting модул за

отчети. Подходящият модул за отчети е от особено значение за икономическия успех

на организацията. В резултат на това на пазара се конкурират голям брой от фирми,

които твърдят, че предлагат подходящата платформа. Правилният избор на отчетни

системи е зависим от фактори като: функции, настоящи Know-How и инфраструктура,

бюджет, стратегия на фирмата, бранш и т. н. Създаването на отчети преминава през

следните 4 фази: планиране на отчети ,спецификация на данните и техните източници,

оформяне и дизайн, тестване на отчети в различни формати: HTML, CSV,PD F, XLS.

2.5.2 OLAP Терминът Online Analytical Processing (OLAP) се свързва с над 26

изисквания, описани в Shared Multidimensional Information :

14

Fast - системата трябва да даде отговор в рамките от пет до двадесет секунди;

Analysis - системата трябва да предлага логиката и статистическите инструменти за

анализиране на бизнеса, които са релевантни за дадените потребители;

Shared засяга изискванията за сигурност в OLAP-системата:

Multidimensional - OLAP-система трябва да представя мултидименсионален поглед

върху данните, както и пълното представяне на обикновени и алтернативни йерархии.

Information обозначава всичките данни и придобитата от тяхното обработване

информация, които са нужни на дадения потребител.

Мулти дименсионални вариантни архитектури на OLAP са:

-MOLAP –данните се запазват в мултидименсионални кубове. Форматът на кубовете

се различава при различните производители, но той най-вече се базира на

мултидименсионален масив. Предимства: високата скорост и стабилност на заявките

дори и при сложни статистически изчисления. Недостатъци- ограничен обем от данни,

които могат да се пресметнат в аванс и запаметят;

-ROLAP - данните за запазени в релационни база данни, най-вече в DWH. Операциите,

с които се манипулират данните са базирани на SQL-изрази като SELECT, FROM,

JOIN, WHERE, GROUP BY, ROLL UP, CUBE и т. н., които се компилират и изпълняват

от сървъра на базата данни.

HOLAP архитектурата се стреми да обедини предимствата на MOLAP и ROLAP.

Поради ограничения обем от данни, които той може да съдържа, данните са агрегирани

на ниво By Year, By Color и By Make. Въпреки своите предимствата HOLAP-

архитектурата не е особено разпространена. Причините за това са сравнително

високите цени на HOLAP-софтуера, комплексността на реализация и поддръжка и

липсата на проекти с отворен код в тази област.

2.6 Изводи 1. Независимо от изборът на софтуер, концепцията и реализацията на една DWH/BI-

система преминава през изграждането на следните три модела:

• бизнес модел - представлява един концептуален модел за това как хората от

бизнеса гледат на реалните обекти или процеси, с които се извършват бизнес-сделките.

Той отразява дейността, която бизнесът иска да наблюдава, измерва и управлява;

• логически модел - представлява един интерфейс между бизнес и физическия

модел, който е независим от техническата инфраструктура. Неговата цел е да се

изяснят нужните данни за DWH/BI-системата без да се посочват технически

подробности;

• физически модел - представлява техническото развитие на логическия модел в

базата данни. Той е много по-подробен от логическия модел и съдържа технически

елементи, които са зависими от съответната база данни.

2. Успешната реализация на физическия модел е предпоставката за моделирането и

реализацията на ETL-процесите. За да се подобри качеството им и да се удовлетворят

бизнес изискванията те се трансформират, след което се зареждат в таблиците на базата

данни.

3. Бизнес анализ (BI) е общ термин за информационни системи от тип отчетни модули

и OLAP, има за цел извличане и представяне на информацията от обработените данни:

• отчетният модул предлага инструменти и услуги за изготвяне и администрация

на електронни доклади (отчети) и табла (интерактивни агрегирани отчети), които

представят информация предимно под формата на изчисления, двуизмерни таблици

и графики. Изготвянето на докладите включва планиране, спецификация на

източниците на данните, оформяне на дизайн и тестване. Администрацията се състои

от разпределение, мониторинг и сигурност на докладите;

15

• Online Analytical Processing (OLAP) е термин за технологии, които предлагат

възможност за интерактивен и мултидименсионен анализ на данните под формата на

обединение и разделение. Мултидименсионният поглед върху информацията се

извършва с помощта на кубове, които се представят на потребителя чрез кръстосани

таблици. OLAP-технологиите се базират предимно на две основни архитектури:

мултидименсионнен OLAP(MOLAP) и релационен OLAP (ROLAP).

4. Приложението на DWH/BI-технологии е свързано със създаване на модели на

данните, което изисква задълбочен и обективен анализ на информационните

потребности на фирмата. Моделиране и анализ на данните е сложен процес, зависещ до

голяма степен от предметната област, структурата и организацията на дейностите на

МСБ. Комплексността на въвеждането на DWH/BI-технологии се усложнява

допълнително от концепцията и реализацията на ETL-процесите и представяне на

данните и информацията. В литературата липсват данни за стандартни процедури и

последователност, както при тяхната концепция, така при тяхната реализация, което

е един основен фактор за ефективността и себестойността на DWH/BI-технологиите.

5. Липсата на единна методология при разработката и внедряването на DWH/BI-

системи за обработка и анализ на данни при управлението на фирма представлява

значителен проблем за МСБ. Поради тази причина e необходима да бъде разработена

подходяща методология за концепцията и реализацията на DWH/BI-технологии.

По този начин фирмите могат да придобият ясна представа както за изграждането, така

и за администрацията и себестойността на информационните системи и да вземат

адекватно решение за свързаните с тях инвестиции.

Глава 3

Методология за изграждане на DWH/BI-системи Целта на тази глава е разработката на методология, с която фирмите от МСБ ще

бъдат в състояние да въведат DWH/BI-система и да намалят максимално разходите за

развитие и поддръжка. Методологията се състои от следните четири раздела:

• архитектура за моделиране на данни и метаданни;

• изграждане на оптимизирани ETL-процеси;

• представяне и разпространение на информацията;

• избор на подходяща софтуерна платформа.

3.1 Архитектура за моделиране на данни и метаданни Архитектурата на данните е най-важният основен елемент от изграждането н на

една DWH/BI-система.. В по-късен стадий на развитие, когато всичките процеси на

ETL и отчети са реализирани, промяната на модела е изключително скъп и сложен

процес, който засяга всяка част на реализацията и често води до концепцията и

изграждането на нова DWH/BI-система.

3.1.1 Универсално-трезорна архитектура на моделиране Универсално-трезорна архитектура е в състояние да приеме всякакви промени без

да нарушава съгласуването на реализацията, свързана с ETL-процесите и представянето

на данните. За постигането на тази цел се прилага комбинация от универсално

моделиране и трезорно моделиране на данни.

2.2. Универсалното моделиране се базира на следните принципи:

1. Типовете класове трябва да представляват и да се наименуват на тяхната основна

същност, а не на ролята, която играят в даден контекст.

2. Типовете класове трябва да бъдат част от под тип/супер тип йерархия, за да се

определи универсален контекст за техния дизайн.

3. Дейностите и асоциациите трябва да бъдат представени от типове класове (не от

връзки).

16

4.Връзки (в смисъл на ERM представящи дейности или асоциации) трябва единствено

да се използват за изразяване на участие с типове класове.

5.Кандидат атрибутите трябва да се търсят в представляващи връзки с другите типове

обекти.

6.Типовете класове трябва да имат един атрибут за свой главен ключ. Той трябва да

бъде изкуствен и да не може да се променя от потребителя. За разлика от

универсалният модел, където таблиците са изключително нормализирани, при

трезорният модел обектите се моделират като стандартни типизирани таблици, които се

определят като хъбове, сателити и връзки между тях. С този подход се постига една

изключително гъвкава архитектура със следните качества:

• промени на модела на данните се извършват предимно с добавяне на

допълнителни сателити и връзки. Поради тази причина промените са локални и

останалите части от него остават съгласувани;

• ETL-процесите са стандартизирани за хъбове, връзки и сателити и когато нови

елементи се прибавят към модела, те могат да бъдат копирани от вече реализираните

процеси и да се напасват на новите елементи. Това води до ускоряване на реализацията

и улесняване на поддръжката на целия проект;

• разделението на бизнес правилата от обектите позволява паралелизиране на ETL-

процесите и ефективно управление на жизнения им цикъл;

• моделът е оптимизиран за запазване на данните и тяхната история.

Поради тази причина е нужно създаването допълнителен модел за анализ на данните

от тип схема звезда, който съдържа факт-таблици, дименсии, агрегати и дата кубове.

В настоящата методология предлагам съчетание от универсално и трезорно

моделиране на данните, което спомага за осъществяване на предимствата от двете

архитектури, както и за драстично намаляване на разходите за концепция, реализация и

поддръжка на цялата система. Универсалната структура позволява повторното

използване на модулите на моделът. Трезорният дизайн улеснява реализацията и

поддръжката на моделът. Моделите са универсално-трезорни и могат да бъдат

разширени и приспособени към изискванията на организацията с минимални промени

или чрез генериране на нови локални модули. Тези характеристики водят до значителен

потенциал за намаляване на разходите за нова концепция, реализация и поддръжката на

системата. Редуцирането на разходите се дължи на универсално-трезорната структура

на модела, но също така и на оптимизираната структура на ETL-процесите, които се

базират върху него.

3.1.2 Универсално-трезорен модел за метаданни Метаданните най-често биват дефинирани като "data about data” - данни, които

определят данните. Това определение е сравнително абстрактно и може да се тълкува

различно в различен контекст. Но точно в този двусмислен аспект на определението

се изразяват неговата прецизност и съдържание. Това са данните, които възникват при

моделирането на дадени обекти и връзки между тях на зададено абстрактно ниво и

контекст. Моделът във всяко следващо абстрактно ниво е мета модел на предишното.

На фиг. 3.1 e представена зависимостта на модели и метаданни в различните

абстрактни нива. Реалните обекти съществуват в реалния свят на абстрактно ниво 0.

Моделът на реалния обект представлява неговото абстрактно (опростено) изображение

за определена цел и в определен контекст. С моделирането на реалният обект в първото

абстрактно ниво се създава модел 1, който се състои от метаданни за реалният обект. С

последователното моделиране на модел 1 във второ ниво се създава модел 2, който от

своя страна се състои от метаданни на модел 1. В контекста на реалният обект модел 2

е неговият мета модел, а модел 3 неговият мета мета модел, който от своя страна е

модел на модел 2 и мета модел на модел 1. Всеки модел на фиг. 3.1 има своя конвенция

17

и език на моделиране3. С изграждането на мета модел в по-високо абстрактно ниво

могат да се комбинират и консолидират различни модели притежаващи различни

конвенции, семантики и метаданни. Метаданните, които възникват при моделиране на

обектите и свързаните с тях процеси се определят като структурни метаданни. В

зависимост от сферата на техният произход те се класифицират като технически или

бизнес метаданни. За пример на технически метаданни може да послужи описанието

на една таблица, която се състои от определени колони с определен формат. Пример за

бизнес метаданни може да бъде дефиницията на клиент, който представлява физическо

или юридическо лице с определени атрибути, което е закупило определен продукт. С

помощта на структурните метаданни потребителите могат да се ориентират и да

придобият ясна представа за реалните обекти без дори да са се докоснали до тях.

Структурните метаданни са сравнително статични данни. Свързаните с тях обекти

претърпяват промени главно в дългосрочен план. За разлика от тях метаданните

произлизащи при взаимодействието на обектите са динамични и биват определени като

оперативни метаданни. Оперативни метаданни са предимно статистически данни,

които описват събитията и процесите свързани с реалните обекти. В зависимост от

сферата на техният произход те също се класифицират като технически или бизнес

метаданни. На фиг. 3.2 e представена класификацията на технически/бизнес и

структурни/оперативни метаданни. Метаданните са от изключително значение за

коректната експлоатация и бъдещо развиете на една DWH/BI-система. Въпреки този

факт повечето организации притежаващи DWH нямат централизирано обработване и

управление на метаданни. Основните причини за този факт се определят като:

• липса на утвърдени стандарти - всеки софтуерен производител намира свой подход за

моделирането, запазването и управлението на метаданните;

• допълнителни ресурси и инвестиции - произлизащи от комплексна концепция и

реализация за централизирано управление на метаданните.

Поради горе споменатите причини, целта на представения прототип е реализацията на

ефективен склад за метаданни, който е достатъчно универсален за запазването на

всякакви метаданни и модели в организацията. С неговото въвеждане е възможно:

• каталогизиране на всички технически и бизнес обекти в организацията;

• проследяване на структурната им зависимост на обектите през всички системи и

процеси на организацията;

• проследяване на промените и възстановяването на стари версии на обектите;

• модуларно изграждане и конфигурация на цялата DWH/BI-система;

18

• генериране на нови технически елементи и системни модули (ETL- процеси и

доклади).

За постигането на тази цел моделирането започва на високо абстрактно ниво. Всеки

самостоятелен елемент е представен като един обект H_OBJECT с определени

атрибути H_ATTRIBUTE. Както обектите, така и атрибутите притежават определени

типове H_OBJECT_TYPE и H_ATTRIBUTE_ TYPE. На фиг. 3.3 e представена първата

скица на склада за метаданни. Всеки обект може да притежава неограничен брой

атрибути, както и всеки атрибут може да бъде притежаван от неограничен брой обекти.

Релацията между класовете обект и атрибут притежава кардиналност (n:m), е

осъществена чрез допълнителният клас L_OBJECT_AT- TRIBUTE. Аналогично се

изразяват и релациите между всички останали класове. По този начин се спазват трети

и четвърти принцип на универсалното моделиране, които изискват дейностите,

асоциациите и връзките да се моделират с отделни класове. Релациите между атрибут с

тип на атрибутите L_ATTRIBUTE_ATTRIBUTE_TYPE и обект с тип на обектите

L_OBJECT_OBJECT_TYPE са моделирани на същият принцип. Типовете обекти също

могат да притежават атрибути, което е моделирано с връзката между тях

L_ATTRIBUTE_OBJECT_TYPE. Всички обекти са наименувани на тяхната основна

19

същност, което е първото изискване на универсалното моделиране. Префиксите H-HUB

хъб и L-LINK връзка са типични за трезорното моделиране и подсказват за тяхното

предназначение: таблиците от тип хъб се състоят от уникални списъци на бизнес

ключове, връзките от своя страна се състоят от уникални списъци на асоциации,

дейности и релации на два или повече технически ключа. Поради факта, че

техническите ключове не се променят, моделирането с хъб и връзки позволява

изграждането на една изключително стабилна и в същото време гъвкава архитектура.

Промени в структурата на модела се осъществяват чрез добавянето на нови хъбове,

които се интегрират с помощта на нови връзки без да се променя съгласуването на

другите части на модела. Всичките обекти на модела притежават един изкуствен

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

Вторият принцип на универсалното моделиране изисква класовете да бъдат част от под

тип/супер тип йерархия, за да се определи универсален контекст за техния дизайн. За да

се удовлетвори това условие в модела се добавят класовете релация H_RELATION и

тип на релация H_RELATION_TYPE, както и връзките L_OBJECT_RELATION_TYPE,

L_OBJECT_ RELATION и L_OBJECT_RELATION_TYPE между хъбовете релация,

обект и тип на обект представени на фиг. 3.4:

Класовете от тип хъб H_RELATION_TYPE и H_RELATION имат за цел

класифицирането на всички възможни релации - йерархии, асоциации, връзки,

кардиналности и др. - между класовете H_OBJECT и H_OBJECT_TYPE. Релациите са

представени от хъб H_RELATION и връзките L_OBJECT_RELATION и

L_OBJECT_RELATION_TYPE, които ще бъдат двойно посочени с хъбовете

H_OBJECT и H_OBJECT_TYPE. Двойната връзка се осъществява с два външни ключа

в клас от тип връзка, които посочват към един първичен ключ от съответният хъб. С

помощта на хъб H_RELATION релацията се осъществява в определен контекст, което

удовлетворява изискването за универсалният контекст за дизайн на класовете.

20

Връзката L_OBJECT_RELATION с хъбове H_OBJECT и H_RELATION са представени

подробно на фиг. 3.5. Хъб H_OBJECT притежава първичен изкуствен ключ

H_OBJECT_ID и един съставен бизнес ключ6 състоящ се от SOURCE_KEY и

OBJECT_KEY. SOURCE_KEY е бизнес ключът на източниците, от които са

импортирани бизнес ключовете на обектите. Ключът е съставен, защото бизнес

ключовете на различни обекти от различни източници могат да притежават еднакви

бизнес ключове. H_OBJECT е единственият хъб със съставен бизнес ключ. Всички

останали хъбове притежават един първичен изкуствен ключ, един бизнес ключ и два

технически атрибута LOAD_DTS и RECORD_SOURCE, които са стандартни атрибути

в трезорното моделиране и съдържат датата на зареждане и първоизточника на

данните.

Връзката L_OBJECT_RELATION притежава един атрибут L_OBJECT_RELATION_

ID играещ ролята на изкуствен първичен ключ и комбинация от три изкуствени

вторични ключа, един от хъб релация H_RELATION_ID и два от хъб обект

H_OBJECT_ID и REL_H_OBJECT_ID. Както H_OBJECT_ID така и

REL_H_OBJECT_ID се отнася за първичния ключ H_OBJECT_ID на хъб H_OBJECT.8

По този начин могат да се моделират горе описаните връзки с неограничена дълбочина

и структура. Принципът на йерархична релация е демонстриран с моделиране на

организация със следните характеристики:

• дейността на организацията O1 се разпределя в два основни отдела D1 и D2;

• дейността на отделът D2 се разпределя в два региона, които се обработват от

звената U1 и U2;

• с разрастване на организацията в бъдеще се очакват възникването на нови

отдели и звена;

• както новите, така и старите отдели и звена също могат да имат свои

подразделения;

• структурата на организацията е гъвкава, което позволява реформирането

на разделения и подразделения.

Моделът на горе описаната структура представлява йерархия от елементи на

определени нива, която може да бъде представена по следния начин:

Метаданните за моделът представен на фиг. 3.6 са заредени във връзката

L_OBJECT_RELATION и хъбовете H_OBJECT и H_RELATION, са представени на

табл. 3.7. В хъб H_OBJECT са записани бизнес ключовете на организацията, отделите и

звената. Първичните изкуствени ключове са свързани двойно във връзката L_OB-

JECT_RELATION като вторични ключове, с което се осъществява йерархията между

тях. В H_OBJECT_ID са вкарани ключовете на родителският елемент, докато в

REL_H_OBJECT_ID тези на преките им наследници. Посочването на H_RELATION

21

класифицира връзката между елементите на организацията, в този случай от тип

"родител-дете” (parent-child). С развитието на организацията новите отдели и звена се

прибавят на съответното ниво и техните метаданни се заредят аналогично.

Представените на този етап класове са от тип хъб и връзка, които съдържат единствено

бизнес ключове на реалните обекти и релациите между тях. Метаданните обаче се

състоят не само от бизнес ключове, но и много други допълнителни атрибути.

Характерно за тези атрибути, е че те изпълняват описателна роля за реалните обекти и

техните връзки и се променят с времето. При трезорното моделиране всички атрибути

от такъв тип се поставят в класовете от тип сателит, които отговарят на съответния хъб

или връзка. На фиг. 3.8 са представени сателитите на H_OBJECT и

L_OBJECT_RELATION.

Кардиналността на хъбовете и връзките към сателитите е (1:n), всеки бизнес ключ

притежава минимум една асоциация в своят сателит. Сателитите са изградени на

принципа на бавно променящи се дименсии (SCD 2) и съдържат цялата история на

съответния хъб или връзка. Структурата на таблиците от тип сателит съдържа следните

технически атрибути:

• S_OBJECT_ID - изкуствен първичен ключ, който се състои от уникални номера.

Единственото му предназначение е да определя всяка редица в таблицата като уникат.

За неговото генериране често се използват последователности, функции,

специализирани таблици, ETL-инструменти и др.;

• H_OBJECT_ID - вторичен ключ, който се отнася до изкуственият първичен ключ на

съответният хъб или връзка;

• LOAD_DTS - дата и час на зареждане. LOAD_DTS не се променя в историята на

обекта;

• END_DTS - дата и час, в които възниква нова версия на атрибутите. За актуалната

версия END_DTS� е NULL или често дата в бъдещето като например 31.12.9999. За

предишната версия END_DTS�−1 = LOAD_DTS�−1 сек. Например новата версия на

22

Фигура 3.7. Метаданни на организацията

Фигура 3.8. Хъб H_OBJECT, връзка L_OBJECT_RELATION и сателити

S_OBJECT и S_OBJECT_RELATION

атрибутите се записва в LOAD_DTS� = 02.04.2012 12:00:25 с END_DTS� = 31.12.9999

и старата версия се актуализира с END_DTS�−1 = 02.04.2012 12:00:24;

• RECORD_SOURCE - източникът на данните;

• LAST_UTS - дата и час, в които се актуализират атрибутите. За

разлика от LOAD_DTS LAST_UTS се променя при всяка актуализация;

• CURRENT_IND - 1 за актуалната версия и 0 за всички останали. С

23

Фигура 3.9. Универсално-трезорен модел на склад за данни

24

помощта на CURRENT_IND актуалната версия може да се индексира с битмап и по

този начин да се запитва ефективно;

• L_MODEL_VERSION_CHANGE_ID - е асоциация към модел, който проследява

промени във версията на моделите. Всички останали сателити са изградени аналогично

и притежават същите технически атрибути. На фиг. 3.9 е представен цялостният

универсално-трезорен модел, който се отличава със следните характеристики:

• допълнителни описателни атрибути могат винаги да се прибавят към модела без да се

променя съгласуването на класовете и техните релации;

• към хъбовете и връзките също така могат да се прибавят и допълнителни сателити,

които имат различни описателни атрибути. Пример за това приложение могат да бъдат

атрибутите на обекти от различни източници, които се различават по между си.

Тяхното моделиране в отделни сателити допринася за ефективното им зареждане,

спестяване на пространство10 и запазване на яснотата на модела;

• промени в моделът могат да бъдат реализирани и чрез добавяне на нови хъбове и

връзки между тях, което също няма да наруши съгласуването на другите класове и

техните релации;

• универсално-трезорната структура позволява повторното използване на неговите

модули и на базиращите се върху тях ETL-процеси. Промени в бизнеса на

организацията, на законовите, нормативните и регулаторни изисквания могат да

засегнат, както атрибутите на обектите, така и структурата на техният модел. Данните

за структурните промени на моделите съдържат важна информация, която се запазва в

специализиран модел за структурни промени.

3.1.3 Универсално-трезорен модел за структурни промени

Структурните промени на моделите се проследяват с помощта на атрибута

L_MODEL_VERSION_CHANGE_ID, който се отнася за връзката

L_MODEL_VERSION_ CHANGE намираща се в модела представен на фиг. 3.10.

Моделът за структурните промени е базиран на същите принципи, както и

универсално-трезорен модел за метаданни, но на по-високо абстрактно ниво. В него се

запазват метаданни на моделите, които се състоят от версиите и промените на техният

жизнен цикъл. Основните класове на модела са:

• H_MODEL - хъб, съдържащ бизнес ключовете на различните модели. В сателита

S_MODEL се запазват описателни метаданни за моделите,

както и тяхната история;

• H_VERSION - хъб, съдържащ бизнес ключовете на различните версии за даден модел.

В сателита S_VERSION се запазват описателни метаданни за версиите, както и тяхната

историзация;

• H_CHANGE - хъб, съдържащ бизнес ключовете на различните промени за дадена

версия и модел. Към него е прибавен хъб H_CHANGE_TYPE тип на промените, както и

връзка между тях L_CHANGE_CHANGE_TYPE. В сателитите S_CHANGE и

S_CHANGE_TYPE се запазват съответно описателни метаданни за промените и

техните типове, както и тяхната история;

25

Фигура 3.10. Универсално-трезорен модел за структурни промени

На Фигура 3.11 са представени примерни метаданни за класове H_MODEL,

H_VERSION, H_CHANGE и L_MODEL_VERSION_CHANGE:

В хъб H_MODEL са заредени бизнес ключовете на три модела: MD_DV_MODEL,

HR_DV_MODEL и HR_DWH_MODEL. Моделът MD_DV_MODEL е създаден на

01.01.2012 и първоначално е имал една версия V100 и една промяна CH100, които са

заредени съответно в хъб H_VERSION и H_CHANGE. Връзката

L_MODEL_VERSION_CHANGE пресъздава това съчетание с релацията на трите хъба.

Всички сателити на модела притежават първоначално

L_MODEL_VERSION_CHANGE_ID = 1.

Фигура 3.11. Метаданни за структурни промени

С приложението на складовете за метаданни и структурни промени могат да се

поставят основите на едно централизирано и ефективно управление за всички видове

модели и метаданни. По този начин е възможно каталогизирането на техническите и

бизнес обекти в организацията, проследяването на структурната им зависимост и

промени, възстановяването на техни стари версии и промени.

26

3.2 Изграждане на ETL-процеси ETL-процесите включват всички дейности от набавянето на данни от различни

източници, преработването и почистването им до финалното им зареждане в DWH/BI-

системата. Тяхната концепция и структура се базира на изградените модели на данните,

които пресъздават бизнес моделът на организацията. Реализацията на ETL-процесите се

осъществява с помощта на програмни езици като C, JAVA, PL/SQL и др., със

специализирани софтуерни продукти като OWB, KETTLE, Informatica и др. или най-

често с комбинацията от двете алтернативи. Основните принципи при развитието на

ETL-процесите се изразяват в:

• цялостност - коректната концепция и реализация на всички релевантни процеси за

обработка на данните;

• приспособимост - ETL-процесите трябва да бъдат лесно приспособими на

евентуални промени на модела на данните или на бизнес логиката;

• устойчивост - ETL-процесите трябва да бъдат устойчиви при голямо натоварване и

голям обем от данни. Времето за зареждане на данните не трябва да се увеличава

експоненциално с увеличаване на обема на данните;

• опростеност - опростената структура на ETL-процесите спомага за яснотата им.

Комплексната структура води автоматично до сложна и скъпа реализация и

администрация на цялата система;

• стандартизация - стандартизиране на ETL-процесите спомага както за яснотата и

поддръжката на цялата система, така и за намаляване на риска от допускането на

евентуални грешки;

• съгласуване - ETL-процесите трябва да спомагат за запазване на съгласуването на

данните. Желателно е автоматично запазване на съгласуването при евентуални

умишлени или неумишлени прекъсвания на процесите, породени от несъгласувани

данни, срив на системата или по други причини.

Разходите за концепция, реализация и поддръжка на ETL-процесите често надхвърлят

бюджета за DWH/BI-системата. Поради тази причина е от изключително значение

спазването на горе описаните принципи. ETL-процесите се състоят предимно от две

основни части: mapping изображение и workflow13 работен поток. Изображението

представлява ориентиран граф, който се състои от следните типове градивни елементи:

• sources - източници на данните могат да бъдат всякакви хардуерни или софтуерни

обекти, но най-вече те са: структурирани или неструктурирани файлове, таблици, уеб-

страници и др. На фиг. 3.12 източникът на данните е буферната таблица

STG_OBJ_TYPE;

• components - структурни елементи, които извършват операции с данните. Тези

елементи от своя страна могат да бъдат активни, които променят кардиналността на

данните или пасивни, които не я променят. На фиг. 3.12 всички елементи между

източниците и целите на данните са от този тип;

• mapplets - композиционни елементи, които се състоят от други елементи със

заложени входни и изходни атрибути. Целта е комбинации от елементи15, които могат

да се използват повторно, да бъдат запазени като един съгласуван елемент. Това

допринася за намаляване на грешките и запазването на яснотата на изображението, чрез

намаляване на графичните му елементи. На фиг. 3.12 не са използвани елементи от този

тип;

• targets - цели на данните са аналогични обекти на източниците с единствената

разлика че данните не се прочитат, а се записват в тях. На фиг. 3.12 целите на данните

са таблиците H_OBJ_TYPE и S_OBJ_TYPE. Работният поток също представлява

ориентиран граф, който се състои от едно или няколко изображения и допълнителни

контролни елементи за управление на изпълнението, които могат да бъдат извършени

27

паралелно или последователно. Основните функции на работеният поток се

различават при различните софтуерни продукти, но общо могат да бъдат описани като:

• комбинативен елемент, който обединява изображения, под-процеси и други

контролни елементи за извършването на комплексна логика;

• допълнително абстрактно ниво на изображенията от техните физикални атрибути

като например: комит-интервал, логин, схема, база данни, часови график и др.

Фигура 3.12 HLD изображение за зареждане на данни в хъб и сателит

С представената концепция ETL-процесите могат да бъдат оптимизирани и разходите

максимално редуцирани. За тази цел се разработва т. нар. дизайн на високо ниво high

level design (HLD), който цели установяването на основните характеристики на ETL-

процесите под формата на псевдо код и диаграми.

На фиг. 3.11 е представен един универсален HLD, структурата на който се използва при

реализацията на работен поток за всички ETL-процеси:

Фигура 3.13 HLD на работен поток

В първата стъпка на фиг. 3.11 е моделиран старта на процесът

START_ETL_PROCESS.

Всеки процес, който променя данните трябва да гарантира техният съгласуван статус,

дори при евентуално желателно или нежелателно прекъсване на процеса. За тази цел е

моделиран универсален20 под-процес SEC_CONS_STATUS, който запазва

първоначалният статус на данните.

След запазването на данните се стартира под-процесът INS_UPD_DATA, който

зарежда новите или променя настоящите данни. В зависимост от обработените данни,

28

бизнес правилата за тяхното зареждане, както и стабилността на инфраструктурата са

възможни следните три завършека на процеса:

• NOT OK - под-процесът INS_UPD_DATA е прекъснат или завършен с грешки. За

възстановяването на съгласуваният статус на данните е реализиран универсалният под-

процес RECOV_CONS_STATUS. След неговото изпълнение отговорните специалисти

ще бъдат информирани за неуспешният завършек от под-процеса INFORM;

• WARN - под-процесът INS_UPD_DATA е завършен с предупреждения. В този

случай специалистите трябва да определят дали трябва да бъдат информирани или

може да се пристъпи към изпълнението на следващия процес;

• NOT OK - под-процесът INS_UPD_DATA е завършен успешно и може

да се пристъпи към изпълнението на следващия процес.

3.3 Представяне и разпространение на информацията Представянето (презентацията) на данните т. нар. frontend представлява върха на

айсберга в една DWH/BI-система. Моделите на данните са поставили архитектурата на

системата и ETL-процесите са обработили и заредили данните в нея.21 След което

информацията трябва да се представи на потребителите под формата на доклади,

графики, мултидименсионни кубове и табла. Представянето на информацията обхваща

също и т. нар. графичен потребителски интерфейс (GUI)22, с който потребителите

могат директно да боравят с данните: да ги вкарват, променят и изваждат от базата

данни или операционната система.

Основните принципи при концепцията и реализацията не се различават особено от тези

на ETL-процесите и се изразяват в: сигурност, опростеност, устойчивост,

съгласуваност, точност. стандартизация.

3.4 Избор на софтуерна платформа

В примерната цена за хардуер от т. 1.2 е включен корпоративен сървър с

минимална конфигурация, който може да бъде използван при малки и средни фирми

със сравнително малък до среден обем (2 ТB) от данни и натоварване. Поради

минималният потенциал за намаляване на хардуерните разходите, е разгледано

единствено оптимизиране на софтуерните разходи за системата.

Софтуерните разходи са приблизително двойно на хардуерните разходи и при тях

съществува потенциал за намаляване на разходите за цялата система. Потенциалът се

изразява в изборът на софтуер, при който сумата от лицензни разходи, разходи за

развитие и разходи за поддръжка е минимална в сравнение с функциите, които

предлага DWH/BI-системата. За избор на софтуер съществуват следните алтернативи:

• закупуване на комерсиален софтуер;

• закупуване на софтуер с отворен код;

• аутсорсинг на цялата система.

За комерсиалната алтернатива предлагам въвеждането на Oracle база данни, която

включва интегрирани ETL-софтуер и сървър за представяне на данните. Oracle

Corporation предлага различни лицензни договори, които са подходящи, както за голям,

така и за малък и среден бизнес.

За алтернативата с отворен код предлагам въвеждането на PostgreSQL база данни и

Pentaho28. С комбинацията от PostgreSQL и Pentaho фирмите могат да разполагат с

всички необходими средства за изграждане на една корпоративна DWH/BI-система.

Основните предимствата на този избор са: нулевата цена, отвореният код, голямата

общественост и платформената независимост. Тези характеристики определят тази

комбинация като идеален избор за сравнително малки фирми, които нямат възможност

или не са готови да вложат средства за закупуването на комерсиален софтуер. Въпреки

своите предимства тази алтернатива не може да покрие изискванията на всички

организации. Предимно средно големи фирми са заинтересовани от качествата на

29

софтуера, който използват като: дългосрочни гаранции за поддръжка и бъдещо

развитие, подкрепа на първо и второ ниво от производителят, стабилност на софтуера

при големи обеми от данни и натоварване и др. Допълнително към тези изисквания

много от тези фирми вече притежават комерсиален софтуер, за който са вложили

определени средства и са изградили ноу-хау(know-how) в неговата употреба.

За аутсорсинг алтернативата трябва да се съпоставят общите разходи на година към

предимствата и недостатъците, които са свързани с нея.

При даденият пример общите разходи на година са TCO = 60 877 лв. /

3 г. = 20 292,33 лв./г. Трите основни предимствата при аутсорсинг са:

• фирмата може да се концентрира върху своята основна дейност;

• DWH/BI-системата може по-бързо и ефективно да бъде въведена

в употреба;29

• потенциал за намаляване на общите разходи и увеличаване на гъвкавостта

на фирмата.

Трите основни недостатъка при аутсорсинг са:

• загуба на контрол върху поверителни данни на фирмата, което е

основният недостатък при аутсорсинг;

• скрити разходи произхождащи от проблеми с комуникацията, недостатъци

в качеството на услугите, както и управление и изпълнение

на договорни отношения;

• потенциал за намаляване на гъвкавостта на фирмата, произхождащо

от факторите изброени във втора точка.

3.5 Изводи

1. За постигане на висока степен на ефективност при изграждането

и реализацията на DWH/BI-системи за малки и средни предприятия, е необходима

методология на развитие състояща се от следните основни раздели: избор на

подходяща инфраструктура, гъвкава архитектура за моделиране на данни,

стандартизирани ETL- и BI-процеси.

2. Софтуерната платформа може да бъде реализирана както с комерсиален софтуер,

така и със софтуер с отворен код. Въвеждането на софтуер с отворен код може

първоначално да улесни фирмите, но в по-късен стадий на развитие разходите за

поддръжка и реализация могат да надхвърлят тези на комерсиалният софтуер.

3. С комбинацията от трезорно и универсално моделиране е разработена гъвкава

архитектура за моделиране на данни. Разработените с нея модели са универсално-

трезорни и могат да бъдат разширени или приспособени към изискванията на всяка

организация. Стандартизираната структура и типизиране на класовете спомагат

за бързата ориентация в моделите и позволяват изграждането на стандартни методи и

процеси за тяхното зареждане и запитване. 4. С приложението на представената

архитектура са разработени модели на склад за метаданни и структурни промени, които

поставят основите на едно централизирано и ефективно управление за всички видове

модели и метаданни. По този начин е възможно каталогизирането

на техническите и бизнес обекти в организацията, проследяването на структурната им

зависимост и промени, възстановяването на техни стари версии и промени.

5. На базата на представените модели е разработена концепция за изграждане на ETL-

процесите, която е независима от използваният ETL-софтуер и може да се приложи за

всички таблици от представените модели. Това изключително предимство позволява

реализацията на оптимизирана структура за всички ETLпроцеси, която може да се

извършва много по-бързо и ефективно в сравнение с конвенционалният подход, при

който всеки ETL-програмист прилага свой дизайн и начин на изпълнение.

30

Оптимизираната структура на ETL-процесите също така улеснява поддръжката на

цялата DWH-система.

6. Основната цел на BI-процесите е ефективното разпространение и представяне на

получената информация под формата на доклади, графики, мултидименсионни кубове

и табла. За да бъде гарантирано качеството на информацията е необходим системен

подход още от процеса на проектиране, при който основните изисквания са:

сигурност, цялостност, устойчивост, точност и стандартизация.

7. С използването на разработената методология се осигурява висока степен на

ефективност, улеснена реализация и повторно използване на вече съществуващи

модули. Поради тези качества се очаква значително намаляване на разходите за

концепция, реализация и поддръжка на DWH/BI-системата.

Глава 4

Приложение на методология за изграждане на DWH/BI-системи

4.1 Модели на данни за човешки ресурси

Човешкият ресурс е най-важният актив във всяка организация За неговото

управление мениджърите трябва да са в състояние да разберат възможно най-добре

демографията и уменията на служителите си. Това е предпоставката за постигането на

тяхната максимална производителност и ефективност, което от своя страна е основния

фактор за успешното управление на фирмата. В следващите раздели са разработени

модели за управлението на човешките ресурси.

4.1.1 Универсално-трезорен модел за човешки ресурси

За да се създаде контекст на моделиране, нека изходим от организация

със следните характеристики:

• организацията е изградена йерархично и притежава отдели и звена, които също

могат да имат техни подразделения;

• организацията работи и сключва договори с физически и юридически лица;

• служителите на организацията могат да бъдат, както външни консултанти от други

фирми, така и назначени на трудов договор;

• всеки служител може да има различна квалификация и да заема различни постове

в йерархията на организацията;

• служителите извършват различни типове дейности, които са организирани в

определени проекти;

• извършените дейности трябва да се администрират както на ниво служител, така и

на ниво проект и организация.

4.1.2 Схема звезда за човешки ресурси

Схема звезда е тип мултидименсионален модел (MDM), който намира широко

приложение в областта на DWH. За разлика от универсалното моделиране, моделите на

мултидименсионалното моделиране са оптимизирани за запитването и анализ на

данните т. нар. query трансакции. В този раздел e развит мултидименсионален модел

със схема звезда, който се базира на универсално-трезорния модел за човешки ресурси.

4.2 Реализация на ETL-процеси

ETL-процесите включват всички дейности от набавянето на данни от различни

източници, преработването и почистването им до финалното зареждане в DWH/BI-

системата. За демонстрация на тяхната разработка ще дефинираме един ETL-процес

със следните изисквания:

• намери всичките типове обекти, които съществуват в базата данни;

• запиши всичките типове обекти, в принадлежащите хъб и сателит таблици;

• изгради история на променените данни за всички обекти.

31

4.2.1 ETL c Oracle Warehouse Builder

За моделирането и управлението на горе дефинираният ETL-процес са използвани

инструментите Дизайн Център (DC) и Мениджър на Контролния Център (CCM) (Design

Center и Control Center Manager). Реализацията на ETL-процеса е разделена в три

изображения и един работен поток.

4.2.2 ETL c Pentaho Data Integration

4.3 Приложение на BI

4.3.1 Реализация с Oracle Application Express (APEX)

За презентация на BI е разработено уеб приложение с APEX, което има за цел

администрацията на потребителите в базата данни. Приложението представя табло,

стандартни доклади за потребители, техните роли и профили, както и GUI за тяхното

управление.

Oracle Application Express (APEX) е браузер-базирана програмна среда интегрирана в

базата данни, която се използва за развитие на уеб-приложения.

4.3.2 Реализация c Pentaho Pentaho Business Intelligence

Pentaho Business Intelligence (BI) Platform е сървър за бизнес анализ, който се състои от

набор софтуерни компоненти, които са интегрирани и работят заедно. Някои от

компонентите управляват основните функции като автентификация и авторизация на

потребителя или връзката с базата данни. Други компоненти работят на по-високо ниво

като осигуряватвизуализиране на данните с помощта на диаграми и графики.

Отчетът може да бъде прегледан в следните формати: PDF, HTML, Excel (2007), RTF,

Text и CSV. След завършването му той може да бъде запазен локално или да се

публикува директно на BI-сървъра.

4.4 Изводи

1. С приложението на разработената генерично-трезорна архитектура, е

конструиран и реализиран модел за управлението на човешки ресурси със следните

характеристики:

• възможност за проследяване на наличните ресурси, техните квалификации,

компетенции и зависимости;

• отчетност и администрация на заетите ресурси по проекти и дейности в

организацията;

• управление на договори с физически и юридически лица;

• история на данните, позволяваща проследяване на промените за даден период от

време.

2. Разработеният модел е универсален и може да приеме данните за човешки ресурси

на всякакъв тип организации. Гъвкавата му архитектура позволява промени в

структурите на организацията и нейният персонал да бъдат въведени без или с

минимални локални

промени в модела. Това ще доведе до оптимизиране на разходите за управление на

човешките ресурси, както и за увеличаване тяхната ефективност.

3. Представеният универсално-трезорен модел е оптимизиран за запазването и

данните, но не и за тяхното запитване и анализ. Поради тази причина е разработен

допълнителен мултидименсионален модел, който се базира върху него и покрива

следните процеси:

• процес управление на договорни отношения на ниво: ден, договор, роля, служител и

организация;

• процес мениджмънт на кадрови състав на ниво: ден, квалификация и служител;

• процес изразходвано работно време на ниво: час (час: минута: (секунда), ден,

дейност, проект, служител и организация.

32

4. На базата на разработените модели и на разработената в раздел 3.2 методология и

дизайн за зареждане на таблиците, са конструирани и реализирани ETL-процеси със

следните изисквания:

• намери всичките типове обекти, които съществуват в базата данни;

• запиши всичките типове обекти, в принадлежащите хъб и сателит таблици;

• изгради история на променените данни за всички обекти.

5. Реализацията на ETL-процесът с OWB се състои от три изображения и шест

операции, които заедно представляват стандартна структура за зареждането на

таблиците от тип хъб, линк и сателит. Процесът и неговите елементи са реализирани,

така че да запазват съгласуването на данните дори и при прекъсване и рестартиране

на процеса. Те могат да бъдат лесно приспособени и използвани в други структури и

процеси за зареждането на таблиците на универсално- трезорният склад за метаданни.

6. Аналогична реализация състояща се от три изображения и две операции на същият

ETL-процес беше извършена и с PDI. При PDI данните се извличат от базата данни,

обработват се от ETL-сървъра и отново се зареждат в нея. Докато при OWB всичките

операции се извършват по-ефективно и бързо, директно в базата данни. Въпреки този

недостатък, PDI е софтуер с отворен код и представлява една отлична алтернатива

предимно за малки фирми, които нямат възможност да закупят комерсиални продукти.

7. След обработката на данните, получената информация се представя на

потребителите под формата на доклади, графики, мултидименсионни кубове и табла.

Разработеното BI-приложение, състоящо се от уеб приложение реализирано с

Application Express

(APEX), има за цел администрацията на потребителите в базата данни. Приложението

представя информацията под формата на табла, стандартни доклади за потребители,

техните роли и профили, както и графичен потребителски интерфейс (GUI) за тяхното

управление.

8. APEX е интегрирана в базата данни програмна среда, включваща готови елементи,

с които реализацията и администрацията на апликациите се извършват бързо и

ефективно. Интеграцията в базата данни позволява използването на всички нейни

средства и механизми: SQL, PL/SQL, сигурност, разпределяне на натоварването,

архивиране на файлове, контрол на едновременно изпълнение и заключващи

механизми, трансакции, метаданни и мн. др. Тясната интеграция на APEX в базата

данни предлага много предимства, но също така е свързана и с предпоставката да се

използва единствено базата данни Oracle, която е комерсиална и трябва да бъде

лицензирана.

9. Като алтернатива на комерсиалната реализация беше направено BI-приложение с

платформата Pentaho, която предлага голям набор от функции и опции за изграждане на

BI система, напълно безплатно и без ограничение в базата данни. Реализираното

приложение се състои от стандартен доклад, табло и мултидименсионен куб (ROLAP)

за анализ на данните.

10. Използваните софтуерни инструменти, готови елементи и портал на Pentaho

изискват от програмиста задълбочени познания в HTML, XML, JavaScript и Java.

Реализацията на компонентите е свързана с екстензивното използване на програмен

код, без който са възможни единствено ограничен набор от функциите, които предлага

Pentaho. Данните и метаданните на апликациите се запазват под формата на файлове в

т. нар. склад, който се състои от директории с определена структура разположени в

инсталационната директория на операционната система. Тези характеристики водят

до допълнителни разходи при реализацията и администрацията, които в дългосрочен

план могат да надвишат общите разходи на приложенията реализирани с комерсиален

софтуер.

33

11. Въпреки тези качества на Pentaho фирмите от МСБ разполагат с нужните

инструменти за развитието на първокласна BI система. Pentaho е система с отворен код

и като такава разполага с голяма общност, която всекидневно допринася за бъдещото

му развитие. Фирмите, които имат изисквания за директна поддръжка и по-голяма

сигурност могат да използват комерсиалната версия Pentaho Enterprise Edition или

други комерсиални продукти.

Характеристика на приносите Научни приноси

1. Разработена е систематизирана методология за въвеждане на DWH/BI-технологии в

малки и средни фирми включваща:

• универсално-трезорна архитектура за данни и метаданни;

• класификация и моделиране на ETL-процеси;

• избор на софтуерна платформа.

2. Концепция и разработка на универсално-трезорни модели за метаданни

и структурни промени на моделите.

Приложни приноси

1. Разработени са универсално-трезорен и мулти-димензионен модел с агрегати за

управление на човешки ресурси.

2. Разработени са оптимизирани ETL-процеси, базиращи върху разработените

модели.

3. Разработени са приложения на основните модули от бизнес анализ (BI), за отчети,

табла и OLAP.

4. Създаден е код за тестване на системата с комерсиален софтуер и софтуер с

отворен код.

Публикации, свързани с дисертацията: 1. Saratchev, P., Rubertus, S. "Entwicklung einer Web Log Mining-Komponente

f.ur HERBIE\, WWU IT-Controlling, 2006-06-19, M.unster, Germany

2. L.ucke, C., Saratchev, P. "Methoden zur Identifizierung von Nutzerpr.aferenzen bei LBS”

WWU LBS, 2006-07-06, M.unster, Germany

3. Saratchev, P.,"DWH/BI-systems for SMEs\, TU Sofia, 2008, Kavala, Greece, September

18 th-19th

2008 pages 996-999; http://link.springer.com/chapter/10.1007%2F978-3-8349-

9591-9_9

4. Saratchev, P., Towards a Generic Metadata Modeling”, Goce Delcev

University, 2012- pages 11-18, Shtip, Macedonia

Приети материали за публикуване: 1. Saratchev, P.,"Универсално-трезорна архитектура за моделиране на данни”,

“Автоматика и Информатика”, 2013, София, България

Цитирания(Impact factor): 1. http://link.springer.com/chapter/10.1007%2F978-3-8349-9591-9_9

34

ABSTRACT

New trends and technologies driving the emerging and development of new forms of

communication and interaction, both in economic and social life. Professional and social

networks contribute to the global exchange of information and knowledge and are an integral

part of the modern life. This evolutionary process is reflected inevitably on the small and

medium-sized enterprises (SMEs). In search of competitive advantage in this dynamic

environment, the SMEs are seeking to use their material and intellectual resources most

efficiently and effectively. For this purpose they have to rely on information based on data

and facts.

The main topic of the PhD thesis is the developing of a systematic methodology for

the implementation and integration of DWH/BI information systems in the SMEs

including:

• generic-vault architecture for data and metadata;

• classification and modeling of standardized ETL-processes;

• choice of software platform.

With adopting of the presented methodology the SMEs may reduce the costs of concept and

implementation and lay the foundations of a modern information system.