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

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

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

Технологията за комплексен многовариантен анализ на данни се нарича OLAP (On-Line Analytical Processing).

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

Концепцията OLAP е описана за първи път през 1993 г. от Едгар Код, известен изследовател на бази данни и автор на релационния модел на данни.E.F. Код, С.Б. Codd и C.T. Salley, Предоставяне на OLAP (онлайн аналитична обработка) на потребителски анализатори: ИТ мандат.Технически доклад, 1993).

През 1995 г., въз основа на изискванията, определени от Codd, е формулиран т. нар. тест за бърз анализ на споделена многоизмерна информация (FASMI), който включва следните изисквания за приложения за мултивариантен анализ:

· предоставяне на потребителя на резултатите от анализа в разумен срок (обикновено не повече от 5 s), дори с цената на по -малко подробен анализ;

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

· многопотребителски достъп до данни с поддръжка на подходящи заключващи механизми и разрешени средства за достъп;

· многоизмерно концептуално представяне на данни, включително пълна поддръжка за йерархии и множество йерархии (това е ключово изискване на OLAP);

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

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

2. Какво е OLAP

OLAP - съкращение от On -Line Analytical Processing - не е име за конкретен продукт, а за цяла технология. На руски език е най -удобно да се обаждате на онлайн аналитична обработка на OLAP. Въпреки че в някои издания аналитичната обработка се нарича онлайн и интерактивна, прилагателното „оперативно“ отразява възможно най -точно значението на технологията OLAP.

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

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

В исторически план решенията за автоматизация на оперативните дейности са най -развитите. Говорим за системи за обработка на транзакционни данни (OLTP), по -просто наречени операционни системи. Тези системи осигуряват регистриране на някои факти, тяхното кратко съхранение и съхранение в архиви. Основата на такива системи се осигурява от релационни системи за управление на бази данни (RDBMS). Традиционният подход е да се опитате да използвате вече изградени операционни системи за подпомагане на вземането на решения. Обикновено те се опитват да изградят развита система от заявки към операционната система и да използват отчетите, получени след интерпретация, директно за подкрепа при вземане на решения. Отчетите могат да се изграждат на персонализирана база, т.е. ръководителят изисква доклад и редовно, когато отчетите се изграждат след достигане на някакво събитие или час. Например, традиционен процес на подпомагане на вземането на решения може да изглежда така: мениджър отива при специалист от отдел информация и споделя въпроса си с него. След това CIO специалистът изгражда заявка към операционната система, получава електронен отчет, интерпретира го и след това го съобщава на управленския персонал. Разбира се, такава схема осигурява до известна степен подкрепа за вземане на решения, но има изключително ниска ефективност и огромен брой недостатъци. Малко данни се използват в подкрепа на критично важни решения. Има и други проблеми. Този процес е много бавен, тъй като процесът на писане на заявки и тълкуване на електронен отчет отнема много време. Отнема много дни, в момент, когато може да се наложи лидерът да вземе решение веднага, веднага. Ако вземем под внимание, че мениджърът, след получаване на доклада, може да се интересува от друг въпрос (да речем, изясняване или изискване на разглеждане на данните в различен контекст), тогава този бавен цикъл трябва да се повтори и тъй като процесът на анализ на данните операционни системище се случи итеративно, тогава се отделя още повече време. Друг проблем е проблемът с различни области на дейност на специалист в информационни технологиии лидер, който може да мисли в различни категории и в резултат на това не се разбират. Тогава ще са необходими допълнителни итерации за прецизиране и това отново е време, което винаги не е достатъчно. Друг важен въпрос е сложността на докладите за разбиране. Мениджърът няма време да избира цифрите, които представляват интерес от доклада, особено след като може да има твърде много от тях (не забравяйте огромните многостранични доклади, в които действително се използват няколко страници, а останалите - за всеки случай). Отбелязваме също, че работата по устен превод най -често се пада на специалистите от информационните отдели. Тоест, компетентен специалист се разсейва от рутинната и неефективна работа по чертане на диаграми и т.н., което, естествено, не може да има благоприятен ефект върху неговата квалификация. Освен това не е тайна, че във веригата за интерпретация има доброжелатели, които се интересуват от умишлено изкривяване на входящата информация.

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

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

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

3. История на създаване на OLAP технология

Идеята за обработка на данни върху многоизмерни масиви не е нова. Всъщност датира от 1962 г., когато Кен Айвърсън публикува книгата си A Programming Language (APL). Първата практическа реализация на APL се осъществи в края на шейсетте години от IBM. APL е много елегантен, математически дефиниран език с многоизмерни променливи и обработваеми операции. Той трябваше да бъде оригиналният мощен инструмент за многоизмерна трансформация в сравнение с други практически езици за програмиране.

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

Разочарованието от тези първоначални грешки обаче не уби идеята. Използва се в много бизнес приложения през 70 -те, 80 -те години. Много от тези приложения имат характеристики на съвременните аналитични системи за обработка. Например, IBM разработи операционна системаза APL, наречен VSPC, и някои хора го смятаха за идеалната среда за лична употреба, докато електронните таблици станаха повсеместни.

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

През 80 -те години на миналия век APL стана достъпна на лични машини, но не намери пазарна употреба. Алтернативата беше програмиране на многоизмерни приложения с помощта на масиви на други езици. Това беше много трудна задача дори за професионалните програмисти, което принуди да чака следващото поколение многоизмерни софтуерни продукти.

През 1972 г. няколко приложени многоизмерни софтуерни продукти, използвани преди това за образователни цели, намериха търговско приложение: Express. Той остава в напълно пренаписана форма и сега, но първоначалните концепции от 70 -те вече не са актуални. Express е една от най -популярните OLAP технологии през 90 -те години днес и Oracle (r) ще го прокара напред и ще добави нови функции.

Още многоизмерни продукти се появяват през 80-те години на миналия век. В началото на десетилетието - продукт, наречен Stratagem, по -късно наречен Acumate (днес собственост на Kenan Technologies), който все още се популяризира до началото на 90 -те години, но днес, за разлика от Express, практически не се използва.

Comshare System W беше многоизмерен продукт от различен стил. Представен през 1981 г., той е първият, който предлага повече разработки на крайни потребители и финансови приложения. Той въведе много концепции, които не бяха добре адаптирани, като напълно непроцедурни правила, преглед на цял екран и редактиране на многоизмерни данни, автоматично преизчисляване и пакетна интеграция с релационни данни. Comshare System W обаче беше достатъчно тежък за хардуера на времето в сравнение с други продукти и в бъдеще се използваше по -малко, продаваше се по -малко и не правеше подобрения на продукта. Въпреки че все още е наличен в UNIX днес, той не е клиент-сървър, което не увеличава предлагането му на аналитичния пазар. В края на 80-те Comshare пусна продукт за DOS и по-късно за Windows. Тези продукти бяха наречени Commander Prism и използваха същите концепции като System W.

