{"id":92015,"date":"2020-08-21T19:42:13","date_gmt":"2020-08-21T17:42:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh"},"modified":"2020-08-21T19:42:13","modified_gmt":"2020-08-21T17:42:13","slug":"obzor-gibkih-metodologij-proektirovaniya-dwh","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>El desarrollo de un almac\u00e9n es un proceso largo y serio. <\/p>\n<p>Mucho en la vida del proyecto depende de cu\u00e1n bien se haya pensado el modelo de objeto y la estructura de la base desde el inicio.<\/p>\n<p>El enfoque com\u00fanmente aceptado ha sido y sigue siendo diversas combinaciones de la estructura en 'estrella' con la tercera forma normal. Por lo general, bajo el principio: datos originales \u2014 3NF, vitrinas \u2014 estrella. Este enfoque, probado por el tiempo y respaldado por una gran cantidad de investigaciones, es lo primero (y a veces lo \u00fanico) que le viene a la mente a un experto en DWH al pensar en c\u00f3mo debe verse un almac\u00e9n anal\u00edtico.<\/p>\n<p>Por otro lado, los negocios en general y los requisitos del cliente en particular tienden a cambiar r\u00e1pidamente, mientras que los datos pueden crecer 'en profundidad' y 'en amplitud'. Y aqu\u00ed es donde se manifiesta la principal desventaja de la estrella: su limitaci\u00f3n. <b>flexibilidad<\/b>.<\/p>\n<p>Y si de repente en su tranquila y acogedora vida como desarrollador de DWH aparece:<\/p>\n<ul>\n<li>la tarea de 'hacer algo r\u00e1pido y luego ya veremos';<\/li>\n<li>un proyecto en r\u00e1pido desarrollo, con la incorporaci\u00f3n de nuevas fuentes y un cambio en el modelo de negocio al menos una vez por semana;<\/li>\n<li>un cliente que no tiene idea de c\u00f3mo deber\u00eda ser el sistema y qu\u00e9 funciones deber\u00eda desempe\u00f1ar, pero est\u00e1 dispuesto a experimentar y a precisar de manera continua el resultado deseado acerc\u00e1ndose de forma progresiva a \u00e9l;<\/li>\n<li>el gerente de proyectos aparece con la alegre noticia: '\u00a1Y ahora tenemos Agile!'.<\/li>\n<\/ul>\n<p>\nO si simplemente le interesa conocer otras formas de construir almacenes, \u00a1bienvenido debajo del cat!<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/59cd70ca3af4841d0c5c9bfbbd7636a3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>\u00bfQu\u00e9 significa 'flexibilidad'?<\/h3>\n<p>\nPara comenzar, definamos qu\u00e9 propiedades debe tener un sistema para poder ser considerado 'flexible'. <\/p>\n<p>Cabe mencionar que las propiedades descritas deben referirse espec\u00edficamente a <b>el sistema<\/b>, y no al <b>proceso <\/b>de su desarrollo. Por lo tanto, si deseaba leer sobre Agile como metodolog\u00eda de desarrollo, es mejor consultar otros art\u00edculos. Por ejemplo, aqu\u00ed en Habr hay una gran cantidad de materiales interesantes (tales como <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">publicaciones de revisi\u00f3n<\/a><\/noindex> y <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">pr\u00e1cticos<\/a><\/noindex>, como <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problem\u00e1ticos<\/a><\/noindex>).<\/p>\n<p>Esto no significa que el proceso de desarrollo y la estructura del HLD no est\u00e9n relacionados en absoluto. En general, desarrollar un almac\u00e9n de arquitectura flexible siguiendo Agile deber\u00eda ser considerablemente m\u00e1s f\u00e1cil. Sin embargo, en la pr\u00e1ctica, a menudo se encuentran opciones para el desarrollo de un DWH cl\u00e1sico seg\u00fan Kimball y DataVault \u2014 siguiendo el enfoque en cascada, m\u00e1s que coincidencias felices de flexibilidad en sus dos manifestaciones en un mismo proyecto.<\/p>\n<p>Entonces, \u00bfqu\u00e9 capacidades deber\u00eda tener un almac\u00e9n flexible? Aqu\u00ed se pueden destacar tres puntos:<\/p>\n<ol>\n<li><b>Entrega temprana y r\u00e1pida modificaci\u00f3n<\/b> \u2014 esto significa que, en ideal, el primer resultado comercial (por ejemplo, los primeros informes funcionales) debe lograrse lo antes posible, es decir, incluso antes de que el sistema completo est\u00e9 dise\u00f1ado e implementado. Cada modificaci\u00f3n subsiguiente tambi\u00e9n deber\u00eda tomar el menor tiempo posible.<\/li>\n<li><b>Modificaci\u00f3n iterativa<\/b> \u2014 esto significa que cada modificaci\u00f3n subsiguiente, en ideal, no deber\u00eda afectar la funcionalidad ya operativa. Este aspecto a menudo se convierte en la mayor pesadilla en proyectos grandes: tarde o temprano, los objetos individuales comienzan a acumular tantas relaciones que es m\u00e1s f\u00e1cil repetir la l\u00f3gica en una copia al lado, que agregar un campo en una tabla existente. Y si te sorprende que el an\u00e1lisis del impacto de la modificaci\u00f3n en los objetos existentes pueda llevar m\u00e1s tiempo que la modificaci\u00f3n misma, probablemente a\u00fan no has trabajado con grandes HLD en banca o telecomunicaciones.<\/li>\n<li><b>Adaptaci\u00f3n constante a los requisitos comerciales cambiantes<\/b> \u2014 la estructura objeto general debe dise\u00f1arse no solo teniendo en cuenta una posible expansi\u00f3n, sino considerando que la direcci\u00f3n de esta nueva expansi\u00f3n no podr\u00eda haberte siquiera imaginado en la etapa de dise\u00f1o.<\/li>\n<\/ol>\n<p>\nY s\u00ed, cumplir con todos estos requisitos en un mismo sistema es posible (por supuesto, en ciertos casos y con algunas aclaraciones).<\/p>\n<p>A continuaci\u00f3n, analizar\u00e9 dos de las metodolog\u00edas de dise\u00f1o flexible m\u00e1s populares para HLD \u2014 <b>Modelo de ancla<\/b> y <b>Data Vault<\/b>. Se dejan de lado t\u00e9cnicas tan excelentes como EAV, 6NF (en su forma pura) y todo lo relacionado con soluciones NoSQL, no porque sean peores, ni tampoco porque en este caso el art\u00edculo amenazara con adquirir el volumen de una tesis promedio. Simplemente, todo esto se relaciona con soluciones de una categor\u00eda algo diferente, ya sea con t\u00e9cnicas que se pueden aplicar en casos espec\u00edficos, independientemente de la arquitectura general de su proyecto (como EAV), o con paradigmas de almacenamiento de informaci\u00f3n completamente distintos (como bases de datos gr\u00e1ficas y otras variantes de NoSQL).<\/p>\n<h3>Los problemas del enfoque \u201ccl\u00e1sico\u201d y sus soluciones en metodolog\u00edas flexibles<\/h3>\n<p>\n<i>Con el enfoque \u201ccl\u00e1sico\u201d me refiero a la buena y antigua estrella (independientemente de la implementaci\u00f3n espec\u00edfica de las capas subyacentes, que me perdonen los adeptos de Kimball, Inmon y el CDM).<br \/>\n<\/i><\/p>\n<h4>1. La cardinalidad estricta de las relaciones<\/h4>\n<p>\nDicha modelo se basa en una clara separaci\u00f3n de datos en <b>dimensiones (Dimension)<\/b> y <b>hechos (Fact)<\/b>. Y esto, maldita sea, es l\u00f3gico, ya que el an\u00e1lisis de datos en la gran mayor\u00eda de los casos se reduce precisamente al an\u00e1lisis de ciertos indicadores num\u00e9ricos (hechos) en determinados cortes (dimensiones).<\/p>\n<p>Al mismo tiempo, las relaciones entre objetos se establecen en forma de relaciones entre tablas a trav\u00e9s de claves externas. Esto parece bastante natural, pero inmediatamente conduce a la primera limitaci\u00f3n de flexibilidad: <b>la definici\u00f3n r\u00edgida de la cardinalidad de las relaciones<\/b>.<\/p>\n<p>. Esto significa que en la etapa de dise\u00f1o de tablas, debe determinar exactamente para cada par de objetos relacionados si pueden relacionarse como muchos a muchos, o solo uno a muchos, y \u201cen qu\u00e9 direcci\u00f3n\u201d. Esto depende directamente de en cu\u00e1l de las tablas estar\u00e1 la clave primaria y en cu\u00e1l la externa. Cambiar esta relaci\u00f3n ante nuevos requisitos probablemente llevar\u00e1 a la reestructuraci\u00f3n de la base.<\/p>\n<p>Por ejemplo, al dise\u00f1ar el objeto \u201crecibo de caja\u201d, usted, bas\u00e1ndose en las garant\u00edas juradas del departamento de ventas, estableci\u00f3 la posibilidad de que <b>una promoci\u00f3n afectara a varias posiciones de recibo<\/b> (pero no al rev\u00e9s):<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nY despu\u00e9s de un tiempo, los colegas introdujeron una nueva estrategia de marketing, en la que en una misma posici\u00f3n pueden actuar <b>varias promociones simult\u00e1neamente<\/b>. Ahora debe modificar las tablas, destacando la relaci\u00f3n en un objeto separado. <\/p>\n<p>(Todos los objetos derivados donde se realiza el chequeo de la promoci\u00f3n tambi\u00e9n necesitan ajustes).<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Relaciones en Data Vault y Modelo Ancla<\/b><\/p>\n<p>Evitar tal situaci\u00f3n result\u00f3 ser bastante sencillo: no hay que creer en el departamento de ventas, para ello es suficiente <b>almacenar todas las relaciones inicialmente en tablas separadas<\/b> y procesarlas como muchos a muchos. <\/p>\n<p>Este enfoque fue propuesto <b>por Dan Linstedt<\/b> como parte de la paradigma <b>Data Vault<\/b> y totalmente respaldado <b>por Lars R\u00f6nnb\u00e4ck<\/b> en <b>Modelo Ancla<\/b>.<\/p>\n<p>Como resultado, obtenemos la primera caracter\u00edstica distintiva de las metodolog\u00edas flexibles:<\/p>\n<blockquote><p>Las relaciones entre los objetos no se almacenan en los atributos de las entidades parentales, sino que representan un tipo separado de objetos.<\/p><\/blockquote>\n<p>En <b>Data Vault<\/b> tales tablas de relaci\u00f3n se llaman <b>Link<\/b>, mientras que en <b>Modelo Ancla<\/b> \u2014 <b>Tie<\/b>. A primera vista, son muy similares, aunque sus diferencias no se agotan en el nombre (de lo que hablaremos a continuaci\u00f3n). En ambas arquitecturas, las tablas de relaci\u00f3n pueden vincular <b>cualquier cantidad de entidades<\/b> (no necesariamente 2).<\/p>\n<p>Esta aparente redundancia brinda una flexibilidad considerable en las modificaciones. Esta estructura se vuelve tolerante no solo a los cambios en las cardinalidades de las relaciones existentes, sino tambi\u00e9n a la adici\u00f3n de nuevas: si ahora el elemento de chequeo tambi\u00e9n tiene un enlace al cajero que lo proces\u00f3, la aparici\u00f3n de dicha relaci\u00f3n se convierte simplemente en una superestructura sobre las tablas existentes sin afectar a ning\u00fan objeto o proceso existente.<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Duplicaci\u00f3n de datos<\/h4>\n<p>\nEl segundo problema que resuelven las arquitecturas flexibles es menos obvio y es caracter\u00edstico principalmente de <b>mediciones tipo SCD2<\/b> (dimensiones lentamente cambiantes de segundo tipo), aunque no solo de ellas.<\/p>\n<p>En un almac\u00e9n cl\u00e1sico, una dimensi\u00f3n normalmente representa una tabla que contiene una clave surrogada (como PK) as\u00ed como un conjunto de claves de negocio y atributos en columnas separadas. <\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSi la dimensi\u00f3n soporta versionado, al conjunto est\u00e1ndar de campos se a\u00f1aden l\u00edmites de tiempo de validez de la versi\u00f3n, y en una fila de la fuente aparecen varias versiones en el almac\u00e9n (una por cada cambio en los atributos de versi\u00f3n).<\/p>\n<p>Si una dimensi\u00f3n contiene al menos un atributo de versi\u00f3n que cambia con frecuencia, la cantidad de versiones de dicha dimensi\u00f3n ser\u00e1 considerable (incluso si los dem\u00e1s atributos no son de versi\u00f3n o nunca cambian), y si hay varios de esos atributos, la cantidad de versiones puede crecer en progresi\u00f3n geom\u00e9trica de acuerdo a su cantidad. Esta dimensi\u00f3n puede ocupar un volumen significativo de espacio en disco, aunque la mayor parte de los datos almacenados en ella son simplemente duplicados de los valores de atributos invariables de otras filas.<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA menudo se aplica tambi\u00e9n <b>la desnormalizaci\u00f3n<\/b> \u2014 parte de los atributos se almacenan intencionalmente como un valor y no como una referencia a un diccionario o a otra dimensi\u00f3n. Este enfoque acelera el acceso a los datos, reduciendo la cantidad de uniones al acceder a la dimensi\u00f3n.<\/p>\n<p>En general, esto lleva a que <b>la misma informaci\u00f3n se almacene simult\u00e1neamente en varios lugares<\/b>. Por ejemplo, la informaci\u00f3n sobre la regi\u00f3n de residencia y la pertenencia a la categor\u00eda del cliente puede almacenarse simult\u00e1neamente en las dimensiones \u201cCliente\u201d y en los hechos \u201cCompra\u201d, \u201cEntrega\u201d y \u201cLlamadas al centro de atenci\u00f3n al cliente\u201d, as\u00ed como en la tabla de v\u00ednculo \u201cCliente \u2014 Gestor de Cliente\u201d.<\/p>\n<p>Lo descrito anteriormente tambi\u00e9n se aplica a las dimensiones ordinarias (no versionadas), pero en las versionadas puede tener una escala diferente: la aparici\u00f3n de una nueva versi\u00f3n de un objeto (especialmente retroactivamente), no solo actualiza todas las tablas relacionadas, sino que provoca la aparici\u00f3n en cascada de nuevas versiones de los objetos relacionados, cuando la Tabla 1 se utiliza para construir la Tabla 2, y la Tabla 2 \u2014 para construir la Tabla 3, etc. Incluso si ning\u00fan atributo de la Tabla 1 participa en la construcci\u00f3n de la Tabla 3 (y otros atributos de la Tabla 2, obtenidos de otras fuentes, s\u00ed lo hacen), la actualizaci\u00f3n versionada de esta construcci\u00f3n como m\u00ednimo llevar\u00e1 a costos adicionales y, en el peor de los casos, a versiones innecesarias en la Tabla 3, que aqu\u00ed no tiene relevancia y as\u00ed sucesivamente en la cadena.<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Complejidad no lineal de la modificaci\u00f3n<\/h4>\n<p>\nA su vez, cada nueva vitrina construida sobre la base de otra aumenta la cantidad de lugares donde los datos pueden \u201cdesviarse\u201d al realizar cambios en ETL. Esto, a su vez, lleva a un aumento de la complejidad (y duraci\u00f3n) de cada modificaci\u00f3n subsiguiente.<\/p>\n<p>Si lo anterior se aplica a sistemas con procesos ETL que rara vez se modifican, es posible vivir en tal paradigma: basta con asegurarse de que las nuevas modificaciones se apliquen correctamente a todos los objetos relacionados. Sin embargo, si las modificaciones ocurren con frecuencia, la probabilidad de 'perder' accidentalmente algunas relaciones aumenta significativamente.<\/p>\n<p>Si adem\u00e1s se tiene en cuenta que el ETL 'versionado' es significativamente m\u00e1s complejo que el 'no versionado', evitar errores al realizar modificaciones frecuentes a todo este sistema se vuelve bastante complicado.<\/p>\n<h3>Almacenamiento de objetos y atributos en Data Vault y Modelo Ancla<\/h3>\n<p>\nEl enfoque propuesto por los autores de arquitecturas flexibles se puede formular de la siguiente manera:<\/p>\n<blockquote><p>Es necesario separar lo que cambia de lo que permanece inalterado. Es decir, almacenar las claves por separado de los atributos.<\/p><\/blockquote>\n<p> Sin embargo, no se debe confundir <b>no versionado<\/b> atributo con <b>inalterable<\/b>: el primero no almacena el historial de su cambio, pero puede variar (por ejemplo, al corregir un error de entrada o al recibir nuevos datos), el segundo nunca cambia.<\/p>\n<p>Las opiniones sobre lo que se puede considerar inalterable en Data Vault y el Modelo Ancla var\u00edan.<\/p>\n<p>Desde el punto de vista de la arquitectura <b>Data Vault<\/b>, se puede considerar inalterable <b>todo el conjunto de claves<\/b> \u2014 naturales (NIF de la organizaci\u00f3n, c\u00f3digo de producto en el sistema fuente, etc.) y surrogadas. Al mismo tiempo, los dem\u00e1s atributos se pueden dividir en grupos seg\u00fan la fuente y\/o frecuencia de cambios y <b>para cada grupo, llevar una tabla separada<\/b> con un conjunto independiente de versiones.<\/p>\n<p>En el paradigma <b>Modelo Ancla<\/b> , se considera inalterable <b>solo la clave surrogada<\/b> de la entidad. Todo lo dem\u00e1s (incluyendo las claves naturales) es simplemente un caso particular de sus atributos. Sin embargo, <b>todos los atributos son, por defecto, independientes entre s\u00ed<\/b>, por lo que para cada atributo debe crearse una <b>tabla separada<\/b>.<\/p>\n<p>En <b>Data Vault<\/b> las tablas que contienen las claves de las entidades se denominan <b>Hub (Hub)<\/b>. Los Hubs siempre contienen un conjunto fijo de campos:<\/p>\n<ul>\n<li>Claves naturales de la entidad<\/li>\n<li>Clave surrogada<\/li>\n<li>Referencia a la fuente<\/li>\n<li>Fecha de adici\u00f3n del registro<\/li>\n<\/ul>\n<p>\nLos registros en los Hubs <b>nunca cambian y no tienen versiones.<\/b>. Los hubs exteriores son muy parecidos a las tablas de tipo ID-map, utilizadas en algunos sistemas para generar sustitutos, sin embargo, se recomienda utilizar un hash de un conjunto de claves de negocio como sustituto en Data Vault. Este enfoque simplifica la carga de relaciones y atributos desde las fuentes (no es necesario hacer un join en el hub para obtener el sustituto; basta con calcular el hash de la clave natural), pero puede causar otros problemas (relacionados, por ejemplo, con colisiones, may\u00fasculas y caracteres no imprimibles en las claves de texto, etc.), por lo que no es com\u00fanmente aceptado.<\/p>\n<p>Todos los dem\u00e1s atributos de las entidades se almacenan en tablas especiales llamadas <b>Sat\u00e9lites (Satellit)<\/b>. Un hub puede tener varios sat\u00e9lites que almacenan diferentes conjuntos de atributos.<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nLa distribuci\u00f3n de atributos entre los sat\u00e9lites se realiza de acuerdo con el principio de <b>cambio conjunto<\/b> \u2014 en un sat\u00e9lite pueden almacenarse atributos no versionados (por ejemplo, la fecha de nacimiento y el n\u00famero de la Seguridad Social para personas f\u00edsicas), en otro, atributos versionados que cambian raramente (por ejemplo, el apellido y el n\u00famero del pasaporte), y en un tercero, atributos que cambian con frecuencia (como la direcci\u00f3n de entrega, categor\u00eda, fecha del \u00faltimo pedido, etc.). La versionidad se lleva a cabo a nivel de sat\u00e9lites individuales, y no de la entidad en su conjunto, por lo que es conveniente distribuir los atributos de tal manera que la intersecci\u00f3n de las versiones dentro de un sat\u00e9lite sea m\u00ednima (lo que reduce el n\u00famero total de versiones almacenadas). <\/p>\n<p>Adem\u00e1s, para optimizar el proceso de carga de datos, a menudo se extraen a sat\u00e9lites separados los atributos que se obtienen de diversas fuentes.<\/p>\n<p>Los sat\u00e9lites est\u00e1n vinculados al Hub mediante <b>clave externa<\/b> (lo que corresponde a la cardinalidad de uno a muchos). Esto significa que m\u00faltiples valores de atributos (por ejemplo, varios n\u00fameros de tel\u00e9fono de contacto para un mismo cliente) son compatibles de forma predeterminada con esta arquitectura.<\/p>\n<p>En <b>Modelo Ancla (Anchor Model)<\/b> las tablas que almacenan claves se llaman <b>Anclas (Anchor)<\/b>. Y almacenan: <\/p>\n<ul>\n<li><b>Solo claves sustitutas<\/b><\/li>\n<li>Referencia a la fuente<\/li>\n<li>Fecha de adici\u00f3n del registro<\/li>\n<\/ul>\n<p>\nLas claves naturales, desde la perspectiva del Modelo Ancla, se consideran <b>atributos comunes<\/b>. Esta opci\u00f3n puede parecer m\u00e1s compleja de entender, pero ofrece muchas m\u00e1s oportunidades para la identificaci\u00f3n del objeto.<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor ejemplo, si los datos de una misma entidad pueden llegar de diferentes sistemas, en cada uno de los cuales se utiliza su propia clave natural. En Data Vault, esto puede llevar a construcciones bastante complejas de varios hubs (uno por fuente + una versi\u00f3n maestra combinada), mientras que en el modelo Ancla cada clave natural de cada fuente se almacena en su propio atributo y puede ser utilizada durante la carga de manera independiente de los dem\u00e1s. <\/p>\n<p>Pero aqu\u00ed hay un punto enga\u00f1oso: si en una entidad se combinan atributos de diferentes sistemas, probablemente existan ciertas <b>reglas de 'fusi\u00f3n'<\/b>, seg\u00fan las cuales el sistema debe entender que los registros de diferentes fuentes corresponden a una instancia \u00fanica de la entidad. <\/p>\n<p>En <b>Data Vault<\/b> Estas reglas probablemente definir\u00e1n la formaci\u00f3n de <b>'un hub sustituto' de la entidad maestra<\/b> y no influir\u00e1n en los Hubs que almacenan las claves naturales de las fuentes y sus atributos originales. Si en alg\u00fan momento las reglas de fusi\u00f3n cambian (o llega una actualizaci\u00f3n de los atributos sobre los que se realiza), ser\u00e1 suficiente volver a formar los hubs sustitutos.<\/p>\n<p>En <b>El modelo Ancla<\/b> tendr\u00e1 tal entidad almacenada en <b>un \u00fanico ancla<\/b>. Esto significa que todos los atributos, independientemente de la fuente de donde provienen, estar\u00e1n vinculados a un mismo sustituto. Separar registros err\u00f3neamente fusionados y en general rastrear la validez de la fusi\u00f3n en tal sistema puede resultar mucho m\u00e1s dif\u00edcil, especialmente si las reglas son lo suficientemente complejas y cambian con frecuencia, y el mismo atributo puede provenir de diferentes fuentes (aunque es exactamente posible, ya que cada versi\u00f3n del atributo conserva un enlace a su fuente).<\/p>\n<p>En cualquier caso, si en su sistema se prev\u00e9 la implementaci\u00f3n de funcionalidades de <b>deduplicaci\u00f3n, fusi\u00f3n de registros y otros elementos de MDM<\/b>, es especialmente importante familiarizarse con los aspectos del almacenamiento de claves naturales en metodolog\u00edas flexibles. Es probable que una construcci\u00f3n m\u00e1s compleja de Data Vault resulte ser m\u00e1s segura en t\u00e9rminos de errores de fusi\u00f3n.<\/p>\n<p><b>El modelo Ancla<\/b> tambi\u00e9n contempla un tipo adicional de objeto llamado <b>Nudo (Knot)<\/b> y en esencia es un tipo especial de <b>ancla degenerada.<\/b>, que puede contener solo un atributo. Se supone que los nodos se utilizan para almacenar diccionarios planos (por ejemplo, g\u00e9nero, estado civil, categor\u00eda de servicio al cliente, etc.). A diferencia de un ancla, un nodo <b>no tiene tablas de atributos relacionadas<\/b>, y su \u00fanico atributo (nombre) siempre se almacena en la misma tabla con la clave. Los nodos se vinculan a las anclas mediante tablas de relaci\u00f3n (Tie) de la misma manera que los anclas entre s\u00ed.<\/p>\n<p>No hay un consenso definitivo sobre el uso de nodos. Por ejemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolai Golov<\/a><\/noindex>, que promueve activamente el uso del modelo de anclaje en Rusia, considera (no sin fundamento) que para ning\u00fan diccionario se puede afirmar con certeza que <b>siempre<\/b> ser\u00e1 est\u00e1tico y unidimensional, por lo que para todos los objetos es mejor usar un ancla completa desde el principio.<\/p>\n<p>Otra importante diferencia entre Data Vault y el modelo de anclaje es la existencia de <b>atributos en las relaciones<\/b>:<\/p>\n<p>En <b>Data Vault<\/b> Las relaciones son objetos completos, al igual que los hubs, y pueden tener <b>sus propios atributos<\/b>. Hay <b>El modelo Ancla<\/b> Las relaciones se utilizan \u00fanicamente para conectar anclas y <b>no pueden tener atributos propios<\/b>. Esta diferencia da lugar a enfoques de modelado significativamente diferentes <b>de hechos<\/b>, sobre lo que se hablar\u00e1 a continuaci\u00f3n.<\/p>\n<h3>Almacenamiento de hechos<\/h3>\n<p>\nHasta ahora, hemos hablado principalmente sobre la modelizaci\u00f3n de dimensiones. Con los hechos la situaci\u00f3n es un poco menos clara.<\/p>\n<p>En <b>Data Vault<\/b> objeto t\u00edpico para almacenar hechos \u2014<b> Relaci\u00f3n (Link)<\/b>, cuyos sat\u00e9lites contienen indicadores reales.<\/p>\n<p>Este enfoque parece intuitivamente claro. Ofrece acceso sencillo a los indicadores analizados y en general es similar a una tabla de hechos tradicional (solo que los indicadores no se almacenan en la propia tabla, sino en la 'vecina'). Pero hay trampas: una de las modificaciones t\u00edpicas del modelo \u2014la expansi\u00f3n de la clave del hecho\u2014 presenta la necesidad de <b>agregar una nueva clave externa en el Link<\/b>. A su vez, esto 'rompe' la modularidad y potencialmente requiere modificaciones en otros objetos.<\/p>\n<p>En <b>El modelo Ancla<\/b> La relaci\u00f3n no puede tener atributos propios, por lo que este enfoque no funcionar\u00e1: absolutamente todos los atributos e indicadores deben estar vinculados a un ancla concreta. La conclusi\u00f3n es simple: <b>cada hecho tambi\u00e9n necesita su propio ancla<\/b>Para una parte de lo que acostumbramos a ver como hechos, esto puede parecer natural, por ejemplo, el hecho de una compra se traduce perfectamente en un objeto \u201cpedido\u201d o \u201crecibo\u201d, la visita al sitio web se convierte en una sesi\u00f3n, etc. Pero hay hechos para los cuales encontrar un \u201cobjeto portador\u201d natural no es tan sencillo, como por ejemplo, los inventarios de productos al inicio de cada d\u00eda. <\/p>\n<p>En consecuencia, no hay problemas de modularidad al expandir la clave del hecho en el modelo Anchor (solo es necesario agregar una nueva Relaci\u00f3n al Anchor correspondiente), pero el dise\u00f1o del modelo para mostrar hechos es menos claro, pueden surgir Anchors \u201cartificiales\u201d que no representan evidentemente el modelo de negocio.<\/p>\n<h3>C\u00f3mo se logra la flexibilidad<\/h3>\n<p>\nLa construcci\u00f3n resultante en ambos casos contiene <b>muchas m\u00e1s tablas<\/b>, que una dimensi\u00f3n tradicional. Pero puede ocupar <b>sustancialmente menos espacio en disco<\/b> con el mismo conjunto de atributos de versi\u00f3n que una dimensi\u00f3n tradicional. No hay magia aqu\u00ed, por supuesto \u2014 todo se trata de la normalizaci\u00f3n. Al distribuir atributos en los Satellites (en Data Vault) o en tablas separadas (Modelo Anchor), reducimos (o eliminamos completamente) <b>la duplicaci\u00f3n de valores de alg\u00fan atributo al cambiar otros<\/b>.<\/p>\n<p>Para <b>Data Vault<\/b> el beneficio depender\u00e1 de la distribuci\u00f3n de los atributos en los Satellites, y para <b>El modelo Ancla<\/b> es pr\u00e1cticamente directamente proporcional al n\u00famero promedio de versiones del objeto de medici\u00f3n.<\/p>\n<p>Sin embargo, la ganancia en espacio ocupado es un beneficio importante, pero no el principal ventaja del almacenamiento separado de atributos. Junto con el almacenamiento separado de relaciones, este enfoque convierte el almacenamiento en <b>una construcci\u00f3n modular<\/b>. Esto significa que la adici\u00f3n tanto de atributos individuales como de nuevas \u00e1reas tem\u00e1ticas a este modelo parece una <b>superestructura<\/b> sobre el conjunto existente de objetos sin modificarlos. Y esto es precisamente lo que hace que las metodolog\u00edas descritas sean flexibles.<\/p>\n<p>Tambi\u00e9n recuerda la transici\u00f3n de la producci\u00f3n individual a la masiva \u2014 si en el enfoque tradicional cada tabla del modelo es \u00fanica y requiere atenci\u00f3n individual, en las metodolog\u00edas flexibles, ya es un conjunto de \u201ccomponentes\u201d est\u00e1ndar. Por un lado, hay m\u00e1s tablas, los procesos de carga y extracci\u00f3n de datos deben parecer m\u00e1s complicados. Por otro lado, se vuelven <b>est\u00e1ndar<\/b>. Y eso significa que pueden ser <b>automatizados y gestionados por metadatos<\/b>. La pregunta \u201c\u00bfc\u00f3mo vamos a estructurar?\u201d, cuya respuesta podr\u00eda haber ocupado una parte significativa del trabajo en el dise\u00f1o de mejoras, ahora simplemente no se plantea (al igual que la pregunta sobre el impacto del cambio de modelo en los procesos operativos). <\/p>\n<p>Esto no significa que los analistas en dicho sistema sean completamente prescindibles; a\u00fan se necesita a alguien que trabaje en un conjunto de objetos con atributos y sepa de d\u00f3nde y c\u00f3mo cargar todo esto. Sin embargo, el volumen de trabajo, as\u00ed como la probabilidad y el costo de errores, se reducen significativamente. Tanto en la fase de an\u00e1lisis como en el desarrollo de ETL, que en gran medida puede resumirse en la edici\u00f3n de metadatos. <\/p>\n<h3>El lado oscuro<\/h3>\n<p>\nTodo lo anterior hace que ambos enfoques sean realmente flexibles, tecnol\u00f3gicos y aptos para desarrollos iterativos. Por supuesto, hay tambi\u00e9n un \u201ctarro de miel\u201d, del que, creo que ya te est\u00e1s imaginando.<\/p>\n<p>La descomposici\u00f3n de datos, que subyace a la modularidad de arquitecturas flexibles, lleva a un aumento en la cantidad de tablas y, por lo tanto, <b>gastos generales<\/b> en uniones durante la selecci\u00f3n. Para obtener todos los atributos de la medida, en un almac\u00e9n cl\u00e1sico basta con una sola selecci\u00f3n, mientras que la arquitectura flexible requerir\u00e1 una serie de uniones. Adem\u00e1s, si para los informes se pueden escribir de antemano todas estas uniones, los analistas, acostumbrados a escribir SQL manualmente, sufrir\u00e1n el doble.<\/p>\n<p>Hay varios hechos que facilitan tal situaci\u00f3n:<\/p>\n<p><b>Al trabajar con grandes dimensiones, casi nunca se utilizan simult\u00e1neamente todos sus atributos.<\/b> Esto significa que puede haber menos uniones de las que parecen a primera vista en el modelo. En Data Vault tambi\u00e9n se puede tener en cuenta la frecuencia esperada de uso conjunto al distribuir atributos entre sat\u00e9lites. Al mismo tiempo, los hubs o anclas son necesarios principalmente para generar y mapear sustitutos en la fase de carga y rara vez se utilizan en consultas (especialmente en el caso de las anclas).<\/p>\n<p><b>Todas las uniones son por clave.<\/b> Adem\u00e1s, un m\u00e9todo de almacenamiento de datos m\u00e1s \"compacto\" reduce los costos de escaneo de tablas donde sea necesario (por ejemplo, al filtrar por el valor de un atributo). Esto puede hacer que la selecci\u00f3n de una base de datos normalizada con muchas uniones sea incluso m\u00e1s r\u00e1pida que el escaneo de una \u00fanica dimensi\u00f3n pesada con m\u00faltiples versiones por fila.<\/p>\n<p>Por ejemplo, en <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">esta <\/a><\/noindex> este art\u00edculo hay una prueba comparativa detallada del rendimiento del Modelo Anchor con selecci\u00f3n de una sola tabla.<\/p>\n<p><b>Mucho depende del motor.<\/b> Muchas plataformas modernas tienen mecanismos internos de optimizaci\u00f3n de uniones. Por ejemplo, MS SQL y Oracle pueden \"omitir\" uniones con tablas si sus datos no se utilizan en ning\u00fan otro lugar, excepto en otras uniones y no afectan la selecci\u00f3n final (eliminaci\u00f3n de tabla\/uni\u00f3n), mientras que el MPP Vertica, seg\u00fan <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">la experiencia de mis colegas en Avito<\/a><\/noindex>, ha demostrado ser un gran motor para el Modelo Anchor con cierta optimizaci\u00f3n manual del plan de consulta. Por otro lado, almacenar el Modelo Anchor, por ejemplo, en Click House, que tiene un soporte limitado para uniones, no parece ser una buena idea.<\/p>\n<p>Adem\u00e1s, para ambas arquitecturas existen <b>t\u00e9cnicas especiales<\/b>, que facilitan el acceso a los datos (tanto desde el punto de vista del rendimiento de las consultas como para los usuarios finales). Por ejemplo, <b>las tablas Point-In-Time<\/b> en Data Vault o <b>funciones tabulares especiales<\/b> en el Modelo Anchor.<\/p>\n<h2>Total<\/h2>\n<p>\nLa esencia de estas arquitecturas flexibles radica en la modularidad de sus \"construcciones\". <\/p>\n<p>Precisamente esta propiedad permite:<\/p>\n<ul>\n<li>Despu\u00e9s de una preparaci\u00f3n inicial relacionada con el despliegue de metadatos y la escritura de algoritmos b\u00e1sicos de ETL, <b>proporcionar r\u00e1pidamente al cliente un primer resultado<\/b> en forma de un par de informes que contienen datos de solo unos pocos objetos fuente. No es necesario planificar completamente (incluso a un alto nivel) todo el modelo de objetos para esto.<\/li>\n<li>El modelo de datos puede comenzar a operar (y aportar beneficios) con solo 2-3 objetos, y luego <b>crecer progresivamente<\/b> (en relaci\u00f3n con el Modelo Anchor, Nikolai <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">aplic\u00f3 <\/a><\/noindex>una bonita comparaci\u00f3n con una micorriza).<\/li>\n<li>La mayor\u00eda de las modificaciones, incluyendo la ampliaci\u00f3n del dominio tem\u00e1tico y la adici\u00f3n de nuevas fuentes <b>no afectan la funcionalidad existente y no corren el riesgo de romper algo que ya est\u00e9 funcionando.<\/b>.<\/li>\n<li>Gracias a la descomposici\u00f3n en elementos est\u00e1ndar, los procesos ETL en tales sistemas tienen una apariencia uniforme, su escritura puede ser sistematizada y, al final, <b>automatizaci\u00f3n<\/b>.<\/li>\n<\/ul>\n<p>\nEl precio de tal flexibilidad es <b>rendimiento<\/b>. Esto no significa que alcanzar un rendimiento aceptable en tales modelos sea imposible. M\u00e1s bien, a menudo puede requerir m\u00e1s esfuerzo y atenci\u00f3n a los detalles para lograr las m\u00e9tricas deseadas.<\/p>\n<h2>Aplicaciones<\/h2>\n<p><\/p>\n<h4>Tipos de entidad <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nM\u00e1s sobre Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Sitio de Dan Linstedt<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"http:\/\/www.dwh-club.com\/ru\/dwh-bi-articles\/vse-o-data-vault.html\">Todo sobre Data Vault en ruso<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/348188\/\">Sobre Data Vault en Habrahabr<\/a><\/noindex><\/p>\n<h4>Tipos de entidades <b>Modelo Ancla<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nM\u00e1s sobre el modelo Anchor:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Sitio de los creadores del modelo Anchor<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Art\u00edculo sobre la experiencia de implementaci\u00f3n del modelo Anchor en Avito<\/a><\/noindex><\/p>\n<p>Tabla resumen con caracter\u00edsticas comunes y diferencias de los enfoques discutidos:<\/p>\n<p><img decoding=\"async\" alt=\"Resumen de metodolog\u00edas de dise\u00f1o \u00e1gil para DWH\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/glowbyte\/blog\/515940\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435. \u041c\u043d\u043e\u0433\u043e\u0435 \u0432 \u0436\u0438\u0437\u043d\u0438 \u043f\u0440\u043e\u0435\u043a\u0442\u0430 \u0437\u0430\u0432\u0438\u0441\u0438\u0442 \u043e\u0442 \u0442\u043e\u0433\u043e, \u043d\u0430\u0441\u043a\u043e\u043b\u044c\u043a\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u0440\u043e\u0434\u0443\u043c\u0430\u043d\u0430 \u043e\u0431\u044a\u0435\u043a\u0442\u043d\u0430\u044f \u043c\u043e\u0434\u0435\u043b\u044c \u0438 \u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u0430 \u0431\u0430\u0437\u044b \u043d\u0430 \u0441\u0442\u0430\u0440\u0442\u0435. \u041e\u0431\u0449\u0435\u043f\u0440\u0438\u043d\u044f\u0442\u044b\u043c \u043f\u043e\u0434\u0445\u043e\u0434\u043e\u043c \u0431\u044b\u043b\u0438 \u0438 \u043e\u0441\u0442\u0430\u044e\u0442\u0441\u044f \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u0435 \u0432\u0430\u0440\u0438\u0430\u043d\u0442\u044b \u0441\u043e\u0447\u0435\u0442\u0430\u043d\u0438\u044f \u0441\u0445\u0435\u043c\u044b \u201c\u0437\u0432\u0435\u0437\u0434\u0430\u201d \u0441 \u0442\u0440\u0435\u0442\u044c\u0435\u0439 \u043d\u043e\u0440\u043c\u0430\u043b\u044c\u043d\u043e\u0439 \u0444\u043e\u0440\u043c\u043e\u0439. \u041a\u0430\u043a \u043f\u0440\u0430\u0432\u0438\u043b\u043e, \u043f\u043e \u043f\u0440\u0438\u043d\u0446\u0438\u043f\u0443: \u0438\u0441\u0445\u043e\u0434\u043d\u044b\u0435 \u0434\u0430\u043d\u043d\u044b\u0435 \u2014 3NF, \u0432\u0438\u0442\u0440\u0438\u043d\u044b \u2014 \u0437\u0432\u0435\u0437\u0434\u0430. \u042d\u0442\u043e\u0442 \u043f\u043e\u0434\u0445\u043e\u0434, \u043f\u0440\u043e\u0432\u0435\u0440\u0435\u043d\u043d\u044b\u0439 \u0432\u0440\u0435\u043c\u0435\u043d\u0435\u043c \u0438 \u043f\u043e\u0434\u043a\u0440\u0435\u043f\u043b\u0435\u043d\u043d\u044b\u0439 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":92016,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-92015","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-08-21T17:42:13+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Revisi\u00f3n de metodolog\u00edas \u00e1giles de dise\u00f1o DWH | ProHoster","description":"El desarrollo de un almac\u00e9n es un proceso largo y serio.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u041e\u0431\u0437\u043e\u0440 \u0433\u0438\u0431\u043a\u0438\u0445 \u043c\u0435\u0442\u043e\u0434\u043e\u043b\u043e\u0433\u0438\u0439 \u043f\u0440\u043e\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f DWH | ProHoster","og:description":"\u0420\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u0445\u0440\u0430\u043d\u0438\u043b\u0438\u0449\u0430 \u2014 \u0434\u0435\u043b\u043e \u0434\u043e\u043b\u0433\u043e\u0435 \u0438 \u0441\u0435\u0440\u044c\u0435\u0437\u043d\u043e\u0435.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-08-21T17:42:13+00:00","article:modified_time":"2020-08-21T17:42:13+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"92015","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 12:16:44","updated":"2022-09-27 14:57:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}