Олап ексел кубчета. Създаване на OLAP куб с помощта на Microsoft Query

Ориз. 2. OLAP кубичен срез

Завъртане(Фигура 3) - операцията за промяна на местоположението на измерванията, представени в отчета или на показаната страница. Например ротационна операция може да включва размяна на редовете и колоните на таблица. В допълнение, завъртането на куб с данни премества измерения извън таблица до местоположението на измеренията, налични на показаната страница, и обратно.

OLAP не е отделен софтуерен продукт, нито език за програмиране, нито дори специфична технология. Ако се опитате да покриете OLAP във всичките му проявления, тогава това е набор от концепции, принципи и изисквания, които са в основата на софтуерните продукти, които улесняват достъпа на анализаторите до данни. Нека разберем За каквоанализаторите имат нужда от нещо специално улеснявамдостъп до данни.

Факт е, че анализаторите са специални потребители корпоративна информация. Задачата на анализатора е да намира модели в големи масиви от данни. Следователно анализаторът няма да обърне внимание на единствения факт, че в четвъртък, четвъртия ден, е продадена партида черно мастило на контрагента Чернов - той се нуждае от информация около стотици и хилядиподобни събития. Единични факти в базата данни могат да представляват интерес например за счетоводител или ръководител на отдел продажби, в чиято компетентност е сделката. Един запис не е достатъчен за един анализатор - например може да му трябват всички транзакции на даден клон или представителство за месец или година. В същото време анализатор изхвърляненужни подробности като ЕГН на купувача, точен адрес и телефонен номер, индекс на договора и други подобни. В същото време данните, които анализаторът трябва да работи, задължително съдържат числени стойности - това се дължи на самата същност на неговата дейност.

Така че анализаторът се нуждае от много данни, тези данни са селективни и също имат характер " набор от атрибути - номер". Последното означава, че анализаторът работи с таблици от следния тип:

Тук " Страна", "Продукт", "година" са атрибути или измервания, А " Обем на продажбите" - по този начин числова стойност или мярка. Задачата на анализатора, повтаряме, е да идентифицира устойчиви връзки между атрибути и числени параметри.. Разглеждайки таблицата, можете да видите, че тя може лесно да бъде преведена в три измерения: на една от осите поставяме държави, на другата - стоки, на третата - години. И стойностите в този триизмерен масив ще бъдат съответните обеми на продажбите.

3D представяне на масата. Сивият сегмент показва, че няма данни за Аржентина през 1988 г

Именно такъв триизмерен масив от гледна точка на OLAP се нарича куб. Всъщност, от гледна точка на строгата математика, такъв масив не винаги ще бъде куб: за истински куб броят на елементите във всички измерения трябва да е еднакъв, докато OLAP кубовете нямат такова ограничение. Въпреки тези подробности обаче, терминът "OLAP кубове", поради своята краткост и образност, стана общоприет. OLAP кубът изобщо не трябва да бъде 3D. Тя може да бъде както двумерна, така и многомерна, в зависимост от проблема, който се решава. Особено опитни анализатори може да се нуждаят от около 20 измервания - а сериозните OLAP продукти са проектирани точно за такъв брой. По-простите настолни приложения поддържат около 6 измерения.

измервания OLAP кубовете са съставени от т.нар маркиили членове. Например измерението „Държава“ се състои от етикетите „Аржентина“, „Бразилия“, „Венецуела“ и т.н.

Не всички елементи на куба трябва да бъдат попълнени: ако няма информация за продажбите на каучукови изделия в Аржентина през 1988 г., стойността в съответната клетка просто няма да бъде определена. Също така не е необходимо OLAP приложение да съхранява данни непременно в многоизмерна структура - основното е, че за потребителя тези данни изглеждат точно така. Между другото, именно при специални начини за компактно съхранение на многомерни данни "вакуумът" (незапълнените елементи) в кубовете не води до загуба на памет.

Самият куб обаче не е подходящ за анализ. Ако все още е възможно да се представи или изобрази адекватно триизмерен куб, тогава с шест или деветнадесет измерения ситуацията е много по-лоша. Ето защо преди употребаобикновените кубчета се извличат от многоизмерен куб двуизмерни маси. Тази операция се нарича "разрязване" на куба. Отново този термин е образен. Анализаторът, така да се каже, взема и "нарязва" размерите на куба според марките, които го интересуват. По този начин анализаторът получава двуизмерен разрез на куба и работи с него. Приблизително по същия начин дървосекачите броят годишните пръстени на рязане.

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

Ако погледнете по-отблизо таблицата, която изобразихме първо, можете да видите, че данните в нея най-вероятно не са първични, а са получени в резултат на сумиранеза по-малки предмети. Например една година е разделена на тримесечия, тримесечия на месеци, месеци на седмици, седмици на дни. Държавата е съставена от региони, а регионите са съставени от населени места. И накрая, в самите градове могат да се разграничат квартали и специфични търговски обекти. Продуктите могат да се комбинират в стокови групии така нататък. От гледна точка на OLAP такива многостепенни съединения се наричат ​​съвсем логично йерархии. Инструментите на OLAP позволяват по всяко време да преминете към желаното ниво на йерархията. Освен това, като правило, няколко вида йерархии се поддържат за едни и същи елементи: например ден-седмица-месец или ден-десетилетие-тримесечие. Изходните данни се вземат от по-ниските нива на йерархиите и след това се обобщават, за да се получат стойностите на по-високите нива. За да се ускори процеса на преход, сумираните стойности за различните нива се съхраняват в куб. Така това, което изглежда като едно кубче от страна на потребителя, грубо казано, се състои от много по-примитивни кубчета.

Пример за йерархия

Това е една от съществените точки, довели до появата на OLAP – производителност и ефективност. Нека си представим какво се случва, когато един анализатор трябва да получи информация, а OLAP инструментите не са налични в предприятието. Анализаторът самостоятелно (което е малко вероятно) или с помощта на програмист прави подходяща SQL заявка и получава интересуващите данни под формата на отчет или ги експортира в електронна таблица. Има много проблеми с това. Първо, анализаторът е принуден да върши нещо различно от работата си (SQL програмиране) или да чака програмистите да свършат задачата вместо него - всичко това се отразява негативно на производителността на труда, нападението, нараства нивото на инфаркт и инсулт и т.н. . Второ, един доклад или таблица, като правило, не спасява гигантите на мисълта и бащите на руския анализ - и цялата процедура ще трябва да се повтаря отново и отново. Трето, както вече разбрахме, анализаторите не искат дреболии - те се нуждаят от всичко наведнъж. Това означава (въпреки че технологията напредва със скокове и граници), че сървърът на корпоративната релационна база данни, достъпен от анализатора, може да мисли дълбоко и дълго време, блокирайки останалите транзакции.

