дома › СО › Што е Олап коцка во ексел. Креирање на проект SSAS. Што е анализа и зошто е потребна?

Што е Олап коцка во ексел. Креирање на проект SSAS. Што е анализа и зошто е потребна?

Информациските системи на сериозно претпријатие, по правило, содржат апликации дизајнирани за сложена анализа на податоци, нивната динамика, трендови итн. Според тоа, врвниот менаџмент станува главен потрошувач на резултатите од анализата. Таквата анализа на крајот има за цел да го поддржи донесувањето одлуки. А за да се донесе каква било одлука за управување, неопходно е да се поседуваат потребните информации, најчесто квантитативни. За да го направите ова, неопходно е да се соберат овие податоци од сите информациски системипретпријатија, доведете ги до заеднички формат и потоа анализирајте ги. За таа цел се креираат складишта на податоци.

Што е складиште за податоци?

Обично - местото каде што се собираат сите информации од аналитичка вредност. Барањата за такви продавници одговараат на класичната дефиниција на OLAP и ќе бидат објаснети подолу.

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

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

Второ, додека традиционалните бази на податоци се предмет на постојана промена додека работат корисниците, складиштето на податоци е релативно стабилно: податоците во него обично се ажурираат според распоред (на пример, неделно, дневно или час, во зависност од потребите). Идеално, процесот на збогатување е едноставно додавање на нови податоци во одреден временски период без промена на претходните информации веќе во продавницата.

И трето, редовните бази на податоци најчесто се извор на податоци кои завршуваат во магацинот. Покрај тоа, складирањето може да се надополни со надворешни извори, на пример статистички извештаи.

Како се гради складиште?

ETL– основен концепт: Три фази:

Екстракција – извлекување податоци од надворешни извори во разбирлив формат;
Трансформација – трансформација на структурата на изворните податоци во структури погодни за градење аналитички систем;

Ајде да додадеме уште една фаза - чистење на податоци ( Чистење) – процес на филтрирање на ирелевантни или корекција на погрешни податоци врз основа на статистички или експертски методи. За да не се генерираат извештаи како „Продажба за 20011“ подоцна.

Да се вратиме на анализата.

Што е анализа и зошто е потребна?

Анализата е проучување на податоците за целите на донесување одлуки. Аналитичките системи се нарекуваат системи за поддршка на одлуки ( ДСС).

Овде вреди да се истакне разликата помеѓу работата со DSS и едноставен сет на регулирани и нерегулирани извештаи. Анализата во DSS е скоро секогаш интерактивна и итеративна. Оние. аналитичарот копа во податоците, составува и приспособува аналитички прашања и добива извештаи, чија структура можеби е однапред непозната. Ќе се вратиме на ова подетално подолу кога ќе разговараме за јазикот на барањето. MDX.

OLAP

Системите за поддршка на одлуки обично имаат средства да му обезбедат на корисникот збирни податоци за различни примероци од оригиналниот сет во форма погодна за перцепција и анализа (табели, графикони, итн.). Традиционалниот пристап за сегментирање на изворните податоци вклучува извлекување од изворните податоци една или повеќе мултидимензионални множества на податоци (често наречени хиперкоцка или метакуба), чии оски содржат атрибути, а ќелиите содржат збирни квантитативни податоци. (Таквите податоци можат да се чуваат и во релациони табели, но во овој случај станува збор за логичка организација на податоците, а не за физичка имплементација на нивното складирање.) По секоја оска, атрибутите можат да се организираат во форма на хиерархии. претставувајќи различни нивоа на нивните детали. Благодарение на овој модел на податоци, корисниците можат да формулираат сложени прашања, да генерираат извештаи и да добијат подмножества на податоци.

Технологијата за сложена повеќедимензионална анализа на податоци се нарекува OLAP (On-Line Analytical Processing). OLAP е клучна компонента на традиционалното складирање на податоци. Концептот на OLAP беше опишан во 1993 година од Едгар Код, познат истражувач на бази на податоци и автор на моделот на релациони податоци. Во 1995 година, врз основа на барањата поставени од Код, беше формулиран таканаречениот тест FASMI (Брза анализа на споделени повеќедимензионални информации), вклучувајќи ги следните барања за апликации за повеќедимензионална анализа:

обезбедување на корисникот со резултатите од анализата во прифатливо време (обично не повеќе од 5 секунди), дури и по цена на помалку детална анализа;
способноста да се спроведе каква било логичка и статистичка анализа карактеристична за оваа апликација, и зачувување во форма достапна за крајниот корисник;
повеќекориснички пристап до податоци со поддршка за соодветни механизми за заклучување и овластени средства за пристап;
повеќедимензионално концептуално претставување на податоци, вклучувајќи целосна поддршказа хиерархии и повеќекратни хиерархии (ова е клучен услов на OLAP);
можност за пристап до сите потребни информации, без оглед на нејзиниот волумен и локацијата на складирање.

Треба да се напомене дека функционалноста на OLAP може да се имплементира различни начини, почнувајќи од наједноставните алатки за анализа на податоци во канцелариски апликации и завршувајќи со дистрибуирани аналитички системи базирани на производи на сервери. Оние. OLAP не е технологија, но идеологијата.

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

Повеќедимензионални концепти

Ќе ја користиме базата на податоци Northwind вклучена во Microsoft за да ги илустрираме принципите на OLAP. SQL Serverи која е типична база на податоци што чува информации за трговските операции на компанија која се занимава со снабдување на големо со храна. Таквите податоци вклучуваат информации за добавувачите, клиентите, списокот на испорачаните стоки и нивните категории, податоци за нарачките и нарачаните стоки, списокот на вработени во компанијата.

Коцка

Да ја земеме на пример табелата Фактури1, која ги содржи нарачките на компанијата. Полињата во оваа табела ќе бидат како што следува:

Датум на нарачка
Земја
Градот
Име на клиентот
Компанија за испорака
Име на производ
Количина на стоки
Цена за нарачка

Кои збирни податоци можеме да ги добиеме од овој поглед? Обично ова се одговори на прашања како што се:

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

Сите овие податоци може да се добијат од оваа табела користејќи сосема очигледни SQL барања со групирање.

Резултатот од ова барање секогаш ќе биде колона со броеви и листа на атрибути што го опишуваат (на пример, земја) - ова е еднодимензионално збир на податоци или, на математички јазик, вектор.

Да замислиме дека треба да добиеме информации за вкупните трошоци на нарачките од сите земји и нивната дистрибуција меѓу компаниите за испорака - ќе добиеме табела (матрица) на броеви, каде што компаниите за испорака ќе бидат наведени во насловите на колоните, земји во редот наслови, а во ќелиите ќе има количина на нарачки. Ова е дводимензионална низа со податоци. Овој сет на податоци се нарекува стожерна табела ( стожерна табела) или вкрстено јазиче.

Доколку сакаме да ги добиеме истите податоци, но и по година, тогаш ќе се појави друга промена, т.е. множеството податоци ќе стане тридимензионално (условен тензор од трет ред или 3-димензионална „коцка“).

Очигледно, максималниот број на димензии е бројот на сите атрибути (Датум, земја, клиент итн.) кои ги опишуваат нашите збирни податоци (количина на нарачки, број на производи итн.).

Така доаѓаме до концептот на мултидимензионалност и неговото олицетворение - повеќедимензионална коцка. Таква табела ќе ја наречеме “ табела со факти" Димензии или коцкасти оски ( димензии) се атрибути чии координати се изразени со поединечните вредности на овие атрибути присутни во табелата со факти. Оние. на пример, ако информациите за нарачките се одржувале во системот од 2003 до 2010 година, тогаш оваа година оската ќе се состои од 8 соодветни точки. Ако нарачките доаѓаат од три земји, тогаш оската на земјата ќе содржи 3 точки, итн. Без оглед на тоа колку земји се вклучени во директориумот Земја. Точките на оската се нарекуваат нејзини „членови“ ( Членови).

