дома › СО › Мерки и димензии на коцката Олап. Што е коцка? OLAP на клиентот и серверот

Мерки и димензии на коцката Олап. Што е коцка? OLAP на клиентот и серверот

/ На кубистички начин. Примена на OLAP коцките во менаџерската практика на големите компании

Во контакт со

Соучениците

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

Во кубистички стил.
Примена на OLAP коцките во менаџерската практика на големите компании

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

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

Во јамката за корпоративно управување, помеѓу „необработените“ податоци и „лостовите“ за влијание врз управуваниот објект, постојат „показатели за перформанси“ - KPI. Тие формираат еден вид „табла“, што ја одразува состојбата на различните потсистеми на контролираниот објект. Опремувањето на компанијата со информативни показатели за успешност и следењето на нивната пресметка и добиените вредности е работа на деловен аналитичар. Услугите за автоматска анализа, како што е алатката MS, можат да обезбедат значителна помош во организирањето на аналитичката работа на корпорацијата. SQL ServerУслуги за анализа (SSAS) и нејзината главна карактеристика е коцката OLAP.

Уште една точка треба да се истакне токму овде. Да речеме, во американската традиција, специјалитетот фокусиран на работа со OLAP коцки се нарекува BI (Business Intelligence). Не треба да има илузии дека американската БИ одговара на рускиот „бизнис аналитичар“. Без навреда, но често нашиот деловен аналитичар е „под-сметководител“ и „под-програмер“, специјалист со нејасно знаење и мала плата, кој навистина нема никакви сопствени алатки и методологија.

Специјалист за БИ е, всушност, применет математичар, висококвалификуван специјалист кој користи современи математички методи за арсеналот на компанијата (она што беше наречено Операционо истражување). БИ е поконзистентен со специјалитетот „системски аналитичар“ што некогаш беше во СССР, дипломиран на Факултетот за пресметковна математика и математика на Московскиот државен универзитет. М.В. Ломоносов. Коцката OLAP и услугите за анализа може да станат ветувачка основа за работното место на руски деловен аналитичар, можеби по некоја напредна обука во насока на американскиот БИ.

Неодамна се појави уште еден штетен тренд. Благодарение на специјализацијата, меѓусебното разбирање помеѓу различните категории вработени во корпорацијата е изгубено. Сметководител, менаџер и програмер, како „лебед, рак и штука“ во басната на И.А. Крилов, ја влечат корпорацијата во различни насоки.

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

Менаџерот е зафатен со својот дел од деловниот процес, но не е во состојба да ги процени глобално, на ниво на компанијата како целина, резултатите и перспективите на неговите постапки.

Конечно, програмерот, кој некогаш (благодарение на своето образование) беше проводник на напредни технички идеи од сферата на науката до сферата на бизнисот, се претвори во пасивен извршител на фантазиите на сметководителот и менаџерот, така што не е подолго невообичаено за ИТ одделенијата на корпорациите да бидат управувани од сметководители и, генерално, сите на кои не се мрзливи. Недостигот од иницијатива, неписмен, но релативно високо платен 1C програмер е вистинско зло руски корпорации. (Речиси како домашен фудбалер.) Не зборувам ни за таканаречените „економисти и правници“, за нив се е кажано одамна.

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

Предности на OLAP коцките

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

Некој вовед во OLAP-
коцка може да се даде со „стожерна табела“ на MS Excel. Овие објекти имаат слична логика и слични интерфејси. Но, како што ќе се види од статијата, функционалноста на OLAP е неспоредливо побогата, а перформансите се неспоредливо повисоки, така што „стожерната табела“ останува локален десктоп производ, додека OLAP е производ на ниво на претпријатие.

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

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

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

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

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