Концепцията за OLAP се появи точно за решаване на такива проблеми. OLAP кубовете са по същество мета-отчети. Чрез разрязване на мета-отчети (т.е. кубове) по размери, анализаторът всъщност получава „обикновените“ двуизмерни отчети, които го интересуват (това не е непременно отчети в обичайния смисъл на термина - говорим за структури от данни със същите функции). Предимствата на кубовете са очевидни - данните трябва да бъдат поискани от релационна СУБД само веднъж - при изграждането на куб. Тъй като анализаторите по правило не работят с информация, която се допълва и променя в движение, генерираният куб е актуален за доста дълго време. Благодарение на това не само се елиминират прекъсванията в работата на релационния СУБД сървър (няма заявки с хиляди и милиони редове за отговор), но и драстично се увеличава скоростта на достъп до данните за самия анализатор. В допълнение, както вече беше отбелязано, производителността също се подобрява чрез изчисляване на подсуми на йерархии и други агрегирани стойности по време на изграждането на куба. Тоест, ако първоначално нашите данни съдържаха информация за дневните приходи за конкретен продукт в един магазин, то при формирането на куба OLAP приложението изчислява сумите за различни нива на йерархия (седмици и месеци, градове и държави).

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

Отговори на въпросите:

Какво стана куб OLAP?

Какво стана етикети конкретно измерение? Дай примери.

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

Анотация: Тази лекция обхваща основите на проектирането на кубове с данни за OLAP хранилища на данни. Примерът показва как да изградите куб с данни с помощта на инструмента CASE.

Целта на лекцията

След като изучите материала на тази лекция, ще знаете:

• в какво е кубът с данни OLAP хранилище за данни ;
• как да проектираме куб с данни за OLAP хранилища за данни ;
• какво е измерение на куб данни;
• как фактът е свързан с куба с данни;
• какво представляват атрибутите на измерението;
• какво е йерархия;
• какво е метрика на куба данни;

и научи:

• изграждане многомерни диаграми ;
• дизайн прост многомерни диаграми.

Въведение

OLAP технологията не е самостоятелна софтуер, Не програмен език. Ако се опитате да покриете OLAP във всичките му проявления, тогава това е набор от концепции, принципи и изисквания, които са в основата на софтуерните продукти, които улесняват достъпа на анализаторите до данни.

Анализаторите са основните потребители на корпоративна информация. Задачата на анализатора е да намира модели в големи масиви от данни. Затова анализаторът няма да обърне внимание на единствения факт, че в определен ден е продадена партида химикалки на купувача Иванов - той се нуждае от информация за стотици и хиляди подобни събития. Единични факти в хранилището на данни могат да представляват интерес например за счетоводител или ръководител на отдел продажби, чиято компетентност е да поддържа конкретен договор. Един запис не е достатъчен за анализатор - например, той може да се нуждае от информация за всички договори за точки за продажба за месец, тримесечие или година. Анализът може да не се интересува от TIN на купувача или неговия телефонен номер - той работи с конкретни цифрови данни, което е същността на неговата професионална дейност.

Централизацията и удобното структуриране далеч не са всичко, от което се нуждае един анализатор. Той има нужда от инструмент за гледане, визуализиране на информация. Традиционните отчети, дори изградени на базата на едно хранилище на данни, обаче са лишени от известна гъвкавост. Те не могат да бъдат "усукани", "разширени" или "свити", за да се получи желаният изглед на данните. Колкото повече „срезове“ и „срезове“ данни може да изследва един анализатор, толкова повече идеи има, които от своя страна изискват все повече и повече „срезове“ за проверка. Като такъв инструмент за изследване на данни, анализаторът е OLAP.

Въпреки че OLAP не е необходим атрибут на хранилище за данни, той все повече се използва за анализ на информацията, натрупана в това хранилище за данни.

Оперативните данни се събират от различни източници, почистват се, интегрират се и се добавят към хранилището на данни. В същото време те вече са достъпни за анализ чрез различни инструменти за отчитане. След това данните (изцяло или частично) се подготвят за OLAP анализ. Те могат да бъдат заредени в специална OLAP база данни или оставени в хранилище за релационни данни. Най-важният елемент от използването на OLAP са метаданните, т.е. информация за структурата, местоположението и трансформация на данни. Благодарение на тях се осигурява ефективно взаимодействие на различни компоненти за съхранение.

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

OLAP на клиент и сървър

В основата на OLAP е многоизмерният анализ на данни. Той може да бъде създаден с помощта на различни инструменти, които условно могат да бъдат разделени на клиентски и сървърни OLAP инструменти.

OLAP инструментите от страна на клиента са приложения, които изчисляват и показват агрегирани данни (суми, средни стойности, максимуми или минимуми), а самите агрегирани данни се кешират в адресното пространство на OLAP инструмента.

Ако изходните данни се съдържат в десктоп СУБД, обобщените данни се изчисляват от самия OLAP инструмент. Ако източникът на изходните данни е сървърна СУБД, много от клиентските OLAP инструменти изпращат SQL заявки, съдържащи клаузата GROUP BY, към сървъра и в резултат получават обобщени данни, изчислени на сървъра.

По правило OLAP функционалността се реализира в инструменти статистическа обработкаданни (на продуктите от този клас на руския пазар, продуктите на Stat Soft и SPSS са широко използвани) и в някои електронни таблици. По-специално, добри инструменти за многоизмерен анализ има Microsoft Excel 2000. Използвайки този продукт, можете да създадете и запишете малък локален многоизмерен OLAP куб като файл и да покажете неговите дву- или триизмерни секции.

много инструменти за разработкасъдържат библиотеки от класове или компоненти, които ви позволяват да създавате приложения, които реализират най-простата OLAP функционалност (като компонентите Decision Cube в Borland Delphi и Borland C++Builder). Освен това много компании предлагат контроли ActiveX и други библиотеки, които реализират подобна функционалност.

Обърнете внимание, че клиентските OLAP инструменти се използват като правило с малък брой измерения (обикновено се препоръчват не повече от шест) и малко разнообразие от стойности за тези параметри - в крайна сметка получените обобщени данни трябва да се поберат в адресното пространство на такъв инструмент и техният брой нараства експоненциално с увеличаване на броя измервания. Следователно дори най-примитивните клиентски OLAP инструменти, като правило, ви позволяват да направите предварително изчисление на необходимото количество оперативна паметза да създадете многоизмерен куб в него.

Много (но не всички) OLAP инструменти от страна на клиента ви позволяват да съхранявате съдържанието на кеша за обобщени данни като файл, което на свой ред предотвратява повторното им изчисляване. Имайте предвид, че тази възможност често се използва за отчуждаване на обобщени данни с цел прехвърлянето им на други организации или за публикуване. Типичен примертакива отчуждени обобщени данни са статистиките за заболеваемостта в различни региони и в различни възрастови групи, кое е отворена информация, публикуван от министерствата на здравеопазването на различни страни и Световната здравна организация. В същото време самите оригинални данни, които са информация за конкретни случаи на заболявания, са поверителни данни на лечебните заведения и в никакъв случай не трябва да попадат в ръцете на застрахователни компании, камо ли да стават публични.