Во овој случај, самите збирни податоци ќе се нарекуваат „мерки“ ( Мерка). За да се избегне забуна со „димензиите“, вторите по можност се нарекуваат „оски“. Збирката мерки формира друга оска „Мерки“ ( Мерки). Има онолку членови (поени) колку што има мерки (збирни колони) во табелата со факти.

Членовите на димензиите или оските може да се комбинираат со една или повеќе хиерархии ( хиерархија). Дозволете ни да објасниме што е хиерархија со пример: градовите од редови може да се обединат во области, области во региони, региони на една земја, земји во континенти или други ентитети. Оние. постои хиерархиска структура - континент- земја-регион-област-град- 5 нивоа ( Ниво). За регион, податоците се собираат за сите градови кои се вклучени во него. За регион низ сите области кои ги содржат сите градови итн. Зошто ни се потребни повеќе хиерархии? На пример, на оската за датум на редослед можеби ќе сакаме да групираме точки (т.е. денови) во хиерархија Година-месец-денили од страна на Година-недела-ден: и во двата случаи има три нивоа. Очигледно, неделата и месецот ги групираат деновите поинаку. Има и хиерархии, чиј број на нивоа не е детерминистички и зависи од податоците. На пример, папки на компјутерски диск.

Агрегација на податоци може да се случи со користење на неколку стандардни функции: збир, минимум, максимум, просек, броење.

MDX

Ајде да преминеме на јазикот за пребарување во повеќедимензионални податоци.
Јазикот SQL првично беше дизајниран не за програмери, туку за аналитичари (и затоа има синтакса што наликува на природен јазик). Но, со текот на времето стануваше сè покомплицирано и сега малку аналитичари знаат како добро да го користат, ако воопшто и воопшто. Таа стана алатка за програмери. Јазикот за прашања MDX, за кој се шпекулира дека е развиен од нашиот поранешен сонародник Моша (или Моша) Посумански во дивините на Мајкрософт, исто така првично беше наменет да биде насочен кон аналитичарите, но неговите концепти и синтакса (што нејасно потсетува на SQL, и сосема залудно, т.е. затоа што само збунува), дури и покомплицирано од SQL. Сепак, неговите основи сè уште се лесно разбирливи.

Ќе го разгледаме детално затоа што е единствениот јазик што доби стандарден статус во рамките на општиот стандард за протокол XMLA, и второ затоа што има имплементација со отворен код во форма на проектот Mondrian од компанијата. Пентахо. Другите системи за анализа на OLAP (на пример, Oracle OLAP Option) обично користат свои екстензии на синтаксата SQL, но тие исто така објавуваат поддршка за MDX.

Работата со збирки на аналитички податоци значи само читање и не значи нивно пишување. Тоа. MDX нема клаузули за промена на податоци, туку само една изборна клаузула - изберете.

Во OLAP можете да направите повеќедимензионални коцки парчиња– т.е. кога податоците се филтрираат по една или повеќе оски, или проекции– кога коцката „се сруши“ по една или повеќе оски, собирајќи податоци. На пример, нашиот прв пример со количината на нарачки од земјите е проекција на коцката на оската на земјата. Барањето MDX за овој случај ќе изгледа вака:

Изберете ...Деца на редови од
Што има тука?

Изберете– клучниот збор е вклучен во синтаксата исклучиво за убавина.
е името на оската. Сите соодветни имиња во MDX се напишани во квадратни загради.
е името на хиерархијата. Во нашиот случај, ова е хиерархија земја-град
– ова е името на членот на оската на првото ниво на хиерархијата (т.е. земја) Сите – ова е мета-член што ги обединува сите членови на оската. Во секоја оска има таков мета-поим. На пример, во годишната оска има „Сите години“ итн.
Децае членска функција. Секој член има неколку функции на располагање. Како родител. Ниво, Хиерархија, враќајќи ги соодветно предокот, нивото во хиерархијата и самата хиерархија на која членот припаѓа во овој случај. Деца - враќа збир на деца членови на овој член. Оние. во нашиот случај – земји.
на редови– Покажува како да се подредат овие податоци во добиената табела. Во овој случај - во заглавието на линиите. Можни вредности овде: на колони, на страници, на пасуси итн. Исто така, можно е едноставно да се означи по индекс, почнувајќи од 0.
од– ова е показател за коцката од која се прави изборот.

Што ако не ни требаат сите земји, туку само неколку специфични? За да го направите ова, можеме експлицитно во барањето да ги наведеме земјите што ни се потребни, наместо да избираме сè со помош на функцијата Деца.

Изберете ( ..., ... ) на редовите од
Кадравите загради во овој случај се декларација на сетот ( Поставете). Комплет е листа, набројување на членови од една оска.

Сега да напишеме барање за нашиот втор пример - излез во контекст на лице за испорака:

Изберете ...Деца на редови .Членови на колони од
Додадено овде:
– оска;
.Членови– функција на оска која ги враќа сите термини на неа. Хиерархијата и нивото имаат иста функција. Бидејќи Во оваа оска има само една хиерархија, тогаш нејзината ознака може да се изостави, бидејќи нивото и хиерархијата се исто така исти, тогаш можете да ги прикажете сите членови во една листа.

Мислам дека веќе е очигледно како можеме да го продолжиме ова со нашиот трет пример со детали по година. Но, подобро да не дупчеме по година, туку да филтрираме - т.е. изгради парче За да го направите ова, ќе го напишеме следново барање:

Изберете ..Деца на редови .Членови на колони од каде (.)
Каде е тука филтрацијата?

каде- клучен збор
е еден член на хиерархијата . Целосното име, вклучувајќи ги сите термини, би било: .. , но затоа што Бидејќи името на овој член е единствено во рамките на оската, сите посредни појаснувања на името може да се изостават.

Зошто терминот датум е во заграда? Заградите се торка ( торка). Топка е една или повеќе координати заедно различнисекири На пример, за филтрирање по две оски одеднаш, во загради наведуваме два члена од различнимерења одделени со запирки. Односно, торката дефинира „парче“ од коцката (или „филтрирање“, ако таквата терминологија е поблиска).

Торката се користи за повеќе од само филтрирање. Топките може да бидат и во заглавија на редови/колони/страници, итн.

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

Изберете вкрстено спојување(...Деца, ..Деца) на редовите .Членови на колони од каде (.)
Вкрстено спојувањее функција. Враќа множество торки (да, множеството може да содржи торки!) кои произлегуваат од Декартовиот производ од две множества. Оние. добиениот сет ќе ги содржи сите можни комбинации на земји и години. Така, заглавијата на редовите ќе содржат пар вредности: Земја-година.

Прашањето е, каде е ознаката за тоа кои нумерички карактеристики треба да се прикажат? Во овој случај се користи стандардната мерка дефинирана за оваа коцка, т.е. Цена за нарачка. Ако сакаме да изведеме друга мерка, тогаш се сеќаваме дека мерките се членови на димензија Мерки. И ние постапуваме на ист начин како и со другите оски. Оние. филтрирањето на барањето по една од мерките ќе ја прикаже токму оваа мерка во ќелиите.

Прашање: Која е разликата помеѓу филтрирање во каде и филтрирање со наведување на членовите на оската во редовите. Одговор: практично ништо. Едноставно каде што е означено парче за оние оски кои не учествуваат во формирањето на насловите. Оние. истата оска не можебидете присутни во исто време на редови, и во каде.

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

Повеќе сложени прашањаМожете да прогласите пресметани членови. Членови и на оските на атрибутот и мерката. Оние. Можете да пријавите, на пример, нова мерка која ќе го прикаже придонесот на секоја земја во вкупниот износ на нарачки:

Со член. како '.CurrentMember / ..', FORMAT_STRING='0,00%' изберете ...Деца на редови од каде .
Пресметката се случува во контекст на ќелија во која се познати сите нејзини координатни атрибути. Соодветните координати (членови) може да се добијат со функцијата CurrentMember за секоја од оските на коцката. Тука мора да разбереме дека изразот .Тековен член/..“ не дели еден поим со друг, туку дели релевантни збирни податоцикоцки парчиња! Оние. парчето за сегашната територија ќе биде поделено на парче за сите територии, т.е. вкупната вредност на сите нарачки. FORMAT_STRING – го поставува форматот за прикажување на вредностите, т.е. %.

Друг пример на пресметан член, но на оската години:

Со член. како '. -.'
Очигледно, извештајот нема да содржи единица, туку разликата на соодветните делови, т.е. разликата во износот на нарачките во овие две години.

Прикажи во ROLAP

Системите OLAP се на еден или друг начин засновани на некој вид систем за складирање и организација на податоци. Кога ние зборуваме заза RDBMS, потоа зборуваат за ROLAP (ќе ги оставиме MOLAP и HOLAP за самостојно учење). ROLAP – OLAP на релациона база на податоци, т.е. опишани во форма на обични дводимензионални табели. ROLAP системите конвертираат MDX барања во SQL. Главниот компјутерски проблем за базите на податоци е брзата агрегација. За да се агрегираат побрзо, податоците во базата обично се многу денормализирани, т.е. не се чуваат многу ефикасно во однос на зафатениот простор на дискот и следењето на интегритетот на базата на податоци. Плус тие дополнително содржат помошни табели кои складираат делумно собрани податоци. Затоа, за OLAP, обично се креира посебна шема на база на податоци, која само делумно ја реплицира структурата на оригиналните трансакциски бази на податоци во однос на директориумите.

Навигација

Многу OLAP системи нудат интерактивни алатки за навигација за веќе генерирано барање (и соодветно избрани податоци). Во овој случај, се користи таканареченото „дупчење“ или „дупчење“. Поадекватен превод на руски би бил зборот „продлабочување“. Но, ова е прашање на вкус, во некои средини зборот „дупчење“ се заглавил.

Дупчалка– ова е детално известување со намалување на степенот на агрегација на податоци, во комбинација со филтрирање по некоја друга оска (или неколку оски). Постојат неколку видови на дупчење:

вежба надолу– филтрирање по една од изворните оски на извештајот со прикажување на детални информации за потомците во хиерархијата на избраниот член за филтрирање. На пример, ако има извештај за распределбата на нарачките поделени по земји и години, тогаш со кликнување на 2007 година ќе се прикаже извештај расчленат по истите земји и месеци од 2007 година.
дупчалка– филтрирање под една или повеќе избрани оски и отстранување на агрегација по една или повеќе други оски. На пример, ако има извештај за распределбата на нарачките поделени по земји и години, тогаш со кликнување на 2007 година ќе се прикаже друг извештај поделен, на пример, по земји и добавувачи со филтрирање до 2007 година.
дупчалка– отстранување на агрегација по сите оски и истовремено филтрирање по нив – ви овозможува да ги видите изворните податоци од табелата со факти од која е добиена вредноста во извештајот. Оние. Кога ќе кликнете на вредноста на ќелијата, се прикажува извештај со сите нарачки што ја дале оваа сума. Еден вид инстант дупчење во самите „длабочини“ на коцката.

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

Ознаки: Додадете ознаки

Јас сум жител на Хабр веќе подолго време, но никогаш не сум читал написи на тема мултидимензионални коцки, OLAP и MDX, иако темата е многу интересна и секој ден станува се поактуелна.
Не е тајна дека во тој краток временски период на развој на бази на податоци, електронско сметководство и онлајн системи, се акумулираа многу податоци. Сега, од интерес е и целосна анализа на архивите, а можеби и обид да се предвидат ситуации за слични модели во иднина.
Од друга страна, големите компании, дури и во текот на неколку години, месеци или дури недели, можат да акумулираат толку големи количини на податоци што дури и нивната основна анализа бара извонредни пристапи и строги хардверски барања. Тоа може да бидат системи за обработка на банкарски трансакции, агенти за размена, телефонски операториитн.
Мислам дека сите се добро запознаени со 2 различни пристапи за дизајнирање на бази на податоци: OLTP и OLAP. Првиот пристап (Онлајн обработка на трансакции - обработка на трансакции во реално време) е дизајниран за ефикасно собирање податоци во реално време, додека вториот (Онлајн аналитичка обработка - аналитичка обработка во реално време) е насочен конкретно на земање примероци и обработка на податоци во најефикасно начин.

Ајде да ги погледнеме главните способности на модерните OLAP коцки и кои проблеми ги решаваат (Анализа Услуги 2005/2008 се земени како основа):

брз пристапна податоци
предагрегација
хиерархија
работејќи со времето
повеќедимензионален јазик за пристап до податоци
KPI (Клучни индикатори за изведба)
датум рударството
кеширање на повеќе нивоа
повеќејазична поддршка

Значи, да ги погледнеме можностите на OLAP коцките малку подетално.

Малку повеќе за можностите

Брз пристап до податоци
Всушност, брзиот пристап до податоците, без оглед на големината на низата, е основата на OLAP системите. Бидејќи ова е главниот фокус, складиштето на податоци обично се гради на принципи различни од оние на релационите бази на податоци.
Овде, времето за преземање едноставни податоци се мери во делови од секундата, а барањето кое надминува неколку секунди најверојатно бара оптимизација.

Преагрегација
Покрај брзото враќање на постоечките податоци, тој исто така обезбедува можност за преагрегирање на вредностите „најверојатно да се користат“. На пример, ако имаме дневна евиденција за продажба на одреден производ, системот МожебиИсто така, можеме да ги собереме месечните и кварталните износи на продажба, што значи дека ако бараме податоци месечно или квартално, системот веднаш ќе ни го даде резултатот. Зошто не секогаш се случува предагрегација?Бидејќи теоретски можни комбинации на стоки/време/итн. може да има огромен број, што значи дека треба да имате јасни правила за кои елементи ќе се гради агрегацијата, а за кои не. Генерално, темата за земање предвид на овие правила и вистинскиот дизајн на агрегациите е доста обемна и заслужува посебна статија сама по себе.

Хиерархии
Природно е дека кога се анализираат податоците и се конструираат конечни извештаи, треба да се земе предвид фактот дека месеците се состојат од денови, а тие самите формираат четвртини, а градовите се вклучени во области, кои пак се дел од региони или земји. . Добрата вест е тоа OLAP коцкипрвично тие ги разгледуваат податоците од гледна точка на хиерархии и односи со други параметри на истиот ентитет, така што градењето и користењето хиерархии во коцки е многу едноставна работа.

Работа со времето
Бидејќи анализата на податоците главно се одвива во временски области, на времето му се придава посебно значење во OLAP системите, што значи дека со едноставно дефинирање за системот каде што имаме време овде, во иднина лесно можете да користите функции како година до датум, месец до датум (периодот од почетокот на годината/месецот до тековниот датум), паралелен период (во истиот ден или месец, но минатата година) итн.

Јазик за повеќедимензионален пристап до податоци
MDX(Мултидимензионални изрази) - јазик за прашања за едноставен и ефикасен пристап до повеќедимензионални структури на податоци. И тоа кажува сè - ќе има неколку примери подолу.

Клучни показатели за изведба (KPI)
Клучни индикаторие финансиски и нефинансиски мерен систем кој и помага на организацијата да го одреди постигнувањето на стратешките цели. Клучните показатели за изведба можат едноставно да се дефинираат во OLAP системите и да се користат во извештаите.

Датум на рударство
Рударство на податоци(Data Mining) - во суштина, идентификување скриени обрасци или односи помеѓу променливите во големи збирки податоци.
Англискиот термин „Data Mining“ нема недвосмислен превод на руски (копирање податоци, рударство на податоци, рударство информации, екстракција на податоци/информации) затоа во повеќето случаи се користи во оригиналот. Најуспешниот индиректен превод е терминот „копање податоци“ (DMA). Сепак, ова е посебна, не помалку интересна тема за разгледување.