Друг творчески продукт от края на 80 -те се нарича Метафора. Той беше насочен към професионални търговци. Той също така предлага много нови концепции, които едва сега започват да се използват широко: клиент-сървърни изчисления, използването на многоизмерен модел за релационни данни, обектно-ориентирано разработване на приложения. Стандартният хардуер на лични машини от онези дни обаче не можеше да работи с Metaphor и доставчиците бяха принудени да разработят свои собствени стандарти за лични машини и мрежи. Постепенно Metaphor започва да работи успешно на серийни персонални машини, но продуктът е направен изключително за OS / 2 и има собствен графичен потребителски интерфейс.

След това Metaphor влезе в маркетингов съюз с IBM, който впоследствие беше придобит. В средата на 1994 г. IBM реши да интегрира технологията Metaphor (преименувана на DIS) с бъдещите си технологии и по този начин да прекрати финансирането за отделна посока, но клиентите изразиха своето недоволство и поискаха продължаваща поддръжка на продукта. Поддръжката продължи за останалите клиенти и IBM повторно пусна продукта под ново име DIS, което обаче не го направи популярен. Но творческите, иновативни концепции на Metaphor не са забравени и са видими днес в много продукти.

В средата на 80-те години се ражда терминът EIS (Executive Information System). Първият продукт, който ясно демонстрира тази посока, беше пилотският команден център. Това беше продукт, който позволяваше съвместни изчисления, това, което днес наричаме клиент-сървър изчисление. Тъй като мощността на персоналните компютри през 80-те години на миналия век беше ограничена, продуктът беше много „ориентиран към сървъра“, но принципът все още е много популярен днес. Pilot не продава Command Center за дълго, но предлага много концепции, които могат да бъдат научени в днешните OLAP продукти, включително автоматично синхронизиране, многоизмерно изчисление клиент / сървър и опростен контрол на процеса на анализ (мишка, чувствителни екрани и т.н.). Някои от тези концепции бяха приложени отново по -късно в сървъра за пилотен анализ.

В края на 80 -те години електронните таблици бяха доминиращият инструмент на пазара за предоставяне на анализ на крайните потребители. Първата многоизмерна електронна таблица беше представена от Compete. Той беше пуснат на пазара като много скъп продукт за специалисти, но доставчиците не предоставиха възможност за превземане на пазара за този продукт и Computer Associates придоби правата върху него заедно с други продукти, включително Supercalc и 20/20. Основният ефект от придобиването на CA Compete беше рязко намаляване на цените и премахване на защитата срещу копиране, което естествено допринесе за нейното разпространение. Това обаче не беше успешно. Състезавайте се в основата на Supercalc 5, но неговият многоизмерен аспект не се популяризира. Старият Compete все още понякога се използва поради факта, че в него бяха инвестирани много пари едновременно.

Lotus беше следващият, който се опита да навлезе на пазара на многоизмерни електронни таблици с Improv, който работи на машина NeXT. Това гарантира най-малкото, че продажбите от 1-2-3 не спадат, но когато в крайна сметка беше пусната за Windows, Excel вече имаше голям пазарен дял, което попречи на Lotus да направи каквито и да било промени в разпределението на пазара. Lotus, подобно на CA с Compete, премести Improv в долния край на пазара, но това не беше предпоставка за успешен напредък на пазара и новите развития в тази област не бяха продължени. Оказа се, че потребителите на персонални компютри предпочитат 1-2-3 електронни таблици и не се интересуват от нови многоизмерни възможности, ако не са напълно съвместими със старите си електронни таблици. По същия начин концепциите за малки настолни електронни таблици, предлагани като лични приложения, не са се оказали наистина удобни и не са се вкоренили в реалния бизнес свят. Microsoft (r) пое по този път, добавяйки обобщени таблици (в руското издание се нарича „обобщени таблици“) към Excel. Въпреки че малко потребители на Excel са се възползвали от тази функция, това е може би единственият факт, че възможностите за многоизмерен анализ са широко използвани в света, просто защото има толкова много потребители на Excel в света.

4. OLAP, ROLAP, MOLAP ...

Добре известно е, че когато Код публикува своите правила за изграждане на релационни СУБД през 1985 г., те предизвикаха силна реакция и впоследствие оказаха силно въздействие върху индустрията на СУБД като цяло. Малко хора обаче знаят, че през 1993 г. Код публикува работа, озаглавена „OLAP за аналитични потребители: какво трябва да бъде“. В него той очерта основните концепции за онлайн аналитична обработка и идентифицира 12 правила, на които трябва да отговарят продуктите, които позволяват онлайн аналитична обработка.

Това са правилата (оригиналният текст се съхранява, когато е възможно):

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

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

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

4. Постоянна производителност при разработването на отчети. Ако броят на измеренията или размерът на базата данни се увеличи, потребителят-аналитик не трябва да усеща значително влошаване на производителността. Постоянната производителност е от решаващо значение за поддръжката на крайния потребител с лекота на използване и ограничаване на сложността на OLAP. Ако потребителският анализатор изпитва значителни разлики в производителността в зависимост от броя на измеренията, тогава той ще се стреми да компенсира тези разлики със стратегия за проектиране, което ще доведе до представяне на данните по начин, различен от начина, по който данните наистина трябва да бъдат представени. Отделянето на време за обикаляне на системата, за да се компенсира нейната неадекватност, не е предназначено за аналитични продукти.

5. Архитектура клиент-сървър. Повечето от данните, които днес трябва да се обработват онлайн, са на мейнфрейм и са достъпни чрез компютър. Това означава, следователно, че OLAP продуктите трябва да могат да работят в клиент-сървърна среда. От тази гледна точка е необходимо сървърният компонент на аналитичния инструмент да бъде по същество „интелигентен“, така че различни клиенти да могат да се свързват със сървъра с минимални проблеми и програмиране за интеграция. „Умният“ сървър трябва да може да извършва съпоставяне и консолидация между неподходящи логически и физически схеми на база данни. Това ще осигури прозрачност и ще изгради цялостна концептуална, логическа и физическа схема.

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

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

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

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

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

11. Гъвкави опции за отчитане. Анализирането и представянето на данни е просто, когато редовете, колоните и клетките с данни, които ще бъдат визуално сравнени помежду си, ще бъдат близки един до друг или според някаква логическа функция, която се извършва в предприятието. Инструментите за отчитане трябва да представляват синтезирани данни или информация, получена от модела на данните във всяка възможна ориентация. Това означава, че редове, колони или страници трябва да показват от 0 до N измерения наведнъж, където N е броят на измеренията в целия аналитичен модел. В допълнение, всяко измерение на съдържанието, показано в един запис, колона или страница, също трябва да може да показва всяко подмножество от елементите (стойностите), съдържащи се в измерението, в произволен ред.