Идеята за съхраняване на кеш от сборни данни във файл е доразвита в OLAP инструменти от страна на сървъра, в които съхранението и модифицирането на сборни данни, както и поддръжката на хранилището, което ги съдържа, се извършват от отделно приложение или процес, наречен OLAP сървър. Клиентските приложения могат да поискат такова многоизмерно съхранение и да получат някои данни в отговор. Някои клиентски приложения могат също да създават такива хранилища или да ги актуализират според променени изходни данни.

Предимствата на използването на сървърни OLAP инструменти в сравнение с клиентските OLAP инструменти са подобни на предимствата на използването на сървърни СУБД в сравнение с тези за настолни компютри: в случай на използване на сървърни инструменти, изчисляването и съхранението на обобщените данни се извършва на сървъра, а клиентското приложение получава само резултатите от заявките към тях, което позволява общо намаляване на мрежовия трафик, предниназаявки и изисквания за ресурси, използвани от клиентското приложение. Имайте предвид, че инструментите за анализ и обработката на данни в мащаб на предприятието по правило се основават точно на сървърни OLAP инструменти, например като Oracle Express Server, Microsoft SQL Server 2000 Analysis Services, Hyperion Essbase, Crystal Decisions, Business Objects, Cognos, продукти на SAS Institute. Тъй като всички водещи производители на сървърни СУБД произвеждат (или са лицензирали от други компании) определени сървърни OLAP инструменти, техният избор е доста широк и в почти всички случаи можете да закупите OLAP сървър от същия производител като самия сървър на база данни.

Обърнете внимание, че много клиентски OLAP инструменти (по-специално Microsoft Excel 2003, Seagate Analysis и т.н.) ви позволяват достъп до сървърни OLAP хранилища, действащи в този случай като клиентски приложения, които изпълняват подобни искания. Освен това има много продукти, които са клиентски приложения за OLAP инструменти от различни производители.

Технически аспекти на многомерното съхранение на данни

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

Имайте предвид, че запазването на всички обобщени данни не винаги е оправдано. Факт е, че при добавяне на нови измерения количеството данни, които съставляват куба, нараства експоненциално (понякога казват за „експлозивния растеж“ на количеството данни). По-конкретно, размерът на нарастването на обобщените данни зависи от броя на измеренията в куба и членовете на измеренията на различни нива на йерархиите на тези измерения. За решаване на проблема с "експлозивния растеж" се използват различни схеми, които позволяват, когато се изчисляват далеч от всички възможни агрегирани данни, да се постигне приемлива скорост на изпълнение на заявката.

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

• МОЛАП(Multidimensional OLAP) - източникът и обобщените данни се съхраняват в многомерна база данни. Съхраняването на данни в многоизмерни структури ви позволява да манипулирате данните като многоизмерен масив, така че скоростта на изчисляване на агрегатните стойности да е еднаква за всяко от измеренията. В този случай обаче многоизмерната база данни е излишна, тъй като многоизмерните данни съдържат изцяло оригиналните релационни данни.
• ROLAP(Релационен OLAP) - Оригиналните данни остават в същата релационна база данни, където са се намирали първоначално. Агрегираните данни се поставят в служебни таблици, специално създадени за тяхното съхранение в същата база данни.
• ХОЛАП(Hybrid OLAP) - Оригиналните данни остават в същата релационна база данни, където са се намирали първоначално, докато обобщените данни се съхраняват в многоизмерна база данни.

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

Също така отбелязваме, че по-голямата част от съвременните OLAP инструменти не съхраняват „празни“ стойности (пример за „празна“ стойност би била липсата на продажби на сезонни стоки извън сезона).

Основни OLAP концепции

FAMSI тест

Технологията за комплексен многоизмерен анализ на данни се нарича OLAP (On-Line Analytical Processing). OLAP е ключов компонент на организацията на хранилището на данни. Концепцията за OLAP е описана през 1993 г. от Едгар Код, известен изследовател на бази данни и автор на релационния модел на данни. През 1995 г. въз основа на изискванията, изложени от Codd, т.нар FASMI тест(Fast Analysis of Shared Multidimensional Information) - бърз анализ на споделена многомерна информация, включително следните изисквания за приложения за многомерен анализ:

• Бърз(Бързо) - предоставяне на потребителя на резултатите от анализа за разумно време (обикновено не повече от 5 s), дори с цената на по-малко подробен анализ;
• анализ(Анализ) - възможността за извършване на всякакъв логически и статистически анализ, характерен за това приложениеи запазването му във вид, достъпен за крайния потребител;
• споделено(Споделен) - многопотребителски достъп до данни с поддръжка на подходящи заключващи механизми и инструменти за оторизиран достъп;
• Многоизмерен(Multidimensional) - Многомерно концептуално представяне на данни, включително пълна поддръжка за йерархии и множество йерархии (това е ключово изискване за OLAP);
• Информация(Информация) - приложението трябва да има достъп до всяка необходима информация, независимо от нейния обем и място за съхранение.

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

Многомерно представяне на информация

Куба

OLAP предоставя удобно, високоскоростно средство за достъп, преглед и анализ на бизнес информация. Потребителят получава естествен, интуитивен модел на данни, организирайки ги под формата на многомерни кубове (Cubes). Осите на многомерната координатна система са основните атрибути на анализирания бизнес процес. Например за продажби може да бъде продукт, регион, тип купувач. Времето се използва като едно от измерванията. В пресечните точки на осите на измерванията (Dimensions) има данни, които количествено характеризират процеса - мерки (Measures). Това могат да бъдат обеми на продажби в бройки или в парично изражение, салда на склад, разходи и т.н. Потребителят, анализиращ информацията, може да "нареже" куба в различни посоки, да получи обобщение (например по години) или, обратно, подробно ( седмично) информация и извършва други манипулации, които му хрумнат в процеса на анализ.

Като мерки в триизмерния куб, показан на фиг. 26.1 се използват суми на продажби, а като измервания се използват време, продукт и магазин. Измерванията са представени на специфични нива на групиране: продуктите са групирани по категория, магазините са групирани по държава, а времето за транзакции е групирано по месец. Малко по-късно ще разгледаме по-подробно нивата на групиране (йерархии).

Ориз. 26.1.

"Нарязване" на куба

Дори триизмерен куб е трудно да се покаже на екрана на компютъра, така че да могат да се видят стойностите на интересуващите ни мерки. Какво можем да кажем за кубовете с повече от три измерения. За визуализиране на данните, съхранявани в куб, като правило се използват обичайните двуизмерни, т.е. таблични представяния, които имат сложни йерархични заглавки на редове и колони.

Двуизмерно представяне на куб може да се получи чрез "разрязване" напречно по една или повече оси (измерения): фиксираме стойностите на всички измерения, с изключение на две, и получаваме правилен двуизмерен маса. Хоризонталната ос на таблицата (заглавки на колони) представлява едно измерение, вертикалната ос (заглавки на редове) представлява друго измерение, а клетките на таблицата представляват стойности на измерване. В този случай наборът от мерки всъщност се счита за едно от измеренията: ние или избираме една мярка за показване (и след това можем да поставим две измерения в заглавките на редове и колони), или показваме няколко измервания (и след това една от осите на таблицата ще бъдат заети от имената на мерките, а другата - стойности на едно "неотсечено" измерение).