Кеширање на повеќе нивоа
Всушност, за да се обезбеди најголема брзина на пристап до податоци, покрај незгодните структури на податоци и предагрегации, OLAP системите поддржуваат кеширање на повеќе нивоа. Покрај кеширањето едноставни прашања, делови од податоците прочитани од продавницата, збирните вредности и пресметаните вредности исто така се кешираат. Така, колку подолго работите со OLAP коцка, толку побрзо таа, всушност, почнува да работи. Постои и концепт на „загревање на кешот“ - операција која го подготвува системот OLAP за работа со специфични извештаи, прашања или сите комбинирани.

Повеќејазична поддршка
Да да да. Најмалку, Analysis Services 2005/2008 (иако Enterprise Edition) природно поддржува повеќејазичност. Доволно е да обезбедите превод на параметрите на стрингот на вашите податоци, а клиентот кој го навел својот јазик ќе добие локализирани податоци.

Повеќедимензионални коцки

Значи, што точно се овие повеќедимензионални коцки?
Ајде да замислиме 3-димензионален простор чиишто оски се Времето, Производите и Клиентите.
Точка на таков простор ќе укаже на фактот дека некој од купувачите купил одреден производ во одреден месец.

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

Малку MDX

Значи, која е убавината на MDX? Најверојатно, не треба да опишеме како сакаме да избираме податоци, туку Што точноние сакаме.
На пример,

ИЗБЕРИ
( . ) НА КОЛОНИ,
( ., . ) НА РЕДИТЕ
ОД
КАДЕ (., .)

Што значи дека го сакам бројот на продадени iPhone-и во јуни и јули во Мозамбик.
Во исто време опишувам коиова се податоците што ги сакам и КакоСакам да ги видам во извештајот.
Прекрасно, нели?

Еве малку покомплицирано:

СО ЧЛЕН Просечно трошење AS
. / .
ИЗБЕРИ
( Просечно трошење ) НА КОЛОНИ,
( .., .. ) НА РЕДИТЕ
ОД
КАДЕ (.)
* Овој изворен код беше означен со Истакнувачот на изворниот код.

Всушност, прво ја одредуваме формулата за пресметување на „просечната големина на купување“ и се обидуваме да споредиме кој (кој пол) троши повеќе пари при една посета на продавницата на Apple.

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

Заклучок

Всушност, овој напис опфаќа многу малку дури и основни концепти; јас би го нарекол „мезе“ - можност да се заинтересира заедницата Хабра за оваа тема и да се развие понатаму. Што се однесува до развојот, тука има огромно неорано поле и со задоволство ќе одговорам на сите ваши прашања.

П.С.Ова е мојот прв пост за OLAP и првата публикација на Habré - би бил многу благодарен за конструктивните повратни информации.
Ажурирање:Го префрлив на SQL, ќе го префрлам на OLAP штом ми дозволат да креирам нови блогови.

Ознаки: Додадете ознаки

Како дел од оваа работа, ќе се разгледаат следниве прашања:

Што се OLAP коцките?
Што се мерки, димензии, хиерархии?
Какви видови операции може да се извршат на OLAP коцките?

Концептот на OLAP коцка

Главниот постулат на OLAP е мултидимензионалноста во презентацијата на податоците. Во терминологијата OLAP, концептот на коцка, или хиперкоцка, се користи за да се опише повеќедимензионален дискретен простор за податоци.

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

Податоци- ова се податоци за предмети и настани во компанијата кои ќе бидат предмет на анализа. Факти од ист тип формираат мерки. Мерката е тип на вредност во ќелија со коцка.

Мерења- тоа се податочните елементи со кои се анализираат фактите. Збирката од такви елементи формира атрибут за димензија (на пример, деновите во неделата може да формираат атрибут за временска димензија). Во задачите за деловна анализа за комерцијалните претпријатија, димензиите често вклучуваат категории како што се „време“, „продажба“, „производи“, „клиенти“, „вработени“, „географска локација“. Мерењата се најчесто хиерархиски структури, кои се логички категории со кои корисникот може да ги анализира вистинските податоци. Секоја хиерархија може да има едно или повеќе нивоа. Така, хиерархијата на димензијата „географска локација“ може да ги вклучува нивоата: „земја - регион - град“. Во временската хиерархија, можеме да ја разликуваме, на пример, следната низа на нивоа: Една димензија може да има неколку хиерархии (секоја хиерархија на една димензија мора да го има истиот клучен атрибут на табелата со димензии).

Коцката може да содржи вистински податоци од една или повеќе табели со факти и најчесто содржи повеќе димензии. Секоја дадена коцка обично има специфичен фокус за анализа.

Слика 1 покажува пример на коцка дизајнирана да ја анализира продажбата на нафтени деривати од одредена компанија по регион. Оваа коцка има три димензии (време, производ и регион) и една мерка (продажен волумен изразен во пари). Мерните вредности се зачувуваат во соодветните ќелии на коцката. Секоја клетка е уникатно идентификувана со збир на членови од секоја димензија, наречена торка. На пример, ќелијата сместена во долниот лев агол на коцката (содржи вредност 98399 $) е специфицирана со торката [јули 2005, Далечен Исток, Дизел]. Овде вредноста од 98.399 долари го покажува обемот на продажба (во монетарна смисла) на дизелот на Далечниот Исток за јули 2005 година.

Исто така, вреди да се напомене дека некои ќелии не содржат никакви вредности: овие ќелии се празни бидејќи табелата со факти не содржи податоци за нив.

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

Крајната цел на создавањето на такви коцки е да се минимизира времето на обработка на барањата кои ги извлекуваат бараните информации од вистинските податоци. За да се постигне оваа задача, коцките обично содржат претходно пресметани збирови наречени агрегации(агрегации). Оние. коцката покрива простор за податоци поголем од вистинскиот - во него има логични, пресметани точки. Функциите за агрегација ви овозможуваат да ги пресметате вредностите на точките во логичкиот простор врз основа на вистинските вредности. Наједноставните функции за собирање се SUM, MAX, MIN, COUNT. Така, на пример, користејќи ја функцијата MAX, за коцката дадена во примерот, можете да идентификувате кога се случил врвот во продажбата на дизелот на Далечниот Исток, итн.

Друга специфична карактеристика на повеќедимензионалните коцки е тешкотијата да се одреди потеклото. На пример, како ја поставувате точката 0 за димензијата Производ или региони? Решението за овој проблем е да се воведе посебен атрибут кој ги комбинира сите елементи на димензијата. Овој атрибут (создаден автоматски) содржи само еден елемент - Сите. За едноставни функции за собирање, како што е збир, елементот Сите е еквивалентен на збирот на вредностите на сите елементи во вистинскиот простор на дадена димензија.

Важен концепт во мултидимензионалниот модел на податоци е потпросторот или подкоцката. Подкоцка е дел од целосниот простор на коцката во форма на некоја повеќедимензионална фигура во внатрешноста на коцката. Бидејќи повеќедимензионалниот простор на коцката е дискретен и ограничен, подкоцката е исто така дискретна и ограничена.

Операции на OLAP коцки

Следниве операции може да се извршат на OLAP коцка:

парче;
ротација;
консолидација;
детализирање.

Парче(Слика 2) е посебен случај на подкоцка. Ова е постапка за формирање подмножество од повеќедимензионална податочна низа што одговара на една вредност на една или повеќе димензионални елементи кои не се вклучени во ова подмножество. На пример, за да дознаете како напредувала продажбата на нафтени деривати со текот на времето само во одреден регион, имено во Урал, треба да ја поправите димензијата „Производи“ на елементот „Урал“ и да го извлечете соодветното подмножество (поткоцка) од коцка.

Ориз. 2.Парче коцка OLAP