Да дадеме пример. Да речеме дека менаџерот ги контролира побарувањата. Сè додека KPI за доспеани побарувања е зелен, тоа значи дека сè е нормално и не се потребни никакви активности на управување. Ако бојата е сменета во жолта или црвена, нешто не е во ред: ги пресекуваме KPI по оддели за продажба и веднаш ги гледаме одделенијата „во црвено“. Идентификуван е следниот дел од менаџерите - и продавачот чии клиенти заостануваат при плаќањето. (Понатаму, задоцнетиот износ може да се подели по клиенти, по услови итн.) Шефот на корпорацијата може директно да контактира со прекршителите на кое било ниво. Но, генерално, истиот KPI (на нивните хиерархиски нивоа) го гледаат и раководителите на одделот и менаџерите за продажба. Затоа, за да се поправи ситуацијата, не треба ни да чекаат „повик на тепих“... Се разбира, самиот KPI не мора нужно да биде износот на задоцнетите плаќања - може да биде пондериран просечен период на доспеани плаќања или, генерално, стапката на промет на побарувањата.

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

Да обрнеме внимание и на фактот дека секој вработен во компанијата може да собере од општото поле аналитичар на OLAP токму жетвата што му е потребна за неговата работа, а не да се задоволува со „лентата“ што му е отсечена во комунални „стандардни извештаи“.

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

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

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

OLTP + OLAP: преглед повратни информацииво синџирот на управување со компанијата

Сега да ја погледнеме општата идеја за коцките OLAP и нивната точка на примена во синџирот на корпоративно управување. Терминот OLAP (OnLine Analytical Processing) го воведе британскиот математичар Едгар Код покрај неговиот претходно воведен термин OLTP (OnLine Transactions Processing). За ова ќе се дискутира подоцна, но Е. Код, се разбира, ги предложи не само термините, туку и математичките теории на OLTP и OLAP. Без да навлегуваме во детали, во современото толкување, OLTP е релациона база на податоци, која се смета како механизам за снимање, складирање и преземање информации.

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

ERP системите (Enterprice Resource Planning), како што се 1C7, 1C8, MS Dynamics AX, имаат софтверски интерфејси ориентирани кон корисникот (внесување и уредување документи, итн.) и релациона база на податоци (DB) за складирање и преземање информации, претставени денес со софтвер производи како што се MS SQL Server (SS).

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

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

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

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

Како софтверска имплементација на OLAP, ќе ја разгледаме алатката MS Analysis Services, која е дел од стандардната испорака на MS SQL Server, скратено SSAS. Имајте предвид дека, според планот на Е.

OLAP логистика

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

Ќе претпоставиме дека корпорацијата користи систем ERP, на пример, 1C7 или 1C8, во кој информациите се снимаат како и обично. Базата на податоци на овој ERP систем се наоѓа на одреден сервер и е поддржана од MS SQL Server.

Исто така, ќе претпоставиме дека друг сервер има инсталиран софтвер, вклучително и MS SQL Server со алатката MS Analysis Services (SSAS), како и MS SQL Server Management Studio, MS C#, MS Excel и MS Visual Studio. Овие програми заедно го формираат потребниот контекст: алатките и потребните интерфејси за развивачот на OLAP коцки.

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

На работните станици на вработените, во рамките на локална мрежа, меѓу другото, се инсталирани програми MS Excel (верзии не помали од 2003 година), како и, можеби, посебен драјвер за да се осигура дека MS Excel работи со MS Analysis Services (освен ако соодветниот двигател е веќе вклучен во MS Excel).

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

OLAP дизајн на коцки (OLAP кубизам)

Да кажеме неколку зборови за дизајнот на самата коцка OLAP. На јазикот на статистиката, коцката OLAP е збир на индикатори за перформанси пресметани во сите потребни делови, на пример, индикаторот за испорака во делови по клиенти, по стоки, по датуми итн. Поради директен превод од англиски во руската литература за коцки OLAP, индикаторите се нарекуваат „мерки“, а деловите се нарекуваат „димензии“. Ова е математички точен, но синтаксички и семантички не многу успешен превод. Руските зборови „мерка“, „димензија“, „димензија“ се речиси исти по значење и правопис, додека англиските „мерка“ и „димензија“ се различни и по правопис и по значење. Затоа, им даваме предност на традиционалните руски статистички термини „индикатор“ и „сече“, кои се слични по значење.

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