OLAP приложна архитектура

Всичко, което беше казано по-горе за OLAP, всъщност се отнася до многомерното представяне на данни. Грубо казано, нито крайният потребител, нито разработчиците на инструмента, който клиентът използва, се интересуват от това как се съхраняват данните.

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

• Многомерно представяне на данни - инструменти за краен потребител, които осигуряват многомерна визуализация и манипулиране на данни; многомерният слой на представяне се абстрахира от физическата структура на данните и ги третира като многоизмерни.
• Многомерната обработка е инструмент (език) за формулиране на многомерни заявки (традиционни релационни SQL езиксе оказва неизползваем тук) и процесор, способен да обработи и изпълни такава заявка.
• Многоизмерно съхранение - инструменти физическа организацияданни, които осигуряват ефективно изпълнение на многомерни заявки.

Първите две нива са задължителни във всички OLAP инструменти. Третото ниво, макар и широко използвано, не е необходимо, тъй като данните за многоизмерно представяне могат също да бъдат извлечени от обикновени релационни структури; процесорът за многомерни заявки в този случай превежда многомерните заявки в SQL заявки, които се изпълняват от релационна СУБД.

Конкретните OLAP продукти обикновено са или многоизмерен инструмент за представяне на данни (OLAP клиент - например Pivot Tables в Excel 2000 от Microsoft или ProClarity от Knosys) или многоизмерен бек-енд СУБД (OLAP сървър - например Oracle Express Server или Microsoft OLAP услуги).

Слоят за многомерна обработка обикновено е вграден в OLAP клиента и/или OLAP сървъра, но може да бъде изолиран в най-чистата си форма, като например компонента Pivot Table Service на Microsoft.

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

Във връзка с

Съученици

Константин Токмачев, системен архитект

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

Може би вече е минало времето, когато изчислителните ресурси на корпорацията са изразходвани само за регистрация на информация и счетоводни отчети. В същото време управленските решения се взимаха „на око“ в офиси, на срещи и срещи. Може би в Русия е време да се върнат към своите корпоративни изчислителни системи основен ресурс– решаване на задачи за управление въз основа на данните, регистрирани в компютъра

За ползите от бизнес разузнаването

В контура на корпоративното управление, между „суровите“ данни и „лостовете“ за влияние върху управлявания обект, има „индикатори за ефективност“ - KPI. Те образуват, така да се каже, "табло", отразяващо състоянието на различни подсистеми на контролирания обект. Да оборудва компанията с информативни показатели за ефективност и да контролира тяхното изчисляване и получените стойности е работа на бизнес анализатор. Значителна помощ при организирането на аналитичната работа на една корпорация може да бъде предоставена от услуги за автоматизиран анализ, като MS SQL сървър Analysis Services (SSAS) и неговият основен диспозитив е OLAP куб.

Тук трябва да се направи още една бележка. Например в американската традиция специалност, фокусирана върху работата с OLAP кубове, се нарича BI (Business Intelligence). Не бива да си правим илюзии, че американският BI съответства на руския „бизнес анализатор“. Без да се обиждате, но често нашият бизнес анализатор е „подсчетоводител“ и „подпрограмист“, специалист с размити познания и малка заплата, който наистина не разполага със собствени инструменти и методология.

BI специалистът всъщност е приложен математик, специалист от висока класа, който прилага съвременни математически методи в услуга на фирмите (това, което се нарича Operations Research - методи за изследване на операциите). BI е по-скоро в съответствие със специалността „системен анализатор“, която беше в СССР, която се произвеждаше от факултета на VMK на Московския държавен университет. М.В. Ломоносов. OLAP кубът и услугите за анализ могат да се превърнат в обещаваща основа за работното място на руски бизнес анализатор, може би след известно подобряване на квалификацията му спрямо американския BI.

Напоследък се появи още една вредна тенденция. Благодарение на специализацията взаимното разбирателство между различните категории служители на корпорацията е загубено. Счетоводител, мениджър и програмист, като "лебед, рак и щука" в баснята на I.A. Крилов, дърпайки корпорацията в различни посоки.

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

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

И накрая, програмистът, който някога (благодарение на образованието) беше проводник на напреднали технически идеи от сферата на науката към сферата на бизнеса, се превърна в пасивен изпълнител на фантазиите на счетоводител и мениджър, така че вече не е необичайно, когато счетоводителите и като цяло всички, които не са мързеливи. Непосветеният, неграмотен, но сравнително високо платен 1C програмист е истински бич за руските корпорации. (Почти като роден футболист.) Не говоря за т. нар. "икономисти и юристи", за тях всичко е казано отдавна.

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

Предимства на OLAP кубовете

OLAP кубът е модерно съоръжениеанализ на базата данни на корпоративната компютърна система, която позволява да се предоставят на служителите от всички нива на йерархията необходимия набор от показатели, характеризиращи производствения процес на компанията. Въпросът не е само в това удобен за потребителя интерфейси гъвкав език за заявки за MDX куб (MultiDimensional eXpressions) ви позволяват да формулирате и изчислявате необходимите аналитични индикатори, но със забележителната скорост и лекота, с която това се прави от OLAP куб. Освен това тази скорост и лекота, в определени граници, не зависят от сложността на изчисленията и обема на базата данни.

Известно разбиране на OLAP
куб може да даде " осева таблица» MS Excel. Тези обекти имат сходна логика и сходни интерфейси. Но, както ще се види от статията, функционалността на OLAP е несравнимо по-богата, а производителността - несравнимо по-висока, така че "пивот таблицата" остава локален десктоп продукт, докато OLAP е продукт на корпоративно ниво.

Защо един OLAP куб е толкова подходящ за решаване на аналитични проблеми? OLAP кубът е проектиран по такъв начин, че всички индикатори във всички възможни секции са предварително изчислени (изцяло или частично), а потребителят трябва само да „извади“ необходимите индикатори (измерва мерки) и секции (размери размери ) с мишката и програмата преначертава чиниите.

Всички възможни анализи във всички секции образуват едно огромно поле или по-скоро не поле, а просто многоизмерен OLAP куб. Каквато и заявка да отправи потребител (мениджър, бизнес анализатор, мениджър) към услугата за анализ, скоростта на реакция се дължи на две неща: първо, необходимите анализи могат лесно да бъдат формулирани (или избрани от списъка по име, или дадени по формула на езика MDX), и второ, като правило, той вече е изчислен.

Формулирането на аналитика е възможно в три версии: това е или поле на база данни (по-точно поле на склад), или поле за изчисление, дефинирано на ниво дизайн на куба, или езиков израз на MDX при интерактивна работа с куба.