Ротација(Слика 3) - операција за промена на локацијата на мерењата претставени во извештај или на прикажаната страница. На пример, операцијата за ротација може да вклучи преуредување на редовите и колоните од табелата. Дополнително, ротирањето на коцка за податоци ги поместува димензиите надвор од табеларно на своето место со димензии присутни на прикажаната страница, и обратно.

Во принцип, секој специјалист знае што е OLAP денес. Барем концептите на „OLAP“ и „мултидимензионални податоци“ се цврсто поврзани во нашите умови. Сепак, фактот што оваа тема повторно се покренува, се надевам дека ќе биде одобрена од мнозинството читатели, бидејќи за да не застари идејата со текот на времето, треба периодично да комуницирате со паметни луѓеили читајте статии во добра публикација...

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

Терминот „OLAP“ е нераскинливо поврзан со терминот „складиште на податоци“ (Data Warehouse).

Еве ја дефиницијата формулирана од „основачот“ на складирањето податоци, Бил Инмон: „Складиште на податоци е специфична за домен, временски ограничена, непроменлива збирка на податоци за поддршка на одлучувањето за управувањето“.

Податоците во магацинот доаѓаат од оперативните системи (OLTP системи), кои се дизајнирани да ги автоматизираат деловните процеси. Дополнително, складиштето може да се надополнува од надворешни извори, како што се статистички извештаи.

Зошто да се градат складишта за податоци - на крајот на краиштата, тие содржат очигледно непотребни информации што веќе „живеат“ во бази на податоци или датотеки на оперативниот систем? Одговорот може да биде краток: невозможно е или многу тешко директно да се анализираат податоците од оперативните системи. Ова се должи на различни причини, вклучувајќи ја фрагментацијата на податоците, нивното складирање во различни формати на DBMS и во различни „агли“ корпоративна мрежа. Но, дури и ако претпријатието ги складира сите свои податоци на сервер за централна база на податоци (што е исклучително ретко), аналитичарот речиси сигурно нема да ги разбере нивните сложени, понекогаш збунувачки структури. Авторот има доста тажно искуство во обидот да ги „храни“ гладните аналитичари со „суровини“ податоци од оперативните системи - се покажа дека е „премногу за нив“.

Така, целта на складиштето е да обезбеди „суровини“ за анализа на едно место и во едноставна, разбирлива структура. Ралф Кимбал, во предговорот на својата книга „The Data Warehouse Toolkit“, пишува дека ако читателот по читањето на целата книга разбере само една работа - имено, дека структурата на складиштето треба да биде едноставна - авторот ќе ја земе предвид неговата завршена задача.

Постои уште една причина што го оправдува појавувањето на посебно складиште - сложени аналитички прашања до оперативни информацииуспори тековна работакомпании, блокирање табели долго време и запленување ресурси на серверот.

Според мое мислење, складиштето не мора да значи огромна акумулација на податоци - главната работа е што е погодно за анализа. Општо земено, постои посебен термин за мали капацитети за складирање - Data Marts (киосци со податоци), но во нашата руска практика не го слушате често.

OLAP - удобна алатка за анализа

Централизацијата и практичното структурирање не се сè што му треба на аналитичарот. Тој сè уште има потреба од алатка за гледање и визуелизирање информации. На традиционалните извештаи, дури и на оние изградени на едно складиште, им недостасува едно нешто - флексибилност. Тие не можат да бидат „извртени“, „проширени“ или „срушени“ за да се добие посакуваниот приказ на податоците. Се разбира, можете да повикате програмер (ако сака да дојде), а тој (ако не е зафатен) ќе направи нов извештај доволно брзо - да речете, во рок од еден час (ова го пишувам и не верувам тоа сам - тоа не се случува толку брзо во животот; ајде да му дадеме три часа). Излегува дека аналитичарот може да тестира не повеќе од две идеи дневно. И тој (ако е добар аналитичар) може да излезе со неколку такви идеи на час. И колку повеќе „парчиња“ и „делови“ од податоци гледа аналитичарот, толку повеќе идеи има, кои, пак, бараат се повеќе и повеќе „парчиња“ за проверка. Ако само тој имаше алатка која ќе му овозможи да ги прошири и колабира податоците едноставно и удобно! OLAP делува како таква алатка.

Иако OLAP не е неопходен атрибут на складиштето на податоци, тој се повеќе се користи за анализа на информациите акумулирани во складиштето.

Компонентите вклучени во типично складиште се прикажани на сл. 1.

Ориз. 1. Структура на складиште на податоци

Оперативните податоци се собираат од различни извори, се чистат, интегрираат и се складираат во релациона продавница. Покрај тоа, тие се веќе достапни за анализа со користење на различни алатки за известување. Потоа податоците (целосно или делумно) се подготвуваат за OLAP анализа. Тие можат да се вчитаат во специјална база на податоци OLAP или да се складираат во релациона складирање. Нејзиниот најважен елемент се метаподатоците, односно информации за структурата, поставеноста и трансформацијата на податоците. Благодарение на нив, се обезбедува ефективна интеракција на различни компоненти за складирање.

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

Дефиниција и основни концепти на OLAP

Прво, ајде да дешифрираме: OLAP е онлајн аналитичка обработка, т.е. оперативна анализа на податоци. 12-те дефинирачки принципи на OLAP беа формулирани во 1993 година од E. F. Codd, „пронаоѓачот“ на релационите бази на податоци. Подоцна, нејзината дефиниција беше преработена во таканаречениот тест FASMI, кој бара апликацијата OLAP да обезбеди можност за брзо анализирање на споделени повеќедимензионални информации ().

Тест FASMI

Брзо(Брзо) - анализата треба да се изврши подеднакво брзо на сите аспекти на информациите. Прифатливото време на одговор е 5 секунди или помалку.

Анализа(Анализа) - мора да биде можно да се спроведат основни типови на нумеричка и статистичка анализа, претходно дефинирани од развивачот на апликацијата или слободно дефинирани од корисникот.

Споделено(Споделено) - многу корисници мора да имаат пристап до податоците, додека е неопходно да се контролира пристапот до доверливи информации.

Повеќедимензионални(Мултидимензионална) е главната, најсуштинската карактеристика на OLAP.

Информации(Информации) - апликацијата мора да има пристап до сите потребни информации, без оглед на нејзиниот волумен и локацијата на складирање.

OLAP = Повеќедимензионален приказ = коцка

OLAP обезбедува практично, брзо средство за пристап, прегледување и анализа на деловни информации. Корисникот добива природен, интуитивен модел на податоци, организирајќи ги во форма на повеќедимензионални коцки (Коцки). Оските на повеќедимензионалниот координатен систем се главните атрибути на анализираниот деловен процес. На пример, за продажба може да биде производ, регион, тип на купувач. Времето се користи како една од димензиите. На пресеците на оските - димензии (Димензии) - има податоци кои квантитативно го карактеризираат процесот - мерки (Мерки). Ова може да биде обем на продажба на парчиња или во пари, салда на акции, трошоци итн. Корисникот што ги анализира информациите може да ја „пресече“ коцката на различни насоки, добиваат резиме (на пример, по година) или, обратно, детални (по седмици) информации и вршат други манипулации што ќе му паднат на ум во текот на процесот на анализа.

Како мерки во тродимензионалната коцка прикажана на сл. 2, се користат продажните износи, а како димензии се користат времето, производот и продавницата. Мерењата се претставени на одредени нивоа на групирање: производите се групирани по категорија, продавници по земја и податоци за времето на трансакции по месеци. Малку подоцна подетално ќе ги разгледаме нивоата на групирање (хиерархија).

Ориз. 2. Пример со коцка

„Сечење“ на коцка

Дури и тридимензионална коцка е тешко да се прикаже на компјутерски екран, така што вредностите на мерките од интерес се видливи. Што можеме да кажеме за коцките со повеќе од три димензии? За да се визуелизираат податоците зачувани во коцка, по правило, се користат познати дводимензионални, т.е., табеларни, погледи со сложени хиерархиски наслови на редови и колони.