Во овој дизајн, OLAP и OLTP не споделуваат табели, а OLAP аналитиката се пресметува колку што е можно подетално за време на фазата на ажурирање на коцки (Процес), која и претходи на фазата на користење. Оваа шема се нарекува MOLAP (Мултидимензионален OLAP). Неговите недостатоци се асинхронијата со ERP и високите трошоци за меморија.

Иако формално може да се изгради OLAP коцка со користење на сите (илјадници) табели за релациони бази на податоци на ERP како извор на податоци и сите (стотици) нивни полиња како индикатори или делови, во реалноста тоа не треба да се направи. Обратно. За да се вчита во коцка, поправилно е да се подготви посебна база на податоци, наречена „излог“ или „магацин“.

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

Прво,Поврзувањето на коцка OLAP со табели во вистинска база на податоци сигурно ќе создаде технички проблеми. Промената на податоците во табела може да предизвика освежување на коцката, а освежувањето на коцката не е нужно брз процес, така што коцката ќе биде во состојба на постојана обнова; Во исто време, процедурата за ажурирање на коцки може да ги блокира (при читање) податоците од табелите на базата на податоци, забавувајќи ја работата на корисниците при регистрирањето на податоците во системот ERP.
Второ, Ако имате премногу индикатори и намалувања, драматично ќе се зголеми просторот за складирање на коцката на серверот. Да не заборавиме дека коцката OLAP ги складира не само изворните податоци, како во системот OLTP, туку и сите индикатори сумирани на сите можни делови (па дури и сите комбинации на сите делови). Покрај тоа, брзината на ажурирање на коцката и, на крајот, брзината на градење и ажурирање на аналитиката и корисничките извештаи врз основа на нив соодветно ќе се забави.
Трето, премногу полиња (индикатори и делови) ќе создадат проблеми во интерфејсот на програмерите OLAP, бидејќи списоците на елементи ќе станат огромни.
Четврто, Коцката OLAP е многу чувствителна на прекршување на интегритетот на податоците. Коцката не може да се изгради ако клучните податоци не се наоѓаат на врската наведена во структурата на врските на полето со коцка. Привремените или трајните прекршувања на интегритетот и празните полиња се вообичаени во базата на податоци на системот ERP, но ова апсолутно не е погодно за OLAP.

Можете исто така да додадете дека системот ERP и коцката OLAP треба да се наоѓаат на различни сервери за споделување на оптоварувањето. Но, тогаш, ако има заеднички табели за OLAP и OLTP, се јавува и проблемот со мрежниот сообраќај. Практично нерешливите проблеми се јавуваат во овој случај кога е неопходно да се консолидираат неколку различни ERP системи (1C7, 1C8, MS Dynamics AX) во една OLAP коцка.

Веројатно, можеме да продолжиме да натрупуваме технички проблеми. Но, што е најважно, запомнете дека, за разлика од OLTP, OLAP не е средство за снимање и складирање податоци, туку алатка за аналитика. Ова значи дека нема потреба да се поставуваат и преземаат „валкани“ податоци од ERP на OLAP „за секој случај“. Напротив, прво мора да развиете концепт за управување со компанијата, барем на ниво на системот KPI, а потоа да дизајнирате складиште за податоци за апликација (магацин), сместен на истиот сервер како и коцката OLAP и содржи мал , рафинирано количество податоци од ERP неопходни за управување .

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

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

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

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

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

На серверот OLAP создаваме слики (празни копии) од базите на податоци на сите овие ERP системи. Ние периодично (ноќно) вршиме делумна репликација на соодветните активни ERP бази на податоци на овие празни копии.

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

Потоа се стартува стандардната процедура за ажурирање/изградба на коцка врз основа на податоци од складиштето (Операција на процесот во интерфејсот SSAS).

Ајде да коментираме за некои аспекти на технологијата. Каква работа работат СП?

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

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

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

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

