В предишната статия говорих за основите на 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 беше разширена с елементи като:
- PIT (point in time) таблици;
- маси BRIDGE;
- ПРЕДВАРИТЕЛНО ИЗВОДИ.
Нека разгледаме по-подробно предназначението на тези елементи.
PIT таблици
По правило един бизнес обект (HUB) може да съдържа данни с различни скорости на актуализация, например, ако говорим за данни, характеризиращи дадено лице, можем да кажем, че информацията за телефонен номер, адрес или имейл има по-висока скорост на актуализация от да речем, пълно име, паспортни данни, семейно положение или пол.
Следователно, когато определяте сателитите, трябва да имате предвид честотата на тяхното обновяване. Защо е важно?
Ако съхранявате атрибути с различна честота на актуализиране в една и съща таблица, ще трябва да добавяте ред към таблицата всеки път, когато се актуализира най-често променяният атрибут. В резултат на това има увеличаване на размера на дисковото пространство, увеличаване на времето за изпълнение на заявките.
Сега, след като разделихме сателитите по скорост на актуализиране и можем да зареждаме данни в тях независимо, трябва да сме сигурни, че можем да получим актуални данни. По-добре без използване на ненужни JOIN.
Позволете ми да обясня, например, трябва да получите актуална (до датата на последната актуализация) информация от сателити с различни скорости на актуализация. За да направите това, ще трябва не само да направите JOIN, но и да създадете няколко вложени заявки (за всеки сателит, съдържащ информация) с избор на максимална дата на актуализиране MAX (Дата на актуализиране). С всеки нов JOIN такъв код нараства и много бързо става труден за разбиране.
PIT таблицата е предназначена да опрости такива заявки, PIT таблиците се попълват едновременно с записването на нови данни в DATA VAULT. PIT таблица:
По този начин имаме информация за уместността на данните за всички спътници във всеки момент от време. Използвайки JOIN на PIT таблицата, можем напълно да елиминираме вложените заявки, разбира се при условие, че PIT се попълва всеки ден и без пропуски. Дори ако има пропуски в PIT, можете да получите актуални данни само с помощта на една вложена заявка към самия PIT. Една вложена заявка ще работи по-бързо от вложените заявки за всеки сателит.
BRIDGE
BRIDGE таблиците се използват и за опростяване на аналитични заявки. Разликата от PIT обаче е средство за опростяване и ускоряване на заявките между различни хъбове, връзки и техните сателити.
Таблицата съдържа всички необходими ключове за всички сателити, които често се използват в заявки. Освен това, ако е необходимо, хешираните бизнес ключове могат да бъдат допълнени с ключове в текстова форма, ако имената на ключовете са необходими за анализ.
Факт е, че без да се използва BRIDGE, в процеса на получаване на данни, разположени в сателити, принадлежащи към различни хъбове, ще е необходимо да се ПРИСЪЕДИНЯТ не само самите сателити, но и връзките, свързващи хъбовете.
Наличието или отсъствието на BRIDGE се определя от конфигурацията за съхранение, необходимостта от оптимизиране на скоростта на изпълнение на заявката. Трудно е да се измисли универсален пример за BRIGE.
ПРЕДВАРИТЕЛНО ИЗВОДИ
Друг тип обекти, които ни доближават до BUSINESS DATA VAULT са таблици, съдържащи предварително изчислени показатели. Такива таблици са наистина важни за бизнеса, те съдържат информация, агрегирана по зададени правила и я правят сравнително лесна за достъп.
Архитектурно, ПРЕДВАРИТЕЛНИТЕ ПРОИЗВОДНИЦИ не са нищо повече от друг сателит на определен център. Той, подобно на обикновен сателит, съдържа бизнес ключ и датата, на която записът е създаден в сателита. Тук обаче приликите свършват. По-нататъшният състав на атрибутите на такъв "специализиран" сателит се определя от бизнес потребителите въз основа на най-популярните, предварително изчислени показатели.
Например, център, съдържащ информация за служител, може да включва сателит с индикатори като:
- Минимална заплата;
- Максимална заплата;
- Средна работна заплата;
- Натрупана сума на начислените заплати и др.
Логично е да включите ПРЕДВАРИТЕЛНО ДЕФИНИРАНИ ДЕРИВАЦИИ в PIT таблицата на същия център, след което можете лесно да получите срезове с данни за служители за конкретна дата.
ИЗВОДИ
Както показва практиката, използването на DATA VAULT от бизнес потребители е донякъде трудно поради няколко причини:
- Кодът на заявката е сложен и тромав;
- Изобилието от JOIN засяга производителността на заявките;
- Писането на аналитични заявки изисква изключителни познания за структурата на склада.
За да опрости достъпа до данни, DATA VAULT е разширен с допълнителни обекти:
- PIT (point in time) таблици;
- маси BRIDGE;
- ПРЕДВАРИТЕЛНО ИЗВОДИ.
Следващия Смятам да разкажа най-интересното според мен за тези, които работят с BI. Ще представя начини за създаване на таблици - факти и таблици - измерения на базата на DATA VAULT.
Материалите на статията се основават на:
- На Kenta Graziano, който освен подробно описание, съдържа диаграми на модели;
- Книга: "Изграждане на мащабируемо хранилище на данни с DATA VAULT 2.0";
- статия .
Източник: www.habr.com