12. Неограничен размер и брой нива на агрегиране. Изследването на възможния брой необходими измервания, необходими в аналитичен модел, показа, че могат да се използват до 19 измервания едновременно. Оттук и силната препоръка аналитичният инструмент да може да предоставя поне 15 измерения едновременно и за предпочитане 20. Освен това всяко от общите измерения не трябва да бъде ограничено от броя на дефинираните от потребителя нива на агрегиране и пътищата на консолидация, дефинирани от потребител-аналитик.

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

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

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

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

ROLAP ... Релационен OLAP. Както подсказва името, многоизмерната структура в такива инструменти се реализира чрез релационни таблици. И данните в процеса на анализ, съответно, се избират от релационна база данни чрез аналитичен инструмент.

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

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

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

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

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

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

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

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

Предимства на OLAP:

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

OLAP и OLTP. Характеристики и основни разлики

Правила на Codd за OLAP системи

През 1993 г. Код публикува работа, озаглавена OLAP за аналитични потребители: начинът, по който трябва да бъде. В него той очерта основните концепции за онлайн аналитична обработка и идентифицира 12 правила, на които трябва да отговарят продуктите, които позволяват онлайн аналитична обработка.

1. Концептуален многоизмерен изглед. Моделът OLAP трябва да бъде многоизмерен в основата си. Многоизмерна концептуална схема или персонализиран изглед улеснява моделирането и анализа, както и изчисляването.
2. Прозрачност. Потребителят може да получи всички необходими данни от OLAP машината, без дори да знае откъде идват. Независимо дали OLAP продуктът е част от инструментите на потребителя или не, този факт трябва да бъде невидим за потребителя. Ако OLAP се предоставя от изчисления от страна на клиент-сървър, тогава този факт също, ако е възможно, трябва да бъде невидим за потребителя. OLAP трябва да бъде представен в контекста на една наистина отворена архитектура, позволяваща на потребителя, където и да се намира, да комуникира със сървъра с помощта на аналитичен инструмент. В допълнение към това трябва да се постигне и прозрачност, когато аналитичният инструмент взаимодейства с хомогенни и хетерогенни среди на база данни.
3. Наличност. OLAP трябва да предостави своя собствена логическа диаграмаза достъп в хетерогенна среда на база данни и извършване на подходящи трансформации за предоставяне на данни на потребителя. Освен това е необходимо предварително да се помисли къде и как и какви видове организация на физически данни всъщност ще се използват. OLAP системата трябва да има достъп само до данните, които са действително необходими, а не да прилага общия принцип на "кухненската фуния", който води до ненужно въвеждане.
4. Постоянен производителностпри разработване на отчети. производителностотчитането не трябва да намалява значително с увеличаването на броя измерения и размера на базата данни.
5. Архитектура клиент-сървър. Изисква се продуктът да бъде не само клиент-сървър, но и че сървърният компонент е достатъчно интелигентен, така че различните клиенти да могат да се свързват с минимум усилия и програмиране.
6. Обща многоизмерност. Всички размери трябва да бъдат равни, всяко измерение трябва да бъде еквивалентно както по структура, така и по експлоатационни възможности. Вярно е, че са разрешени допълнителни оперативни възможности за отделни измерения (очевидно времето се подразбира), но такива допълнителни функции трябва да бъдат предвидени за всяко измерение. Не би трябвало да е толкова елементарно структури от данни, изчислителните или отчетни формати са по -специфични за всяко едно измерение.
7. Динамичен контрол редки матрици... OLAP системите трябва автоматично да коригират своята физическа схема въз основа на типа на модела, обемите данни и рядката база данни.
8. Поддръжка за мултиплейър. OLAP инструментът трябва да предоставя възможности споделяне(заявка и допълнение), цялост и сигурност.
9. Неограничени кросоувъри. Всички видове операции трябва да бъдат разрешени за всякакви измервания.
10. Интуитивно манипулиране на данни. Манипулирането на данни се извършва чрез директни действия върху клетки в режим на изглед, без да се използват менюта и множество операции.
11. Гъвкави опции за отчитане. Измерванията трябва да се поставят в отчета според нуждите на потребителя.
12. Неограничен

4. Класификация на OLAP продуктите.

5. Принципи на работа на OLAP-клиенти.

7. Сфери на приложение на OLAP-технологиите.

8. Пример за използване на OLAP-технологии за анализ в областта на продажбите.

1. Мястото на OLAP в информационната структура на предприятието.

Терминът "OLAP" е неразривно свързан с термина "склад за данни".

Данните в склада идват от операционни системи (OLTP системи), които са предназначени да автоматизират бизнес процесите. В допълнение, складът може да бъде попълнен с външни източници, като например статистически отчети.

Целта на хранилището е да предостави „суровината“ за анализ на едно място и в проста, разбираема структура.

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

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

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

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

Мястото на OLAP в информационната структура на предприятието (фиг. 1).

Снимка 1... МястоOLAP в информационната структура на предприятието

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

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

2. Оперативна аналитична обработка на данни.

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

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

Едновременният анализ в множество измерения се определя като многовариантен анализ. Всяко измерение включва насоки за консолидиране на данни, състоящи се от поредица от последователни нива на агрегиране, където всяко по -високо ниво съответства на по -голяма степен на агрегиране на данни за съответното измерение.

По този начин измерението на изпълнителя може да бъде определено от посоката на консолидация, която се състои от нивата на обобщение „предприятие - отдел - отдел - служител“. Измерението Време може дори да включва две посоки на консолидация - година - тримесечие - месец - ден и седмица - ден, тъй като броенето на време по месец и по седмица е несъвместимо. В този случай става възможно произволно да се избере желаното ниво на детайлност на информацията за всяко от измерванията.

Операцията на пробиване съответства на движението от по-високите етапи на консолидация към по-ниските; напротив, подвижна операция означава преминаване от по -ниски нива към по -високи нива (фиг. 2).

Фигура 2.Измервания и направления на консолидиране на данните

3. Изисквания за инструменти за онлайн аналитична обработка.

Многоизмерният подход се появява почти едновременно и успоредно с релационния. Въпреки това едва от средата на деветдесетте години или по-скоро от тогава
1993 г., интерес към MSUBDзапочна да придобива общ характер. През тази година се появи нова програмна статия от един от основателите на релационния подход Е. Кода, в който формулира 12 основни изисквания към средствата за изпълнение OLAP(Маса 1).

Маса 1.

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

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

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

Спомнянето на 12 -те правила на Код е твърде натоварващо за повечето хора. Оказа се, че можете да обобщите дефиницията на OLAP само с пет ключови думи: Бърз анализ на споделена многоизмерна информация - или накратко - FASMI (превод от английски:Ф аст А анализ на С оскъден М ултраизмерна аз информация).

Това определение е формулирано за първи път в началото на 1995 г. и оттогава не се нуждае от преразглеждане.

БЪРЗ ( бързо) - означава, че системата трябва да може да предоставя повечето от отговорите на потребителите в рамките на приблизително пет секунди. В същото време най -простите заявки се обработват в рамките на една секунда и много малко - повече от 20 секунди. Изследванията показват, че крайните потребители възприемат процеса като неуспешен, ако не са получени резултати след 30 секунди.

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

