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

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

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

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

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

Концепцията за OLAP е описана през 1993 г. от Едгар Код, известен изследовател на база данни и автор на релационния модел на данни.Е.Ф. Код, С.Б. 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). Традиционният подход е да се опитаме да използваме вече изградени оперативни системи за подкрепа на вземането на решения. Обикновено те се опитват да изградят развита система от заявки към операционната система и да използват отчетите, получени след интерпретация, директно за подкрепа на решенията. Отчетите могат да се изграждат на персонализирана база, т.е. мениджърът изисква отчет и то редовно, когато отчетите се изграждат при достигане на определени събития или времена. Например, традиционният процес за подкрепа на вземане на решения може да изглежда така: мениджърът отива при информационния специалист и споделя въпроса си с него. След това информационният специалист изгражда заявка към операционната система, получава електронен отчет, интерпретира го и след това го довежда до вниманието на управленския персонал. Разбира се, такава схема осигурява до известна степен подкрепа за вземане на решения, но има изключително ниска ефективност и огромен брой недостатъци. Малко количество данни се използва за подкрепа на критични решения. Има и други проблеми. Такъв процес е много бавен, тъй като процесът на писане на заявки и тълкуване на електронен отчет е продължителен. Отнема много дни, в момент, когато лидерът може да трябва да вземе решение точно сега, незабавно. Като се има предвид, че мениджърът след получаване на отчета може да се интересува от друг въпрос (да речем, изясняване или изискване на разглеждане на данните в различен контекст), тогава този бавен цикъл трябва да се повтори и тъй като процесът на анализ на данните оперативни системище се случва итеративно, тогава се изразходва още повече време. Друг проблем е проблемът с различните сфери на дейност на специалист по информационни технологии и мениджър, които могат да мислят в различни категории и в резултат на това не се разбират. Тогава ще са необходими допълнителни итерации за усъвършенстване и това отново е време, което винаги не е достатъчно. Друг важен въпрос е сложността на отчетите за разбиране. Мениджърът няма време да избере интересните числа от отчета, особено след като може да има твърде много от тях (припомнете си огромни многостранични отчети, които всъщност използват няколко страници, а останалите за всеки случай). Отбелязваме също, че работата по превода се пада най-често на специалисти в информационните отдели. Тоест, компетентен специалист се разсейва от рутинна и неефективна работа по чертане на диаграми и т.н., което, разбира се, не може да повлияе благоприятно на неговата квалификация. Освен това не е тайна, че във веригата за тълкуване има доброжелатели, които се интересуват от умишленото изкривяване на входящата информация.

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

Всъщност тези проблеми не са следствие от лошото качество на операционната система или неуспешното й изграждане. Корените на проблемите се крият в фундаменталната разлика между оперативните дейности, които се автоматизират от операционната система, и дейностите по разработване и вземане на решения. Тази разлика се състои във факта, че данните на оперативните системи са просто записи на някои събития, които са се случили, факти, но не и информация в общия смисъл на думата. Информацията е нещо, което намалява несигурността във всяка област. И би било много хубаво информацията да намали несигурността при подготовката на решенията. Небезизвестният Е.Ф. Код, човекът, който е пионер на технологията за управление на релационни бази данни през 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-те години са престанали да бъдат актуални. Днес, през 90-те, Express е една от най-популярните OLAP технологии и 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 и доставчиците бяха принудени да разработят свои собствени стандарти за компютри и мрежи. Постепенно Metaphor започна да работи успешно на серийни персонални машини, но продуктът беше направен изключително за OS / 2 и имаше собствен графичен потребителски интерфейс.

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

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

В края на 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 осигурява обработка на големи масиви от съхранявани данни, тъй като е възможно да се осигури по-икономично съхранение, но в същото време губи значително в скоростта на многоизмерния OLAP. Подобни разсъждения доведоха до избора на нов клас аналитични инструменти - HOLAP. Това е хибридна (хибридна) оперативна аналитична обработка. Инструментите от този клас ви позволяват да комбинирате двата подхода - релационен и многоизмерен. Достъпът може да се осъществява както до данни от многоизмерни бази данни, така и до релационни данни.

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

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

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

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

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

История на OLAP

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

Историята на самата OLAP технология датира от 1970 г., когато бяха пуснати информационните ресурси Express и първия сървър Olap. Те бяха придобити от Oracle през 1995 г. и впоследствие станаха основа за онлайн аналитичната обработка на многоизмерен изчислителен двигател, който известна компютърна марка предостави в своята база данни. През 1992 г. друг известен продукт за онлайн аналитична обработка, Essbase, беше пуснат от Arbor Software (придобен от Oracle през 2007 г.).

През 1998 г. Microsoft пусна MS Analysis Services, онлайн сървър за обработка на аналитични данни. Това допринесе за популярността на технологията и стимулира развитието на други продукти. Днес има няколко световно известни доставчици, предлагащи Olap приложения, включително IBM, SAS, SAP, Essbase, Microsoft, Oracle, IcCube.

Онлайн аналитична обработка

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

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

1. Многоизмерно представяне на данни.
2. Поддръжка за сложни изчисления.
3. Временно разузнаване.

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

Поддръжката на сложни изчисления е гръбнакът на OLAP софтуера.

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

Многоизмерна структура от данни

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

Основни характеристики на OLAP системите:

1. Използвайте многоизмерни методи за анализ на данни.
2. Осигурете разширена поддръжка на база данни.
3. Създайте лесни за използване интерфейси за крайни потребители.
4. Поддържа архитектура клиент/сървър.

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

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

кубична форма

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

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

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

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

Обединяване на данни

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

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

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

Принцип на действие

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

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

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

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

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

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

1. По-малък размер на данните на диска.
2. Автоматично изчисляване на агрегати от по-високо ниво на данни.
3. Моделите на масивите осигуряват естествено индексиране.
4. Ефективното извличане на данни се постига чрез предварително структуриране.
5. Компактност за набори от данни с ниски размери.

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

Основни аналитични операции

Конволюция(навиване/разбиване) е известно още като "консолидация". Сгъването включва събиране на всички данни, които могат да бъдат получени, и изчисляване на всички в едно или повече измерения. Най-често това може да изисква прилагането на математическа формула. Като пример за OLAP, разгледайте търговска верига с търговски обекти в различни градове. За да се идентифицират моделите и да се предвидят бъдещи тенденции в продажбите, те се навиват от всички места до главния търговски отдел на компанията за консолидиране и изчисляване.

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

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

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

Разновидности на базата данни

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

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

OLAP инструменти

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

Най-популярните от тях:

1. Dundas BI от Dundas Data Visualization е базирана на браузър платформа за бизнес разузнаване и визуализация на данни, която включва интегрирани табла за управление, инструменти за отчитане на OLAP и анализ на данни.
2. Yellowfin е платформа за бизнес разузнаване, която е единно интегрирано решение, предназначено за компании от различни индустрии и размери. Тази система е адаптивна за бизнеси в областта на счетоводството, рекламата, селското стопанство.
3. ClicData е решение за бизнес разузнаване (BI), предназначено за използване предимно от малки и средни предприятия. Инструментът позволява на крайните потребители да създават отчети и табла за управление. Board е създаден, за да комбинира бизнес разузнаване, управление на ефективността на предприятието и е пълнофункционална система, която обслужва средни и корпоративно ниво.
4. Domo е облачен пакет за управление на бизнеса, който се интегрира с множество източници на данни, включително електронни таблици, бази данни, социални мрежии всеки съществуващ облачен или локален софтуерно решение.
5. InetSoft Style Intelligence е софтуерна платформа за бизнес анализатори, която позволява на потребителите да създават табла за управление, технология за визуален анализ на OLAP и отчети с помощта на машина за смесване.
6. Birst от Infor Company е уеб-базирано решение за бизнес разузнаване и анализ, което свързва прозренията между екипите, за да ви помогне да вземате информирани решения. Инструментът позволява на децентрализираните потребители да разширят модела на корпоративния екип.
7. Halo е цялостна система за управление на веригата за доставки и бизнес разузнаване, която подпомага бизнес планирането и прогнозирането на инвентара за управление на веригата за доставки. Системата използва данни от всички източници - големи, малки и междинни.
8. Chartio е базирано на облак решение за бизнес анализатор, което предоставя на основателите, бизнес екипите, анализаторите на данни и продуктовите екипи инструментите за организиране на ежедневната им работа.
9. Exago BI е уеб решение, предназначено да бъде вградено в уеб приложения. Внедряването на Exago BI позволява на компании от всякакъв размер да предоставят на своите клиенти ad hoc, в реално време и интерактивно отчитане.

Бизнес влияние

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

Някои от най-често срещаните му приложения включват:

1. Анализ на маркетингови OLAP данни.
2. Финансово отчитане, което обхваща продажби и разходи, бюджетиране и финансово планиране.
3. Управление на бизнес процеси.
4. Анализ на продажбите.
5. Маркетинг на бази данни.

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

Концепция OLAP технологиие формулиран от Едгар Код през 1993 г.

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

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

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

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

Основният модел на данни, използван в множество инструменти за създаване и поддържане на бази данни - СУБД, е релационният модел. Данните в него са представени под формата на набор от двумерни таблици-релации, свързани с ключови полета. За да се премахне дублирането, несъответствието и да се намалят разходите за труд за поддържане на бази данни, се използва формален апарат за нормализиране на таблици на обекти. Използването му обаче е свързано с допълнително време, прекарано за генериране на отговори на заявки към бази данни, въпреки че ресурсите на паметта се спестяват.

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

В рамките на OLAP технологиите, въз основа на факта, че многоизмерно представяне на данни може да бъде организирано както чрез релационни СУБД, така и чрез многоизмерни специализирани инструменти, има три вида многоизмерни OLAP системи:

• - многоизмерен (Multidimensional) OLAP-MOLAP;
• - релационен (Relation) OLAP-ROLAP;
• - смесен или хибриден (Hybrid) OLAP-HOLAP.

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

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

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

MOLAP ограниченията включват:

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

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

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

• - възможност за бърз анализ на данните, директно съдържащи се в хранилището, т.к мнозинство изходни базиданни - релационен тип;
• - с променливо измерение на проблема RO-LAP печели, т.к не се изисква физическа реорганизация на базата данни;
• - ROLAP системите могат да използват по-малко мощни клиентски станции и сървъри, а сървърите поемат основната тежест за обработка на сложни SQL заявки;
• - нивото на защита на информацията и диференциране на правата за достъп в релационните СУБД е несравнимо по-високо, отколкото в многоизмерните.

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

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

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

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

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

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

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

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

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

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

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

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

OLAP технологията се отнася до вида на интелектуалния анализ и включва 12 принципа:

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

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

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

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

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

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

7. Динамично управление на разредени матрици. Физическият дизайн на инструмента OLAP трябва да бъде напълно адаптивен към конкретния аналитичен модел, за да управлява оптимално разредените матрици. Рядостта (измерена като процент празни клетки към всички възможни) е една от характеристиките на разпространението на данни.

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

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

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

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

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

Като специализирани OLAP системи, предлагани в момента на пазара, можете да посочите CalliGraph, Business Intelligence.

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

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

Вижте каталога с OLAP решения и проекти в секцията OLAP на TAdviser.

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

Изисквания към OLAP системите. FASMI

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

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

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

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

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

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

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

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

Съхранение на активни данни в многоизмерна база данни

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

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

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

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

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

Съхранение на активни данни в релационна база данни

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

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

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

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

Съхранение на активни данни в "плоски" файлове

Този подход включва съхраняване на парчета данни в обикновени файлове. Обикновено се използва като допълнение към един от двата основни подхода за ускоряване на работата чрез кеширане на актуални данни на диск или в оперативна паметклиентски компютър.

Хибриден подход за съхранение

Повечето производители на OLAP системи, които популяризират своите интегрирани решения, често включващи, в допълнение към самата OLAP система, СУБД, ETL (Extract Transform Load) и инструменти за отчитане, в момента използват хибриден подход за организиране на съхранението на системни активни данни, разпределянето им по един или друг начин между RDBMS и специализираното хранилище, както и между дисковите структури и кеширането в паметта.

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

OLAP(на английски on-line analytical processing) - набор от методи за динамична обработка на многоизмерни заявки в аналитични бази данни. Такива източници на данни обикновено са доста големи и в инструментите, използвани за обработката им, едно от най-важните изисквания е високата скорост. В релационните бази данни информацията се съхранява в отделни таблици, които са добре нормализирани. Но сложните заявки за няколко таблици са доста бавни в тях. Значително по-добра производителност по отношение на скоростта на обработка в OLAP системите се постига поради особеностите на структурата за съхранение на данни. Цялата информация е ясно организирана и се използват два типа хранилища на данни: измервания(съдържат директории, разделени на категории, като точки за продажба, клиенти, служители, услуги и т.н.) и факти(характеризират взаимодействието на елементите различни измервания, например на 3 март 2010 г. продавач А е предоставил услуга на клиент Б в магазин C за сумата G парични единици). Мерките се използват за изчисляване на резултатите в аналитичен куб. Мерките са колекции от факти, обобщени от съответните избрани измерения и техните членове. Поради тези характеристики сложните заявки с многоизмерни данни отнемат много по-малко време от релационните източници.

Един от основните доставчици на OLAP системи е Microsoft Corporation. Нека разгледаме прилагането на принципите на OLAP, използвайки практически примери за създаване на аналитичен куб в приложенията Microsoft SQL Server Business Intelligence Development Studio (BIDS) и Microsoft Office PerformancePoint Server Planning Business Modeler (PPS) и да се запознаем с възможностите за визуално представяне на многоизмерни данни под формата на графики, диаграми и таблици.

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

Нека първо дефинираме размерите. Следните субекти (категории данни) са свързани с дейността на компанията:

• Точки за продажба
  - Служители
  - Партньори

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

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