Следно, главната задача на SP е да ги конвертира ERP системските податоци во формат на складиште. Ако има само еден ERP систем, тогаш задачата за конверзија главно се сведува на копирање и евентуално реформатирање на потребните податоци. Но, ако е неопходно да се консолидираат неколку ERP системи од различни структури во иста OLAP коцка, тогаш трансформациите стануваат покомплицирани.

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

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

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

Ова е визуелен „педагошки“ опис. Всушност, архитектурата на OLAP коцката може да биде многу посложена.

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

Второ, „зракот“ на ѕвездичка може да биде не само еден директориум, туку цел (хиерархиски) датотечен систем.

Трето, врз основа на постојните делови за димензии, може да се дефинираат нови хиерархиски делови со помош на алатките за интерфејс за развивачи OLAP (да речеме, со помалку нивоа, со различен редослед на нивоа, итн.)

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

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

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

Покрај самиот SSAS, постојат многу програми кои обезбедуваат интерфејс за OLAP, покривајќи ја нивната функционалност во поголема или помала мера. Но, меѓу нив има еден, кој, според наше мислење, има непобитни предности. Ова е MS Excel.

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

Се разбира, покрај неговата прилично целосна функционалност, главната предност на MS Excel е широката дистрибуција на оваа програма и блиското запознавање со неа на огромниот број канцелариски корисници. Во оваа смисла, за разлика од другите програми за интерфејс, компанијата нема потреба да купува ништо дополнително и не треба да тренира никого дополнително.

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

Ноќен циклус на третмани Facubi

Сега ќе го опишеме дневниот (ноќен) пресметковен циклус на операцијата OLAP. Пресметката се врши под контрола на програмата facubi, напишана во C# 2005 и лансирана преку Task Scheduler на сервер со магацин и SSAS. На почетокот, facubi оди на Интернет и ги чита тековните девизни курсеви (се користи за претставување на голем број индикатори во валута). Следно, направете ги следните чекори.

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

Второ, преку SP, се врши мапирање од ERP реплики до складиштето на магацинот - специјален DB, кој е извор на податоци од OLAP коцка и се наоѓа на серверот SSAS. Во овој случај, се решаваат три главни задачи:

ERP податоциприлагодени на потребните формати на коцки; зборуваме заи за табелите и за полињата за табели. (Понекогаш потребната табела треба да се „оформи“, да речеме, од неколку листови на MS Excel.) Слични податоци може да имаат различни формати во различни ERP, на пример, полињата за идентификација на клучот во директориумите 1C7 имаат 36-цифрен код на знаци со должина 8 , и _idrref полиња во директориумите 1С8 – хексадецимални броеви со должина 32;
за време на обработката се спроведува логичка контрола на податоците (вклучувајќи запишување стандардни поставки наместо податоците што недостасуваат, каде што е можно) и контрола на интегритетот, т.е. проверка на присуството на примарни и секундарни клучеви во соодветните класификатори;
консолидација на кодот објекти кои имаат исто значење во различни ERP. На пример, соодветните елементи на директориуми на различни ERP може да имаат исто значење, да речеме, тие се иста договорна страна. Проблемот со консолидирање на кодови се решава со конструирање табели за пресликување, каде разни кодовиистите предмети се доведени до единство.

Трето, лансирање на факуби стандардна процедураажурирање на податоците за процесната коцка (од SSAS utility procedures).

Врз основа на листите за проверка, facubi испраќа е-пошта за напредокот на чекорите за обработка.

По извршувањето на факуби, Распоредувачот на задачи за возврат стартува неколку ексел-датотеки, во кои извештаите се претходно креирани врз основа на индикаторите за коцки OLAP. Како што рековме, MS Excel има посебен софтверски интерфејс(одделно може да се преземе или вграден драјвер) за работа со OLAP коцки (со SSAS). Кога ќе го стартувате MS Excel, се активираат програмите MS VBA (како што се макроата), кои обезбедуваат ажурирање на податоците во извештаите; извештаите се менуваат доколку е потребно и се испраќаат по пошта (блат програма) до корисниците според листите за проверка.

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

