Desenvolver unha instalación de almacenamento é unha empresa longa e seria.
Gran parte da vida dun proxecto depende do ben pensado o modelo de obxecto e a estrutura base ao comezo.
O enfoque xeralmente aceptado foi e segue sendo varias variantes de combinar o esquema estrela coa terceira forma normal. Como regra xeral, segundo o principio: datos iniciais - 3NF, vitrinas - estrela. Este enfoque, probado no tempo e apoiado por unha gran cantidade de investigacións, é o primeiro (e ás veces o único) que se lle ocorre a un especialista en DWH experimentado cando pensa como debería ser un repositorio analítico.
Por outra banda, o negocio en xeral e os requisitos dos clientes en particular tenden a cambiar rapidamente, e os datos tenden a crecer tanto "en profundidade" como "en amplitude". E aquí é onde aparece a principal desvantaxe dunha estrela: limitada flexibilidade.
E se na túa vida tranquila e acolledora como desenvolvedor de DWH de súpeto:
- a tarefa xurdiu "facer polo menos algo rapidamente, e despois xa veremos";
- apareceu un proxecto de rápido desenvolvemento, con conexión de novas fontes e reelaboración do modelo de negocio polo menos unha vez á semana;
- apareceu un cliente que non ten nin idea de como debería ser o sistema e que funcións debería realizar en última instancia, pero está preparado para experimentar e perfeccionar constantemente o resultado desexado mentres se achega constantemente a el;
- O director do proxecto presentou a boa noticia: "E agora temos áxil!"
Ou se estás interesado en descubrir como podes construír instalacións de almacenamento, benvido ao corte!
Que significa "flexibilidade"?
En primeiro lugar, imos definir que propiedades debe ter un sistema para ser chamado "flexible".
Por separado, paga a pena mencionar que as propiedades descritas deben relacionarse especificamente sistema, non para proceso o seu desenvolvemento. Polo tanto, se queres ler sobre Agile como metodoloxía de desenvolvemento, é mellor ler outros artigos. Por exemplo, alí mesmo, en Habré, hai moitos materiais interesantes (como и E ).
Isto non significa que o proceso de desenvolvemento e a estrutura do almacén de datos estean completamente alleos. En xeral, debería ser moito máis sinxelo desenvolver un repositorio áxil para unha arquitectura áxil. Non obstante, na práctica, con máis frecuencia hai opcións co desenvolvemento áxil do clásico DWH segundo Kimbal e DataVault, segundo Waterfall, que felices coincidencias de flexibilidade nas súas dúas formas nun proxecto.
Entón, que capacidades debería ter o almacenamento flexible? Aquí hai tres puntos:
- Entrega anticipada e entrega rápida - isto significa que, idealmente, o primeiro resultado comercial (por exemplo, os primeiros informes de traballo) debería obterse o antes posible, é dicir, mesmo antes de que todo o sistema estea totalmente deseñado e implementado. Ademais, cada revisión posterior tamén debería levar o menor tempo posible.
- Refinamento iterativo - isto significa que cada mellora posterior idealmente non debería afectar á funcionalidade que xa está funcionando. É este momento o que adoita converterse no maior pesadelo dos grandes proxectos: tarde ou cedo, os obxectos individuais comezan a adquirir tantas conexións que resulta máis fácil repetir completamente a lóxica nunha copia próxima que engadir un campo a unha táboa existente. E se che sorprende que a análise do impacto das melloras nos obxectos existentes poida levar máis tempo que as propias melloras, é probable que aínda non teñas traballado con grandes almacéns de datos en banca ou telecomunicacións.
- Adaptándose constantemente ás necesidades empresariais cambiantes - A estrutura global do obxecto debe deseñarse non só tendo en conta a posible expansión, senón coa expectativa de que a dirección desta próxima expansión nin sequera podería soñarse na fase de deseño.
E si, cumprir todos estes requisitos nun só sistema é posible (por suposto, en certos casos e con algunhas reservas).
A continuación, vou considerar dúas das metodoloxías de deseño áxil máis populares para almacéns de datos: Modelo de áncora и Bóveda de datos. Quedan fóra dos corchetes técnicas tan excelentes como, por exemplo, EAV, 6NF (na súa forma pura) e todo o relacionado coas solucións NoSQL, non porque sexan dalgún xeito peores, nin sequera porque neste caso o artigo ameazaría con adquirir o volume do disertante medio. É só que todo isto está relacionado con solucións dunha clase lixeiramente diferente, ben con técnicas que pode usar en casos específicos, independentemente da arquitectura xeral do seu proxecto (como EAV), ou con outros paradigmas de almacenamento de información globalmente (como bases de datos de gráficos). e outras opcións NoSQL).
Problemas do enfoque “clásico” e as súas solucións en metodoloxías flexibles
Por enfoque "clásico" refírome á boa estrela vella (independentemente da implementación específica das capas subxacentes, que me perdoen os seguidores de Kimball, Inmon e CDM).
1. Cardinalidade ríxida das conexións
Este modelo baséase nunha clara división dos datos en Dimensión и feitos. E isto, carallo, é lóxico: ao cabo, a análise de datos na inmensa maioría dos casos redúcese á análise de determinados indicadores numéricos (feitos) en determinadas seccións (dimensións).
Neste caso, as conexións entre obxectos establécense en forma de relacións entre táboas mediante unha chave estranxeira. Isto parece bastante natural, pero inmediatamente leva á primeira limitación da flexibilidade: definición estrita da cardinalidade das conexións.
Isto significa que na fase de deseño da táboa, debes determinar con precisión para cada par de obxectos relacionados se poden relacionarse tantos con moitos ou só 1 para moitos e "en que dirección". Isto determina directamente que táboa terá a chave primaria e cal terá a chave estranxeira. Cambiar esta actitude cando se reciban novos requisitos levará moi probablemente a unha reelaboración da base.
Por exemplo, ao deseñar o obxecto "recibo de efectivo", ti, confiando nos xuramentos do departamento de vendas, estableceches a posibilidade de actuar unha promoción para varias posicións de cheques (pero non viceversa):
E despois dun tempo, os compañeiros presentaron unha nova estratexia de mercadotecnia na que poden actuar no mesmo posto varias promocións ao mesmo tempo. E agora cómpre modificar as táboas separando a relación nun obxecto separado.
(Agora tamén hai que mellorar todos os obxectos derivados nos que se une a verificación de promoción).
Relacións en Data Vault e Modelo Anchor
Evitar esta situación resultou moi sinxelo: non tes que confiar no departamento de vendas para facelo. todas as conexións almacénanse inicialmente en táboas separadas e procesala como moitos a moitos.
Este enfoque foi proposto Dan Linstedt como parte do paradigma Bóveda de datos e totalmente apoiado Lars Rönnbäck в Modelo de áncora.
Como resultado, obtemos a primeira característica distintiva das metodoloxías flexibles:
As relacións entre obxectos non se almacenan nos atributos das entidades principais, senón que son un tipo de obxecto separado.
В Bóveda de datos tales táboas de enlace chámanse ligazón, e dentro Modelo de áncora - lazo. A primeira vista, son moi similares, aínda que as súas diferenzas non rematan co nome (do que se comentará a continuación). En ambas arquitecturas, as táboas de ligazóns poden enlazar calquera número de entidades (non necesariamente 2).
Esta redundancia, a primeira vista, proporciona unha flexibilidade significativa para as modificacións. Tal estrutura faise tolerante non só aos cambios na cardinalidade das ligazóns existentes, senón tamén á adición doutras novas. convértese nun complemento sobre táboas existentes sen afectar a ningún obxecto e proceso existente.
2. Duplicación de datos
O segundo problema resolto polas arquitecturas flexibles é menos obvio e é inherente en primeiro lugar. Medidas tipo SCD2 (dimensiones cambiando lentamente do segundo tipo), aínda que non só elas.
Nun almacén clásico, unha dimensión é normalmente unha táboa que contén unha clave substitutiva (como un PK) e un conxunto de claves e atributos comerciais en columnas separadas.
Se unha dimensión admite a versión, engádense límites de validez de versión ao conxunto estándar de campos e, para unha fila da fonte, aparecen varias versións no repositorio (unha por cada cambio nos atributos versionados).
Se unha dimensión contén polo menos un atributo de versión que cambia con frecuencia, o número de versións desta dimensión será impresionante (aínda que os atributos restantes non sexan versionados ou nunca cambien), e se hai varios destes atributos, o número de versións pode medran exponencialmente a partir do seu número. Esta dimensión pode ocupar unha cantidade significativa de espazo no disco, aínda que gran parte dos datos que almacena son simplemente duplicados de valores de atributos inmutables doutras filas.
Ao mesmo tempo, tamén se usa con moita frecuencia desnormalización — algúns atributos almacénanse intencionadamente como un valor, e non como unha ligazón a un libro de referencia ou a outra dimensión. Este enfoque acelera o acceso aos datos, reducindo o número de unións ao acceder a unha dimensión.
Normalmente isto leva a a mesma información almacénase simultaneamente en varios lugares. Por exemplo, a información sobre a rexión de residencia e a categoría do cliente pódese almacenar simultáneamente nas dimensións "Cliente" e nos feitos "Compra", "Entrega" e "Chamadas ao centro de chamadas", así como no "Cliente - Xestor de clientes". ” táboa de ligazóns.
En xeral, o descrito anteriormente aplícase ás dimensións regulares (non versionadas), pero nas versionadas poden ter unha escala diferente: a aparición dunha nova versión dun obxecto (especialmente en retrospectiva) leva non só á actualización de todos os elementos relacionados. táboas, pero á aparición en cascada de novas versións de obxectos relacionados - cando a Táboa 1 se usa para construír a Táboa 2 e a Táboa 2 se usa para crear a Táboa 3, etc. Aínda que nin un só atributo da Táboa 1 está implicado na construción da Táboa 3 (e están implicados outros atributos da Táboa 2 obtidos doutras fontes), a versión desta construción levará como mínimo a sobrecarga adicional e como máximo a extra. versións na táboa 3. que non ten nada que ver con iso, e máis abaixo na cadea.
3. Complexidade non lineal do retraballo
Ao mesmo tempo, cada novo escaparate construído en base a outro aumenta o número de lugares onde os datos poden "diverxer" cando se realizan cambios no ETL. Isto, á súa vez, leva a un aumento da complexidade (e da duración) de cada revisión posterior.
Se o anterior describe sistemas con procesos ETL raramente modificados, pode vivir nese paradigma; só precisa asegurarse de que as novas modificacións se fan correctamente en todos os obxectos relacionados. Se as revisións ocorren con frecuencia, a probabilidade de "perder" accidentalmente varias conexións aumenta significativamente.
Se, ademais, temos en conta que ETL "versionado" é significativamente máis complicado que un "non versionado", faise bastante difícil evitar erros ao actualizar con frecuencia toda esta instalación.
Almacenamento de obxectos e atributos en Data Vault e Anchor Model
O enfoque proposto polos autores das arquitecturas flexibles pódese formular do seguinte xeito:
É necesario separar o que cambia do que permanece igual. É dicir, almacenar as claves por separado dos atributos.
Non obstante, non se debe confundir non versionado atributo con sen cambios: o primeiro non almacena o historial dos seus cambios, pero pode cambiar (por exemplo, ao corrixir un erro de entrada ou recibir novos datos); o segundo nunca cambia.
Os puntos de vista difiren sobre o que se pode considerar exactamente inmutable no Data Vault e no Modelo Anchor.
Dende o punto de vista arquitectónico Bóveda de datos, pódese considerar inalterado conxunto completo de chaves - natural (TIN da organización, código do produto no sistema fonte, etc.) e substituto. Neste caso, os atributos restantes pódense dividir en grupos segundo a orixe e/ou frecuencia dos cambios e Manter unha táboa separada para cada grupo cun conxunto independente de versións.
No paradigma Modelo de áncora considerado inalterado só chave substitutiva esencia. Todo o demais (incluídas as claves naturais) é só un caso especial dos seus atributos. onde todos os atributos son independentes entre si por defecto, polo que para cada atributo a mesa separada.
В Bóveda de datos chámanse táboas que conteñen claves de entidade Hubami. Os concentradores sempre conteñen un conxunto fixo de campos:
- Claves de entidades naturais
- Chave substitutiva
- Ligazón á fonte
- Gravar o tempo de engadido
Publicacións en Hubs nunca cambiar e non ter versións. Externamente, os concentradores son moi similares ás táboas de tipo ID-map que se usan nalgúns sistemas para xerar substitutos, non obstante, recoméndase usar un hash dun conxunto de claves de negocio como substitutos en Data Vault. Este enfoque simplifica a carga de relacións e atributos das fontes (non é necesario unirse ao concentrador para obter un substituto, só precisa calcular o hash dunha clave natural), pero pode causar outros problemas (relacionados, por exemplo, con colisións). , maiúsculas e caracteres non imprimibles nas teclas de cadea, etc. .p.), polo que non se acepta xeralmente.
Todos os demais atributos da entidade gárdanse en táboas especiais chamadas Satélites. Un concentrador pode ter varios satélites que almacenan diferentes conxuntos de atributos.
A distribución de atributos entre satélites prodúcese segundo o principio cambio conxunto - nun satélite pódense almacenar atributos non versionados (por exemplo, data de nacemento e SNILS para un individuo), noutro - raramente cambian de versión (por exemplo, apelidos e número de pasaporte), no terceiro - cambian frecuentemente. (por exemplo, enderezo de entrega, categoría, data do último pedido, etc.). Neste caso, o versionado realízase a nivel de satélites individuais, e non da entidade no seu conxunto, polo que é recomendable distribuír atributos para que a intersección de versións dentro dun satélite sexa mínima (o que reduce o número total de versións almacenadas). ).
Ademais, para optimizar o proceso de carga de datos, os atributos obtidos de varias fontes adoitan incluírse en satélites individuais.
Os satélites comunícanse co Hub a través de chave estranxeira (que corresponde á cardinalidade de 1 a moitos). Isto significa que esta arquitectura "predeterminada" admite varios valores de atributos (por exemplo, varios números de teléfono de contacto para un cliente).
В Modelo de áncora chámanse táboas que almacenan claves Áncoras. E manteñen:
- Só chaves substitutivas
- Ligazón á fonte
- Gravar o tempo de engadido
Considéranse claves naturais dende o punto de vista do Modelo de Áncora atributos ordinarios. Esta opción pode parecer máis difícil de entender, pero dá moito máis espazo para identificar o obxecto.
Por exemplo, se os datos sobre a mesma entidade poden proceder de sistemas diferentes, cada un dos cales utiliza a súa propia clave natural. En Data Vault, isto pode levar a estruturas bastante engorrosas de varios hubs (un por fonte + unha versión mestra unificadora), mentres que no modelo Anchor, a clave natural de cada fonte cae no seu propio atributo e pódese usar cando se carga de forma independente. todos os demais.
Pero tamén hai un punto insidioso aquí: se os atributos de diferentes sistemas se combinan nunha entidade, moi probablemente haxa algúns regras de "pegado", polo que o sistema debe entender que os rexistros de diferentes fontes corresponden a unha instancia da entidade.
В Bóveda de datos estas regras moi probablemente determinarán a formación "hub substituto" da entidade mestra e non inflúen de ningún xeito nos Hubs que almacenan as claves de orixe natural e os seus atributos orixinais. Se nalgún momento cambian as regras de fusión (ou se actualizan os atributos polos que se realiza), bastará con reformatear os hubs substitutos.
В Modelo de áncora tal entidade probablemente estará almacenada a única áncora. Isto significa que todos os atributos, independentemente da fonte que proveñan, estarán ligados ao mesmo substituto. Separar rexistros fusionados de forma errónea e, en xeral, supervisar a relevancia da fusión nun sistema deste tipo pode ser moito máis difícil, especialmente se as regras son bastante complexas e cambian con frecuencia, e o mesmo atributo pódese obter de diferentes fontes (aínda que certamente é posible, xa que cada versión do atributo conserva unha ligazón á súa fonte).
En calquera caso, se se supón que o seu sistema implementará a funcionalidade deduplicación, fusión de rexistros e outros elementos MDM, paga a pena prestar especial atención aos aspectos de almacenamento de claves naturais en metodoloxías áxiles. É probable que o deseño máis voluminoso de Data Vault sexa de súpeto máis seguro en termos de erros de combinación.
Modelo de áncora tamén proporciona un tipo de obxecto adicional chamado nó é esencialmente especial tipo degenerado de áncora, que só pode conter un atributo. Suponse que os nodos se usan para almacenar directorios planos (por exemplo, sexo, estado civil, categoría de servizo ao cliente, etc.). A diferenza da Áncora, o Nó non ten táboas de atributos asociadas, e o seu único atributo (nome) gárdase sempre na mesma táboa coa chave. Os nós conéctanse ás áncoras mediante táboas de amarre (Tie) do mesmo xeito que as áncoras están conectadas entre si.
Non hai unha opinión clara sobre o uso de Nodes. Por exemplo, , quen promove activamente o uso do Modelo Anchor en Rusia, cre (non razoablemente) que para nin un só libro de referencia se pode afirmar con certeza que é sempre será estático e dun só nivel, polo que é mellor usar inmediatamente un Anchor completo para todos os obxectos.
Outra diferenza importante entre Data Vault e o modelo Anchor é a dispoñibilidade atributos das conexións:
В Bóveda de datos As ligazóns son os mesmos obxectos completos que os Hubs e poden ter atributos propios. En Modelo de áncora As ligazóns úsanse só para conectar áncoras e non poden ter os seus propios atributos. Esta diferenza resulta en enfoques de modelización significativamente diferentes feitos, que se tratará máis adiante.
Almacenamento de feitos
Antes disto, falamos principalmente do modelado de medición. Os feitos son un pouco menos claros.
В Bóveda de datos un obxecto típico para almacenar feitos é Ligazón, en cuxos satélites se engaden indicadores reais.
Este enfoque parece intuitivo. Proporciona un fácil acceso aos indicadores analizados e, en xeral, é semellante a unha táboa de feitos tradicional (só os indicadores se almacenan non na propia táboa, senón na "veciña"). Pero tamén hai trampas: unha das modificacións típicas do modelo -a ampliación da clave de feito- fai necesaria engadindo unha nova clave externa a Link. E isto, á súa vez, "rompe" a modularidade e potencialmente provoca a necesidade de modificacións noutros obxectos.
В Modelo de áncora Unha conexión non pode ter os seus propios atributos, polo que este enfoque non funcionará; absolutamente todos os atributos e indicadores deben estar ligados a unha áncora específica. A conclusión disto é sinxela: Cada feito tamén precisa da súa propia áncora. Para algúns dos que estamos acostumados a percibir como feitos, isto pode parecer natural; por exemplo, o feito dunha compra pode reducirse perfectamente ao obxecto "pedido" ou "recibo", visitar un sitio a unha sesión, etc. Pero tamén hai feitos para os que non é tan fácil atopar un "obxecto portador" tan natural - por exemplo, os restos de mercadorías nos almacéns ao comezo de cada día.
En consecuencia, os problemas de modularidade ao expandir unha clave de feito no modelo de áncora non xorden (abonda con engadir unha nova Relación á áncora correspondente), pero deseñar un modelo para mostrar feitos é menos inequívoco; poden aparecer áncoras "artificiais" que mostran o modelo de obxectos de negocio dunha forma pouco clara.
Como se consegue a flexibilidade
A construción resultante en ambos os casos contén significativamente máis táboasque a medición tradicional. Pero pode levar significativamente menos espazo no disco co mesmo conxunto de atributos versionados que a dimensión tradicional. Por suposto, aquí non hai maxia: todo é cuestión de normalización. Ao distribuír atributos entre satélites (no Data Vault) ou táboas individuais (modelo de ancoraxe), reducimos (ou eliminamos por completo) duplicación de valores duns atributos ao cambiar outros.
Para Bóveda de datos as ganancias dependerán da distribución de atributos entre os Satélites, e para Modelo de áncora — é case directamente proporcional ao número medio de versións por obxecto de medición.
Non obstante, o aforro de espazo é unha vantaxe importante, pero non a principal, de almacenar atributos por separado. Xunto co almacenamento separado das relacións, este enfoque fai que a tenda deseño modular. Isto significa que se pode engadir atributos individuais e áreas temáticas novas enteiras nun modelo deste tipo superestructura sobre un conxunto existente de obxectos sen cambialos. E isto é precisamente o que flexibiliza as metodoloxías descritas.
Isto tamén se asemella á transición da produción de pezas á produción en masa: se no enfoque tradicional cada táboa do modelo é única e require unha atención especial, en metodoloxías flexibles xa é un conxunto de "pezas" estándar. Por unha banda, hai máis táboas, e os procesos de carga e recuperación de datos deberían parecer máis complicados. Por outra banda, convértense típico. O que significa que pode haber automatizado e impulsado por metadatos. A pregunta "como o poñeremos?", cuxa resposta podería ocupar unha parte importante do traballo no deseño de melloras, agora simplemente non paga a pena (así como a pregunta sobre o impacto do cambio de modelo nos procesos de traballo). ).
Isto non significa que os analistas non sexan necesarios nun sistema deste tipo: alguén aínda ten que traballar a través do conxunto de obxectos con atributos e descubrir onde e como cargalo todo. Pero a cantidade de traballo, así como a probabilidade e o custo dun erro, redúcense significativamente. Tanto na fase de análise como durante o desenvolvemento de ETL, que nunha parte importante se pode reducir a editar metadatos.
Lado escuro
Todo o anterior fai que ambos enfoques sexan verdadeiramente flexibles, tecnoloxicamente avanzados e axeitados para a mellora iterativa. Por suposto, tamén hai un "baril na pomada", que creo que xa podes adiviñar.
A descomposición de datos, que subxace á modularidade das arquitecturas flexibles, leva a un aumento do número de táboas e, en consecuencia, sobrecarga para xuntas ao tomar a mostra. Para simplemente obter todos os atributos dunha dimensión, nunha tenda clásica é suficiente unha selección, pero unha arquitectura flexible requirirá toda unha serie de unións. Ademais, se todas estas unións para informes poden escribirse con antelación, entón os analistas que están afeitos a escribir SQL a man sufrirán dobremente.
Hai varios feitos que facilitan esta situación:
Cando se traballa con grandes dimensións, case nunca se usan todos os seus atributos ao mesmo tempo. Isto significa que pode haber menos unións do que parece a primeira vista no modelo. Data Vault tamén pode ter en conta a frecuencia esperada de compartir ao asignar atributos aos satélites. Ao mesmo tempo, os propios Hubs ou Anchors son necesarios principalmente para xerar e mapear substitutos na fase de carga e raramente se usan nas consultas (isto é especialmente certo para os Anchores).
Todas as unións son por clave. Ademais, unha forma máis "comprimida" de almacenar datos reduce a sobrecarga das táboas de dixitalización onde se precisa (por exemplo, ao filtrar por valor de atributo). Isto pode levar ao feito de que a mostra dunha base de datos normalizada cunha morea de unións será aínda máis rápida que a dixitalización dunha dimensión pesada con moitas versións por fila.
Por exemplo, aquí dentro O artigo contén unha proba comparativa detallada do rendemento do modelo Anchor cunha mostra dunha táboa.
Depende moito do motor. Moitas plataformas modernas teñen mecanismos internos de optimización de unión. Por exemplo, MS SQL e Oracle poden "saltar" as unións ás táboas se os seus datos non se usan en ningún lugar, excepto noutras combinacións e non afectan á selección final (eliminación de táboas/unións) e MPP Vertica , demostrou ser un excelente motor para o Modelo Anchor, dada algunha optimización manual do plan de consulta. Por outra banda, almacenar o modelo de áncora, por exemplo, en Click House, que ten un soporte limitado de unión, aínda non parece moi boa idea.
Ademais, para ambas arquitecturas hai movementos especiais, facilitando o acceso aos datos (tanto desde o punto de vista do rendemento das consultas como para os usuarios finais). Por exemplo, Táboas puntuales en Data Vault ou funcións especiais da táboa no modelo Anchor.
En total
A esencia principal das arquitecturas flexibles consideradas é a modularidade do seu "deseño".
É esta propiedade a que permite:
- Despois dunha preparación inicial relacionada coa implementación de metadatos e a escritura de algoritmos ETL básicos, proporcionar rapidamente ao cliente o primeiro resultado en forma dun par de informes que conteñen datos duns poucos obxectos fonte. Non é necesario pensar completamente (incluso no nivel superior) todo o modelo de obxectos.
- Un modelo de datos pode comezar a funcionar (e ser útil) con só 2-3 obxectos, e despois medrar gradualmente (sobre o modelo Anchor Nikolai boa comparación co micelio).
- A maioría das melloras, incluíndo ampliar a área temática e engadir novas fontes non afecta a funcionalidade existente e non supón un risco de romper algo que xa está funcionando.
- Grazas á descomposición en elementos estándar, os procesos ETL en tales sistemas teñen o mesmo aspecto, a súa escritura préstase á algoritmo e, en definitiva, automatización.
O prezo desta flexibilidade é rendemento. Isto non significa que sexa imposible acadar un rendemento aceptable en tales modelos. Na maioría das veces, pode que simplemente necesites máis esforzo e atención aos detalles para acadar as métricas que queres.
Apps
Tipos de entidades Bóveda de datos
Máis información sobre Data Vault:
Tipos de entidades Modelo de áncora
Máis detalles sobre o modelo Anchor:
Táboa resumo con características comúns e diferenzas dos enfoques considerados:
Fonte: www.habr.com