{"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\/pt\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","title":{"rendered":"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>Desenvolver um armaz\u00e9m \u00e9 um trabalho demorado e s\u00e9rio. <\/p>\n<p>Muito na vida de um projeto depende de qu\u00e3o bem elaborada est\u00e1 a modelagem de objetos e a estrutura do banco desde o in\u00edcio.<\/p>\n<p>A abordagem comum sempre foi e permanece sendo v\u00e1rias combina\u00e7\u00f5es do esquema \u201cestrela\u201d com a terceira forma normal. Geralmente, pelo princ\u00edpio: dados brutos \u2014 3NF, vitrines \u2014 estrela. Essa abordagem, comprovada pelo tempo e respaldada por uma quantidade consider\u00e1vel de pesquisas, \u00e9 a primeira (e \u00e0s vezes a \u00fanica) que vem \u00e0 mente de um experiente especialista em DWH ao pensar em como deve ser um armaz\u00e9m anal\u00edtico.<\/p>\n<p>Por outro lado, os neg\u00f3cios em geral e os requisitos do cliente em particular tendem a mudar rapidamente, e os dados a crescer tanto em \u201cprofundidade\u201d quanto em \u201clargura\u201d. E \u00e9 aqui que se revela a principal desvantagem da estrela \u2014 sua limita\u00e7\u00e3o. <b>flexibilidade<\/b>.<\/p>\n<p>E se na sua vida tranquila e confort\u00e1vel de desenvolvedor de DWH, de repente:<\/p>\n<ul>\n<li>surgiu a tarefa de \u201cfazer rapidamente algo, e depois veremos\u201d;<\/li>\n<li>apareceu um projeto em r\u00e1pida expans\u00e3o, com a inclus\u00e3o de novas fontes e a reformula\u00e7\u00e3o do modelo de neg\u00f3cios pelo menos uma vez por semana;<\/li>\n<li>surgiu um cliente que n\u00e3o tem ideia de como o sistema deve parecer e quais fun\u00e7\u00f5es deve desempenhar no final, mas que est\u00e1 aberto a experimentos e ajustes sucessivos dos resultados desejados, aproximando-se deles gradualmente;<\/li>\n<li>um gerente de projetos apareceu com a feliz not\u00edcia: \u201cE agora temos \u00e1gil!\u201d.<\/li>\n<\/ul>\n<p>\nOu se voc\u00ea est\u00e1 apenas curioso para saber de que outras maneiras os armaz\u00e9ns podem ser constru\u00eddos \u2014 bem-vindo ao post!<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de 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>O que significa \u201cflexibilidade\u201d?<\/h3>\n<p>\nPara come\u00e7ar, vamos definir quais propriedades um sistema deve ter para ser considerado \u201cflex\u00edvel\u201d. <\/p>\n<p>Vale a pena ressaltar que as propriedades descritas devem se referir especificamente a <b>o sistema<\/b>, e n\u00e3o a <b>processo <\/b>de seu desenvolvimento. Portanto, se voc\u00ea queria ler sobre Agile como metodologia de desenvolvimento, \u00e9 melhor consultar outros artigos. Por exemplo, aqui mesmo, no Habr, existem muitos materiais interessantes (como <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/436178\/\">resumo<\/a><\/noindex> e <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/284012\/\">pr\u00e1tico<\/a><\/noindex>, quanto o <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataart\/blog\/245605\/\">problem\u00e1tico<\/a><\/noindex>).<\/p>\n<p>Isso n\u00e3o significa que o processo de desenvolvimento e a estrutura de um Data Warehouse (DW) n\u00e3o estejam de forma alguma interligados. De modo geral, desenvolver um armaz\u00e9m com uma arquitetura flex\u00edvel utilizando Agile deve ser significativamente mais f\u00e1cil. No entanto, na pr\u00e1tica, \u00e9 mais comum encontrar implementa\u00e7\u00f5es com desenvolvimento Agile de um DW cl\u00e1ssico pelo m\u00e9todo Kimball ou DataVault \u2014 seguindo o waterfall, do que coincidir com a flexibilidade em suas duas formas em um \u00fanico projeto.<\/p>\n<p>Assim, quais caracter\u00edsticas um armaz\u00e9m flex\u00edvel deve ter? Podemos destacar tr\u00eas pontos:<\/p>\n<ol>\n<li><b>Entrega antecipada e r\u00e1pida adapta\u00e7\u00e3o<\/b> \u2014 isso significa que, idealmente, o primeiro resultado comercial (por exemplo, os primeiros relat\u00f3rios funcionais) deve ser obtido o mais r\u00e1pido poss\u00edvel, ou seja, antes de todo o sistema ser completamente projetado e implementado. Al\u00e9m disso, cada adapta\u00e7\u00e3o subsequente tamb\u00e9m deve levar o menor tempo poss\u00edvel.<\/li>\n<li><b>Revis\u00e3o iterativa<\/b> \u2014 isso significa que cada adapta\u00e7\u00e3o subsequente n\u00e3o deve, idealmente, afetar as funcionalidades j\u00e1 operacionais. Este aspecto frequentemente se torna o maior pesadelo em grandes projetos \u2014 cedo ou tarde, objetos individuais come\u00e7am a acumular tantas interconex\u00f5es que se torna mais simples duplicar completamente a l\u00f3gica em uma c\u00f3pia ao lado do que adicionar um campo \u00e0 tabela existente. E se voc\u00ea se surpreende ao descobrir que a an\u00e1lise do impacto da adapta\u00e7\u00e3o nos objetos existentes pode levar mais tempo do que a pr\u00f3pria adapta\u00e7\u00e3o \u2014 provavelmente voc\u00ea ainda n\u00e3o trabalhou com grandes DWs em setores banc\u00e1rio ou de telecomunica\u00e7\u00f5es.<\/li>\n<li><b>Adapta\u00e7\u00e3o cont\u00ednua \u00e0s mudan\u00e7as nos requisitos de neg\u00f3cios<\/b> \u2014 a estrutura geral dos objetos deve ser projetada n\u00e3o apenas considerando a possibilidade de expans\u00e3o, mas com a previs\u00e3o de que a dire\u00e7\u00e3o dessa expans\u00e3o poderia nunca ter sido imaginada na fase de design.<\/li>\n<\/ol>\n<p>\nE sim, atender a todos esses requisitos em um \u00fanico sistema \u00e9 poss\u00edvel (claro, em certos casos e com algumas ressalvas).<\/p>\n<p>Abaixo, eu revisarei duas das metodologias mais populares para projetos flex\u00edveis de DW \u2014 <b>Modelo Anchor<\/b> e <b>Data Vault<\/b>. H\u00e1 t\u00e9cnicas maravilhosas que ficam de fora, como EAV, 6NF (na sua forma pura) e tudo que se refere a solu\u00e7\u00f5es NoSQL - n\u00e3o porque sejam de alguma forma piores, e nem porque o artigo correria o risco de se tornar o tamanho de uma disserta\u00e7\u00e3o m\u00e9dia. Simplesmente, tudo isso se relaciona a solu\u00e7\u00f5es de uma classe um pouco diferente - ou a t\u00e9cnicas que voc\u00ea pode aplicar em casos espec\u00edficos, independentemente da arquitetura geral do seu projeto (como EAV), ou a paradigmas de armazenamento de informa\u00e7\u00f5es totalmente diferentes (como, por exemplo, bancos de dados de grafos e outras op\u00e7\u00f5es NoSQL).<\/p>\n<h3>Problemas da abordagem \u201ccl\u00e1ssica\u201d e suas solu\u00e7\u00f5es em metodologias \u00e1geis<\/h3>\n<p>\n<i>Com a abordagem \u201ccl\u00e1ssica\u201d, refiro-me ao velho conhecido (independentemente da implementa\u00e7\u00e3o espec\u00edfica das camadas subjacentes, que os adeptos de Kimball, Inmon e CDM me perdoem).<br \/>\n<\/i><\/p>\n<h4>1. Cardinalidade r\u00edgida dos relacionamentos<\/h4>\n<p>\nNesta modelagem, h\u00e1 uma clara separa\u00e7\u00e3o de dados em <b>dimens\u00f5es (Dimension)<\/b> e <b>fatos (Fact)<\/b>. E isso, veja bem, faz sentido - pois a an\u00e1lise de dados na esmagadora maioria dos casos se resume \u00e0 an\u00e1lise de indicadores num\u00e9ricos espec\u00edficos (fatos) em determinadas perspectivas (dimens\u00f5es).<\/p>\n<p>Al\u00e9m disso, os relacionamentos entre os objetos s\u00e3o estabelecidos na forma de liga\u00e7\u00f5es entre tabelas por chaves estrangeiras. Isso parece bastante natural, mas leva imediatamente \u00e0 primeira limita\u00e7\u00e3o da flexibilidade - <b>defini\u00e7\u00e3o r\u00edgida da cardinalidade dos relacionamentos.<\/b>.<\/p>\n<p>Isso significa que, na fase de design das tabelas, voc\u00ea deve definir com precis\u00e3o para cada par de objetos relacionados se eles podem se relacionar como muitos-para-muitos, ou apenas um-para-muitos, e \u201cem que dire\u00e7\u00e3o\u201d. Isso afeta diretamente em qual tabela estar\u00e1 a chave prim\u00e1ria e em qual estar\u00e1 a chave estrangeira. Alterar esse relacionamento ao receber novos requisitos provavelmente resultar\u00e1 em uma reestrutura\u00e7\u00e3o do banco de dados.<\/p>\n<p>Por exemplo, ao projetar um objeto \u201ccomprovante de pagamento\u201d, voc\u00ea, baseando-se nas promessas feitas pelo departamento de vendas, planejou a possibilidade de uma <b>promo\u00e7\u00e3o se aplicar a v\u00e1rias linhas do comprovante<\/b> mas n\u00e3o o contr\u00e1rio:<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/15226cb79c30364d94147383ba36a8fd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\nE depois de um tempo, os colegas introduziram uma nova estrat\u00e9gia de marketing, na qual v\u00e1rias promo\u00e7\u00f5es podem ser aplicadas simultaneamente \u00e0 mesma linha. <b>Agora voc\u00ea precisa revisar as tabelas, destacando o relacionamento como um objeto separado.<\/b>. <\/p>\n<p>(Todos os objetos derivados no qual ocorre o join na promo\u00e7\u00e3o tamb\u00e9m precisam ser ajustados agora).<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/3c4d84a31088660257d74c4c703071e0.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<b>Rela\u00e7\u00f5es no Data Vault e no Modelo Anchor<\/b><\/p>\n<p>Evitar tal situa\u00e7\u00e3o foi bastante simples: n\u00e3o se deve confiar no departamento de vendas para isso. <b>Manter todas as rela\u00e7\u00f5es inicialmente em tabelas separadas.<\/b> E process\u00e1-las como muitos-para-muitos. <\/p>\n<p>Essa abordagem foi proposta <b>por Dan Linstedt<\/b> como parte da paradigm\u00e1tica <b>Data Vault<\/b> e totalmente apoiada <b>por Lars R\u00f6nnb\u00e4ck<\/b> em <b>do Modelo Anchor<\/b>.<\/p>\n<p>No final, obtemos a primeira caracter\u00edstica distintiva das metodologias \u00e1geis:<\/p>\n<blockquote><p>As rela\u00e7\u00f5es entre os objetos n\u00e3o s\u00e3o armazenadas nos atributos das entidades pai, mas constituem um tipo separado de objetos.<\/p><\/blockquote>\n<p>Em <b>Data Vault<\/b> Essas tabelas de jun\u00e7\u00e3o s\u00e3o chamadas <b>Liga\u00e7\u00e3o<\/b>, e no <b>Modelo Anchor<\/b> \u2014 <b>Tie<\/b>. \u00c0 primeira vista, elas parecem muito semelhantes, embora suas diferen\u00e7as n\u00e3o se limitem ao nome (sobre isso falaremos mais abaixo). Em ambas as arquiteturas, as tabelas de jun\u00e7\u00e3o podem conectar <b>qualquer n\u00famero de entidades<\/b> (n\u00e3o necessariamente 2).<\/p>\n<p>Essa aparente redund\u00e2ncia proporciona uma flexibilidade significativa em ajustes. Essa estrutura torna-se tolerante n\u00e3o apenas \u00e0s mudan\u00e7as nas cardinalidades das rela\u00e7\u00f5es existentes, mas tamb\u00e9m \u00e0 adi\u00e7\u00e3o de novas \u2014 se agora uma posi\u00e7\u00e3o de cheque tiver uma refer\u00eancia ao caixa que a processou, o surgimento de tal jun\u00e7\u00e3o ser\u00e1 apenas uma extens\u00e3o das tabelas existentes sem impactar quaisquer objetos e processos existentes.<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6a3b942a6e5d04dcbe2ff0881ebdf1bf.png\" style=\"display:block;margin: 0 auto;\" \/><\/p>\n<h4>2. Duplica\u00e7\u00e3o de dados<\/h4>\n<p>\nO segundo problema abordado por arquiteturas flex\u00edveis \u00e9 menos \u00f3bvio e \u00e9 caracter\u00edstico principalmente <b>de medidas do tipo SCD2<\/b> (medidas lentamente mudando do segundo tipo), embora n\u00e3o apenas para elas.<\/p>\n<p>Em um armaz\u00e9m de dados cl\u00e1ssico, a medida geralmente \u00e9 uma tabela que cont\u00e9m uma chave substituta (como PK) e tamb\u00e9m um conjunto de chaves e atributos de neg\u00f3cio em colunas separadas. <\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/059dd47b2302b58c19a0144061b78cb4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe a medida suporta versionamento, ao conjunto padr\u00e3o de campos s\u00e3o adicionados limites de tempo de validade da vers\u00e3o, e na fonte uma linha aparece com v\u00e1rias vers\u00f5es no armaz\u00e9m (uma para cada altera\u00e7\u00e3o dos atributos de vers\u00e3o).<\/p>\n<p>Se a medi\u00e7\u00e3o contiver pelo menos um atributo de vers\u00e3o que muda com frequ\u00eancia, o n\u00famero de vers\u00f5es dessa medi\u00e7\u00e3o ser\u00e1 consider\u00e1vel (mesmo que os outros atributos n\u00e3o sejam versionados ou nunca mudem) e, se houver v\u00e1rios desses atributos, o n\u00famero de vers\u00f5es pode crescer em progress\u00e3o geom\u00e9trica de acordo com sua quantidade. Essa medi\u00e7\u00e3o pode ocupar um espa\u00e7o significativo em disco, embora a maior parte dos dados armazenados sejam apenas c\u00f3pias de valores de atributos imut\u00e1veis de outras linhas.<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/f3d5a4fd83a5ef36355961302173791d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nNesse contexto, \u00e9 muito comum tamb\u00e9m aplicar <b>a desnormaliza\u00e7\u00e3o<\/b> \u2014 parte dos atributos \u00e9 intencionalmente armazenada como valor, e n\u00e3o como refer\u00eancia a um dicion\u00e1rio ou outra medi\u00e7\u00e3o. Essa abordagem acelera o acesso aos dados, reduzindo o n\u00famero de joins ao acessar a medi\u00e7\u00e3o.<\/p>\n<p>Geralmente, isso resulta no fato de que <b>a mesma informa\u00e7\u00e3o \u00e9 armazenada simultaneamente em v\u00e1rios locais<\/b>. Por exemplo, informa\u00e7\u00f5es sobre a regi\u00e3o de resid\u00eancia e a categoria do cliente podem ser armazenadas simultaneamente nas medi\u00e7\u00f5es \"Cliente\" e nos fatos \"Compra\", \"Entrega\" e \"Chamadas ao centro de atendimento\", al\u00e9m da tabela de v\u00ednculo \"Cliente \u2014 Gerente de Cliente\".<\/p>\n<p>De modo geral, o que foi descrito acima tamb\u00e9m se aplica a medi\u00e7\u00f5es normais (n\u00e3o versionadas), mas em medi\u00e7\u00f5es versionadas pode ter uma escala diferente: a apari\u00e7\u00e3o de uma nova vers\u00e3o de um objeto (especialmente retroativamente) resulta n\u00e3o apenas na atualiza\u00e7\u00e3o de todas as tabelas relacionadas, mas na cascata de novas vers\u00f5es de objetos relacionados \u2014 quando a Tabela 1 \u00e9 usada na constru\u00e7\u00e3o da Tabela 2, e a Tabela 2 \u00e9 usada na constru\u00e7\u00e3o da Tabela 3, e assim por diante. Mesmo que nenhum atributo da Tabela 1 participe da constru\u00e7\u00e3o da Tabela 3 (mas outros atributos da Tabela 2, obtidos de outras fontes, participem), a atualiza\u00e7\u00e3o versionada dessa constru\u00e7\u00e3o resultar\u00e1, no m\u00ednimo, em custos adicionais, e no m\u00e1ximo \u2014 em vers\u00f5es desnecess\u00e1rias na Tabela 3, que aqui est\u00e1 completamente \"fora da quest\u00e3o\", e assim por diante ao longo da cadeia.<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/2935f93abc46f02bdc528accda2af758.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h4>3. Complexidade n\u00e3o linear de ajustes<\/h4>\n<p>\nNesse contexto, cada nova vitrine que \u00e9 constru\u00edda com base em outra aumenta o n\u00famero de locais onde os dados podem \"divergir\" ao se fazer altera\u00e7\u00f5es no ETL. Isso, por sua vez, leva a um aumento da complexidade (e dura\u00e7\u00e3o) de cada ajuste subsequente.<\/p>\n<p>Se o descrito acima se aplica a sistemas com processos ETL que raramente s\u00e3o modificados, \u00e9 poss\u00edvel viver nessa paradigma \u2014 basta garantir que novas modifica\u00e7\u00f5es sejam corretamente aplicadas a todos os objetos relacionados. No entanto, se as modifica\u00e7\u00f5es ocorrem com frequ\u00eancia, a probabilidade de acidentalmente \"perder\" v\u00e1rias conex\u00f5es aumenta significativamente.<\/p>\n<p>Al\u00e9m disso, se considerarmos que o ETL \"versionado\" \u00e9 substancialmente mais complexo do que o \"n\u00e3o versionado\", evitar erros durante a modifica\u00e7\u00e3o frequente de todo esse conjunto se torna bastante dif\u00edcil.<\/p>\n<h3>Armazenamento de objetos e atributos no Data Vault e no Modelo \u00c2ncora<\/h3>\n<p>\nA abordagem proposta pelos autores de arquiteturas flex\u00edveis pode ser formulada assim:<\/p>\n<blockquote><p>\u00c9 necess\u00e1rio separar o que muda do que permanece inalterado. Ou seja, armazenar chaves separadamente dos atributos.<\/p><\/blockquote>\n<p> Ao mesmo tempo, n\u00e3o devemos confundir <b>n\u00e3o versionado<\/b> atributo com <b>imut\u00e1vel<\/b>: o primeiro n\u00e3o registra o hist\u00f3rico de suas altera\u00e7\u00f5es, mas pode mudar (por exemplo, ao corrigir um erro de entrada ou ao receber novos dados) o segundo \u2014 nunca muda.<\/p>\n<p>As opini\u00f5es sobre o que pode ser considerado imut\u00e1vel no Data Vault e no Modelo \u00c2ncora divergem.<\/p>\n<p>Do ponto de vista da arquitetura <b>Data Vault<\/b>, o que pode ser considerado imut\u00e1vel \u00e9 <b>todo o conjunto de chaves<\/b> \u2014 naturais (CNPJ da empresa, c\u00f3digo do produto no sistema de origem, etc.) e surrogate. Enquanto isso, os outros atributos podem ser divididos em grupos por origem e\/ou frequ\u00eancia de mudan\u00e7as e <b>para cada grupo, manter uma tabela separada<\/b> com um conjunto independente de vers\u00f5es.<\/p>\n<p>Na paradigma do <b>Modelo \u00c2ncora<\/b> , considera-se imut\u00e1vel <b>apenas a chave surrogate<\/b> da entidade. Tudo o mais (incluindo chaves tradicionais) \u00e9 apenas uma condi\u00e7\u00e3o particular de seus atributos. Nesse contexto, <b>todos os atributos, por padr\u00e3o, s\u00e3o independentes uns dos outros<\/b>, portanto, para cada atributo, deve ser criada uma <b>tabela separada<\/b>.<\/p>\n<p>Em <b>Data Vault<\/b> as tabelas que cont\u00eam as chaves das entidades s\u00e3o chamadas de <b>Hubs<\/b>. Os Hubs sempre cont\u00eam um conjunto fixo de campos:<\/p>\n<ul>\n<li>Chaves naturais da entidade<\/li>\n<li>Chave surrogate<\/li>\n<li>Refer\u00eancia \u00e0 fonte<\/li>\n<li>Tempo de adi\u00e7\u00e3o do registro<\/li>\n<\/ul>\n<p>\nRegistros nos Hubs <b>nunca s\u00e3o modificados e n\u00e3o t\u00eam vers\u00f5es.<\/b>. Os hubs se parecem muito com tabelas do tipo ID-map, usadas em alguns sistemas para gerar substitutos, mas na pr\u00e1tica do Data Vault, recomenda-se utilizar n\u00e3o um sequencial inteiro como substituto, mas um hash de um conjunto de chaves de neg\u00f3cios. Essa abordagem simplifica o carregamento de relacionamentos e atributos das fontes (n\u00e3o \u00e9 necess\u00e1rio fazer join no hub para obter um substituto, basta calcular o hash da chave natural), mas pode causar outros problemas (como colis\u00f5es, distin\u00e7\u00e3o de mai\u00fasculas e min\u00fasculas e caracteres n\u00e3o imprim\u00edveis em chaves de string, etc.), portanto, n\u00e3o \u00e9 uma pr\u00e1tica comum.<\/p>\n<p>Todos os outros atributos das entidades s\u00e3o armazenados em tabelas especiais chamadas <b>Sat\u00e9lites (Satellit)<\/b>. Um hub pode ter v\u00e1rios sat\u00e9lites, armazenando diferentes conjuntos de atributos.<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/e145f211b8cfb51894e6e1789991e1cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA distribui\u00e7\u00e3o de atributos entre os sat\u00e9lites segue o princ\u00edpio de <b>altera\u00e7\u00e3o conjunta<\/b> \u2014 em um sat\u00e9lite podem ser armazenados atributos n\u00e3o versionados (por exemplo, data de nascimento e CPF para uma pessoa f\u00edsica), em outro, atributos versionados que mudam raramente (por exemplo, sobrenome e n\u00famero do passaporte), e em um terceiro, atributos que mudam frequentemente (por exemplo, endere\u00e7o de entrega, categoria, data do \u00faltimo pedido, etc.). A versionamento \u00e9 gerido em n\u00edvel de sat\u00e9lites individuais, e n\u00e3o da entidade como um todo, portanto, a distribui\u00e7\u00e3o dos atributos deve ser feita de maneira a minimizar a interse\u00e7\u00e3o de vers\u00f5es dentro de um \u00fanico sat\u00e9lite (o que reduz o n\u00famero total de vers\u00f5es armazenadas). <\/p>\n<p>Al\u00e9m disso, para otimizar o processo de carregamento de dados, atributos obtidos de v\u00e1rias fontes s\u00e3o frequentemente colocados em sat\u00e9lites separados.<\/p>\n<p>Os sat\u00e9lites s\u00e3o associados ao Hub por meio de <b>uma chave estrangeira<\/b> o que corresponde \u00e0 cardinalidade 1-para-muitos. Isso significa que m\u00faltiplos valores de atributos (por exemplo, v\u00e1rios n\u00fameros de telefone de contato para um \u00fanico cliente) s\u00e3o suportados por essa arquitetura 'por padr\u00e3o'.<\/p>\n<p>Em <b>Modelo \u00c2ncora (Anchor Model)<\/b> tabelas que armazenam chaves s\u00e3o chamadas de <b>\u00c2ncoras (Anchor)<\/b>. E elas armazenam: <\/p>\n<ul>\n<li><b>Somente chaves substitutas<\/b><\/li>\n<li>Refer\u00eancia \u00e0 fonte<\/li>\n<li>Tempo de adi\u00e7\u00e3o do registro<\/li>\n<\/ul>\n<p>\nChaves naturais, do ponto de vista do Modelo \u00c2ncora, s\u00e3o consideradas <b>atributos comuns<\/b>. Essa variante pode parecer mais complexa de entender, mas oferece muito mais espa\u00e7o para a identifica\u00e7\u00e3o do objeto.<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/0bf941581fd1177eda228d4429cf69db.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor exemplo, se os dados sobre uma mesma entidade podem vir de diferentes sistemas, cada um utilizando sua pr\u00f3pria chave natural. No Data Vault, isso pode levar a constru\u00e7\u00f5es bastante complexas compostas por v\u00e1rios hubs (um para cada fonte + uma vers\u00e3o mestre unificadora), enquanto na Modelo Ancorado, a chave natural de cada fonte entra em seu pr\u00f3prio atributo e pode ser utilizada durante o carregamento independentemente dos demais. <\/p>\n<p>Mas aqui h\u00e1 um detalhe trai\u00e7oeiro: se em uma entidade atributos de diferentes sistemas s\u00e3o combinados, provavelmente existem certas <b>regras de 'uni\u00e3o'<\/b>, segundo as quais o sistema deve entender que registros de diferentes fontes correspondem a uma \u00fanica inst\u00e2ncia da entidade. <\/p>\n<p>Em <b>Data Vault<\/b> Essas regras provavelmente definir\u00e3o a forma\u00e7\u00e3o do <b>'hub substituto' da entidade mestre<\/b> e n\u00e3o afetar\u00e3o os Hubs que armazenam as chaves naturais das fontes e seus atributos originais. Se em algum momento as regras de uni\u00e3o mudarem (ou houver uma atualiza\u00e7\u00e3o dos atributos pelos quais isso \u00e9 feito), ser\u00e1 suficiente reformular os hubs substitutos.<\/p>\n<p>Em <b>O Modelo Ancorado<\/b> por sua vez, armazenar\u00e1 essa entidade <b>em um \u00fanico \u00e2ncora<\/b>. Isso significa que todos os atributos, independentemente da fonte de onde foram obtidos, estar\u00e3o vinculados ao mesmo substituto. Separar registros erroneamente unificados e acompanhar a relev\u00e2ncia da uni\u00e3o em um sistema assim pode ser consideravelmente mais dif\u00edcil, especialmente se as regras forem complexas e mudarem frequentemente, e um mesmo atributo puder ser obtido a partir de diferentes fontes (embora isso seja definitivamente poss\u00edvel, pois cada vers\u00e3o do atributo mant\u00e9m um link para sua fonte).<\/p>\n<p>Em todo caso, se em seu sistema est\u00e1 prevista a implementa\u00e7\u00e3o de funcionalidades <b>de deduplica\u00e7\u00e3o, fus\u00e3o de registros e outros elementos de MDM<\/b>, vale a pena prestar aten\u00e7\u00e3o especial aos aspectos de armazenamento de chaves naturais em metodologias flex\u00edveis. Provavelmente, a constru\u00e7\u00e3o mais complexa do Data Vault acabar\u00e1 sendo mais segura em termos de erros de fus\u00e3o.<\/p>\n<p><b>O Modelo Ancorado<\/b> tamb\u00e9m prev\u00ea um tipo adicional de objeto chamado <b>N\u00f3 (Knot)<\/b> na verdade, \u00e9 uma esp\u00e9cie de <b>forma degenerada de \u00e2ncora<\/b>, que pode conter apenas um atributo. Os n\u00f3s s\u00e3o destinados a armazenar cat\u00e1logos planos (por exemplo, g\u00eanero, estado civil, categoria de atendimento ao cliente, etc.). Diferente do \u00c2ncora, o N\u00f3 <b>n\u00e3o possui tabelas de atributos relacionadas<\/b>, e seu \u00fanico atributo (nome) sempre \u00e9 armazenado em uma tabela com a chave. Os n\u00f3s se conectam com \u00e2ncoras atrav\u00e9s de tabelas de relacionamento (Tie) da mesma forma que \u00e2ncoras se conectam umas \u00e0s outras.<\/p>\n<p>N\u00e3o h\u00e1 uma opini\u00e3o un\u00e2nime sobre o uso de N\u00f3s. Por exemplo, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/users\/azathot\/\">Nikolay Golov<\/a><\/noindex>, que promove ativamente o uso do modelo de \u00c2ncora na R\u00fassia, acredita (n\u00e3o sem fundamentos) que n\u00e3o se pode afirmar com certeza que qualquer cat\u00e1logo <b>sempre<\/b> ser\u00e1 est\u00e1tico e de um n\u00edvel, portanto, para todos os objetos \u00e9 melhor usar imediatamente uma \u00c2ncora completa.<\/p>\n<p>Outra importante diferen\u00e7a entre o Data Vault e o modelo de \u00c2ncora reside na presen\u00e7a <b>de atributos nas rela\u00e7\u00f5es<\/b>:<\/p>\n<p>Em <b>Data Vault<\/b> As rela\u00e7\u00f5es s\u00e3o objetos t\u00e3o completos quanto os Hubs e podem ter <b>atributos pr\u00f3prios<\/b>. No <b>O Modelo Ancorado<\/b> As rela\u00e7\u00f5es s\u00e3o utilizadas apenas para conectar \u00c2ncoras e <b>n\u00e3o podem ter atributos pr\u00f3prios.<\/b>Essa diferen\u00e7a leva a abordagens de modelagem substancialmente diferentes <b>de fatos<\/b>, sobre o que falaremos a seguir.<\/p>\n<h3>Armazenamento de fatos<\/h3>\n<p>\nAntes, falamos principalmente sobre a modelagem de dimens\u00f5es. Com os fatos, a situa\u00e7\u00e3o \u00e9 um pouco menos clara.<\/p>\n<p>Em <b>Data Vault<\/b> um objeto t\u00edpico para armazenar fatos \u2014<b> Rela\u00e7\u00e3o (Link)<\/b>, cujos Satelites acumulam m\u00e9tricas reais.<\/p>\n<p>Essa abordagem parece intuitivamente clara. Ela oferece acesso simples aos indicadores analis\u00e1veis e se assemelha a uma tabela de fatos tradicional (apenas os indicadores n\u00e3o s\u00e3o armazenados na pr\u00f3pria tabela, mas sim em uma 'vizinhan\u00e7a'). Mas h\u00e1 armadilhas: uma das adequa\u00e7\u00f5es t\u00edpicas do modelo \u2014 a amplia\u00e7\u00e3o da chave do fato \u2014 exige <b>a adi\u00e7\u00e3o de uma nova chave estrangeira no Link<\/b>. E isso 'desmonta' a modularidade e potencialmente causa a necessidade de ajustes em outros objetos.<\/p>\n<p>Em <b>O Modelo Ancorado<\/b> A liga\u00e7\u00e3o n\u00e3o pode ter atributos pr\u00f3prios, portanto, essa abordagem n\u00e3o funcionar\u00e1 \u2014 absolutamente todos os atributos e m\u00e9tricas devem estar vinculados a uma \u00e2ncora espec\u00edfica. A conclus\u00e3o \u00e9 simples \u2014 <b>cada fato tamb\u00e9m precisa de sua pr\u00f3pria \u00e2ncora.<\/b>Para parte do que costumamos perceber como fatos, isso pode parecer natural \u2014 por exemplo, o fato da compra se resume ao objeto 'pedido' ou 'recibo', a visita ao site \u2014 \u00e0 sess\u00e3o, etc. Mas existem tamb\u00e9m fatos para os quais encontrar um 'objeto-portador' natural n\u00e3o \u00e9 t\u00e3o simples \u2014 como os estoques de produtos no in\u00edcio de cada dia. <\/p>\n<p>Consequentemente, n\u00e3o h\u00e1 problemas com a modularidade ao expandir a chave do fato no Modelo \u00c2ncora (basta adicionar uma nova Rela\u00e7\u00e3o ao \u00c2ncora correspondente), mas o projeto do modelo para representar fatos \u00e9 menos claro, podendo surgir \u00c2ncoras 'artificiais' que representam o modelo de neg\u00f3cio de forma n\u00e3o \u00f3bvia.<\/p>\n<h3>Como se alcan\u00e7a a flexibilidade<\/h3>\n<p>\nA constru\u00e7\u00e3o resultante em ambos os casos cont\u00e9m <b>substancialmente mais tabelas<\/b>, do que uma medida tradicional. Mas pode ocupar <b>substancialmente menos espa\u00e7o em disco<\/b> com o mesmo conjunto de atributos de vers\u00e3o que uma medida tradicional. N\u00e3o h\u00e1 m\u00e1gica, naturalmente \u2014 tudo se resume \u00e0 normaliza\u00e7\u00e3o. Distribuindo atributos entre S\u00e1telites (no Data Vault) ou tabelas separadas (Modelo \u00c2ncora), reduzimos (ou eliminamos completamente) <b>a duplica\u00e7\u00e3o de valores de alguns atributos ao alterar outros<\/b>.<\/p>\n<p>Para <b>Data Vault<\/b> o ganho depender\u00e1 da distribui\u00e7\u00e3o dos atributos entre S\u00e1telites, e para <b>O Modelo Ancorado<\/b> \u2014 \u00e9 praticamente diretamente proporcional \u00e0 m\u00e9dia de vers\u00f5es por objeto de medida.<\/p>\n<p>No entanto, a economia de espa\u00e7o \u2014 \u00e9 uma vantagem importante, mas n\u00e3o a principal do armazenamento separado de atributos. Junto com o armazenamento separado de rela\u00e7\u00f5es, essa abordagem torna o reposit\u00f3rio <b>uma constru\u00e7\u00e3o modular<\/b>. Isso significa que a adi\u00e7\u00e3o tanto de atributos individuais quanto de novas \u00e1reas tem\u00e1ticas em tal modelo parece uma <b>superestrutura<\/b> sobre o conjunto existente de objetos sem alter\u00e1-los. E \u00e9 exatamente isso que torna as metodologias descritas flex\u00edveis.<\/p>\n<p>Isso tamb\u00e9m lembra a transi\u00e7\u00e3o da produ\u00e7\u00e3o individual para a produ\u00e7\u00e3o em massa \u2014 se na abordagem tradicional cada tabela do modelo \u00e9 \u00fanica e requer aten\u00e7\u00e3o separada, nas metodologias flex\u00edveis \u2014 \u00e9 um conjunto de 'pe\u00e7as' t\u00edpicas. Por um lado, o n\u00famero de tabelas aumenta, e os processos de carregamento e extra\u00e7\u00e3o de dados parecem mais complexos. Por outro lado \u2014 elas se tornam <b>t\u00edpicas<\/b>. E isso significa que podem ser <b>automatizados e geridos por metadados<\/b>. A pergunta \"como vamos organizar?\", cuja resposta poderia ocupar uma parte significativa do trabalho de design de ajustes, agora simplesmente n\u00e3o se coloca (assim como a quest\u00e3o do impacto da mudan\u00e7a de modelo nos processos em andamento). <\/p>\n<p>Isso n\u00e3o significa que os analistas em tal sistema sejam completamente desnecess\u00e1rios \u2014 algu\u00e9m ainda precisa trabalhar no conjunto de objetos com atributos e entender de onde e como carregar tudo isso. Mas o volume de trabalho, bem como a probabilidade e o custo de erro, diminuem significativamente. Tanto na fase de an\u00e1lise quanto no desenvolvimento de ETL, que, em grande parte, pode se resumir \u00e0 edi\u00e7\u00e3o de metadados. <\/p>\n<h3>O lado oscuro<\/h3>\n<p>\nTudo o que foi descrito acima torna ambas as abordagens realmente flex\u00edveis, tecnol\u00f3gicas e adequadas para itera\u00e7\u00f5es. Claro que h\u00e1 tamb\u00e9m um \"barril de alcatr\u00e3o\", sobre o qual voc\u00ea, eu acho, j\u00e1 suspeita.<\/p>\n<p>A decomposi\u00e7\u00e3o de dados, que est\u00e1 na base da modularidade das arquiteturas flex\u00edveis, leva ao aumento do n\u00famero de tabelas e, consequentemente, <b>custos indiretos<\/b> de joins durante a sele\u00e7\u00e3o. Para obter todos os atributos de uma medida, em um armaz\u00e9m cl\u00e1ssico, basta um select, enquanto a arquitetura flex\u00edvel exigir\u00e1 uma s\u00e9rie de joins. E se para relat\u00f3rios todos esses joins podem ser escritos com anteced\u00eancia, os analistas, acostumados a escrever SQL manualmente, sofrer\u00e3o em dobro.<\/p>\n<p>Existem alguns fatos que facilitam tal situa\u00e7\u00e3o:<\/p>\n<p><b>Ao trabalhar com grandes dimens\u00f5es, quase nunca s\u00e3o usados todos os seus atributos ao mesmo tempo.<\/b> Isso significa que pode haver menos joins do que parece \u00e0 primeira vista no modelo. No Data Vault, tamb\u00e9m \u00e9 poss\u00edvel considerar a frequ\u00eancia prevista de uso conjunto ao distribuir atributos entre sat\u00e9lites. Nesse contexto, os Hubs ou Ancoras s\u00e3o necess\u00e1rios principalmente para gerar e mapear substitutos na fase de carga e raramente s\u00e3o usados em consultas (especialmente no que diz respeito \u00e0s Ancoras).<\/p>\n<p><b>Todos os joins \u2014 por chave.<\/b> Al\u00e9m disso, um m\u00e9todo de armazenamento de dados mais \"compacto\" reduz a sobrecarga ao escanear tabelas onde necess\u00e1rio (como na filtragem por valor de atributo). Isso pode resultar em consultas a um banco de dados normalizado com muitos joins sendo at\u00e9 mais r\u00e1pidas do que escanear uma \u00fanica dimens\u00e3o pesada com muitas vers\u00f5es por linha.<\/p>\n<p>Por exemplo, aqui na <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Anchor-Modeling.pdf\">artigo. Mas, como mencionado anteriormente, ao tentarmos aplic\u00e1-lo diretamente no blockchain, surgem limita\u00e7\u00f5es t\u00e9cnicas. Aqui est\u00e1 um exemplo de implementa\u00e7\u00e3o de teste do protocolo em um contrato inteligente EOS e sua parte mais importante \u2014 a verifica\u00e7\u00e3o do share publicado pelo participante: <\/a><\/noindex> artigo, h\u00e1 um teste comparativo detalhado de desempenho do Modelo Anchor com consulta de uma \u00fanica tabela.<\/p>\n<p><b>Muito depende do mecanismo.<\/b> Muitas plataformas modernas t\u00eam mecanismos internos de otimiza\u00e7\u00e3o de joins. Por exemplo, o MS SQL e o Oracle conseguem \"pular\" joins em tabelas se seus dados n\u00e3o s\u00e3o utilizados em nenhum outro lugar al\u00e9m de outros joins e n\u00e3o afetam a consulta final (elimina\u00e7\u00e3o de tabela\/join), enquanto o MPP Vertica, de acordo <noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/wp-content\/uploads\/2011\/05\/Big_Data_Normalization.pdf\">com a experi\u00eancia de colegas da Avito,<\/a><\/noindex>, se mostrou um \u00f3timo mecanismo para o Modelo Anchor com alguma otimiza\u00e7\u00e3o manual do plano de consulta. Por outro lado, armazenar o Modelo Anchor, por exemplo, no Click House, que tem suporte limitado a joins, n\u00e3o parece uma boa ideia.<\/p>\n<p>Al\u00e9m disso, existem <b>t\u00e9cnicas especiais<\/b>, que facilitam o acesso a dados (tanto do ponto de vista da performance das consultas quanto para os usu\u00e1rios finais). Por exemplo, <b>tabelas Point-In-Time<\/b> no Data Vault ou <b>fun\u00e7\u00f5es de tabela especiais<\/b> no Modelo Anchor.<\/p>\n<h2>Total<\/h2>\n<p>\nA ess\u00eancia das arquiteturas flex\u00edveis discutidas est\u00e1 na modularidade de sua \"constru\u00e7\u00e3o\". <\/p>\n<p>\u00c9 essa propriedade que permite:<\/p>\n<ul>\n<li>Ap\u00f3s alguma prepara\u00e7\u00e3o inicial, ligada \u00e0 implanta\u00e7\u00e3o de metadados e \u00e0 escrita de algoritmos b\u00e1sicos de ETL, <b>fornecer rapidamente ao cliente o primeiro resultado<\/b> na forma de alguns relat\u00f3rios, contendo dados de apenas alguns objetos fonte. N\u00e3o \u00e9 necess\u00e1rio pensar completamente (mesmo em alto n\u00edvel) em todo o modelo de objetos para isso.<\/li>\n<li>O modelo de dados pode come\u00e7ar a funcionar (e trazer benef\u00edcios) com apenas 2-3 objetos e depois <b>crescer gradualmente<\/b> (em rela\u00e7\u00e3o ao Modelo Anchor, Nikolai <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">fez <\/a><\/noindex>uma bela compara\u00e7\u00e3o com uma mic\u00e9lio).<\/li>\n<li>A maioria das melhorias, incluindo a expans\u00e3o do dom\u00ednio e a adi\u00e7\u00e3o de novas fontes <b>n\u00e3o afeta a funcionalidade existente e n\u00e3o corre o risco de quebrar algo que j\u00e1 est\u00e1 funcionando.<\/b>.<\/li>\n<li>Gra\u00e7as \u00e0 decomposi\u00e7\u00e3o em elementos padr\u00e3o, os processos ETL em tais sistemas apresentam uma apar\u00eancia homog\u00eanea, sua escrita pode ser algoritmizada e, em \u00faltima an\u00e1lise, <b>automatizada<\/b>.<\/li>\n<\/ul>\n<p>\nO pre\u00e7o dessa flexibilidade \u00e9 <b>desempenho<\/b>. Isso n\u00e3o significa que alcan\u00e7ar um desempenho aceit\u00e1vel em tais modelos seja imposs\u00edvel. Na maioria das vezes, pode apenas exigir mais esfor\u00e7os e aten\u00e7\u00e3o aos detalhes para atingir as m\u00e9tricas desejadas.<\/p>\n<h2>Aplicativos<\/h2>\n<p><\/p>\n<h4>Tipos de entidade <b>Data Vault<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/6bbaee505587152d7e5c11b2889bf25a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSaiba mais sobre Data Vault:<br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/danlinstedt.com\/\">Site 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\">Tudo sobre Data Vault em russo<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/348188\/\">Sobre Data Vault no Habr<\/a><\/noindex><\/p>\n<h4>Tipos de entidades <b>Modelo \u00c2ncora<\/b><\/h4>\n<p>\n<img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/d518f01e6a5c241e9e73d1ea0210c557.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSaiba mais sobre o Modelo Anchor:<\/p>\n<p><noindex><a rel=\"nofollow\" href=\"http:\/\/www.anchormodeling.com\/\">Site dos criadores do Modelo Anchor<\/a><\/noindex><br \/>\n<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/avito\/blog\/322510\/\">Artigo sobre a experi\u00eancia de implementa\u00e7\u00e3o do Modelo Anchor no Avito<\/a><\/noindex><\/p>\n<p>Tabela resumo com caracter\u00edsticas comuns e diferen\u00e7as entre os enfoques discutidos:<\/p>\n<p><img decoding=\"async\" alt=\"Vis\u00e3o geral das metodologias \u00e1geis de design de DWH\" src=\"\/wp-content\/uploads\/2020\/08\/807717245fd874ab141031fc64e584fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>Fonte: <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.3 - 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\/pt\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\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\/pt\/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\udd47Vis\u00e3o geral de metodologias \u00e1geis de design de DWH | ProHoster","description":"Desenvolver um armaz\u00e9m \u00e9 um trabalho demorado e s\u00e9rio.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/obzor-gibkih-metodologij-proektirovaniya-dwh","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/92015","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=92015"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/92015\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/92016"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=92015"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=92015"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=92015"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}