Дводимензионална претстава на коцка може да се добие со „сечење“ на една или повеќе оски (димензии): ги поправаме вредностите на сите димензии освен две и добиваме редовна дводимензионална табела. Хоризонталната оска на табелата (заглавија на колоните) претставува една димензија, вертикалната оска (заглавија на редови) претставува друга, а ќелиите на табелата ги претставуваат вредностите на мерките. Во овој случај, збир на мерки всушност се смета како една од димензиите - ние или избираме една мерка за прикажување (и потоа можеме да поставиме две димензии во насловите на редовите и колоните), или покажуваме неколку мерки (а потоа една од оските на табелата ќе бидат окупирани од имињата на мерките, а другите - вредностите на единствената „неотсечена“ димензија).

Погледнете го сл. 3 - тука е дводимензионално парче од коцката за една мерка - Продажба на единици (продадени парчиња) и две „неотсечени“ димензии - Продавница (Продавница) и Време (Време).

Ориз. 3. Парче 2Д коцка за една мерка

На сл. Слика 4 покажува само една „неотсечена“ димензија - Продавница, но ги прикажува вредностите на неколку мерки - Продажба на единица (продадени единици), Продажба во продавница (продажен износ) и Трошоци за продавница (трошоци на продавницата).

Ориз. 4. 2D парче коцка за повеќе мерки

Можно е и дводимензионално претставување на коцка кога повеќе од две димензии остануваат „неотсечени“. Во овој случај, две или повеќе димензии на „сечената“ коцка ќе се постават на оските на парчињата (редови и колони) - види Сл. 5.

Ориз. 5. 2D парче коцка со повеќе димензии на една оска

Тагови

Вредностите „поставени“ по димензиите се нарекуваат членови или етикети. Етикетите се користат и за „сечење“ на коцката и за ограничување (филтрирање) на избраните податоци - кога во димензија што останува „неотсечена“ не нè интересираат сите вредности, туку подмножество од нив, на пример, три града од неколку десетици. Вредностите на етикетите се појавуваат во приказот на 2D коцки како наслови на редови и колони.

Хиерархии и нивоа

Етикетите може да се комбинираат во хиерархии составени од едно или повеќе нивоа. На пример, етикетите на димензијата Продавница се природно групирани во хиерархија со нивоа:

Земја

држава

Градот

Продавница.

Збирните вредности се пресметуваат според нивоата на хиерархија, на пример обемот на продажба за САД (ниво „земја“) или за Калифорнија (ниво „држава“). Можно е да се имплементираат повеќе од една хиерархија во една димензија - да речеме, за време: (Година, четвртина, месец, ден) и (година, недела, ден).

Архитектура на OLAP апликации

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

Мултидимензионалноста во OLAP апликациите може да се подели на три нивоа:

Мултидимензионално претставување на податоци - алатки за крајни корисници кои обезбедуваат повеќедимензионална визуелизација и манипулација со податоците; Слој повеќедимензионално претставувањеапстрахира од физичката структура на податоците и ги перцепира податоците како повеќедимензионални.
Повеќедимензионална обработка - алатка (јазик) за формулирање на повеќедимензионални барања (традиционална релациона SQL јазиксе покажува дека е несоодветен овде) и процесор способен за обработка и извршување на такво барање.
Повеќедимензионалното складирање е средство за физичко организирање на податоците што обезбедува ефикасно извршување на повеќедимензионални барања.

Првите две нивоа се задолжителни во сите OLAP алатки. Третото ниво, иако е широко распространето, не е неопходно, бидејќи податоците за повеќедимензионално претставување може да се извлечат од обичните релациони структури; Повеќедимензионалниот процесор за пребарување во овој случај ги преведува повеќедимензионалните барања во SQL прашања кои се извршуваат од релацискиот DBMS.

Специфичните OLAP производи, по правило, се или мултидимензионална алатка за претставување податоци, OLAP клиент (на пример, Pivot Tables во Excel 2000 од Microsoft или ProClarity од Knosys), или мултидимензионален сервер DBMS, OLAP сервер (на пример, Oracle Експрес сервер или услуги на Microsoft OLAP).

Повеќедимензионалниот слој за обработка обично се вградува во клиентот OLAP и/или OLAP серверот, но може да се изолира во неговата чиста форма, како што е компонентата на услугата Pivot Table Service на Microsoft.

Технички аспекти на повеќедимензионално складирање на податоци

Како што споменавме погоре, алатките за анализа на OLAP исто така можат да извлечат податоци директно од релациони системи. Овој пристап беше поатрактивен во тие денови кога OLAP серверите не беа вклучени во ценовниците на водечките производители на DBMS. Но, денес, Oracle, Informix и Microsoft нудат полноправни OLAP сервери, па дури и оние ИТ менаџери кои не сакаат да создаваат „зоолошка градина“ софтвер од различни производители во нивните мрежи можат да купат (или подобро, да поднесат соодветно барање до менаџментот на компанијата ) OLAP сервер од истиот бренд како и главниот сервер за бази на податоци.

OLAP серверите или серверите за повеќедимензионални бази на податоци, можат да ги складираат своите повеќедимензионални податоци на различни начини. Пред да ги разгледаме овие методи, треба да зборуваме за важен аспект како складирање единици. Факт е дека во секое складиште на податоци - обични и повеќедимензионални - заедно со деталните податоци извлечени од оперативните системи, се чуваат и збирни индикатори (збирни индикатори, агрегации), како што е збирот на обемот на продажба по месец, по категорија стоки итн. Агрегатите се складираат експлицитно со единствена цел да се забрза извршувањето на барањата. На крајот на краиштата, од една страна, како по правило, многу голема количина на податоци се акумулираат во складот, а од друга страна, аналитичарите во повеќето случаи се заинтересирани не за детални, туку за генерализирани показатели. И ако секој пат требаше да се собираат милиони поединечни продажби за да се пресмета вкупната продажба за годината, брзината најверојатно ќе биде неприфатлива. Затоа, при вчитување на податоци во повеќедимензионална база на податоци, сите вкупни индикатори или дел од нив се пресметуваат и складираат.

Но, како што знаете, треба да платите за сè. И за брзината на обработка на барањата за збирни податоци, треба да платите за зголемување на обемот на податоци и времето за нивно вчитување. Покрај тоа, зголемувањето на обемот може да стане буквално катастрофално - во едно од објавените стандардизирани тестовиза целосна пресметка на агрегати за 10 MB оригинални податоци потребни се 2,4 GB, односно податоците пораснале 240 пати! Степенот на „отекување“ на податоците при пресметување на агрегати зависи од бројот на димензиите на коцката и структурата на овие димензии, т.е., односот на бројот на „татковци“ и „деца“ на различни нивоа на мерење. За да се реши проблемот со складирање на агрегати, понекогаш се користат сложени шеми, кои овозможуваат да се постигне значително зголемување на перформансите на барањето при пресметување на не сите можни агрегати.

Сега за различните опции за складирање информации. И гранулираните податоци и агрегатите може да се складираат или во релациски или во повеќедимензионални структури. Повеќедимензионалното складирање ви овозможува да ги третирате податоците како повеќедимензионална низа, што обезбедува подеднакво брзи пресметки на вкупните индикатори и различни повеќедимензионални трансформации по која било од димензиите. Пред извесно време, производите на OLAP поддржуваа или релациско или повеќедимензионално складирање. Денес, по правило, истиот производ ги обезбедува двата типа на складирање, како и трет тип - мешан. Важат следните термини:

MOLAP(Мултидимензионален OLAP) - и деталните податоци и агрегатите се складираат во повеќедимензионална база на податоци. Во овој случај, се добива најголемата вишок, бидејќи повеќедимензионалните податоци целосно содржат релациски податоци.
ROLAP(Релациски OLAP) - деталните податоци остануваат таму каде што првично „живееле“ - во релациската база на податоци; агрегатите се чуваат во истата база на податоци во специјално креирани сервисни табели.
HOLAP(Хибриден OLAP) - деталните податоци остануваат на место (во релациона база на податоци), а агрегатите се складираат во повеќедимензионална база на податоци.

