СА“Д.А.Ценов”
АНАЛИТИЧНА ОБРАБОТКА
В
РЕАЛНО ВРЕМЕ
Разработил:Габриела Дойчинова Донева
МП.ИТБ V курс
фак. № М032042
Свищов
OLAP- OnLine Analytical Processing - логическото значение на думата OLAP включва всяко компютърно приложение, което се използва за анализиране на данни, но никой не използва думата в това и значение. OLAP е един от най-лошо измислените акроними - когато кажеш на някой какво означава съкращението, то още няма и бегла представа какво представлява приложението.
OLAP (популярна дефиниция) - Милиони електронни таблички в кутия - Това е което можете да кажете на хората които никога на са го виждали относно OLAP. OLAP в основата си е инструмент за електронни таблици - доста мощен и гъвкав - неговото главно предназначение е да показва информация в табличен вид. Ключът се крие в способността лесно да преминавате към различен изглед на данните. Не е нужно всеки път да се обръщате към системните администратори, когато искате да видите данните от друг ъгъл, Вашият OLAP инструмент ви дава възможност бързо да видите данните от друга перспектива. Виждате някаква информация която ви интересува? С OLAP можете бързо да видите по-детайлни данни (или по-обобщени).
OLAP (друга популярна дефиниция) - Справки с някои допълнения - Стандартните хартиени справки за изпълнителния директор например съдържат две измерения - обекти показани във всяка колона, сметки във всеки ред и финикииски знаци в средата. OLAP куба добавя допълнителни измерения - тенденция през времето, сметки за различни географски райони или различни продукти. Лесно можете да видите информацията от по-детайлна или по-обобщена перспектива.
OLAP (техническа дефиниция) - Бързо интерактивно разглеждане на многомерни данни на много нива - OLAP винаги включва няколко измерения, които трябва да имат няколко нива (Ако нямате нива, то OLAP-а ви не е много мощен) OLAP трябва да бъде бърз. OLAP е интерактивен. Разглеждането на информацията се извършва от човек анализатор. Когато анализаторът погледне данните, то може да зададе допълнителни въпроси и трябва да получи незабавен отговор. Ако имате приложение за анализ на данни, което не връща резултат на ново запитване почти веднага, то вие нямате OLAP приложение. Колко бързо е достатъчно бързо? По-малко от 5 секунди е добре, но по-малко от секунда е много, много по-добре. Ценното на услугата за анализи е в това че връща възможно най-бързо резултат на запитването. Данните се съхраняват в многомерни структури, заедно с някой от обобщените (възможни да бъдат и изчислени) данни.
За разлика от по-познатото OLTP ("On-Line Transaction Processing"), OLAP описва клас технологии създадени за достъп и анализ на информация в реално време. Докъто транзакционния метод почива главно върху релационни бази данни, OLAP става синоним на многомерен изгледи на бизнес информация. Тези многомерни изгледи се поддържат от технологията за многомерни бази данни. Тези многомерни изгледи предоставят техническата база за изчисленията и анализите необходими на едно интелигентно бизнес приложение.
“Имайки RDBMS (Система за управление на релационни бази данни) система не означава че незабавно имаме система подпомагаща взимането на решения. Още откак са станали достояние на потребителите RDBMS системите никога не са претендирали че могат да предложат мощни функции за синтезиране, анализ и обединяване на информация (функции комплексно познати като многомерен анализ на данни)."
- E. F. Codd, Computerworld
OLTP приложенията се характеризират с това че много потребители създават, обновяват или извличат определен запис. Ето затова OLTP базите данни са оптимизирани за работа с транзакции. OLAP приложенията се използват от аналитици и мениджъри, които често искат силно обобщен изглед на данните, като общо продажби по продуктова линия, по регион и т.н. OLAP базата данни обикновено се обновява наведнъж, често от няколко източника, както и предлага мощен аналитичен back-end на много потребителски приложения. OLAP базите данни са оптимизирани за анализи.
Докато релационните бази данни са добри в бързото извличането на малък брой записи от базата данни, те не са добри в извличането на голям брой записи, като същевременно да ги сумират. Бавното време за отговор и прекомерното използване на системни ресурси са главните характеристики на приложения за подпомагане вземането на решения изградени върху технологията на релационните бази данни.
Много от проблемите които хората се опитват да решат с релационни бази данни са всъщност многомерни. Като пример SQL заявка за извеждане на общия брой продажби на даден продукт по регион, продажбите за даден регион по продукти и т.н. може да се наложи да сканира, ако не всички то повечето от записите в таблицата за продажбите и може да отнеме часове за изпълнението си. OLAP сървър може да върне отговор на тези заявки за секунди.
OLTP приложенията обикновено работят с данни разбити на атоми (по записи), за разлика от OLAP приложенията, които обикновено работят с обобщена информация. Докато OLTP приложенията обикновено не се нуждаят от исторически данни, то почти всяко OLAP приложение е свързано с разглеждане на тенденции и затова е нужна историческа информация. OLAP базите данни е нужно да могат да се справят с “time-series” данни — ще бъде обяснен подробно по-долу. Докато OLTP приложенията и базите данни биват организирани около специфичен процес (като приемане на заявка например), OLAP приложенията обикновено са "тематично ориентирани" отговаряйки на въпроси като "Кои продукти се продават добре?" или "Кои са най слабо представящите се офиси?"
Какво е многомерна информация?
Релационните бази данни са организирани като списък от записи. Всеки запис съдържа съответната информация организирана по полета. Типичен пример е списъка с клиенти с полета за адрес, телефонен номер и т.н, както е в следващия пример:
Релационната таблица е базирана на простия формат редове-колони. В този пример таблицата има 3 колони (наречени полета) и четири реда (наречени записи).
Докато тази таблица има няколко колони, всяка частичка информация се отнася до само един клиент. Всъщност тази таблица има само едно измерение. Ако се опитаме да направим двуизмерна матрица с името на клиента по редове и което и да е друго поле (като телефон например) по колони бързо ще видим че съответствието е само едно-към-едно:
Разглеждайки "клиент по телефонен номер" или "телефонен номер по клиент" дава съответствие едно-към-едно. Ето защо тези данни не са удобни за многомерно показване.
Можете да поставите всяко едно поле надолу по редовете и което и да е друго поле по колоните и все ще се получава само едно-към-едно съответствие. Тази таблица ни показва че тази информация не е многоизмерна и затова не е нужно да се съхранява в многоизмерна база данни.
Сега нека погледнем към релационна таблица в която има повече от просто съответствие едно-към-едно между полетата. В следващия пример имаме продажните на всеки продукт във всеки регион. Да предположим че компанията предлага четири продукта (гайки-nuts, винтове-screws, болтове-bolts и щайби-washers) които са продавани в три района (източен-East, западен-West и централен-Central). Ето как ще изглеждат данните в релационна таблица:
Тази релационна таблица има повече от един продукт за регион и повече от един регион за продукт. От тук следва че е удобно да представим информацията многомерно в следващата диаграма.
Много по-прегледно може да представим информацията в двуизмерна матрица:
Тази информация за продажбите по същество си е двуизмерна матрица (двете измерения са продуктите и регионите). И при все че информацията може да се представи в релационна база данни с три полета то тя много по-естествено се представя като матрица с две измерения — продукти и региони.
Сега нека споменем как ще се отличават запитванията към тези две таблици. Ако всичките ви вапроси към базата данни ще са от типа "Какви са продажбите на гайки в източния регион?", "Какви са продажбите на шайби на запад?" и други такива въпроси които биха извлекли само един ред, то тогава не е нужно да поставяме тези данни в многоизмерна база данни. Но ако искате да зададете въпроси като "Колко са всички продажби на гайки?" или "Колко са продажбите ни на запад?", то отиваме на варианта запитване, което извлича множество редове и ги сумира за да ни върне резултат. Ако базата ни е по-голяма, такава че да имаме хиляди артикули, времето необходимо на релационната база данни да извлече всички редове и да ги сумира става непоносимо. Типична релационна база данни може да сканира няколко стотин реда за секунда. Типична многоизмерна база данни може да попълни стойностите в редовете и колоните със скорост от 10,000 в секунда че и повече. Както виждаме в примера е лесно да генерираме запитване, на което ще му трябват минути или часове за да върне резултат ползвайки релационната технология, но в същото време би отнело само секунди ползвайки многоизмерната OLAP технология.
Запитвания като "Колко са продажбите на гайки?" или "Намери всички продажби в източния регион" включват аритметични действия по редове и колони, точно като в електронна таблица. За да даде отговор на въпроса "Всички продажби на изток" двуизмерната база данни просто намира колоната наречена “изток” и просто сумира всички числа в нея. Същото запитване към релационна база данни трябва да потърси и извлече 4 отделни записа където регион="изток" и сед това да събере стойностите на полето продажби на тези записи. Многоизмерната база данни може да намери колоната наречена "изток" и да обедини съдържанието и в доста по-кратко време, отколкото времето необходимо на релационната база да намери всичко “източни” записи. Затова за този тип запитване многоизмерните бази данни имат огромно предимство по отношение на производителността.
Обединяване на данните: Ключът към бързият отговор
Времето за отговор на запитване към многоизмерна база, още зависи от това колко числа трябва да се съберат. Това което всички желаят е бързо време за отговор, независимо от запитването. Единствения начин да се постигне добро време за отговор е да се пазят изчислени стойности за всички логически субтотали и тотали. Всъщност точно това правят някой с техните релационни таблици. Разликата е в това, че многоизмерните бази данни могат извършват аритметични действия по колони и редове стотици, че дори и хиляди пъти по-бързо отколкото релационните бази данни, така могат да обединят данните от огромна база данни, за няколко минути или часове.
Ползвайки предишния пример, да предположим че искаме да имаме едно доста добро време за отговор от нашето приложение, независимо от запитването. С релационна база данни времето за изпълнение на запитването е правопропорционално на броя записи които бижат извличани от базата. Така можем да направим извода, че ще е необходимо четири пъти повече време за изпълнението на запитването "Всички продажби на изток?", отколкото на запитване връщащо един запис като "Продажби на шайби на изток?" например. За да изпълни първото запитване е необходимо да се извлекът четири записа и да се сумират. Ако попитаме "Какви са всички продажби, независимо от региона?" е необходимо да сумираме всички 12 реда от таблицата (4 продукта, 3 региона). This would това запитване ще отнеме близо 4 пъти повече време от конкретизираното запитване извличащо един запис.
За да постигнат добро и сравнително еднакво време за отговор, повечето системни дизайнери обединяват тоталите и ги записват обратно в базата данни, примерно така:
В тази релационна таблица преизчислените тотали по регион и продукт елиминират нуждата от изчисляването им при поискване. Резултата е кратко и еднакво време за отговор.
С така обединените данни, можем да отговорим на всяко запитване относно продажби за регион и/или продукт, извличайки само един запис. Както ще видим това работи доста добре, докато базата не почне да става доста голяма - тогава преизчисляването на тези тотали може да отнеме повече време, отколкото часове има в денонощието.
В предишния пример, изчисляването на тоталите включва 28 операции за четене и 8 операции за запис в базата данни. Типична релационна база данни може да чете около 200 записа в секунда и да записва около 20 нови. Така че обединяването на информацията от тази маничка база ще отнеме по-малко от секунда. Но всъщност е много по-типично да се работи с бази, за които обединяването може да отнеме дни или седмици.
Многоизмерен OLAP сървър може да извърши същото обединяване с аретмитични действия по редове и колони. Докато релационна база данни може да извлича няколко стотин записа в секунда, то добър OLAP сървър трябва да може да обедини 20 000 - 30 000 клетки в секунда (долу-горе колкото може да са записите в една релационна таблица). Именно възможността да обединява данните с такава висока скорост е ключът към мощта на многоизмерните бази данни.
Нека да видим сега как същото обединяване ще изглежда в многоизмерна OLAP база данни. Не е нужно да знаете нищо за технологията на базата данни за да забележите, че това двуизмерно представяне на данните с тотали по редове и колони, е доста по-смислено от предишния изглед (в релационна таблица). И както следващата таблица заема доста по-малко място на този лист, отколкото предходната релационна таблица, така и многоизмерната OLAP база данни ще заеме по-малко място на диска, тъй като на регионите и продуктите, не се повтарят, както се повтарят във всеки запис на релационната таблица. Физическото съхранение на данните на диска и схемата на индексиране за намиране на данните са ключът към скоростта на OLAP базата данни.
Обединяването е прост с многоизмерна OLAP база данни. Просто добавяме тотали по редовете и колоните.
Сега нека да обърнем внимание на малко многоизмерна терминология: Клетките съдържащи “оригиналните” данни (показани с по-бледия фон) се наричат входящи. Изчислените тотали (показани с удебелено) се наричат изходи. Изток-East, Запад-West, Център-Central се наричат вход-членове на измерението на регионите. Тотала по регион се нарича изход-член на измерението на Регионите. По подобен начин, Гайки-Nuts, Винтове-Screws, Болтове-Bolts, Шайби-Washers, както и тоталите са членове на измерението на продуктите. Числата (в този случай да ги наречем "кутийки") представляват променливи. За тази таблица, Може да се каже че променливите са отнесени към Продукт и Регион. Променливите по принцип са числови стойности като продажби, разходи, печалби и т.н. Числата в сечението на всеки регион и продукт заемат съответната клетка, точно както е в електронна таблица. Клетките са резултат от комбинации. Предишната таблица има 20 комбинации и затова има и 20 клетки.
Измеренията са груб еквивалент на полетата от релационната таблица. В предишната релационна таблица имаше полета неречени Продукт-"Product" и Регион-"Region". В многоизмерната база данни продукт и регион са измерения. Клетките грубо могат да се отъждествят със записите. В примера в релационната таблица имаме същия брой записи, колкото клетки имаме в многоизмерната база, а и съдържат същите променливи (числа).
Проста йерархия при измеренията
В предишния пример имаме проста йерархия и в двете измерения (продуктовото и регионалното). Тази проста йерархиа може да се представи графично така:
При простата йерархия всеки наследник има само един родител.
Всеки индивидуален продукт се отнася към продуктовия тотал и всеки индивидуален регион се отнася към регионалния тотал. Това е проста йерархия, което по същество означава че всеки “вход” се отнася само към един тотал. Възможно е някое от измеренията - продуктовото например да има няколко начина за образуване на тотали. Примерно по размер, цвят, фабрика в която е произведен продукта и т.н. По-долу в часта “Всички измерения не се създават еднакви”, ще разгледаме примери за йерархични структури които са доста по-сложни.
Простата йерархия може да има и няколко нива, като например:
В този пример градовете се отнасят към щатите, щатите към регионите и т.н. Ако OLAP сървърът ви не поддържа няколко нива на йерархия в дно измерение, то ще трябва градовете, щатите и регионите да се разглеждат като отделни измерения.
Причината да се нуждаем или от няколко нива на йерархия или от допълнителни измерения се крие в това, че не можем да смесим градовете, щатите и регионите в едно измерение, освен ако нямаме йерархия в измерението. Да вземем следния пример - Потребителите искат да могат да видят продажбите или по регион или по щат. Ако нямаме йерархични нива в измерението, може да се опитаме да създадем двуизмерна база като тази:
Смесването на Градове и региони в едно измерения, означава че тоталите по колони ще са неверни, защото стойностите за определен град, вече са включени към стойностите за региона към който принадлежи града.
Събирането по редове си работи нормално. Може да видим какви ще са продажбите на изток или в Ню Йорк примерно, но пък тоталите за определен продукт ще се разминават, тъй като колоната съдържа продажбите за даден щат и също за даден регион, но цифрите за съответния щат вече са включени в цифрите за региона.
В многоизмерните бази данни без йерархични нива, решението на проблема е да се добави отделно измерение за щата.
Поставянето на градовете и щатите в различни измерения, прави тоталите по редове и колони верни. Но по този начин,ще се получи празна клетка в сеченията когато продажбата е за даден град който не е в съответния щат.
Сега вече може да сбираме продажбите на даден продукт по регион или по щат и ще получаваме коректен резултат. Обаче този начин на представяне е доста по-усложнен. Представете си сега че разделянето по географски признак има три или четири нива, нека също така и продуктите бъдат категоризирани в групи от няколко йерархични нива, а сега се опитайте да си представите как би изглеждал седем или осем мерен Данов куб!
Другият проблем при това представяне на данните се състои в това че базата данни с градове и щати в различни измерения ще стане доста разпиляна, в смисъл че ще се получат множество клетки които ще бъдат празни. Докъто даден град принадлежи на само един щат, клетките в сечението му с всички другите щати ще останат празни.
Правилното решение на проблема се крие в ползването на йерархични измерения. Щатите в източниа регион ще бъдат едно ниво по-долу (или казано на OLAP жаргон точно под Изток), градовете ще са точно под определения щат и т.н.:
Йерархичните измерения позволяват градовете, щатите и регионите да съществуват в едно измерение, а не да са в отделни измерения за всяко ниво.
С така създаденото географско измерение, съдържащо йерархично подредени региони и щати, сега можем да запитаме базата данни за продажбите по регион и щат и тоталите винаги ще са коректни. Базата данни знае, че при изчисляването по колони, не трябва да включва членовете на измерението на регионите, които са от друго йерархично ниво. Например тя може да сабере продажбите за всички градове, за всички щати или за всички региони, но знае че сабирането на щати и региони заедно дава грешен резултат, тъй като продажбите за даден щат, вече са включени в продажбите за съответния регион към който принадлежи щатът.
Представата за нива на йерархия е доста полезна, когато формулираме OLAP запитвания. За пример можем да посочим следното - ако потребителят иска да види матрица с продуктите по колоните и регионите надолу по редовете, то той трябва да определи на какво ниво на регионалното измерение желае да погледне, само градове, само щати и т.н.
Ако регионалното измерение има ниво по регион, по щат, по град и т.н., потребителят може да избере някое или всички от тези нива в OLAP запитването. В ляво потребителят е избрал Продукт по Регион, на щатско ниво. В дясно е избрано Продукт по регион на ниво град.
Също така ползването на йерархични нива е много полезно за извършване на "drill down" (за термина “drill down” може да се изпише доста, но в общи линии това е действието когато тръгвайки от някаква синтезирана информация - продажби по региони в нашия пример, потребителят последователно детайлизира справката за да открие интересуваща го информация.) до подходящо ниво на детайлизация. Например може първо да погледнем числата за продажбите по региони, след това да поискаме продажбите по щати за източния регион, за да намерим кой е “виновникът” за спад на продажбите на изток. Много OLAP приложения поддържат drill down през всички йерархични нива, като това е дотолкова опростено че потребителят само трябва да кликне върху линията с информацията за която иска детайли и приложението веднага показва информацията от по-ниското йерархично ниво. “По долу в “Drill down” до релационни данни” Ще разгледаме защо е от значение да се ползва OLAP сървър за извършване на обединяването на информацията, но все още запазваме най-ниското ниво на детайлност в релационна база данни.
Променливи
Променливите са числови мярка, подобни на стойностните полета в релационната база данни, като "Продажби", "Разходи", "Цена" и т.н. Някои OLAP сървъри третират променливите като специално измерение и затова има доста добра причина. Помислете за променливите като за отнесени към някакво измерение в базата данни. Например “продажби” могат да се отнесат към регион, продукт, клиент. От друга страна “Цената” може да е идентична за всички региони и клиенти и затова е нужно да се отнесе само към продуктовото измерение. Ако променливите бяха само обикновенно измерение, можеше да опитате да отнесете цената към всички останали измерения и тогава просто щяхме да имаме много ненужно запалнени клетки в базата данни. С третирането на променливите като специален случай на измерение, може да избираме само смислени измерения за всяка променливи.
Тази концепция се нарича Независимо Отнесени Променливи и е основен инструмент за оптимизиране производителността на многоизмерните бази данни, като редуцираме големината им до логичния минимум, както и намаляваме комплектността на товара на базата данни. Не всички OLAP сървъри поддържат независимо отнесени променливи.
Променливите (при някой OLAP сървъри) могат да се дефинират като математически свързани към други променливи. Такива променливи понякога се наричат комплексни променливи. В нормално измерение ("Региони" например), връзката между членовете на измерението може да се изрази само със събиране. Например, щата "New York" ще бъде проста сума на градовете чиито родител е щата. Променливите трябва да могат да се дефинират чрез доста сложни математически връзки. Тези връзки могат да включват комплексна аритметика, изчисляване на средни стойности, стойности отнесени към времето, че даже и уравнения. Добре е да се търсят такива възможности в OLAP сървъра, тъй като отсъствието им обикновенно означава че ще е нужно доста външно програмиране, за да се дефинират такива връзки външно от базата данни.
Променливите са по-специални, защото трябва да включват различни правила за обединяване. Например, когато продажбите се разглеждат от продукти, към общо, то различните цифри са аритметично събрани. От друга страна цената не трябва да се събира, защото тя е средно аретметично от цените на продуктите. Също така когато разглеждаме данните за един период и ги отнасиаме към друг (да кажем дневни към седмични), променливите се третират по различен начин. Обръщането на дневните продажби към седмични става като се съберат продажбите за отделните дни. Но обръщането на среднодневни цени към средно седмични определено не става чрез просто събиране.
Променливите също така може да съдържат информация как стойностите да се конвертират от една валута към друга (например Продажбите и Дълготрайните активи почти винаги ползват различни правила за конвертиране от една валута в друга), описание, дефиниции и т.н. Всички тези атрибути на променливите обикновенно се пазиат в даннов речник.
Още една концепция която ще представим сега е изведена променлива. Изведената променлива е променлива, която за потребителя си изглежда като променлива в базата данни, но в действителност се изчислява при изпълнение на запитването. За пример базата данни може да съдържа променливи за приходите и разходите. Може да си направим променлива "Марж" като аритметична разлика между приходите и разходите и да запазим тази променлива в базата данни. Алтернативата е да дефинираме "Марж" като изведена променлива, което означава че стойността и се изчислява при запитването по формулата Марж = Приходи - Разходи (тук предполагаме че OLAP сървъра поддържа изведени променливи). Изведените променливи естествено не заемат място в базата данни така че това е доста добър начин да се намали размера на базата и да се намали времето за обединяване на информацията, жертвайки малко време, когато се изпълнява запитване включващо изведени променливи. От гледна точка на потребителя, тази изведена променлива си изглежда като всяка друга променлива.
Трябва да се има предвид, че база данни която не третира променливите като по-специално измерение с изброените до тук възможности по всяка вероятност ще изисква доста повече работа по разработката на приложението. В същото време, общата производителност сериозно ще пострада.
Векторна аритметика
Данните които са организирани в масиви, могат да се обработват по-бързо и по-лесно, отколкото същите данни в релационна таблица. Например лесно можем да извадим равнината на Действителните продажби (Actual) от равнината на планираните продажби (Budget) за да създадем равнината на различията (Variance):
Векторната аритметика позволява да се извършват аритметични действия над цели равнини от базата данни.
В многомерните OLAP сървъри, тази векторна аритметика може да се опише с една операция. В случай на релационното представяне, всеки запис от базата данни трябва да бъде прочетен, действителните (actual) да бъдат извадени от планираните (budget) и накрая да се запише в таблицата резултата в новото поле за разликата. Тези операции могат да отнемат на порядък повече време.
Векторната аритметика позволява значително по-бързо изчисляване на изведени променливи. Тъй като можем бързо да извадим действителните (actual) от планираните (budget) за да получим разликата (variance), то тогава не е нужно да съхраняваме получената стойност за разликата в базата данни.
N-Мерни бази данни
двуизмерните бази данни са лесни за разбиране. Сега нека да разгърнем концепцията към три и повече измерения. Да предположим че вземаме предишния пример и добавяме планираните (budget) продажби за всяка комбинация продукт-регион. В релационна таблица можем да направим това като добавим ново поле "Act/Bud" и така всеки запис от таблицата се определя като дейстжителни продажби (Actual) или планирани (Budget). При напално нормализирана база данни добавянето на това ново поле с две стойности (Actual/Budget) удвоява броя на записите:
Тази релационна таблица, доста лесно се конвертира в триизмерна база данни както е показано на следващата диаграма.
В многомерното представяне, конвертираме двумерната матрица (съдържаща продажбите по регион) в тримерен куб:
Добавянето на "Act/Bud" измерението превръща двумерната матрица за продажби по регион в тримерна база данни.
Този 4x3x2 куб има 24 клетки отговарящи на 24-те записа в релационната таблица. Тъй като желаният анализ може да изиска коя да е комбинация от измерения, то трябва да можем да "завъртим" кубът с данни. На горната илюстрация виждаме изглед който ни показва продажбите по регион.
Можем да завъртим данновия куб така че да видим данните от различена гледна точка
Ако завъртим кубът на 90 градуса, лицето което ще е пред нас (ще виждаме) ще ни показва изпълнението на плана по продукт. Ако го завъртим още веднъж, този път ще виждаме изпълнението на плана по регион. Тримерния масив има общо шест страни (лица), четиримерния има 24, а n-мерния има n(n-1) страни. Възможността да “въртим” куба (да виждаме данните от различен ъгъл) лежи в основата на многомерните справки и понякога се нарича "slice and dice."- парчета и зарове.
Практически ограничения върху размера на базата данни
Има едно погрешно схващане на пазара на OLAP бази данни, че размерът е ограничен главно от максималният брой на поддържаните измерения. Истинското ограничение почти винаги е в броя на клетките, а не броя на измеренията. Освен това не всички измереня се създава еднакво. Някой доставчици (на OLAP бази данни) поддържат проста йерархия в измеренията, други поддържат сложна йерархия на много нива. Достатъчно е да споменем, че осем-мерна база данни, ползвайки даден OLAP продукт, може да бъде редуцирана до само три или четири-мерна с друг продукт.
С прости думи можем да кажем, че с нарастването броя на измеренията, броя на клетките нараства експоненциално. Например база данни с две измерения със 100 продукта и 100 региона ще има 10 000 клетки. Ако обаче добавим 3-то измерение (примерно за 52 седмици назад във времето), сега ве1е имаме 52 000 клетки. Добавянето на 4-то измерение за постигнати/планирани/разлика и прогноза ще ни доведе до 2 080 000 клетки. Добавянето на пето измерения в което да съхраняваме разбивка по 10 типа клиенти, ще доведе до 20 800 000 клетки. Една 16-мерна база данни със само 5 члена във всяко измерение ще има над 152 милиона клетки!
Повечето комерсиални OLAP сървъри, стигат лимита си от клетки доста преди да са достигнали лимита на измеренията. Ако един такъв сървър, твърди че поддържа 32 измерения, но има лимит от около 2 милиона клетки, то при само 2 члена на всяко измерение, то 32-мерна база данни ще има 232 клетки около 4.3 милиона. Така дори ако всяко измерение има само два члена, пак няма да можете да позлвате всичките 32 измерения поради ограничението от 2 милиона клетки. Всъщност в действителността повечето измерения (като Продукти и Региони например) имат доста повече от два члена.
Типът данни Time-Series
Времето е може би най-често ползваното измерение в OLAP базите данни. Почти всеки анализатор се интересува какви са тенденциите - тенденции при продажбите, при приходите, сезонност на пазара и т.н. Потребителите искат да видят тенденциите в почти всички аспекти на своя бизнес, да сравнят данните със същите периоди на предходни години и т.н. поредица от числа представляваща някаква променлива (например продажбите) през времето се нарича time series.
В клетка от електрона таблица може да се съхранява само единични число. Да предположим че е нужно да съхраним по дневна информация с 10 годишна история във всяка клетка. Това е идеята на типът данни time-series.
Добавянето на типът time-series (в момента е имплементиран в няколко OLAP сървъра) ни позволява да съхраняваме целия низ от числа, представляващи някаква информация във времето във произволна клетка. Така ако OLAP сървърът поддържа този тип данни, може да си съхраним историческата информация във всяка клетка, вместо да отделяме измерение за времето.
За разлика от другите измерения, времето има много по-специални характерни черти и правила. Първо се характеризира с периодичност, определяща интервалът от време между числата в поредицата. По често ползваните периоди са дневен, седмичен, месечен, за тримесечие и т.н. На второ място типът time-series трябва да включва правила за конвертиране от един период към друг. Тези две неща се наричат атрибути на time-series.
Преди да се впуснем в повече детайли относно типът time-series, нека погледнем как бихме се справили с такива исторически данни, ако нямаме на разположение специален тип. Повечето OLAP сървъри все още нямат такъв специален тип данни.
Ако нямаме специален тип за исторически данни, то трябва изрично да дефинираме едно от измеренията си в базата данни като време-“time” и тъй като искаме аритметиката по редове и колони да работи коректно, то трябва да си изберем един период който ще ползваме в цялата база данни (примерно месечен) и да изразяваме цялата информация за такъв период от време. Членове на измерението на месеците-“months” ще бъдат изрично дефинирани Jan, Feb, Mar, и т.н.
При отсъствие на специален тип time-series, трябва да декларираме едно от измеренията като “време” и изрично да означим неговите членове.
Ако искаме да ползваме различни периоди, то трябва да ги организираме като йерархична структура в измерението на времето. Това ще изисква доста програмиране и поддражка, особено пък ако организацията няма проста годишна фискална структура. В допълнение към голямата сложност, това йерархично представяне на времето съшо така е способно да разрастне базата данни с порядак. (от GBytes към TBytes)
Конвертирането на всички данни към една периодичност може да е незадоволително решение. Ако конвертираме седмичните си данни към месечни преди зареждането на базата данни, то губим за винаги възможността да погледнем към седмичните данни. На второ място такова конвертиране на данните е що годе сложно и изисква една допълнителна стъпка при подготовката на данните. На трето място - с добавянето на нови периоди, се добавят колони в матрицата, която може да стане прекалено голяма.
Решението на проблемите е да не се ползва времето като измерение, ами да си се ползва специализиран тип данни за представянето на историческата информация. Това също така позволява по интелигентен начин данните за една периодичност да се конвертират към друга автоматично от самия OLAP server.
Клетка съдържаща time-series данни,може да съдържа много информация, сравнена с проста числова клетка, че дори и с цял запис от релационна таблица. Например информацията в клетка time-series за продажбите може да има следните атрибути:
• Start date = 1/1/94
• Periodicity = Daily, business days only
• Conversion = Summation
• Long description = Variable=Sales, Product=Nuts, Region=East
• Data type = Numeric, single precision
• Sparsity = Non-sparse
• Calendar = 445 Fiscal year
• Data points = 708,800,821,743,779,856,878,902,799, ...
Start date - датата отговаряща на първия data point (първия елемент от редицата с продажбите);
Periodicity - периодичност - може да бъде дневна, седмична, месечна, годишна по часове и т.н. Също така може да се отчитат или календарни дни или работни дни.
Conversion method - метод на конвертиране на периода към друг период. Summation - ще се събират дните за да се получат седмици; Last Period - ще се ползва стойността за последния ден от седмицата (подходящ метод за банковия баланс например или за други суми които се натрупват); Average - взема се средна стойност за седмицата. Има също така и други методи като weighted averages - средно претеглено например.
Data type - тип на данните в поредицата - числови с единична или двойна точност, текстов низ или дати.
Sparse - разредена - данните в някоя time-series могат да се повтарят. Например цената може да се промени само веднъж в годината. Дефинирането на дадена time-series като sparse ще накара базата данни да съхранява само датите на които цената се е променяла и новата стойност на цената.
Data points - поредица с данните - съхранява същинските стойности за периода.
Всеки OLAP сървър, който може да ползва time-series трябва да има задълбочени “знания” за календара. Да има възможност да конвертира седмиците в месеци не е достатъчно, трябва да може да направи и обратното - да разпредели месеца по седмици. Трябва да знае каква е разликата между календарна и фискална година. Трябва да знае за отчетни периоди, като лунна година, 4-4-5 отчетни периоди и т.н. Също така трябва да знае за високосните години и празниците както и много други павила нужни за успешното коректно конвертиране на периоди. За пример конвертирането на седмични данни към дневни изисква знания относно това дали си имаме работа с 5-дневна или 6-дневна работна седмица и т.н., дали делниците са с еднакво тегло като празниците.
Макар и изглеждайки просто, с логаритмите за конвертиране на периоди изискват вграждане на доста обширни знания относно календарните правила и са едно доста сложно парче от софтуера. Веднъж имайки тази част, това значително опростява бъдещото разрабтоване на приложения и съхраняване на данни, тъй като всички данни могат да бъдат съхранени в тяхната “родна” периодичност, а след това да се ползват в коя да е друга периодичност. Това елеминира необходимостта да изграждаме времево измерение от нулата и писането на външни процедури за конвертиране от една периодичност към друга.
Разредени бази данни
Като добавяме измерения към многомерна база данни, боря на Data-point-ите или на клетките нараства бързо. Лесно можем да си направим извода че не продаваме всеки продукт, във всеки обект всеки ден. На практика някой от по-малките обекти може да поддържат само 20% от продуктовата гама. За тези обекти 80% от клетките ще бъдът празни. На практика много от маркетинговите бази данни може да имат повече от 95 процента от клетките празни или съдържащи нулеви стойности. В ситуация в която по-малко от 10 процента от клетките имат някакви данни, казваме че базата данни е запълнена разредено или просто я наричаме разредена.
Друг пример за разредени бази данни е когато, много клетки съдържат една и съща стойност. Ако матрицата на продажбите ни на дребно има ценово измерение например, то едно и също число може да се повтаря във всички 1200 обекта например. Така ако имаме 3000 прудука, то ще имаме 1,200 data-point-а които ще бъдат еднакви. Когато вземем и дните под внимание, ситуацията ще стане и още по-лоша. Не смяната цената на продукта вски ден, така че ще имате една и съща стойност за всички 1200 обекта за всеки от дните през които цената не се е променяла. Вместо да повтаряме едно и също число в базата данни, то същата информация можем да имаме като съхраним само веднъж числото заедно с броя на дните в които се е запазило непроменено.
Ако вземем за пример ценовата променлива, даден продукт може да има една и съща цена за всички обекти за много дни наред.
Релационната таблица няма как да знае ако цената е останала непроменена за 200 последователни дни, защото релационната таблица не е организирана в измерения. Така сляпо ще се попълва запис след запис с дублирана информация. Така от една страна ще запълним излишно дисково пространство, но по-важното е че скоростта за обработка на заявките ще спадне. OLAP сървър, който ползва разредени данни, може да пропуска нулевите стойности, липсата на данни и съхраняването на дублирана информация.
Всички измерения не се създават еднакви
Някой от производителите на OLAP сървърите, някой предлагат само прости измерения, които не поддържат йерархични нива или специални типове данни. Други предлагат доста усъвършенствани измерения с няколко йерархични нива, богата гама от типове данни, както и разни други възможности. Добре е ако може вашите данни, да се събират във възможностите на OLAP сървъра, без да е необходимо много външно програмиране. Тази задача може да бъде доста сложна, защото спецификациите на OLAP сърърите могат да са доста объркващи.
За пример нека вземем спецификациите за размер на базата данни. Това може да се онесе към максималния брой клетки в базта данни или към максималното дисково пространство което може да бъде заето от базата данни. Както по-рано споменахме, максималния брой клетки в базата данни е един от най-важните критерии за избора на OLAP сървър. Но дори тази спецификация може да бъде объркваща. Да предположим че имаме две бази данни всяка с размер от 100 милиона клетки. Ако едната поддържа типа time-series, а другата не, то сравнението между двете се обезсмисля, тъй като типът time-series може да съхранява хиляди числа в една клетка, то базата данни поддържаща този тип, може да има капацитет който е 1,000 пъти (че и повече) по-голям от капацитета на другата база.
Има още две други неща които са в пряка зависимост от размера на базата данни:
1. Зависимост на скоростта на обединяване - размерът на базата данни може да не е ограничаващ фактор. База данни с много голям капацитет, но със ниска скорост на обединяване на данните може да не е по-полезна от база данни с ограничен капацитет.
2. Може да има голяма разлика между броя на клетките в базата данни и броя на данните които наистина съдържат информация. Някоя база данни може да има 100 милиона възможни комбинации (или клетки) от продукти, региони и т.н. но само около процент от тези клетки да съдържат някакви стойности - разредена база данни. Многомерна OLAP база данни може да има две ограничения спрямо обема:
a) броят на комбинациите;
b) броят на комбинациите съдържащи реални данни .
Няколко думи относно размера на базата данни: някои производители на OLAP сървъри се опитват да заобиколят наследените проблеми с размера на базата данни, с предлагането на връзки и обединявания над различни таблици по време на изпълнение на заявките. Както и при релационните бази данни, такива операции по време на изпълнение на заявката водят до сериозен компромис с производителността.
Измеренията са дори по-объркващи. Всеки опит да сравним броя на измеренията поддържани от базата данни с капацитета на базата данни е обречен на неуспех, заради различните дефиниции на това какво е измерението и какво трябва да съдържа. Осем-мерна база данни в някой продук, може да се представи само като двумерна в друг продукт.
По долу следва списък на някой от важните характеристики поддържани от някои OLAP сървъри, които характеристики могат да понижат сложността на дизайна на базата данни и да опростят разработването на потребителски приложения:
• специален тип данни time-series;
• специални измерения за различни променливи;
• многослойна йерархия в измеренията;
• класове в измеренията;
• Изведени променливи;
• Независимо отнесени променливи;
• псевдоними;
• скорост на обединяване.
Например база данни която няма специален тип time-series може да ползва три различни измерения или нива в измерението за да съхранява дневни, седмични и месечни данни. Но ако базата предлага този тип, както и интелигентни функции за конвертиране от една периодичност в друга, то тези три измерения се обезсмислят.
Някои сървъри имат максимален брой на измеренията, други имат максимален брой на измеренията за една променлива. С други думи Продажбите могат да се отнесат към различно множество измерения сравнени с цената например.
Някои продукти изискват подмножества от членове на измерения, като размер, цвят и т.н. на даден продукт, да бъдат дефинирани като отделни измерения. Други бази данни поддържат класове от членове в дадено измерения, което елиминира нуждата от допълнителни измерения. Също така както е отбелязано в следващия раздел многослойни йерархични нива в дадено измерения, могат да елиминират нуждата да се поставят различни нива на детаилизация в различни измерения.
Сложна йерархия и класове в измеренията
Може би най-големия фактор за решаването колко измерения ще има конкретна база данни е съществуването на многослойна йерархия и класове в измеренията. Например база данни с продажбите на шампоани, може да искаме да детайлизира продуктовата гама по размер на опаковката (200мл, 250мл. и т.н.), по тип (суха, мазна, нормална коса), както и по някой други признаци. Ако OLAP сървърът поддържа многослойна йерархия в измеренията си, но всички от тези връзки могат да се изразят в едно измерение. Едно йерархично ниво ще детайлизира продукта по размер, едно по тип и т.н. Ако не се поддържа възможността за многослойна йерархия, то ще е нужно да имаме различни измерения за размер, тип и т.н., което доста ще усложни базата данни и ще увеличи броя на клетките (размера и). Друго място където често се ползва многослойна йерархия е в географското измерение. Да предположим че данните за продажбите са съхранени по клиент, всеки клиент може да бъде детайлизиран по град, щат и т.н.
Някой OLAP сървъри, поддържат сложна йерархия в измеренията си. Един наследник може да има няколко родителя.
Без сложна йерархия, базата данни трябва да има отделно измерение за всяка детайлизация на клиента:
Без сложна йерархия в измеренията, се нуждаете от повече измерения. В този пример, две са нужни, когато иначе е необходимо едно.
Едно от най-мощните средства за опростяване на многомерна база данни и намаляване на броя на измеренията са класовете. Класовете са типични атрибути като "размер", "цвят" и други характеристики дефиниращи подмножество на членове на измерение.
Drill-Down - детайлизиране на данните
Повечето организации пазят данните си в релационни бази данни. Има случай в които не е нито нужно, нито препорачително да се репликират всички данни в многомерна база данни. Например да предположим че имаме база данни за продажбите на дадена фирма в RDBMS за 50,000 клиента. И да предположим сега че тези 50 000 клиента са от 500 града, от 50 щата, които са от 5 региона.
Обобщената информация може да се съхранява в многомерна база данни, докато детайлизираната все още се съхранява в релационна.
Извличането на един запис от многомерна база данни не е по-бързо от извличането на запис от релационна база данни. Ето защо не е нужно да поставим записа с индивидуален клиент в многомерната база данни. Извличането на сумарния запис “Total” ще изисква събирането на 50,000 записа—нещо което определено не искаме да направим с релационна база данни. Извличането на тотали по региони ще изисква събиране на грубо казано около 10,000 клиенти за даден регион—все още прекалено много за релационната технология. В момента в който поискате детайлизация по градове, по всяка вероятност ще опитате да извлечете около 100 клиента за даден градy—все още си струва да го направите в многомерна база данни. Ако поискате да видите продажбите за определен клиент, то ще извлечете само един запис, таке че ще получите отговор и от релационната база данни със същата скорост както и от многомерната. Казано накратко - хубаво е да имате възможност в процеса на детайлизация “drill-down”, да можете от дъното на многомерната база данни да отидете към релационната. Някои комерсиални OLAP сървъри поддържат тази възможност.
Причината тази техника да бъде полезна е че повечето данни все още се съхраняват в детайлизиран вид. В горния пример това са 50,000 записа в релационната база данни, но в същото време в многоизмерната имаме само 556 члена или около 90% от обема данни си седи в релационната база данни, но въпреки това вие все още имате всички предимства по отношение на скоростта на многомерната база данни.
Сигурност и здравина
Сигурността е важно нещо при всяка база данни, която се ползва от няколко потребителя. Сигурността на базата данни има две главни задачи:
1.Да пази неоторизирани потребители да не пипат базата данни;
2.Контролира достъпа до част от данните на базата на потребителско име (някои потребители имат право да четат дадени данни, други могат да ги четат и да ги променят и т.н.).
Системата за сигурност обикновено е защитена с парола, като всеки потребител има собствено уникално потребителско име "user id" и съответно някаква парола. Потребителите могат да бъдът групирани в групи и привилегиите върху данните да се контролират за цяла група потребители. Индивидуален потребител или група могат да имат ограни1ен достъп до коя да е под част от базата данни. Например, ако сте мениджър продажби за източния регион, то достъпът ви следва да е ограничен до "Select Region Below East." Така, когато ползвате системата, то всичките ви изгледи “viewes” са ограничен до данните за източния регион.
Здравината покрива част от функциите на базата данни за архивиране - backup, възстановяване - recovery и поддръжка - maintenance на базата данни. Например ако някой драпне кабела на компютъра по средата на зареждането на базата данни, ще бъде ли базата повредена? Ще може ли лесно да се възстанови след такова нещо?
Всъщност и тук транзакциите към базата данни трябва да могат да бъдат ограждани и изпълнявани така че или всички операции се изпълняват успешно или нито една от тях не променя базата. Ако има някакви сривове, базта данни трябва да пренебрегни всички недовършени транзакции и да се върне в състоянието в което е била преди сривът, също както е при OLTP системите. Ако OLAP сървърът ви е наистина стабилен, то единственото нещо което ще доведе до повреда на базата данни е физически проблем с дисковото устройство.
Automatic dimension maintenance-автоматична поддръжка на измеренията е много важна и става още по наложителна с нарастване на базата данни. Ако примерно имаме база данни с 30,000 клиенти, то присвояването на тези клиенти към регион, дилър или нещо друго не е препоръчително да се извършва ръчно. Ако транзакционната база от която OLAP сървъра е зареден първоначално съдържа дилърът или региона към който принадлежи клиента (а това е най често срещания случай), то тогава OLAP сървърът трябва да може директно да прочете тази информация от данновото хранилище и автоматично да изгради OLAP йерархията. Средства за ръчна поддръжка на измеренията, които ви позволяват да изтеглите някой член на измерението от едно място в йерархията към друго, са добри но за сравнително малки бази. Но преминаването през 30,000 члена на екрана на компютъра ви може да е доста досадна задача, тъй че такъв инструмент не е много ценен за поддръжката на голяма база данни.
За да обобщим трябва да добавим и следното - добавянето, изтриването или промяната на родител на даден член трябва да е автоматизиран процес. Синхронизирането на OLAP базта данни с лежащото в основата данново хранилище тряябва да се обезечава от такъв авотматизиран процес.
Отворената архитектура се различава от client/server. Много от client/server приложенията не са отворени. Те имат клиентска част и сървърска част, но тези части обикновено работят само заедно и не може някоя от тях да се замени с друго приложение. Отворени client/server продукти позволяват клиентската част да се ползва с различни сървъри или обратното - сървърската част да се ползва с различни клиенти. Има много предимства за потребителите на отворена архитектура, включително възможността да се позлва смесен софтуер, така че да имаме най-доброто от две системи.
"MDSQL" Multidimensional Query Language - език за структурни запитвания към многомерна база данни
Точно както при релационните бази данни имаме SQL (език за структурни запитвания), многомерните бази данни изискват език на който е възможно да се изразят многомерни запитвания. Pilot Software предложил своя "MDSQL" език да послужи като основа на стандартизиран език за запитвания в многомерни бази данни. Докъто различни комисии по стандартизация разглеждат несъмнено ще предложат различни модификации преди да си дадат благословията за един стандартизиран "MDSQL", то езикът на Pilot Software MDSQL предлага работещи примери за напълно функционален многомерен език за запитвания. Също като релационния SQL, този многомерен език за запитвания е Англо--подобен. По долу следват няколко примера:
За да прегледаме продажбите на no-load mutual funds в Южния район за периода Юли-Декември 1994:
1. Select Dimension Product 'No Load' - избираме от измерението на продуктите No Load;
2. Select Dimension Region South - избираме от измерението на регионите Юг;
3. Select Sales - избираме продажби;
4. Across Time Down Region, Product, Variables - търсим сечението на Времето с променливите на регион и продукт;
5. List period July 94 - Dec 94 - извеждаме периода Юли '94 до Декември '94.
Да видим движенията за последния месец, за същия период на миналата година и да изведем процентна разлика:
1. Time Percentage_Change - time-series процентна промяна;
2. Input month latest as Current_Month - Задаваме текущия месец да е последния;
3. Input month latest minus 12 as Previous_Year_Month - задаваме месеца от миналата година като разлика между текущия и 12 (година назад);
4. Output Month_Variance - извеждаме разликата между месеците
5. Month_Variance = (Current_Month - Previous_Year_Month) % Previous_Year_Month - изчисляваме разликата между месеците като процентна промяна.
За да създадем йерархия в компютърните компоненти:
INPUT
'286' '286 CPU Chip', '386' '386 CPU Chip', '486' '486 CPU Chip', VGA 'VGA color monitor', CGA 'CGA
color monitor'
OUTPUT
Chips 'Total Processor chips', Monitors 'Total Color monitors'
RESULT
Total 'Total Equipment'
LEVEL
Device, Category
Chips='286' sum '486'
Monitors=VGA sum CGA
Total=Chips sum Monitors
За да изведем цифрите само за компютърните чипове, трябва да изберем Продукти само под категорията на чиповете.
Заключение
Есенцията на OLAP сървър технологията е бързо и гъвкаво обединяване на данните и представянето им за лесен анализ. Докато SQL базите данни ще продължат да доминират на пазара на OLTP системи (където е нужна обработка запис по запис), то OLAP сървърите са доста по-висша технология за приложения за бизнес разузнаване. Ефикасен и гъвкав анализ изисква да може да се обединят данните по няколко начина, както и да се разгледат тенденциите през времето. OLAP съръвърите и релационните бази данни могат да работят в хармония и така да изградят една обвивка която може да даде на потребителите бързо нужните данни и да им позволи да анализират лесно данните, така че да могат бързо да вземат най-доброто бизнес решение.
ИЗПОЛЗВАНА ЛИТЕРАТУРА:
Основна:
http://olap.ru/basic/olap_and_ida.asp
Оперативная аналитическая обработка данных: концепции и технологии
В. Щавелёв, leonid@iname.com Ивановский государственный энергетический университет
Допълнителна:
http://citforum.isurgut.ru/consulting/BI/whatis
Что такое Business Intelligence?
Валерий Артемьев 24.04.2003 Открытые системы, #04/2003http://www.olapreport.com/fasmi.htm
What is OLAP?
An analysis of what the increasingly misused OLAP term is supposed to mean
You can contact Nigel Pendse, the author of this section, by e-mail on NigelP@OLAPReport.com if you have any comments or observations. Last updated on April 22, 2003.
http://www.olap.ru/basic/oolap.asp
Основы OLAP
Дмитрий Лобач Статья была опубликована на сайте «Софткей»