АНАЛИЗ (анализ)означава, че системата може да обработва всеки логически и статистически анализ, специфичен за дадено приложение, и гарантира, че тя се записва във форма, достъпна за крайния потребител.

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

СПОДЕЛЕНО означава, че системата изпълнява всички изисквания за защита на поверителността (евентуално до ниво клетка) и, ако се изисква многократен достъп за запис, осигурява блокиране на модификации на съответното ниво. Не всички приложения трябва да записват обратно данни. Броят на такива приложения обаче нараства и системата трябва да може да се справи с множество модификации своевременно и сигурно.

МНОГОИЗМЕРЕН - това е основно изискване. Ако трябва да определите OLAP с една дума, вие бихте го избрали. Системата трябва да предоставя многоизмерен концептуален изглед на данните, включително пълна поддръжка за йерархии и множество йерархии, тъй като това определено е най-логичният начин за анализ на бизнеса и организациите. Няма минимален брой измерения, които трябва да бъдат обработени, защото зависи и от приложението, а повечето OLAP продукти имат достатъчно измерения за пазарите, към които са насочени.

ИНФОРМАЦИЯ - това е всичко. Необходимата информация трябва да се получи там, където е необходима. Въпреки това, много зависи от приложението. Мощността на различните продукти се измерва по отношение на това колко входящи данни могат да обработят, но не и колко гигабайта могат да съхраняват. Силата на продуктите варира значително - най -големите OLAP продукти могат да обработват поне хиляда пъти повече данни от най -малките. Има много фактори, които трябва да се вземат предвид в това отношение, включително дублиране на данни, необходима RAM, използване на дисковото пространство, производителност, интеграция на съхранение на данни и др.

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

4. КласификацияOLAP-продукти.

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

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

Класификация по начин на съхранение

Многоизмерните кубове се изграждат на базата на изходни и обобщени данни. И необработените, и обобщените данни за кубчета могат да се съхраняват както в релационни, така и в многоизмерни бази данни. Следователно в момента се използват три начина за съхранение на данни: MOLAP (многомерен OLAP), ROLAP (релационен OLAP) и HOLAP (хибриден OLAP ). Съответно, OLAP -Продуктите са разделени в три подобни категории по начин на съхранение на данни:

1. В случай на MOLAP , изходните и обобщените данни се съхраняват в многоизмерна база данни или в многоизмерен локален куб.

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

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

Класификация на местоположението OLAP-коли.

На тази основа OLAP -продуктите са разделени на OLAP сървъри и OLAP клиенти:

OLAP на сървъра -средствата за изчисляване и съхранение на съвкупни данни се извършват от отделен процес - сървъра. Клиентското приложение получава само резултатите от заявки срещу многоизмерни кубчета, които се съхраняват на сървъра. Някои OLAP -сървърите поддържат съхранение на данни само в релационни бази данни, някои - само в многоизмерни. Много модерни OLAP -сървърите поддържат и трите начина за съхранение на данни:MOLAP, ROLAP и HOLAP.

MOLAP.

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

ROLAP.

ROLAP е Релационна онлайн аналитична обработка,тоест, Релационен OLAP.Терминът ROLAP означава, че OLAP сървърът се основава на релационна база данни. Изходните данни се въвеждат в релационна база данни, обикновено в схема на звезда или снежинка, за да се намали времето за извличане. Сървърът предоставя многоизмерен модел на данни, използвайки оптимизирани SQL заявки.

Съществуват редица причини за избор на релационна база данни пред многомерна база данни. RDB е утвърдена технология с много възможности за оптимизация. Реалната употреба доведе до по -сложен продукт. В допълнение, RDB поддържат по -големи количества данни от MDB. Те са просто проектирани за такива обеми. Основният аргумент срещу RDB е сложността на заявките, необходими за извличане на информация от голяма база данни, използваща SQL. Неопитен SQL програмист може лесно да натовари ценни системни ресурси, като се опита да изпълни подобна заявка, която е много по-лесна за изпълнение в MDB.

Обобщени / Предварително обобщени данни.

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

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

OLAP -клиентът е подреден по различен начин. Изграждане на многоизмерен куб и OLAP -изчисленията се извършват в паметта на клиентския компютър.OLAP -клиентите също се делят на ROLAP и MOLAP.А някои може да поддържат и двата типа достъп до данни.

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

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

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

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

И така, в какви случаи използването на OLAP клиент за потребителите може да бъде по -ефективно и изгодно от използването на OLAP сървър?

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

· Мощните аналитични компютри са друга добра причина OLAP -клиенти. При кандидатстване OLAP -сървър, тези капацитети не се използват.

Сред предимствата на OLAP клиентите са следните:

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

· Използвайки OLAP - за клиент с вградена машина предаването на данни през мрежата се извършва еднократно. Докато прави OLAP -не се създават операции на нови потоци от данни.

5. Принципи на работа OLAP-клиенти.

Нека разгледаме процеса на създаване на OLAP приложение с помощта на клиентския инструмент (Фигура 1).

Снимка 1.Изградете OLAP приложение, използвайки ROLAP Client Tool

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

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

При създаване на семантичен слой източниците на данни - таблиците Продажби и Сделки - се описват с термини, които са разбираеми за крайния потребител и се превръщат в "Продукти" и "Сделки". Полето „ID“ от таблицата „Продукти“ се преименува на „Код“, а „Име“ на „Продукт“ и т.н.

След това се създава бизнес обект Sales. Бизнес обектът е плоска маса, от която се формира многоизмерен куб. Когато се създава бизнес обект, таблиците „Продукти“ и „Сделки“ се комбинират от полето „Код“ на продукта.Тъй като не се изисква всички полета на таблицата да се показват в отчета, бизнес обектът използва само полетата „Елемент“, „Дата“ и „Сума“.

В нашия пример въз основа на бизнес обекта Продажби е създаден отчет за продажбите на стоки по месеци.

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

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

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

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

6. Избор на архитектура на OLAP приложение.

При внедряването на информационна и аналитична система е важно да не направите грешка при избора на архитектура на OLAP приложение. Буквалният превод на термина On-Line Analytical Process - "онлайн аналитична обработка" - често се приема буквално в смисъл, че данните, влизащи в системата, се анализират незабавно. Това е заблуда – ефективността на анализа няма нищо общо с реалното време на актуализация на данните в системата. Тази характеристика се отнася до времето за отговор на OLAP системата на потребителски заявки. В същото време анализираните данни често са моментна снимка на информация „за вчера“, ако например данните в хранилищата се актуализират веднъж на ден.

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

Друга особеност на интерактивната обработка във формулировката на основателя на OLAP Е. Код е способността да „комбинира, разглежда и анализира данните от гледна точка на множество измерения, тоест по най -разбираемия начин за корпоративните анализатори“. За самия Код терминът OLAP означава изключително специфичен начин за представяне на данни на концептуално ниво - многоизмерен. На физическо ниво данните могат да се съхраняват в релационни бази данни, но в действителност OLAP инструментите са склонни да работят с многоизмерни бази данни, в които данните са организирани в хиперкуб (Фигура 1).