Секој од овие методи има свои предности и недостатоци и треба да се користи во зависност од условите - обемот на податоци, моќноста на релацискиот DBMS итн.

При складирање на податоци во повеќедимензионални структури, постои потенцијален проблем на „надуеност“ поради складирање на празни вредности. На крајот на краиштата, ако во повеќедимензионална низа просторот е резервиран за сите можни комбинации на етикети за димензии, но само мал дел е всушност пополнет (на пример, одреден број производи се продаваат само во мал број региони), тогаш повеќето од коцката ќе биде празна, иако просторот ќе биде окупиран. Современите производи на OLAP можат да се справат со овој проблем.

Продолжува. Во иднина ќе зборуваме за специфични производи на OLAP произведени од водечки производители.

04/07/2011 Дерек Комингор

Ако сте работеле во која било област поврзана со технологијата, веројатно сте го слушнале терминот „коцка“; сепак, повеќето обични администратори и развивачи на бази на податоци не работеа со овие објекти. Коцките обезбедуваат моќна архитектура на податоци за брзо собирање повеќедимензионални информации. Ако вашата организација треба да анализира големи количини на податоци, тогаш идеално решениетоа ќе биде коцка

Што е коцка?

Релационите бази на податоци беа дизајнирани да управуваат со илјадници истовремени трансакции додека ги одржуваат перформансите и интегритетот на податоците. Според дизајнот, релационите бази на податоци не се ефикасни за собирање и пребарување на големи количини на податоци. За да се соберат и да се вратат големи количини на податоци, релациската база на податоци мора да добие барање засновано на множество, информациите за кои ќе се собираат и собираат во лет. Ваквите релациски барања се многу скапи бидејќи се потпираат на повеќе спојувања и агрегатните функции; Збирните релациски барања се особено неефикасни кога се работи со големи количини на податоци.

Коцките се повеќедимензионални ентитети дизајнирани да го решат овој недостаток во релационите бази на податоци. Со користење на коцка, можете да им обезбедите на корисниците структура на податоци која обезбедува брз одговор на прашања со големи збирни волумени. Коцките ја изведуваат оваа „магија за агрегација“ така што прво ги собираат податоците (димензиите) низ повеќе димензии. Пред-агрегација на коцката обично се врши за време на обработката. Кога обработувате коцка, произведувате претходно пресметани агрегации на податоци кои се складирани во бинарна форма на дискот.

Коцката е централна структура на податоци во операционен системАнализа на податоци OLAP на SQL Server Analytical Services (SSAS). Коцките обично се градат од основната релациона база на податоци наречена димензионален модел, но се посебни технички ентитети. Логично, коцка е складиште на податоци што се состои од димензии (димензии) и мерења (мерки). Димензиите содржат описни карактеристики и хиерархии, додека димензиите се фактите што ги опишувате во димензии. Димензиите се групирани во логички комбинации наречени димензионални групи. Ги поврзувате димензиите со мерните групи врз основа на карактеристика - степенот на детали.

ВО датотечен системкоцка се имплементира како низа од поврзани бинарни датотеки. Бинарната архитектура на коцката го олеснува брзото пронаоѓање на големи количини на повеќедимензионални податоци.

Спомнав дека коцките се изградени од основната релациона база на податоци наречена димензионален модел. Моделот на димензија содржи релациски табели (факт и димензија) кои го поврзуваат со ентитетите на коцката. Табелите со факти содржат димензии како што е количината на продадениот производ. Табелите со димензии складираат описни атрибути како што се имиња на производи, датуми и имиња на вработени. Вообичаено, табелите со факти и табелите со димензии се поврзани преку примарни ограничувања за странски клучеви, при што странските клучеви се наоѓаат во табелата со факти (оваа релациона врска се однесува на атрибутот за грануларност на коцката што беше дискутиран погоре). Кога табелите со димензии се директно поврзани со табела со факти, се формира шема со ѕвезди. Кога табелите со димензии не се директно поврзани со табела со факти, резултатот е шема на снегулки.

Ве молиме имајте предвид дека димензионалните модели се класифицирани според примената. Март на податоци е димензионален модел кој е дизајниран за еден деловен процес, како што е продажбата или управувањето со залихите. Складиштето на податоци е димензионален модел дизајниран да ги долови компонентаните деловни процеси, така што ја олеснува аналитиката на процесите меѓу бизнисот.

Софтверски барања

Сега кога имате основно разбирање за тоа што се коцките и зошто се важни, ќе ги вклучам брзините и ќе ве одведам на чекор-по-чекор турнеја за градење на вашата прва коцка користејќи SSAS. Постојат некои основни компоненти софтвер, што ќе ви треба, па пред да започнете со градење на вашата прва коцка, проверете дали вашиот систем ги исполнува барањата.

Мојот пример Интернет-продажната коцка ќе биде изградена од тест базата на податоци AdventureWorksDW 2005. Ќе ја изградам коцката за тестирање од подмножество на табели пронајдени во базата на податоци за тестирање што ќе биде корисно за анализа на податоците за продажбата на Интернет. Слика 1 го прикажува основниот распоред на табелите на базата на податоци. Бидејќи ја користам верзијата 2005, можете да ги следите моите упатства користејќи или SQL Server 2005 или SQL Server 2008.

Слика 1. Подмножество на Adventure Works Интернет продажби на податоци март