Евалуација на резултатите

Зборувавме погоре за асинхронијата на OLTP и OLAP. Во технолошката варијанта што се разгледува, циклусот на ажурирање на коцката OLAP се изведува ноќе (да речеме, започнува во 1 часот по полноќ). Тоа значи дека во тековниот работен ден корисниците работат со вчерашните податоци. Бидејќи OLAP не е алатка за снимање (погледнете ја најновата ревизија на документот), туку алатка за управување (разберете го трендот на процесот), таквото заостанување обично не е критично. Меѓутоа, доколку е потребно, дури и во опишаната верзија на архитектурата на коцки (MOLAP), ажурирањето може да се врши неколку пати на ден.

Времето на извршување на процедурите за ажурирање зависи од дизајнерските карактеристики на коцката OLAP (повеќе или помалку сложеност, повеќе или помалку успешни дефиниции на индикатори и делови) и од обемот на бази на податоци на надворешни OLTP системи. Според искуството, постапката за изградба на складиште трае од неколку минути до два часа, процедурата за ажурирање на коцки (Процес) трае од 1 до 20 минути. Станува збор за сложени OLAP коцки кои обединуваат десетици структури од типот на ѕвезди, десетици заеднички „зраци“ (референтни делови) за нив и стотици индикатори. Проценувајќи го обемот на бази на податоци на надворешни ERP системи засновани на документи за испорака, зборуваме за стотици илјади документи и, соодветно, милиони производни линии годишно. Историската длабочина на обработка од интерес за корисникот беше три до пет години.

Опишаната технологија се користи во голем број големи корпорации: од 2008 година во Руската рибна компанија (РРК) и компанијата Руско море (РМ), од 2012 година во компанијата Санта Бремор (СБ). Некои корпорации првенствено тргуваат и купуваат фирми (ППЦ), други се производствени компании (фабрики за преработка на риба и морска храна во Република Молдавија и Република Белорусија). Сите корпорации се големи холдинзи, обединувајќи неколку компании со независни и различни компјутерски сметководствени системи - почнувајќи од стандардни ERP системи како што се 1C7 и 1C8 до „реликтни“ сметководствени системи базирани на DBF и Excel. Ќе додадам дека опишаната технологија за работа со OLAP коцки (без да се земе предвид фазата на развој) или воопшто не бара посебни вработени или е одговорност на еден деловен аналитичар со полно работно време. Проблемот се врти наоколу со години автоматски режим, обезбедувајќи секојдневно ажурирано известување за различни категории вработени во корпорациите.

Добрите и лошите страни на решението

Искуството покажува дека предложеното решение е прилично сигурно и лесно за употреба. Лесно се модифицира (поврзување/исклучување на нови ERP, создавање нови индикатори и секции, креирање и модификација на извештаи на Excel и нивните мејлинг листи) со непроменливост контролна програмафакуби.

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

„Рафинираната“ база на податоци за складиште, во која се консолидираат неколку хетерогени ERP системи (за време на изградбата на коцката), дури и без OLAP, ви овозможува да решавате (на SSAS сервер, користејќи го методот за пребарување во Transact SQL или методот SP , итн.) многу применети проблеми за управување. Да потсетиме дека структурата на базата на податоци за складиште е унифицирана и многу поедноставна (во однос на бројот на табели и бројот на полиња на табелата) од структурите на базата на податоци на оригиналниот ERP.

Посебно забележуваме дека во нашето предложено решение постои можност за консолидирање на различни ERP системи во една OLAP коцка. Ова ви овозможува да добиете аналитика за целото стопанство и да одржувате долгорочен континуитет во аналитиката кога корпорацијата преминува во друг сметководствен ERP систем, да речеме, кога се движи од 1C7 на 1C8.

Го користевме моделот на коцка MOLAP. Предностите на овој модел се доверливост во работењето и голема брзина на обработка на барањата на корисниците. Недостатоци: OLAP и OLTP се асинхрони, како и големи количини на меморија за складирање на OLAP.