Снимка 1. OLAP- куб (хиперкуб, метакуб)

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

Очевидно времето за формиране на многоизмерна база данни зависи значително от обема на данните, заредени в нея, така че е разумно да се ограничи този обем. Но как да не стесним възможностите за анализ и да не лишим потребителя от достъп до цялата информация, която представлява интерес? Има два алтернативни пътя: Анализ след това заявка и Запитване след това анализ.

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

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

Предимствата на втория подход включват "свежестта" на информацията, която потребителят получава под формата на многоизмерен отчет - "микрокуб". Микрокубът се генерира въз основа на току -що поисканата информация от текущата релационна база данни. Работата с микрокуба се извършва в интерактивен режим - получаването на части от информация и нейното детайлизиране в микрокуба се извършва незабавно. Друг положителен момент е, че проектирането на структурата и пълненето на микрокуба се извършва от потребителя "в движение", без участието на администратора на базата данни. Подходът обаче страда и от сериозни недостатъци. Потребителят не вижда общата картина и трябва да се определи предварително с посоката на своето изследване. В противен случай заявеният микрокуб може да е твърде малък и да не съдържа всички данни, които представляват интерес, и потребителят ще трябва да поиска нов микрокуб, след това нов, след това отново и отново. След това подходът за анализ на заявката прилага инструмента BusinessObjects на едноименната компания и инструментите на платформата Company Contour.ИнтерсофтЛаборатория.

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

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

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

Най-известните представители на подхода „Анализирайте и след това заявете“ са инструментите PowerPlay и Impromptu от Cognos.

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

7. Сфери на приложение на OLAP-технологиите.

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

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

1. Продажби.

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

2. Покупки.

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

3. Цени.

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

4. Маркетинг.

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

5. Склад.

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

6. Паричен поток.

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

7. Бюджет.

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

8. Сметки.

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

9. Финансова отчетност.

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

10. Трафик на уебсайт.

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

11. Обеми на производство.

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

12. Консумация на консумативи.

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

13. Ползване на помещения.

Друг вид статистически анализ. Примери: анализ на натовареността на класните стаи, наетите сгради и помещения, използването на конферентни зали и др.

14. Оборот на служители в предприятието.

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

15. Пътнически трафик.

Анализ на броя на продадените билети и сумите в контекста на сезони, посоки, видове автомобили (класове), видове влакове (самолети).

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

8. Пример за използване OLAP -технологии за анализ в областта на продажбите.

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

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

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

Измерението „Клиенти“ отразява структурата на продажбите по географско местоположение. Всяко измерение може да има свои собствени йерархии, например в това измерение може да бъде структура: Държави - Региони - Градове - Клиенти.

За да анализирате работата на отделите, трябва да създадете свое собствено измерение. Например, можете да различите две нива на йерархията: отдели и техните подразделения, които трябва да бъдат отразени в измерението "Отдели".

Всъщност измеренията "Време", "Продукти", "Клиенти" доста напълно определят пространството на предметната област.

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

OLAP - кубът за анализ ще изглежда така (фиг. 2):

Фигура 2.OLAP- куб за анализ на обема на продажбите

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

Не трябва да се попълват всички елементи на куба: ако няма информация за продажбите на Продукт 2 на Клиент 3 през третото тримесечие, стойността в съответната клетка просто няма да бъде определена.

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

Фигура 3.Структура на аналитичния отчет

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

Фигура 4.Доклад за продажбите за третото тримесечие

Можете да изрежете куба по различна ос и да получите отчет за продажбите на продуктова група 2 през годината (фиг. 5).

Фигура 5.Тримесечен отчет за продажбите на продукти 2

По същия начин можете да анализирате връзката с клиента 4, изрязване на куба на етикета Клиенти(фиг. 6)

Фигура 6.Доклад за доставката на стоки до клиента 4

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

В поредица от статии "Въведение в бази данни", публикувани наскоро (виж ComputerPress # 3'2000 - 3'2001), ние обсъдихме различни технологии и софтуер, използвани за създаване информационни системи- настолни и сървърни СУБД, инструменти за проектиране на данни, инструменти за разработка на приложения, както и Business Intelligence - инструменти за анализ и обработка на данни в корпоративен мащаб, които сега стават все по -популярни в света, включително и у нас. Имайте предвид обаче, че проблемите с използването на инструменти и технологии за бизнес разузнаване, използвани за създаване на приложения от този клас, все още не са достатъчно обхванати в родната литература. В нова поредица от статии ще се опитаме да запълним тази празнина и да поговорим за технологиите, които стоят в основата на такива приложения. Като примери за внедряване ще използваме основно OLAP технологии от Microsoft (основно Analysis Services в Microsoft SQL Server 2000 г.), но се надяваме, че по -голямата част от материала ще бъде полезен за потребителите на други инструменти.

Първата статия от тази поредица е посветена на основите на OLAP (On -Line Analytical Processing) - технология за многоизмерен анализ на данни. В него ще обхванем концепциите за хранилища на данни и OLAP, изискванията за складовете с данни и инструментите за OLAP, логическата организация на данните от OLAP и основните термини и концепции, използвани при обсъждане на многоизмерен анализ.

Какво е хранилище за данни

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

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

Ралф Кимбъл, един от създателите на концепцията за хранилище на данни, описва хранилището за данни като „място, където хората имат достъп до техните данни“ (вж. Например Ралф Кимбол, „Инструментариум за хранилище на данни: Практически техники за изграждане на хранилища с размери на данни“) ", John Wiley & Sons, 1996 и "The Data Webhouse Toolkit: Building the Web-Enabled Data Warehouse", John Wiley & Sons, 2000). Той също така формулира основните изисквания за складовете с данни:

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

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

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

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

И трето, обикновените бази данни най-често са източник на данни, влизащи в склада. В допълнение, складът може да бъде попълнен с външни източници, като например статистически отчети.

Какво е OLAP

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

Технологията за комплексен многовариантен анализ на данни се нарича OLAP (On-Line Analytical Processing). OLAP е ключов компонент на организацията за съхранение на данни. Концепцията за OLAP е описана през 1993 г. от Едгар Код, известен изследовател на база данни и автор на модела на релационни данни (вижте EF Codd, SB Codd и CTSalley, Предоставяне на OLAP (онлайн аналитична обработка) на потребителски анализатори: ИТ мандат Технически доклад, 1993 г.). През 1995 г., въз основа на изискванията, определени от Codd, е формулиран т. нар. тест за бърз анализ на споделена многоизмерна информация (FASMI), който включва следните изисквания за приложения за мултивариантен анализ:

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

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

Многоизмерни кубчета

В този раздел ще разгледаме по -отблизо концепцията за OLAP и многоизмерните кубчета. Като пример за релационна база данни, която ще използваме, за да илюстрираме принципите на OLAP, ще използваме базата данни Northwind, включена в Microsoft SQL Server или Microsoft Accessи е типична база данни, която съхранява информация за търговските сделки на търговец на едро с храни. Тези данни включват информация за доставчици, клиенти, доставчици, списък на доставените стоки и техните категории, данни за поръчки и поръчани стоки, списък на служителите на компанията. Подробно описаниеБазите данни на Northwind могат да бъдат намерени в справка Системи на Microsoft SQL Server или Microsoft Access - не го включваме тук поради ограничения в пространството.

За да проучим концепцията OLAP, ще използваме изгледа „Фактури“ и таблиците „Продукти и категории“ от базата данни Northwind, за да създадем заявка, която ще извлече подробностите за всички поръчани артикули и издадени фактури:

ИЗБЕРЕТЕ dbo.Invoices.Country, dbo.Invoices.City, dbo.Invoices.CustomerName, dbo.Invoices.Salesperson, dbo.Invoices.OrderDate, dbo.Categories.CategoryName, dbo.Invoices.Invoices.InductName, dboShivopper .ExtendedPrice FROM dbo.Products INNER JOIN dbo.Categories ON dbo.Products.CategoryID = dbo.Categories.CategoryID INNER JOIN dbo.Invoices ON dbo.Products.ProductID = dbo.Invoices.ProductID

В Access 2000 подобна заявка изглежда така:

SELECT Invoices.Country, Invoices.City, Invoices.Customers.CompanyName AS CustomerName, Invoices.Salesperson, Invoices.OrderDate, Categories.CategoryName, Invoices.ProductName, Invoices.Shippers.CompanyName INOVE INPROME .ProductID = Products.ProductID) ON Categories.CategoryID = Products.CategoryID;

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

