No artigo anterior, falei sobre os conceptos básicos de DATA VAULT, describín os principais elementos de DATA VAULT e a súa finalidade. Non se pode considerar o tema de DATA VAULT como esgotado, é necesario falar dos próximos pasos na evolución de DATA VAULT.
E neste artigo centrareime no desenvolvemento de DATA VAULT e na transición a BUSINESS DATA VAULT ou simplemente BUSINESS VAULT.
Motivos para a aparición de BUSINESS DATA VAULT
Cómpre sinalar que DATA VAULT, aínda que ten certos puntos fortes, non está exento de inconvenientes. Unha destas desvantaxes é a dificultade para escribir consultas analíticas. As consultas teñen un número importante de JOIN, o código é longo e engorroso. Así mesmo, os datos que entran en DATA VAULT non sofren ningunha transformación, polo que, dende o punto de vista empresarial, DATA VAULT na súa forma pura non ten valor absoluto.
Foi para eliminar estas deficiencias que se ampliou a metodoloxía DATA VAULT con elementos como:
- Táboas PIT (punto no tempo);
- mesas BRIDGE;
- DERIVACIONS PREDEFINIDAS.
Vexamos máis de cerca o propósito destes elementos.
Táboas PIT
Normalmente, unha entidade empresarial (HUB) pode conter datos con diferentes taxas de actualización, por exemplo, se falamos de datos que caracterizan a unha persoa, podemos dicir que a información sobre un número de teléfono, enderezo ou correo electrónico ten unha taxa de actualización máis alta que, por exemplo, nome completo, datos do pasaporte, estado civil ou sexo.
Polo tanto, ao determinar os satélites, debes ter en conta a súa frecuencia de actualización. Por que é importante?
Se almacenas atributos con diferentes taxas de actualización na mesma táboa, terás que engadir unha fila á táboa cada vez que se actualice o atributo modificado máis frecuentemente. O resultado é un aumento do espazo no disco e un aumento do tempo de execución da consulta.
Agora que dividimos os satélites pola frecuencia de actualización e podemos cargar datos neles de forma independente, debemos asegurarnos de que podemos recibir datos actualizados. Mellor, sen usar JOINs innecesarios.
Déixame explicar, por exemplo, que cómpre obter información actual (segundo a data da última actualización) de satélites que teñen diferentes taxas de actualización. Para iso, non só terás que facer un JOIN, senón tamén crear varias consultas aniñadas (para cada satélite que conteña información) coa selección da data máxima de actualización MAX (Data de actualización). Con cada novo JOIN, tal código crece e faise moi rapidamente difícil de entender.
A táboa PIT está deseñada para simplificar tales consultas; as táboas PIT énchense ao mesmo tempo que se escriben novos datos no DATA VAULT. Táboa PIT:
Así, temos información sobre a relevancia dos datos para todos os satélites en cada momento. Usando JOINs á táboa PIT, podemos eliminar por completo as consultas aniñadas, naturalmente coa condición de que o PIT se enche todos os días e sen lagoas. Aínda que existan lagoas no PIT, só podes obter os datos máis recentes mediante unha consulta aniñada ao propio PIT. Unha consulta aniñada procesará máis rápido que as consultas aniñadas a cada satélite.
PONTE
As táboas BRIDGE tamén se usan para simplificar as consultas analíticas. Non obstante, o que se diferencia do PIT é un medio para simplificar e acelerar as solicitudes entre varios hubs, enlaces e os seus satélites.
A táboa contén todas as claves necesarias para todos os satélites, que adoitan usarse nas consultas. Ademais, se é necesario, as claves comerciais con hash pódense complementar con claves en forma de texto se os nomes das claves son necesarios para a análise.
O caso é que sen utilizar BRIDGE, no proceso de recepción de datos localizados en satélites pertencentes a distintos hubs, será necesario facer un JOIN non só dos propios satélites, senón tamén dos enlaces que conectan os hubs.
A presenza ou ausencia de BRIDGE está determinada pola configuración de almacenamento e a necesidade de optimizar a velocidade de execución da consulta. É difícil dar cun exemplo universal de BRIGE.
DERIVACIONS PREDEFINIDAS
Outro tipo de obxectos que nos achegan á BÓVEDA DE DATOS EMPRESARIAIS son as táboas que conteñen indicadores precalculados. Tales táboas son realmente importantes para as empresas; conteñen información agregada segundo regras dadas e fan que sexa relativamente fácil acceder.
Arquitectónicamente, as DERIVACIÓNS PREDEFINIDAS non son máis que outro satélite dun determinado hub. Como un satélite normal, contén unha clave comercial e a data de creación do rexistro no satélite. Non obstante, aquí rematan as semellanzas. A composición adicional dos atributos deste satélite "especializado" está determinada polos usuarios empresariais en función dos indicadores máis populares e precalculados.
Por exemplo, un concentrador que contén información sobre un empregado pode incluír un satélite con indicadores como:
- Salario mínimo;
- Salario máximo;
- Salario medio;
- Total acumulado de salarios devengados, etc.
É lóxico incluír DERIVACIONS PREDEFINIDAS na táboa PIT do mesmo centro, entón pode obter facilmente porcións de datos dun empregado nunha data especificamente seleccionada.
CONCLUSIÓNS
Como mostra a práctica, o uso de DATA VAULT por parte dos usuarios empresariais é algo difícil por varias razóns:
- O código de consulta é complexo e engorroso;
- A abundancia de JOIN afecta o rendemento das consultas;
- Escribir consultas analíticas require un coñecemento destacado do deseño de almacenamento.
Para simplificar o acceso aos datos, DATA VAULT amplíase con obxectos adicionais:
- Táboas PIT (punto no tempo);
- mesas BRIDGE;
- DERIVACIONS PREDEFINIDAS.
No seguinte Penso contar, na miña opinión, o máis interesante para os que traballan con BI. Vou presentar formas de crear táboas de feitos e táboas de dimensións baseadas en DATA VAULT.
Os materiais do artigo baséanse en:
- En Kenta Graziano, que, ademais dunha descrición detallada, contén diagramas de modelos;
- Libro: "Construíndo un almacén de datos escalable con DATA VAULT 2.0";
- Artigo .
Fonte: www.habr.com