Како заклучок, еве уште еден аргумент во корист на OLAP кој можеби бил посоодветен во средниот век. Затоа што неговата доказна моќ почива на авторитетот. Скромниот, јасно потценет британски математичар Е. Код ја разви теоријата за релациони бази на податоци во доцните 60-ти. Моќта на оваа теорија беше таква што сега, по 50 години, веќе е тешко да се најде не-релациона база на податоци и јазик за барање база на податоци, освен SQL.

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

Ларсон Б. Развој на деловна аналитика во Microsoft SQL Server 2005. – Санкт Петербург: „Петар“, 2008 година.
Codd E. Релациска комплетност на подјазиците на бази на податоци, системи на бази на податоци, Courant Computer Science Sumposia Series 1972, v. 6, Енглвудски карпи, Њујорк, Прентис - Хол.

Во контакт со

Можеби за некои, употребата на OLAP технологијата (On-line Analytic Processing) при креирање извештаи ќе изгледа нешто егзотично, така што употребата на OLAP-CUBE за нив воопшто не е еден од најважните барања при автоматизирање на буџетирањето и сметководството за управување.

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

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

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

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

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

За да ја потврдиме релевантноста на користењето CUBE при конструирање на известување за управување, можеме да дадеме едноставен пример со буџет за продажба. Во примерот што се разгледува, следните аналитички делови се релевантни за компанијата: производи, филијали и продажни канали. Ако овие три аналитики се важни за компанијата, тогаш буџетот за продажба (или извештај) може да се прикаже во неколку верзии.

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

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

Ориз. 1. Пример за буџет за продажба изграден врз основа на една аналитика „Производи“ во OLAP-CUBE

Истиот буџет за продажба може да се состави со користење на две аналитики (директориуми). Пример за буџет за продажба изграден врз основа на две аналитички „производи“ и „гранки“ е претставен на Слика 2.

Ориз. 2. Пример за буџет за продажба изграден врз основа на две аналитички „производи“ и „гранки“ во OLAP-CUBE на софтверскиот пакет INTEGRAL

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

Ориз. 3. Пример за буџет за продажба изграден врз основа на три аналитички „производи“, „гранки“ и „продажни канали“ во OLAP-CUBE на софтверскиот пакет INTEGRAL

Треба да се потсетиме дека CUBE што се користи за генерирање извештаи ви овозможува да прикажувате податоци во различни секвенци. На Слика 3Продажниот буџет прво се „проширува“ по производ, потоа по гранка, а потоа по продажен канал.

Истите податоци може да се претстават во различна низа. На Слика 4истиот продажен буџет се „проширува“ прво по производ, потоа по продажен канал, а потоа по гранка.

Ориз. 4. Пример за буџет за продажба изграден врз основа на три аналитички „производи“, „Канали за дистрибуција“ и „гранки“ во OLAP-CUBE на софтверскиот пакет INTEGRAL

На Слика 5истиот продажен буџет се „рашири“ прво по гранки, потоа по производи, а потоа по продажни канали.

Ориз. 5. Пример за буџет за продажба изграден врз основа на три аналитички „гранки“, „производи“ и „продажни канали“ во софтверскиот пакет OLAP-CUBE „INTEGRAL“

Всушност тоа не е се можни опцииповлекување на буџетот за продажба.

Покрај тоа, треба да обрнете внимание на фактот дека CUBE ви овозможува да работите со хиерархиска структурареферентни книги. Во презентираните примери, хиерархиските директориуми се „Производи“ и „Канали за дистрибуција“.

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

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

Неопходно е да се споменат уште неколку карактеристики на OLAP-CUBE.

Во повеќедимензионална хиерархиска OLAP-CUBE има неколку димензии: тип на ред, датум, редови, директориум 1, директориум 2 и директориум 3 (види. Ориз. 6). Секако, извештајот прикажува онолку копчиња со директориуми колку што има во буџетската линија што го содржи максималниот број директориуми. Ако нема ниту една референтна книга во ниту една буџетска линија, тогаш извештајот нема да има ниту едно копче со референтни книги.

Првично, OLAP-CUBE е изграден по сите димензии. Стандардно, кога извештајот е првично изграден, димензиите се наоѓаат токму во областите прикажани во Слика 6. Односно, димензијата како „Датум“ се наоѓа во областа на вертикални димензии (димензии во областа на колоната), димензии „Редови“, „Директориум 1“, „Датум 2“ и „Именик 3“ - во област на хоризонтални димензии (димензии во редовите на областа), а димензијата „Тип на ред“ е во областа на димензии „непроширени“ (димензии во областа на страницата). Ако димензијата е во последната област, тогаш податоците во извештајот нема да се „прошират“ на таа димензија.

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

Ориз. 7. Пример за обнова на извештај по промена на мерната конфигурација на софтверскиот пакет INTEGRAL

Конфигурацијата за мерење може да се смени или во главната форма CUBE или во уредувачот за промена на картата (види. Ориз. 8). Во овој уредувач, исто така можете да влечете и спуштате мерења од една област во друга со глувчето. Покрај тоа, можете да ги замените мерењата во една област.

Покрај тоа, во истата форма можете да конфигурирате некои параметри за мерење. За секоја димензија, можете да ја прилагодите локацијата на збирките, редоследот на сортирање на елементите и имињата на елементите (види. Ориз. 8). Можете исто така да одредите кое име на елементот да се прикаже во извештајот: скратено (Име) или целосно (Целосно име).

Ориз. 8. Уредувач на мерни карти на софтверскиот пакет INTEGRAL

Можете да ги уредувате мерните параметри директно во секој од нив (види. Ориз. 9). За да го направите ова, кликнете на иконата што се наоѓа на копчето веднаш до името на мерењето.

Ориз. 9. Пример за уредување директориум 1 Производи и услуги во

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

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

Ориз. 10. Пример за излез во извештај од само една група производи (папка) во софтверскиот пакет ИНТЕГРАЛ

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

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

Всушност, сите такви промени можеа да се направат првично при поставувањето на линиите.

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

Забелешка: темата на овој напис подетално се дискутира на работилниците „Управување со буџет на претпријатие“И „Организација и автоматизација на менаџерското сметководство“спроведена од авторот на оваа статија, Александар Карпов.

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

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 сертификати

Самостојна датотека со коцки (.cub) складира податоци во форма во коцка за онлајн аналитичка обработка (OLAP). Овие податоци може да претставуваат дел од OLAP база на податоци од OLAP сервер, или можеби се создадени независно од која било база на податоци OLAP. За да продолжите да работите со извештаите на PivotTable и PivotChart кога серверот е недостапен или кога е офлајн, користете офлајн датотека со коцка.

Дознајте повеќе за офлајн коцките

Кога работите со извештај за PivotTable или PivotChart кој се базира на извор на податоци од OLAP сервер, користете го Волшебникот за офлајн коцка за да ги копирате изворните податоци во посебна офлајн датотека со коцки на вашиот компјутер. За да ги креирате овие офлајн датотеки, мора да имате инсталирано на вашиот компјутер давател на податоци OLAP кој ги поддржува овие способности, како што е MSOLAP од услугите за анализа на Microsoft SQL Server.

Забелешка:Креирање и користење на офлајн куб-датотеки од услугите за анализа на Microsoft SQL Server, предмет на услови и лиценцирање Инсталации на Microsoft SQL Server. Прегледајте ги соодветните информации за лиценцирање за вашата верзија на SQL Server.

Користење на Волшебникот за офлајн коцки

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

Преземање податоци офлајн, а потоа враќање на податоци на интернет

За да го направите ова, прво треба да креирате извештај за PivotTable или извештај за PivotChart кој се базира на базата на податоци на серверот, а потоа креирајте самостојна датотека со коцка од извештајот. Последователно, кога работите со извештај, можете да се префрлате помеѓу базата на податоци на серверот и датотеката офлајн во секое време (на пример, кога работите на лаптоп дома или на пат, а потоа повторно го поврзувате компјутерот на мрежата).

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

Забелешка:

Кликнете на извештајот PivotTable. Ако ова е извештај за Стожерна табела, изберете го поврзаниот извештај за Стожерна табела.

на „табот“ Анализа“ во Групата пресметкикликнете на копчето OLAP услугаи притиснете го копчето Офлајн OLAP.

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

Ако е побарано да пронајдете извор на податоци, кликнете Најдете извори пронајдете OLAP сервер на мрежата.

Кликнете на извештајот PivotTable што се базира на датотеката со офлајн коцка.

Во Excel 2016: на табулаторот " податоци“ во Групата барања и врски Ажурирајте ги ситеи притиснете го копчето Ажурирање.

Во Excel 2013: на табулаторот " податоци“ во Групата врскикликнете на стрелката веднаш до копчето Ажурирајте ги ситеи притиснете го копчето Ажурирање.

Кликнете на копчето Офлајн OLAP режим, и потоа - .

Забелешка: Стопво полето за дијалог.

Предупредување:

Креирање офлајн датотека со коцка од базата на податоци на серверот OLAP

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

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

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

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

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

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

Ажурирање и повторно креирање офлајн датотека со коцка

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

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

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

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

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

Вклучувајќи други податоци во датотеката со офлајн коцка

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

Потврдете дека постои мрежна врска и дали е достапна изворната база на податоци за серверот OLAP од која датотеката офлајн коцка ги добила податоците.

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

На јазичето Опцииво Група Сервискликнете на копчето OLAP услугаи притиснете го копчето Офлајн OLAP режим.

Кликнете на копчето Офлајн OLAP режим, и потоа - Уредете офлајн датотека со податоци.

Следете го Offline Cube Wizard за да изберете други податоци што ќе ги вклучите во оваа датотека. Во последниот чекор, наведете го името и патеката до датотеката за промена.

Забелешка:За да го откажете зачувувањето на датотеката, кликнете на копчето Стопво полето за дијалог Креирање на датотека со коцка - напредок.

Бришење офлајн датотека со коцка

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

Затворете ги сите работни книги што содржат извештаи што ја користат офлајн-датотеката со коцки или погрижете се сите такви извештаи да се избришат.

ВО Microsoft WindowsЛоцирајте и избришете ја офлајн датотеката со коцка (датотека CUB).

дополнителни информации

Секогаш можете да поставите прашање до специјалист за Excel Tech Community, да побарате помош во заедницата Answers, а исто така да предложите нова карактеристикаили подобрување на веб-страницата

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

Ако сè уште треба да ги анализирате податоците од OLAP откако ќе излезете офлајн, креирајте офлајн коцка за податоци. Офлајн коцка за податоци е посебна датотека што е кеш на стожерната табела и ги складира податоците од OLAP што се гледаат по исклучувањето од локалната мрежа. Податоците од OLAP копирани во стожерна табела може да се испечатат; ова е детално опишано на веб-страницата http://everest.ua.

За да креирате самостојна коцка за податоци, прво креирајте стожерна табела OLAP. Поставете го курсорот во стожерната табела и кликнете на копчето OLAP Tools на контекстуалното јазиче Tools, кое е дел од групата на контекстуални јазичиња Алатки на PivotTable. Изберете ја командата Offline OLAP (Сл. 9.8).

На екранот се појавува полето за дијалог Offline OLAP Data Cube Settings. Кликнете на копчето Креирај офлајн датотека со податоци. Го стартувавте Волшебникот за креирање на коцка податоци за датотеки. Кликнете на копчето Next за да продолжите со постапката.

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

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

Во последниот чекор, наведете ја локацијата и името на коцката со податоци. Во нашиот случај, датотеката со коцка ќе се вика MyOfflineCube.cub и ќе се наоѓа во папката Work.

Датотеките со коцка на податоци имаат наставка .младенче

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

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

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