Во претходната статија, зборував за основите на DATA VAULT, ги опишав главните елементи на DATA VAULT и нивната намена. Темата на DATA VAULT не може да се смета за исцрпена, неопходно е да се зборува за следните чекори во еволуцијата на DATA VAULT.
И во оваа статија ќе се фокусирам на развојот на DATA VAULT и преминот кон BUSINESS DATA VAULT или едноставно BUSINESS VAULT.
Причини за појавата на BUSINESS DATA VAULT
Треба да се напомене дека DATA VAULT, иако има одредени силни страни, не е без свои недостатоци. Една од овие недостатоци е тешкотијата во пишувањето аналитички прашања. Пребарувањата имаат значителен број на JOIN, кодот е долг и тежок. Исто така, податоците што влегуваат во DATA VAULT не претрпуваат никакви трансформации, затоа, од деловна гледна точка, DATA VAULT во својата чиста форма нема апсолутна вредност.
За да се отстранат овие недостатоци методологијата DATA VAULT беше проширена со елементи како што се:
- ПИТ (точка во време) табели;
- BRIDGE маси;
- ПРЕДДЕФИНИРАНИ ДЕРИВАЦИИ.
Ајде внимателно да ја разгледаме целта на овие елементи.
ПИТ маси
Вообичаено, еден деловен субјект (HUB) може да содржи податоци со различни стапки на ажурирање, на пример, ако зборуваме за податоци што карактеризираат лице, можеме да кажеме дека информациите за телефонски број, адреса или е-пошта имаат повисока стапка на ажурирање отколку да речеме, полно име, податоци за пасош, брачен статус или пол.
Затоа, при одредување на сателити, треба да се има предвид нивната фреквенција на ажурирање. Зошто е важно?
Ако складирате атрибути со различни стапки на ажурирање во иста табела, ќе мора да додавате ред во табелата секогаш кога се ажурира најчесто менуваниот атрибут. Резултатот е зголемување на просторот на дискот и зголемување на времето за извршување на барањето.
Сега кога ги поделивме сателитите по фреквенција на ажурирање и можеме да вчитаме податоци во нив независно, треба да се погрижиме да добиваме ажурирани податоци. Подобро, без користење на непотребни JOIN-ови.
Дозволете ми да објаснам, на пример, треба да добиете тековни (според датумот на последното ажурирање) информации од сателити кои имаат различни стапки на ажурирање. За да го направите ова, ќе треба не само да направите JOIN, туку и да креирате неколку вгнездени барања (за секој сателит што содржи информации) со избор на максимален датум за ажурирање MAX (Датум на ажурирање). Со секое ново JOIN, таквиот код расте и многу брзо станува тежок за разбирање.
Табелата PIT е дизајнирана да ги поедностави таквите барања; табелите PIT се пополнуваат истовремено со запишување нови податоци во DATA VAULT. ПИТ табела:
Така, имаме информации за релевантноста на податоците за сите сателити во секој момент во времето. Користејќи JOIN на табелата PIT, можеме целосно да ги елиминираме вгнездените прашања, природно со услов PIT да се пополнува секој ден и без празнини. Дури и ако има празнини во PIT, може да ги добиете најновите податоци само со користење на едно вгнездено барање до самиот PIT. Едно вгнездено барање ќе обработи побрзо од вгнездените барања до секој сателит.
МОЕ
BRIDGE табелите исто така се користат за поедноставување на аналитичките барања. Сепак, она што се разликува од PIT е средство за поедноставување и забрзување на барањата помеѓу различни центри, врски и нивните сателити.
Табелата ги содржи сите потребни клучеви за сите сателити, кои често се користат во барањата. Дополнително, доколку е потребно, хешираните деловни клучеви може да се дополнат со клучеви во текстуална форма, доколку имињата на клучевите се потребни за анализа.
Факт е дека без користење на BRIDGE, во процесот на примање податоци лоцирани во сателити кои припаѓаат на различни хабови, ќе биде неопходно да се направи JOIN не само на самите сателити, туку и на врските што ги поврзуваат хабовите.
Присуството или отсуството на BRIDGE се одредува според конфигурацијата за складирање и потребата да се оптимизира брзината на извршување на барањето. Тешко е да се дојде до универзален пример за BRIGE.
ПРЕДДЕФИНИРАНИ ДЕРИВАЦИИ
Друг тип на објекти што нè доближува до ВАЛТОТ ЗА ДЕЛОВНИ ПОДАТОЦИ се табелите што содржат претходно пресметани индикатори. Ваквите табели се навистина важни за бизнисот; тие содржат информации собрани според дадените правила и го прават релативно лесен пристап до нив.
Архитектонски, ПРЕДДЕФИНИРАНИТЕ ДЕРИВАЦИИ не се ништо повеќе од уште еден сателит на одреден центар. Тој, како обичен сателит, содржи деловен клуч и датум на создавање на записот во сателитот. Сепак, тука завршуваат сличностите. Понатамошниот состав на атрибутите на таков „специјализиран“ сателит го одредуваат деловните корисници врз основа на најпопуларните, претходно пресметани индикатори.
На пример, центар кој содржи информации за вработен може да вклучува сателит со индикатори како што се:
- Минимална плата;
- Максимална плата;
- Просечна плата;
- Кумулативен вкупен износ на пресметани плати итн.
Логично е да се вклучат ПРЕДДЕФИНИРАНИ ДЕРИВАЦИ во табелата PIT на истиот центар, а потоа можете лесно да добиете парчиња податоци за вработен на конкретно избран датум.
ЗАКЛУЧОЦИ
Како што покажува практиката, употребата на DATA VAULT од страна на деловните корисници е донекаде тешка поради неколку причини:
- Кодот за барање е сложен и тежок;
- Изобилството на JOIN влијае на перформансите на барањата;
- Пишувањето аналитички прашања бара извонредно познавање на дизајнот на складирање.
За да се поедностави пристапот до податоци, DATA VAULT се проширува со дополнителни објекти:
- ПИТ (точка во време) табели;
- BRIDGE маси;
- ПРЕДДЕФИНИРАНИ ДЕРИВАЦИИ.
Во следниот Планирам да го кажам, според мене, најинтересното нешто за оние кои работат со БИ. Ќе презентирам начини за креирање табели со факти и табели со димензии врз основа на DATA VAULT.
Материјалите на статијата се засноваат на:
- На Кента Грацијано, која, покрај деталниот опис, содржи и моделски дијаграми;
- Книга: „Градење на скалабилно складиште на податоци со DATA VAULT 2.0“;
- Член .
Извор: www.habr.com