За удобство нека запазим тази заявка като изглед и да я наречем Фактури1. Резултатът от достъпа до този изглед е показан на фиг. 1.

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

• Каква е общата стойност на поръчките, направени от клиенти от Франция?
• Каква е общата стойност на поръчките, направени от клиенти във Франция и доставени от Speedy Express?
• Каква е общата стойност на поръчките, направени от френски клиенти през 1997 г. и доставени от Speedy Express?

Нека преведем тези въпроси в заявки на езика SQL (Таблица 1).

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

Полученият набор от агрегирани стойности (в този случай суми) може да се интерпретира като едноизмерен набор от данни. Същият набор от данни може да бъде получен в резултат на заявка с клаузата GROUP BY от следната форма:

ИЗБЕРЕТЕ Държава, СУММА (Удължена цена) ОТ фактури1 ГРУПА ПО Държава

Сега нека се обърнем към второто от горните заявки, което съдържа две условия в клаузата WHERE. Ако изпълним тази заявка, замествайки в нея всички възможни стойности за параметрите Country и ShipperName, получаваме двуизмерен набор от данни от следната форма (фрагментът е показан по-долу):

Този набор от данни се нарича въртяща таблица или кръстосана таблица (кръстосана таблица). Много електронни таблици и настолни СУБД ви позволяват да създавате такива таблици - от Paradox за DOS до Microsoft Excel 2000. Например, подобна заявка изглежда така в Microsoft Access 2000:

TRANSFORM Sum (Фактури1.ExtendedPrice) КАТО SumOfExtendedPrice ИЗБЕРЕТЕ фактури1.Държава ОТ фактури1 ГРУПА ПО фактури1.Фактури PIVOT за страната1.Име на изпращача;

Обобщени данни за такава обобщена таблица могат да бъдат получени и чрез обикновена заявка GROUP BY:

SELECT Country, ShipperName, SUM (ExtendedPrice) FROM фактури1 GROUP BY COUNTRY, ShipperName Имайте предвид обаче, че резултатът от тази заявка няма да бъде самата обобщена таблица, а само набор от обобщени данни за нейното изграждане (фрагментът е показан по -долу ):

Третата от горните заявки вече има три параметъра в клаузата WHERE. Променяйки ги, получаваме триизмерен набор от данни (фиг. 2).

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

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

Очевидно данните, съдържащи се в клетките на куба, могат да бъдат получени и с помощта на съответната заявка с клаузата GROUP BY. В допълнение, някои електронни таблици (по-специално Microsoft Excel 2000) също ви позволяват да създадете триизмерен набор от данни и да преглеждате различни секции от куба, успоредни на лицето му, изобразени на лист от работна книга (работна книга).

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

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

Някои термини и понятия

Заедно със сумите, клетките на куба OLAP могат да съдържат резултатите от други агрегатни функции SQL езиккато MIN, MAX, AVG, COUNT и в някои случаи други (дисперсия, стандартно отклонение и т.н.). За описание на стойностите на данните в клетките се използва терминът обобщение (по принцип може да има няколко от тях в един куб), за да се обозначат първоначалните данни, въз основа на които се изчисляват, терминът мярка и обозначават параметрите на заявката, термина измерение (превеждано на руски обикновено като "измерение", когато говорим за OLAP кубчета, и като "измерение", когато говорим за складове с данни). Стойностите, нанесени върху осите, се наричат ​​членове.

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

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

Обърнете внимание, че йерархиите могат да бъдат балансирани, като йерархията, показана на фиг. 3, както и дата-час и небалансирани йерархии. Типичен пример за небалансирана йерархия е йерархията шеф-подчинен (тя може да бъде изградена, например, като се използват стойностите на полето Salesperson в оригиналния набор от данни от примера по-горе), показан на фиг. 4 .

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

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

Обърнете внимание, че небалансираните и „неравномерни“ йерархии не се поддържат от всички инструменти на OLAP. Например Microsoft Analysis Services 2000 поддържа и двата типа йерархия, докато Microsoft OLAP Services 7.0 поддържа само балансирани. Различни в различните инструменти на OLAP могат да бъдат броят на йерархичните нива и максимално допустимият брой членове на едно ниво и максимално възможният брой самите измерения.

Заключение

В тази статия научихме за основите на OLAP. Научихме следното:

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

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

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

ComputerPres 4 "2001

Цел на доклада

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

Целта на доклада: да разкрие и открои 2 въпроса: 1) концепцията за OLAP и тяхното приложно значение в финансово управление; 2) внедряване на функционалност OLAP в софтуерни решения: разлики, възможности, предимства, недостатъци.

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

Финансово управление

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

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

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

Финансовият директор винаги трябва да знае:

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

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

знание

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

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

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

Какво е сега

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

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

Какво да правя

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

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

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

Основни концепции за OLAP технологиите

OLAP-технологията (от англ. On-Line Analytical Processing) е името не на конкретен продукт, а на цяла технология за оперативен анализ на многоизмерни данни, натрупани в хранилището. За да се разбере същността на OLAP, е необходимо да се разгледа традиционният процес на получаване на информация за вземане на решения.

Традиционна система за подпомагане на вземане на решения

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

Но този начин на подпомагане на решенията няма гъвкавост и има много недостатъци:

• използва незначително количество данни, които могат да бъдат полезни за вземане на решения
• понякога се създават сложни многостранични отчети, от които всъщност се използват 1-2 реда (останалото е за всеки случай)-претоварване с информация
• бавна реакция на процеса към промените: ако е необходимо ново представяне на данни, тогава заявката трябва да бъде официално описана и кодирана от програмиста, едва тогава изпълнена. Време на изчакване: часове, дни. Може би е необходимо решение сега, незабавно. Но след получаване на нова информация ще възникне нов въпрос (изясняващ)

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

Много компании създават отлични релационни бази данни, идеално разлагащи планини от неизползвана информация, която сама по себе си не осигурява бърза или достатъчно компетентна реакция на пазарните събития. ДА – релационните бази данни бяха, са и ще бъдат най-подходящата технология за съхранение на корпоративни данни. Не става въпрос за нова технология DB, а по -скоро за инструменти за анализ, които допълват функциите на съществуващите СУБД и са достатъчно гъвкави, за да осигурят и автоматизират различните видове майнинг, присъщи на OLAP.

Разбиране на OLAP

Какво дава OLAP?

• Разширени инструменти за достъп до съхранение на данни
• Динамично интерактивно манипулиране на данни (завъртане, консолидиране или пробиване надолу)
• Ясно визуално показване на данни
• Бърз анализ в реално време
• Многоизмерно представяне на данни - едновременен анализ на множество индикатори в множество измерения

За да получите ефект от използването на OLAP технологиите, трябва: 1) да разберете същността на самите технологии и техните възможности; 2) ясно дефинирайте какви процеси трябва да бъдат анализирани, какви показатели ще бъдат характеризирани и в какви измерения е препоръчително да ги видите, тоест да създадете модел за анализ.

Основните концепции, използвани от OLAP технологиите, са следните:

Многоизмерност

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

Тези данни са представени в две измерения:

• статия
• бизнес единица

Тази таблица не е информативна, тъй като показва продажби за всеки период от време. За различни периоди от време анализаторите ще трябва да сравнят няколко таблици (за всеки период от време):

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

Друг начин за показване на многоизмерни данни е представянето им под формата на куб:

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

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

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

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

Обикновено OLAP приложенията ви позволяват да получавате данни за 3 или повече измерения, например можете да добавите още едно измерение - план -действително, категория разходи: директно, непряко, по поръчки, по месеци. Допълнителните измерения ви позволяват да получите повече аналитични изрезки и да предоставите отговори на въпроси с множество условия.

Йерархия

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

Например, препоръчително е да групирате разходите йерархично:

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

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

Промяна на посоките на анализ в куб (ротация на данни)

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

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

Показването на куб данни зависи от:

• ориентации на измерения: кои размери са посочени в редове, колони, филийки;
• групи индикатори, подчертани в редове, колони, резени.
• Промяната на размерите е в полето на действие на потребителя.

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

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

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

Ако можете да прочетете около 200 записа в секунда от релационна база данни и да напишете 20, тогава добрият OLAP сървър, използващ изчислени редове и колони, може да консолидира 20 000-30 000 клетки (еквивалентни на един запис в релационна база данни) в секунда.

Видимост: Трябва да се подчертае, че OLAP предоставя усъвършенствано графично представяне на данните на крайния потребител. Човешкият мозък е в състояние да възприема и анализира информацията, представена под формата на геометрични изображения, в обем с няколко порядъка по -голям от информацията, представена в буквено -цифрова форма. Пример: Да предположим, че трябва да намерите познато лице в една от стоте снимки. Вярвам, че този процес ще ви отнеме по -малко от минута. Сега си представете, че вместо снимки ще ви бъдат предложени сто словесни описания на едни и същи лица. Мисля, че изобщо няма да успеете да разрешите предложения проблем.

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

Въпреки големите възможности на OLAP (в допълнение, идеята е сравнително стара - 60-те години), в действителност нейното използване на практика не се намира в нашите предприятия. Защо?

• няма информация или не са ясни възможностите
• навик да се мисли двуизмерно
• ценова бариера
• прекомерна производителност на статии за OLAP: непознати термини плашат - OLAP, „изкопаване и нарязване на данни“, „ad hoc заявки“, „идентифициране на значими корелации“

Нашият подход и западен подход към OLAP приложението

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

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

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

Приложно използване на OLAP

• Бюджет
• Поток на средства

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

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

• Финансово и управленско отчитане (с анализи, от които се нуждае ръководството)
• Маркетинг
• Балансирана карта с резултати
• Анализ на рентабилността

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

OLAP продукти

Този раздел ще говори за OLAP като софтуерно решение.

Общи изисквания за продуктите OLAP

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

Има характеристики, които трябва да се спазват във всички OLAP продукти (ако е OLAP продукт), които са идеалната технология. Това са 5 ключови дефиниции, които характеризират OLAP (т.нар. FASMI тест): Бърз анализ на споделена многоизмерна информация.

• Бързо(БЪРЗО) - означава, че системата трябва да може да предостави повечето отговори на потребителите в рамките на приблизително пет секунди. Дори ако системата предупреди, че процесът ще отнеме значително повече време, потребителите могат да се разсеят и да загубят мислите си, а качеството на анализа страда. Тази скорост не е лесна за постигане с големи количества данни, особено ако са необходими специални изчисления в движение. Доставчиците прибягват до голямо разнообразие от методи за постигане на тази цел, включително специализирани форми за съхранение на данни, обширно предварително изчисление или затягане на хардуерните изисквания. Понастоящем обаче няма напълно оптимизирани решения. На пръв поглед може да изглежда изненадващо, че при получаване на отчет за минута, което не толкова отдавна отнемаше дни, потребителят много бързо се отегчава, докато чака и проектът се оказва много по-малко успешен, отколкото в случай на незабавен отговор, дори с цената на по -малко подробен анализ.
• Споделеноозначава, че системата дава възможност да се изпълнят всички изисквания за защита на данните и да се прилага разпределен и едновременен достъп до данни за различни нива на потребители. Системата трябва да може да обработва множество промени в данните своевременно и сигурно. Това е основна слабост на много OLAP продукти, които са склонни да приемат, че всички OLAP приложения са само за четене и осигуряват опростена защита.
• Многоизмерене ключово изискване. Ако трябва да определите OLAP с една дума, вие бихте го избрали. Системата трябва да осигури многоизмерен концептуален изглед на данните, включително пълна поддръжка за йерархии и множество йерархии, тъй като това определя най -логичния начин за анализ на бизнеса. Няма минимален брой измерения, които да бъдат обработени, тъй като това също зависи от приложението, а повечето OLAP продукти имат достатъчно размери за пазарите, към които са насочени. Отново, ние не уточняваме каква основна технология на базата данни трябва да се използва, ако потребителят получи наистина многоизмерно концептуално представяне на информацията. Тази функция е в основата на OLAP
• Информация.Необходимата информация трябва да се получи там, където е необходима, независимо от обема и мястото на съхранение. Въпреки това, много зависи от приложението. Мощността на различните продукти се измерва по отношение на това колко входящи данни могат да обработят, но не и колко гигабайта могат да съхраняват. Силата на продуктите варира значително - най -големите OLAP продукти могат да обработват поне хиляда пъти повече данни от най -малките. Има много фактори, които трябва да се вземат предвид в това отношение, включително дублиране на данни, необходима RAM, използване на дисковото пространство, производителност, интеграция на съхранение на данни и др.
• Анализозначава, че системата може да обработва всеки логически и статистически анализ, специфичен за дадено приложение, и гарантира, че тя се записва във форма, достъпна за крайния потребител. Потребителят трябва да може да дефинира нови персонализирани изчисления като част от анализа, без да е необходимо програмиране. Тоест цялата необходима функционалност за анализ трябва да бъде предоставена по интуитивен начин на крайните потребители. Инструментите за анализ могат да включват специфични процедури, като анализ на времеви редове, разпределение на разходите, валутни преводи, търсене на цел и т.н. Такива възможности варират значително при различните продукти, в зависимост от целевата ориентация.

С други думи, тези 5 ключови дефиниции са целите, които OLAP продуктите са предназначени да постигнат.

OLAP технологични аспекти

OLAP системата включва определени компоненти. Има различни схеми на тяхната работа, които определен продукт може да приложи.

Компоненти на OLAP системите (от какво се състои OLAP системата?)

Обикновено OLAP системата включва следните компоненти:

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

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

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

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

Трябва да се отбележи, че терминът OLAP е неразривно свързан с термина Data Warehouse. Складът за данни е специфично за домейна, ограничено във времето и неизменно събиране на данни в подкрепа на процеса на вземане на управленски решения. Данните в склада идват от операционни системи (OLTP системи), които са предназначени да автоматизират бизнес процесите; складът може да се попълва от външни източници, например статистически отчети.

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

• фрагментиране на данни, съхранение в различни СУБД формати;
• подобрена производителност при извличане на данни
• ако всички данни в предприятието се съхраняват на централен сървър на база данни (което е изключително рядко), анализаторът вероятно няма да разбере техните сложни, понякога объркващи структури
• сложните аналитични заявки към оперативна информация забавят текущата работа на компанията, блокират таблици за дълго време и изземват ресурсите на сървъра
• възможност за почистване и съгласуване на данните
• невъзможно или много трудно е да се анализират данните на операционните системи директно;

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

OLAP продукти: Архитектури

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

Опции за съхранение на OLAP данни

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

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

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

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

Опции за обработка на OLAP данни

Има 3 от същите опции за обработка на данни:

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

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

OLAP архитектурна матрица

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

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

• Продуктите на ROLAP в сектори 1, 2, 3
• OLAP на работния плот - в сектор 6

Продукти MOLAP - в сектори 4 и 5

HOLAP продукти (позволяващи както многоизмерно, така и релационно съхранение на данни) - в 2 и 4 (в курсив)

OLAP продуктови категории

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

Трябва да се отбележи, че потребителите на хибридни продукти, които позволяват избор на режим ROLAP и MOLAP, като Microsoft Analysis Services, OracleExpress, Crystal Holos, IBM DB2 OLAPServer, почти винаги избират режим MOLAP.

Всяка от представените категории има своите силни и слаби страни, няма само една оптимален избор... Изборът засяга 3 важни аспекта: 1) производителност; 2) дисково пространство за съхранение на данни; 3) възможностите, функционалността и особено мащабируемостта на OLAP решението. В същото време е необходимо да се вземат предвид обемите на обработваните данни, мощта на технологиите, нуждите на потребителите и да се търси компромис между скоростта и излишъка на дисково пространство, заето от базата данни, просто и гъвкавост.

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

Недостатъци на OLAP

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

Избор на OLAP продукт

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

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

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

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

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

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

Оценка на нуждите

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

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

Няколко фактора вече станаха очевидни след прочитането на прегледа на продуктовите категории OLAP, а именно:

Технически аспекти

• Източници на данни: корпоративно хранилище за данни, OLTP система, файлове с таблици, релационни бази данни. Възможност за свързване на OLAP инструменти с всички СУБД, използвани в организацията. Както показва практиката, интегрирането на различни продукти в стабилна операционна система е един от най-важните проблеми и неговото решаване в някои случаи може да бъде свързано с големи проблеми. Необходимо е да се разбере колко лесно и надеждно е да се интегрират OLAP инструменти със съществуващите СУБД в организацията. Също така е важно да оцените възможностите за интеграция не само с източници на данни, но и с други приложения, в които може да се наложи да експортирате данни: електронна поща, офис приложения
• Променливостта на данните, която се взема предвид
• Сървърна платформа: NT, Unix, AS / 400, Linux - но не настоявайте продуктите за спецификации на OLAP да работят на съмнителни или умиращи платформи, които все още използвате
• Стандарти от страна на клиента и браузъра
• Разгръщаща се архитектура: локалната мрежаи модемен комуникационен компютър, високоскоростен клиент / сървър, интранет, екстранет, интернет
• Международни функции: поддръжка на няколко валути, многоезични операции, споделяне на данни, локализация, лицензиране, актуализация на Windows

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

Членове

• Обхват на приложение: продажби/маркетингов анализ, бюджетиране/планиране, анализ на изпълнението, анализ на счетоводни отчети, качествен анализ, финансово състояние, формиране на аналитични материали (отчети)
• Броят на потребителите и тяхното местоположение, изисквания за разделяне на правата за достъп до данни и функции, секретност (поверителност) на информацията
• Потребителски изглед: висше ръководство, финанси, маркетинг, човешки ресурси, продажби, производство и др.
• Потребителски опит. Ниво на потребителски умения. Помислете за предоставяне на обучение. Много е важно клиентското приложение OLAP да е такова, че потребителите да се чувстват уверени и да могат да го използват ефективно.

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

Изпълнение

• Кой ще внедрява и оперира: външни консултанти, вътрешни ИТ или крайни потребители
• Бюджет: софтуер, хардуер, услуги, предаване на данни. Не забравяйте, че лицензите за OLAP продукти са само малка част от общата стойност на проекта. Разходите за внедряване и хардуер могат да бъдат по-големи от лицензионните такси, а разходите за дългосрочна поддръжка, поддръжка и администрация са почти сигурно значително по-високи. И ако сте взели погрешно решение да закупите грешен продукт, само защото е по -евтино, в крайна сметка можете да имате по -високи общи разходи по проекта поради по -високи разходи за поддръжка, администрация и / или хардуер, докато вероятно ще получите по -ниско ниво на бизнес ползи . Когато оценявате общите разходи, не забравяйте да зададете следните въпроси: Колко широк е изборът на източници за изпълнение, обучение и поддръжка? Потенциалният общ състав (служители, изпълнители, консултанти) е склонен към растеж или намаляване? Колко широко можете да използвате своя индустриален професионален опит?

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

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

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