Това означава няколко привлекателни характеристики на OLAP кубовете наведнъж. Всъщност бариерата между потребителя и данните изчезва. Бариера под формата на приложен програмист, който първо трябва да обясни проблема (да постави задача). Второ, ще трябва да изчакате, докато приложният програмист създаде алгоритъма, напише и отстрани грешки в програмата, след което тя може да бъде модифицирана. Ако служителите са много и изискванията им са разнообразни и променливи, тогава е необходим цял екип от приложни програмисти. В този смисъл едно OLAP кубче (и квалифициран бизнес анализатор) по отношение на аналитична работа замества цял екип от приложни програмисти, както мощен багер с багерист при копаене на канавка замества цяла бригада гастарбайтери с лопати!

В този случай се постига още едно много важно качество на получените аналитични данни. Тъй като OLAP кубът е един за цялата компания, т.е. Тъй като това е едно и също поле с анализатори за всички, досадното несъответствие в данните е изключено. Когато мениджърът трябва да постави една и съща задача на няколко независими служители, за да елиминира фактора субективност, но те все пак дават различни отговори, които всеки се заема да обясни по някакъв начин и т.н. OLAP кубът осигурява еднаквост на аналитичните данни на различни нива на корпоративната йерархия, т.е. ако мениджърът иска да детайлизира определен индикатор, който го интересува, тогава той със сигурност ще стигне до данните от по-ниско ниво, с които работи неговият подчинен, и това ще бъдат само данните, въз основа на които се изчислява индикаторът от по-високо ниво , а не някакви други данни, получени по друг начин, по друго време и т.н. Тоест цялата компания вижда едни и същи анализи, но на различни нива на консолидация.

Да вземем пример. Да предположим, че мениджърът контролира вземанията. Щом KPI на просрочените вземания е зелен, значи всичко е нормално, не са необходими никакви управленски действия. Ако цветът се е променил на жълт или червен, нещо не е наред: изрязваме KPI по отдел продажби и веднага виждаме разделите „в червено“. Следващият раздел за мениджърите - и продавачът, чиито клиенти закъсняват с плащанията, е дефиниран. (По-нататък размерът на забавянето може да бъде разбит по купувачи, по условия и т.н.) Ръководителят на корпорацията може директно да се обърне към нарушителите на всяко ниво. Но като цяло един и същ KPI (на техните йерархични нива) се вижда както от ръководителите на отдели, така и от мениджърите по продажбите. Следователно, за да коригират ситуацията, те дори не трябва да чакат „обаждане на килима“ ... Разбира се, самият KPI не е задължително да е размерът на просрочието - той може да бъде средно претеглена стойност период на просрочие или най-общо скоростта на обръщаемост на вземанията.

Обърнете внимание, че сложността и гъвкавостта на езика MDX, заедно с бързите (понякога мигновени) резултати, ви позволява да решите (като вземете предвид етапите на разработка и отстраняване на грешки) предизвикателни задачиконтроли, които при други условия може би изобщо не биха били зададени поради сложността за приложните програмисти и първоначалната несигурност във формулировката. (Дълги времеви рамки за приложните програмисти за решаване на аналитични проблеми поради лошо разбрана формулировка и дълги програмни модификации, когато условията се променят, често се срещат на практика.)

Нека също така да обърнем внимание на факта, че всеки служител на компанията може да събере от общото поле OLAP анализатора точно реколтата, от която се нуждае за работа, а не да се задоволява с „ивицата“, която е отрязал в общите „стандартни отчети ”.

Многопотребителски интерфейс за работа с OLAP куб в режим клиент-сървър позволява на всеки служител, независимо от другите, да има свои собствени (дори собствено производство с известни умения) аналитични блокове (отчети), които, след като бъдат дефинирани, се автоматично актуализирани - с други думи, те винаги са в актуално състояние.

Това означава, че OLAP кубът ви позволява да направите аналитичната работа (която всъщност се извършва не само от анализатори на бележки, но всъщност от почти всички служители на компанията, дори логистици и мениджъри, които контролират баланси и доставки) по-селективна, “ от лицето не в общо изражение” , което създава условия за подобряване на работата и повишаване на производителността.

Обобщавайки нашето въведение, отбелязваме, че използването на OLAP кубове може да издигне управлението на една компания на по-високо ниво. Еднаквост на аналитичните данни на всички нива на йерархията, тяхната надеждност, сложност, лекота на създаване и модифициране на индикатори, индивидуални настройки, висока скорост на обработка на данни и накрая, спестяване на пари и време, изразходвани за поддържане на алтернативни пътища за анализ (приложни програмисти, независими изчисления на служител), отварят перспективи за използване на OLAP-кубове в практиката на големи руски компании.

OLTP + OLAP: контур обратна връзкавъв веригата на управление на компанията

Сега разгледайте общата идея на OLAP кубовете и тяхната точка на приложение във веригата на корпоративното управление. Терминът OLAP (OnLine Analytical Processing) е въведен от британския математик Едгар Код в допълнение към неговия по-ранен термин OLTP (OnLine Transactions Processing). Това ще бъде обсъдено по-късно, но Е. Код, разбира се, предложи не само термините, но и математическите теории на OLTP и OLAP. Без да навлизаме в подробности, в съвременната интерпретация OLTP е релационна база данни, разглеждана като механизъм за регистриране, съхранение и извличане на информация.

Методология на решението

Такива ERP системи (Enterprice Resource Planning), като 1C7, 1C8, MS Dynamics AX, имат потребителски ориентирани софтуерни интерфейси (въвеждане и коригиране на документи и т.н.) и релационна база данни (DB) за съхраняване и извличане на информация, представена днес софтуерни продуктитип MS SQL Server (SS).

Имайте предвид, че информацията, регистрирана в базата данни на ERP системата, е наистина много ценен ресурс. Въпросът е не само, че регистрираната информация осигурява текущия работен процес на корпорацията (издаване на документи, тяхната корекция, възможност за отпечатване и съгласуване и т.н.), а не само възможността за изчисляване финансови отчети(данъци, одит и др.). От управленска гледна точка е много по-важно една OLTP система (релационна база данни) всъщност да е действителен цифров модел на дейността на една корпорация в пълен размер.

Но за да управлявате процеса, не е достатъчно да регистрирате информация за него. Процесът трябва да се представи като система от числени показатели (KPI), характеризиращи протичането му. Освен това трябва да се определят допустими диапазони от стойности за индикаторите. И само ако стойността на индикатора надхвърли допустимия интервал, трябва да последва контролно действие.

По отношение на подобна логика (или митология) на контрола („управление чрез отклонение“), както древногръцкият философ Платон, създал образа на кормчията (кибернос), който се обляга на греблото, когато лодката се отклонява от курса, така и Американският математик Норбърт Винер, който създава науката кибернетика на прага на ерата на компютрите.

В допълнение към обичайната система за запис на информация по метода OLTP е необходима още една система - система за анализ на събраната информация. Тази добавка, която в контролния цикъл играе ролята на обратна връзка между управлението и контролния обект, е OLAP система или накратко OLAP куб.

Като софтуерна реализация OLAP, ще разгледаме помощната програма MS Analysis Services, която е част от стандартната доставка на MS SQL Server, съкратено SSAS. Имайте предвид, че според идеята на E. Codd, OLAP кубът в анализа трябва да дава същата изчерпателна свобода на действие, която OLTP системата и релационната база данни (SQL Server) дават при съхраняване и извличане на информация.

OLAP логистика

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

Ще приемем, че корпорацията използва ERP система, например 1C7 или 1C8, в която информацията се регистрира по обичайния начин. Базата данни на тази ERP-система се намира на определен сървър и се поддържа от MS SQL Server.

Ще приемем също, че софтуерът е инсталиран на друг сървър, включително MS SQL Server с помощната програма MS Analysis Services (SSAS), както и MS SQL Server Management Studio, MS C#, MS Excel и MS Visual Studio програми. Тези програми заедно формират необходимия контекст: инструментите и необходимите интерфейси за разработчика на OLAP куб.

Сървърът SSAS има инсталиран безплатен софтуер blat, извикан (с параметри) от командна линияи предоставяне на пощенски услуги.

На работните места на служителите, в рамките локална мрежа, наред с други неща, са инсталирани програми на MS Excel (версии поне 2003 г.), а също така, вероятно, специален шофьорза да разрешите на MS Excel да работи с MS Analysis Services (освен ако съответният драйвер вече не е включен в MS Excel).

За категоричност ще приемем, че работните станции на служителите имат операционна система Windows XP и на сървъри - Windows сървър 2008. Освен това да кажем, че MS SQL Server 2005 се използва като SQL Server и Enterprise Edition (EE) или Developer Edition (DE) е инсталиран на сървъра с OLAP куба. В тези издания е възможно използването на т.нар. „полуадитивни мерки“, т.е. допълнителен агрегатни функции(статистика), различна от обичайните суми (например екстремна или средна стойност).

Дизайн на OLAP куб (OLAP кубизъм)

Нека кажем няколко думи за дизайна на самия OLAP куб. На езика на статистиката OLAP кубът е набор от показатели за ефективност, изчислени във всички необходими секции, например индикатор за пратка в секции по купувачи, по стоки, по дати и т.н. Поради директния превод от английски в руската литература за OLAP кубове, индикаторите се наричат ​​"мерки", а разфасовките се наричат ​​"размери". Това е математически правилен, но синтактично и семантично не особено сполучлив превод. Руските думи "мярка", "измерване", "измерение" почти не се различават по значение и правопис, докато английските "мярка" и "размер" са различни както по правопис, така и по смисъл. Ето защо ние предпочитаме традиционните руски статистически термини, подобни по значение на „индикатор“ и „разрез“.

Има няколко опции за софтуерна реализация на OLAP куба по отношение на OLTP системата, където се регистрират данните. Ще разгледаме само една схема, най-простата, най-надеждна и най-бърза.

В тази схема OLAP и OLTP нямат общи таблици и OLAP анализите се изчисляват възможно най-подробно на етапа на актуализиране на куба (процес) преди етапа на използване. Тази схема се нарича MOLAP (Multidimensional OLAP). Недостатъците му са асинхронност с ERP и високи разходи за памет.

Въпреки че формално OLAP куб може да бъде изграден, като се използват всички (хиляди) таблици на релационна база данни на ERP система като източник на данни и всички (стотици) техни полета като индикатори или секции, в действителност това не трябва да се прави. Обратно. За да заредите в куб, е по-правилно да подготвите отделна база данни, наречена „витрина“ или „склад“ (склад).

Причините за това са няколко.

• първо,свързването на OLAP куб с таблици в реална база данни със сигурност ще създаде технически проблеми. Промяната на данни в таблица може да задейства опресняване на куба, а опресняването на куб не е непременно бърз процес, така че кубът ще бъде в състояние на постоянно повторно изграждане; в същото време процедурата за актуализиране на куба може да блокира (по време на четене) данните от таблиците на базата данни, забавяйки работата на потребителите при регистриране на данни в ERP системата.
• Второ, наличието на твърде много индикатори и съкращения драстично ще увеличи площта за съхранение на куба на сървъра. Да не забравяме, че OLAP кубът съхранява не само първоначалните данни, както в системата OLTP, но и всички показатели, сумирани по всички възможни секции (и дори по всички комбинации от всички секции). В допълнение, скоростта на актуализиране на куба и, в крайна сметка, скоростта на изграждане и актуализиране на анализи и потребителски отчети, базирани на тях, ще се забавят съответно.
• трето, твърде много голям бройполета (мерки и аспекти) ще създадат проблеми в интерфейса за разработчици на OLAP, защото списъците с елементи ще станат безкрайни.
• четвърто, OLAP кубът е много чувствителен към нарушения на целостта на данните. Куб не може да бъде изграден, ако ключовите данни не са разположени чрез връзка, указана в структурата на връзката на полетата на куба. Временно или постоянно нарушаване на целостта, празни полета са често срещани в базата данни на ERP система, но това категорично не е подходящо за OLAP.

Можете също така да добавите, че ERP системата и OLAP кубът трябва да бъдат разположени на различни сървъри, за да споделят натоварването. Но тогава, ако има общи таблици за OLAP и OLTP, също има проблем мрежов трафик. В този случай възникват практически неразрешими проблеми, ако е необходимо да се консолидират няколко разнородни ERP системи (1C7, 1C8, MS Dynamics AX) в един OLAP куб.

Вероятно е възможно да се натрупат технически проблеми допълнително. Но най-важното е да запомните, че за разлика от OLTP, OLAP не е средство за регистриране и съхраняване на данни, а инструмент за анализ. Това означава, че няма нужда да зареждате и зареждате "мръсни" данни от ERP в OLAP "за всеки случай". Напротив, първо трябва да разработите концепция за управление на компания, поне на системно ниво на KPI, и след това да проектирате хранилище за данни на приложения (склад), разположено на същия сървър като OLAP куба и съдържащо малко рафинирано количество ERP данни, необходими за управление.

Без да насърчава лошите навици, OLAP кубът по отношение на OLTP може да се оприличи на добре познатия "аламбик", чрез който от "ферментиралата маса" реална регистрация"чистият продукт" се възстановява.

И така, получихме, че източникът на данни за OLAP е специална база данни (склад), разположена на същия сървър като OLAP. По принцип това означава две неща. Първо, трябва да има специални процедури, които ще създадат склад от ERP бази данни. Второ, OLAP кубът е асинхронен със своите ERP системи.

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

Архитектура на решението

Нека има много ERP системи на определена корпорация (холдинг) на различни сървъри, за които бихме искали да видим аналитичните данни, консолидирани в един OLAP куб. Подчертаваме, че в описаната технология ние комбинираме данни от ERP системи на ниво склад, оставяйки дизайна на OLAP куба непроменен.

На OLAP сървъра създаваме изображения (празни копия) на базите данни на всички тези ERP системи. Към тези празни копия периодично (всяка нощ) извършваме частична репликация на базите данни на съответните активно работещи ERP.

След това се стартира SP (съхранена процедура), която на същия OLAP сървър без мрежов трафик, въз основа на частични реплики на базите данни на ERP системите, създава (или попълва) хранилището (склада) - източникът на данни на OLAP куб.

След това се стартира стандартната процедура за актуализиране / изграждане на куб според складовите данни (операцията Процес в интерфейса SSAS).

Нека коментираме някои аспекти на технологията. Какъв вид работа вършат SP?

В резултат на частична репликация действителните данни се появяват в образа на някоя ERP система на OLAP сървъра. Между другото, частичната репликация може да се извърши по два начина.

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

Второ, частичната репликация може също да означава, че не всички полета на таблицата се копират, а само тези, които участват в изграждането на склада. Списъкът с полета за копиране е или посочен, или динамично създаден в SP от изображението на копието (ако копието на таблицата първоначално не съдържа всички полета).

Разбира се, възможно е да не се копират цели редове от таблицата, а само да се добавят нови записи. Това обаче създава сериозно неудобство при отчитане на ревизиите на ERP „с обратна дата“, което често се среща в системите от реалния живот. Така че е по-лесно, без повече шум, да копирате всички записи (или да актуализирате "опашката", започвайки от някаква дата).

Освен това основната задача на SP е да конвертира данни от ERP системи в складов формат. Ако има само една ERP система, тогава задачата за трансформация се свежда главно до копиране и евентуално преформатиране на необходимите данни. Но ако е необходимо да се консолидират няколко ERP системи с различна структура в един и същ OLAP куб, тогава трансформациите стават по-сложни.

Особено трудна е задачата за консолидиране на няколко различни ERP системи в куб, ако множествата от техните обекти (директории на стоки, контрагенти, складове и др.) се пресичат частично, обектите имат едно и също значение, но естествено се описват по различен начин в директориите различни системи(в смисъл на кодове, идентификатори, имена и др.).

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

Нека обърнем малко внимание на архитектурата на складовото съхранение. Обикновено схемата на OLAP куб е представена като "звезда", т.е. като таблица с данни, заобиколена от "лъчи" от директории - таблици със стойности на вторичен ключ. Таблицата е блок от "индикатори", справочниците са техните разфасовки. В същото време директорията от своя страна може да бъде произволно небалансирано дърво или балансирана йерархия, например многостепенна класификация на стоки или контрагенти. В OLAP куб цифровите полета на таблицата с данни от склада автоматично стават „индикатори“ (или измервания), а секции (или измерения) могат да бъдат дефинирани чрез таблици с вторични ключове.

Това е визуално "педагогическо" описание. Всъщност архитектурата на OLAP куб може да бъде много по-сложна.

Първо, един склад може да се състои от няколко "звездички", вероятно свързани чрез общи директории. В този случай OLAP кубът ще бъде обединение от няколко куба (множество блокове данни).

Второ, "лъчът" на звездичката може да не е една директория, а цяла (йерархична) файлова система.

Трето, на базата на съществуващи разфасовки на размери, могат да се дефинират нови йерархични съкращения с помощта на интерфейса за разработчици на OLAP (да речем, с по-малко нива, с различен ред на нивата и т.н.)

Четвърто, нови индикатори (изчисления) могат да бъдат дефинирани въз основа на съществуващи индикатори и раздели, използвайки израза на езика MDX. Важно е да се отбележи, че нови кубове, нови индикатори, нови секции автоматично се интегрират напълно с оригиналните елементи. Трябва също да се отбележи, че лошо формулираните изчисления и йерархичните съкращения могат значително да забавят работата на OLAP куб.

MS Excel като интерфейс с OLAP

От особен интерес е потребителският интерфейс с OLAP кубове. Естествено, самата помощна програма SSAS предоставя най-пълния интерфейс. Това е инструментариум за разработчици на OLAP куб, интерактивен дизайнер на отчети и прозорец за интерактивна работа с OLAP куб, използвайки заявки на езика MDX.

В допълнение към самия SSAS, има много програми, които предоставят интерфейс към OLAP, покривайки тяхната функционалност в по-голяма или по-малка степен. Но сред тях има един, който според нас има неоспорими предимства. Това е MS Excel.

Интерфейсът с MS Excel се осигурява от специален драйвер, който може да бъде изтеглен отделно или включен в Excel. Той не покрива цялата функционалност на OLAP, но с нарастването на броя на версиите на MS Excel това покритие става все по-широко (да речем, в MS Excel 2007 се появява графика на KPI, която не беше в MS Excel 2003 и т.н.).

Разбира се, в допълнение към доста пълната функционалност, основното предимство на MS Excel е повсеместното разпространение на тази програма и близкото запознаване с нея на огромното мнозинство потребители на офиса. В този смисъл, за разлика от други интерфейсни програми, фирмата няма нужда да придобива нищо допълнително и не е необходимо да обучава никого допълнително.

Голямото предимство на MS Excel като интерфейс с OLAP е възможността за по-нататъшна независима обработка на данни, получени в OLAP отчет (т.е. продължаване на изследването на данни, получени от OLAP на други листове на същия Excel, без вече да се използва OLAP инструменти, но използвайки обикновени инструменти на Excel).

Нощен цикъл на лечение с факуби

Сега нека опишем ежедневния (нощен) изчислителен цикъл на OLAP операция. Изчислението се извършва под контрола на програмата facubi, написана на C # 2005 и стартирана с помощта на Task Scheduler на сървър със склад и SSAS. В началото facubi влиза в интернет и чете текущите обменни курсове (използвани за представяне на редица индикатори във валута). След това се изпълняват следните стъпки.

Първо, facubi пуска SP, които извършват частична репликация на база данни на различни ERP системи (холдинг елементи), налични в локалната мрежа. Репликацията се извършва, както казахме, върху предварително подготвени "ярдове" - изображения на отдалечени ERP системи, разположени на SSAS сървъра.

Второ, чрез SP се извършва картографиране от ERP реплики към хранилище на склад - специална DB, която е източник на данни от OLAP куб и се намира на SSAS сървъра. Така се изпълняват три основни задачи:

• ERP данниса приведени под необходимите кубови формати; говорим за таблици и таблични полета. (Понякога необходимата таблица трябва да бъде „оформена“, да речем, от няколко MS Excel листа.) Подобни данни могат да имат различен формат в различни ERP, например полетата за ИД на ключове в директории 1C7 имат код от 36 знака с дължина 8 , и _idrref полета в директории 1C8 - шестнадесетични числа с дължина 32;
• по време на обработката извършва се логически контрол на данните (включително предписване на „по подразбиране“ по подразбиране вместо липсващи данни, когато е възможно) и контрол на целостта, т.е. проверка на наличието на първични и вторични ключове в съответните класификатори;
• консолидация на кода обекти, които имат едно и също значение в различни ERP. Например, съответните елементи на директории на различни ERP могат да имат едно и също значение, да речем, това е един и същ контрагент. Проблемът с консолидирането на кода се решава чрез изграждане на таблици за преобразуване, където различни кодовеедни и същи обекти се довеждат до единство.

Трето, facubi стартира стандартната процедура за актуализиране на данни в куба на процеса (от процедурите на помощната програма SSAS).

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

След като изпълни facubi, Task Scheduler изпълнява няколко excel файлове, които имат предварително създадени отчети, базирани на метрики на OLAP куб. Както казахме, MS Excel има специален интерфейс за програмиране (отделно изтеглящ се или вграден драйвер) за работа с OLAP кубове (със SSAS). При стартиране на MS Excel се включват програми на MS VBA (като макроси), които осигуряват актуализиране на данните в отчетите; докладите се модифицират, ако е необходимо, и се изпращат по пощата (blat програма) до потребителите според контролни списъци.

Потребителите на локалната мрежа с достъп до SSAS сървъра ще получават отчети „на живо“, конфигурирани за OLAP куба. (По принцип те сами, без никаква поща, могат да актуализират OLAP отчети в MS Excel, разположени на техните локални компютри.) Потребителите извън локалната мрежа ще получат или оригинални отчети, но с ограничена функционалност, или за тях (след актуализиране на OLAP отчети в MS Excel) ще бъдат изчислени специални "мъртви" отчети, които не се свързват със SSAS сървъра.

Оценка на резултатите

По-горе говорихме за асинхронността на OLTP и OLAP. В разглежданата версия на технологията цикълът на актуализиране на OLAP куба се извършва през нощта (да речем, започва в 1 часа сутринта). Това означава, че в текущия работен ден потребителите работят с данните от вчера. Тъй като OLAP не е инструмент за регистриране (вижте най-новата версия на документа), а инструмент за управление (разберете тенденцията на процеса), това изоставане обикновено не е критично. Въпреки това, ако е необходимо, дори и в описаната версия на кубовата архитектура (MOLAP), е възможно да се актуализира няколко пъти на ден.

Времето за изпълнение на процедурите за актуализиране зависи от дизайнерските характеристики на OLAP куба (повече или по-малко сложност, повече или по-малко успешни дефиниции на индикатори и секции) и от обема на базите данни на външни OLTP системи. Според опита процедурите по изграждане на склад отнемат от няколко минути до два часа, процедурата по актуализиране на куб (Процес) отнема от 1 до 20 минути. Това е заза сложни OLAP кубове, които комбинират десетки структури от типа "звездичка", за десетки общи "лъчи" (референтни разрези) за тях, за стотици индикатори. Оценявайки обема на базите данни на външни ERP системи по документи за доставка, говорим за стотици хиляди документи и съответно милиони продуктови линии годишно. Историческата дълбочина на обработка, която представлява интерес за потребителя, е била от три до пет години.

Описаната технология се използва в редица големи корпорации: от 2008 г. в Russian Fish Company (RRK) и Russian Sea Company (RM), от 2012 г. в Santa Bremor Company (SB). Някои от корпорациите са предимно фирми за търговско закупуване (RRK), други са производствени фирми (заводи за преработка на риба и морски дарове в Република Молдова и Съвета за сигурност). Всички корпорации са големи холдинги, които обединяват няколко компании с независими и различни компютърни счетоводни системи - вариращи от стандартни ERP системи като 1C7 и 1C8 до "реликтни" счетоводни системи, базирани на DBF и Excel. Ще добавя, че описаната технология за работа с OLAP кубове (без да се взема предвид етапът на разработка) или изобщо не изисква специални служители, или е включена в отговорностите на един бизнес анализатор на пълен работен ден. Задачата се върти от години автоматичен режим, снабдявайки ежедневно различни категории корпоративни служители с актуална отчетност.

Плюсове и минуси на решението

Както показва опитът, вариантът на предложеното решение е доста надежден и лесен за работа. Лесно се модифицира (свързване / прекъсване на нови ERP, създаване на нови индикатори и раздели, създаване и модифициране на Excel отчети и техните пощенски списъци) с инвариантността на контролната програма facubi.

MS Excel като интерфейс с OLAP осигурява достатъчна изразителност и ви позволява бързо да се присъедините към OLAP технологията в различни категории офис работници. Потребителят получава ежедневни "стандартни" OLAP отчети; използвайки интерфейса на MS Excel с OLAP, може самостоятелно да създава OLAP отчети в MS Excel. В допълнение, потребителят може самостоятелно да продължи да изследва информацията от OLAP отчетите, използвайки обичайните възможности на своя MS Excel.

„Усъвършенствана“ складова база данни, в която са консолидирани няколко разнородни ERP системи (по време на изграждането на куба), дори и без OLAP, позволява решаване (на SSAS сървъра, използвайки метода на заявка Transact SQL или SP метода и т.н.) много приложни управленски задачи. Спомнете си, че структурата на складовата база данни е унифицирана и много по-опростена (по отношение на броя на таблиците и броя на полетата на таблицата) от структурите на базата данни на оригиналния ERP.

Специално отбелязваме, че в предложеното от нас решение има възможност за консолидиране на различни ERP системи в един OLAP куб. Това ви позволява да получавате анализи за целия холдинг и да поддържате дългосрочна приемственост в анализите, когато една корпорация се премести към друга ERP счетоводна система, да речем, при преминаване от 1C7 към 1C8.

Използвахме модела куб MOLAP. Предимствата на този модел са надеждността при работа и високата скорост на обработка на потребителските заявки. Минуси - асинхронни OLAP и OLTP, както и големи количества памет за съхранение на OLAP.

В заключение, нека дадем още един аргумент в полза на OLAP, който може би би бил по-подходящ през Средновековието. Защото доказателствената му сила се основава на авторитета. Скромният, явно подценяван британски математик Е. Код разработи теорията за релационните бази данни в края на 60-те години. Силата на тази теория беше такава, че сега, след 50 години, вече е трудно да се намери нерелационна база данни и език за заявки към база данни, различен от SQL.

OLTP технологията, базирана на теорията на релационните бази данни, е първата идея на Е. Код. Всъщност концепцията за OLAP кубове е втората му идея, изразена от него в началото на 90-те години. Дори и да не сте математик, може да очаквате втората идея да бъде също толкова ефективна, колкото и първата. Тоест, по отношение на компютърния анализ, OLAP идеите скоро ще превземат света и ще изместят всички останали. Просто защото темата за анализа намира своето изчерпателно математическо решение в OLAP и това решение е „адекватно” (терминът на Б. Спиноза) на практическата задача на анализа. „Адекватно“ означава при Спиноза, че дори самият Бог не би могъл да измисли по-добра идея ...

1. Ларсън Б. Развитие на бизнес интелигентност в Microsoft SQL Server 2005. - Санкт Петербург: "Питер", 2008 г.
2. Codd E. Relational Completeness of Data Base Sublanguages, Data Base Systems, Courant Computer Science Sumposia Series 1972, v. 6, Englwood cliffs, N.Y., Prentice–Hall.

Във връзка с