Базата на податоци за обука Adventure WorksDW 2005 може да се најде на веб-страницата CodePlex: msftdbprodsamples.codeplex.com. Најдете ја врската „Сè уште се достапни базите на податоци за примероци на производи SQL Server 2005“ (http://codeplex.com/MSFTDBProdSamples/Release/ProjectReleases.aspx?ReleaseId=4004). Базата на податоци за обука е содржана во датотеката AdventureWorksBI.msi (http://msftdbprodsamples.codeplex.com/releases/view/4004#DownloadId=11755).

Како што споменавме, мора да имате пристап до примерок од SQL Server 2008 или 2005, вклучувајќи ги компонентите SSAS и Business Intelligence Development Studio (BIDS). Ќе користам SQL Server 2008, па може да видите некои суптилни разлики ако користите SQL Server 2005.

Креирање на проект SSAS

Првото нешто што треба да направите е да креирате проект SSAS користејќи BIDS. Најдете ПОНУДИ во менито Start, а потоа во менито Microsoft SQL Server 2008/2005, потточка SQL Server Business Intelligence Development Studio. Со кликнување на ова копче ќе се активираат BIDS со стандардниот поздравен екран. Креирај нов проект SSAS со избирање Датотека, Ново, Проект. Ќе го видите прозорецот за дијалог Нов проект, што го прикажува Слика 1. Изберете ја папката за проектни услуги за анализа и поставете го описот на проектот на SQLMAG_MyFirstCube. Кликнете на ОК.

Откако ќе се креира проектот, кликнете со десното копче на него во Solution Explorer и изберете контекстното мениСтавка Својства. Сега изберете го делот Распоредување на левата страна од полето за дијалог SQLMAG_MyFirstCube: Property Pages и прегледајте ги поставките за целниот сервер и базата на податоци, како што е прикажано на Слика 2. Ако работите во дистрибуирана околина на SQL Server, ќе треба да се квалификувате својството Target Server со името на серверот.на кој ќе се распоредите. Кликнете OK кога сте задоволни со поставките за распоредување за овој проект SSAS.

Дефинирање на изворот на податоци

Првиот објект што треба да го креирате е изворот на податоци. Објектот за извор на податоци обезбедува шема и податоци што се користат за изградба на објектите поврзани со и во основата на коцката. За да креирате објект за извор на податоци во BIDS, користете го изворниот волшебник ПодатоциВолшебник за извор.

Започнете го Волшебникот за извор на податоци со десен клик на папката Извор на податоци во панелот Solution Explorer и избирање Нов извор на податоци. Ќе откриете дека создавањето SSAS објекти во BIDS има развојна природа. Волшебникот прво ве води низ процесот на креирање објект и општите поставки. И потоа го отворате добиениот објект SSAS во дизајнерот и детално го приспособувате доколку е потребно. Откако ќе го надминете екранот со барање, дефинирајте нова податочна врска со кликнување на копчето Ново. Изберете и креирајте нова врска заснована на Native OLEDB\SQL Server Native Client 10 што покажува кон саканата SQL серверСервер кој ја поседува саканата база на податоци. Може да користите или Windows или SQL Server автентикација, во зависност од поставките за околината на вашиот SQL Server. Кликнете на копчето за тестирање на врската за да се осигурате дека правилно сте ја идентификувале врската со базата на податоци, а потоа кликнете OK.

Следува Информациите за имитирање, кои, како асоцијација на податоци, зависи од тоа како е структурирана околината на SQL Server. Позајмувањето привилегии е безбедносниот контекст на кој се потпира SSAS кога ги обработува своите објекти. Ако управувате со вашето распоредување на примарен, единствен сервер (или лаптоп), како што претпоставувам дека се повеќето читатели, можете едноставно да ја изберете опцијата Користете ја услугата сметка. Кликнете Следно за да го комплетирате Волшебникот за извор на податоци и поставете го AWDW2005 како Име на изворот на податоци. Сосема е погодно што можете да го користите овој метод за цели на тестирање, но во реално производствено опкружување тоа не е најмногу најдобра практика- користете сметка за услуга. Подобро е да наведете домен Сметкида ги позајмите правата за поврзување SSAS на изворот на податоци.

Приказ на извор на податоци

За изворот на податоци што сте го дефинирале, следниот чекор во процесот на градење на коцка SSAS е да се создаде Преглед на извор на податоци (DSV). DSV обезбедува можност за одделување на шемата што ја очекува вашата коцка од онаа на основната база на податоци. Како резултат на тоа, DSV може да се користи за проширување на основната релациона шема при градење на коцка. Некои од клучните карактеристики на DSV за проширување на шемите за извори на податоци вклучуваат именувани прашања, логички врски помеѓу табелите и именувани пресметани колони.

Ајде да продолжиме и да кликнете со десното копче на папката DSV и изберете New Data Source View за да го стартувате волшебникот Create New DSV View. Во полето за дијалог, на чекорот Изберете извор на податоци, изберете врска со релациона база на податоци и кликнете Следно. Изберете ги табелите FactInternetSales, DimProduct, DimTime, DimCustomer и кликнете на копчето со една десна стрелка за да ги преместите овие табели во колоната Вклучено. Конечно, кликнете Next и завршете го волшебникот со прифаќање на стандардното име и кликнување на Finish.

Во овој момент, треба да имате приказ на DSV лоциран под папката Прегледи на извор на податоци во Solution Explorer. Кликнете двапати на новиот DSV за да го стартувате дизајнерот DSV. Треба да ги видите сите четири табели за даден DSV, како што е прикажано на Слика 2.

Креирање на димензии на базата на податоци

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

Базата на податоци и димензиите на коцките обезбедуваат елегантно решение за концептот познат како „димензии на улоги“. Димензиите засновани на улоги се користат кога треба повеќе пати да користите една димензија во коцка. Датумот е совршен пример во овој примерок на коцка: ќе изградите димензија на единечна датум и ќе ја упатите еднаш за секој датум за кој сакате да ја анализирате продажбата преку Интернет. Календарскиот датум ќе биде првата димензија што ќе ја креирате. Десен-клик на папката Dimensions во Solution Explorer и изберете New Dimension за да го стартувате Dimension Wizard. Изберете Користете постоечка табела и кликнете Следно во чекорот Изберете метод на создавање. На чекорот Наведете информации за изворот, наведете ја табелата DimTime во паѓачката листа Главна табела и кликнете Следно. Сега, на чекорот Select Dimension Attributes, треба да ги изберете атрибутите на временската димензија. Изберете го секој атрибут, како што е прикажано на слика 3.

Кликнете Следно. Како последен чекор, внесете Dim Date во полето Name и кликнете Finish за да го завршите Dimension Wizard. Сега треба да ја видите новата димензија Dim Date која се наоѓа под папката Димензии во Solution Explorer.

Потоа користете го Dimension Wizard за да креирате димензии на производот и клиентот. Следете ги истите чекори за да ја креирате основната димензија како порано. Кога работите со Dimension Wizard, погрижете се да ги изберете сите потенцијални атрибути во чекорот Select Dimension Attributes. Стандардните вредности за другите поставки се добри за пример на коцка за тестирање.

Создавање коцка за продажба на Интернет

Сега кога сте ги подготвиле димензиите на базата на податоци, можете да започнете со градење на коцката. Во Solution Explorer, кликнете со десното копче на папката Cubes и изберете New Cube за да го стартувате Cube Wizard. Во прозорецот Избери метод на создавање, изберете ја опцијата Користи постоечки табели. Изберете ја табелата FactInternetSales за Measure Group во чекорот Select Measure Group Tables. Отштиклирајте ги полињата до димензиите на клучот за промоција, клучот валута, клучот за територија на продажба и бројот на ревизија во чекорот Избери мерки и кликнете Следно.

На екранот Изберете постоечки димензии, проверете дали сите постоечки димензии на базата на податоци се избрани за да се користат како димензии на коцка. Бидејќи би сакал оваа коцка да биде што е можно поедноставна, отселектирај ја димензијата FactInternetSales во чекорот Изберете нови димензии. Ако ја оставите избраната димензијата FactInternetSales, ќе создадете она што се нарекува димензија на факти или дегенерирана димензија. Димензиите на факти се димензии кои се создадени со користење на основна табела со факти за разлика од традиционалната табела со димензии.

Кликнете Следно за да отидете на чекорот Завршување на Волшебникот и внесете „Мојата прва коцка“ во полето Име на коцката. Кликнете на копчето Finish за да го завршите процесот на Create Cube Wizard.

Проширување и обработка на коцка

Сега сте подготвени да ја распоредите и обработите првата коцка. Десен-клик на иконата за нова коцка во Solution Explorer и изберете Process. Ќе видите поле за пораки во кое се наведува дека содржината се чини дека е застарена. Кликнете Да за да ја распоредите новата коцка на целниот сервер SSAS. Кога распоредувате коцка, испраќате XML датотеказа Анализа (XMLA) до целниот сервер SSAS, кој создава коцка на самиот сервер. Како што споменавме, обработката на коцка ги пополнува нејзините бинарни датотеки на дискот со податоци од главниот извор, како и дополнителни метаподатоци што сте ги додале (димензии на коцка, димензии и поставки).

Откако ќе заврши процесот на распоредување, се појавува нов прозорец за дијалог Process Cube. Кликнете на копчето Run за да започнете со обработка на коцката, која се отвора со прозорецот Process Progress. Кога обработката е завршена, кликнете Затвори (двапати за да ги затворите двата дијалог-кутија) за да ги завршите процесите на распоредување и обработка на коцката.

Сега ја изградивте, распоредивте и обработивте вашата прва коцка. Оваа нова коцка можете да ја прегледате со десен клик на неа во прозорецот Solution Explorer и изберете Преглед. Повлечете ги димензиите до центарот на стожерната табела и атрибутите на димензиите на редови и колони за да ја истражите вашата нова коцка. Забележете колку брзо коцката обработува различни барања за агрегација. Сега можете да ја цените неограничената моќност, а со тоа и деловната вредност на коцката OLAP.

Дерек Комингор ( [заштитена е-пошта]) е виш архитект во B. I. Voyage, кој има статус на Microsoft партнер во областа на деловната аналитика. Има титула MVP на SQL Server и неколку Microsoft сертификати

Популарни во категоријата: