Quem me acompanha aqui no GeekBI viu meus posts sobre DV e sabe que eu sofro de uma grave insegurança acerca da hamletiana questão DV or Not DV. Bom, eu sofria.

Todo DW Deve Usar DV

Mas todo mesmo??? Não, nem todos. Ele não é necessário se seu DW é de testes, sua empresa é muito pequena (só tem dois departamentos e faz controle de pedidos em Excel) etc. Caso contrário, sim, todo DW deve usar DV, e meu objetivo hoje é tentar explicar porquê.

(In)Definição funcional de DW

Ok, de novo: o que é um DW? A definição clássica do Bill Inmon é:

Um armazém de dados é uma coleção de dados não-voláteis, historiados, integrados e orientados por assunto para suporte do processo decisório dos gestores.
A warehouse is a subject-oriented, integrated, time-variant and non-volatile collection of data in support of management’s decision making process.

Bill Inmon

Existe uma outra, mas ela não é declarada explicitamente. Ela é advogada por Ralph Kimball e pode ser escrita mais ou menos assim:

O Data Warehouse Corporativo é a coleção de Data Marts integrados através do barramento corporativo de dados.

Ralph Kimball

Uma coisa interessante sobre a definição do Kimball é que ele estressa o fato de que o DW é uma ferramenta de análise de dados. Seu modelo dimensional é tão adequado a isso que o próprio Bill Inmon escreveu, em 2000, que se ele precisasse desenhar um Data Mart, ele não consideraria usar outra coisa que não um Modelo Dimensional (Star Schema – The Complete Reference, Christopher AdamsonInmon’s Corporate Information Factory, p. 18.)

Já a definição do Inmon vai no sentido oposto: o DW acumula os dados, mas não deve ser consultado pelo cliente. Para consultas, Data Marts devem ser populados a partir do DW.

Necessidade de Dados para BI

Existem duas necessidades de dados para Inteligência de Negócios que são atendidas por DWs.

Armazenamento

Se uma empresa decide armazenar dados sobre seus processos e operações, ela deveria armazenar a maior quantidade possível, com o maior detalhamento possível. Afinal, o que hoje não é importante pode sê-lo amanhã. Se a empresa armazena apenas o que entende importante hoje, ela pode sentir falta de algo no futuro. Claro, essa lacuna sempre pode ser preenchida daquele momento em diante, mas o passado – com todo seu valor – terá sido perdido.

  • Do tamanho da empresa;
  • Tudo que já existiu;
  • Sempre aumenta.
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!
Foto de um moderno armazém típico. Consegue se imaginar comprando num lugar destes? So se for via web!

Análise

Uma vez que o dado foi resgatado das entranhas dos sistemas transacionais e separados, podemos analisá-los – responder perguntas de negócio, estimar, prever e extrapolar tendências. Dados brutos raramente entregam algum conhecimento, e por isso é necessário “massagear” os dados até que eles ofereçam alguma interpretação possível. Isso é tão importante que, depois de décadas ocultos em projetos de Data Mining, estatísticos, matemáticos e físicos estão ganhando notoriedade com a invenção da buzz word Data Scientist (Cientista de Dados – como se algum cientista não lidasse com dados, hehe.)

  • Do tamanho de pessoas;
  • Só o relevante;
  • Renova-se.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.
Um supermercado facilita o acesso à mercadoria que o cliente procura. O estoque está escondido, no armazém.

Armazéns de dados usados para análise

Pausa para epifania:

O que acontece se você tenta criar um Data Warehouse Corporativo (EDW) para análise?

Se você tentar forçar todos os dados da empresa em um formato adequado ao “consumo” por analistas terá um DW que:

  • É do tamanho da empresa;
  • É usado por pessoas;
  • Acumula tudo;
  • Expõe tudo;
  • É consumido em partes.

Resposta: ele não seria nem uma coisa, nem outra.

Armazém + Supermercado = WTF???
Armazém + Supermercado = WTF???

Olhem as figuras: elas mostram como é um armazém puro, como é um supermercado, e como fica um armazém quando você dá para o cliente um carrinho de compras e diz “se vira aí.” Podemos descrever essa situação como “atacado no varejo” – uma antítese, uma definição contraditória.

Model Wars

E é por isso que você precisa de um Data Vault: para armazenar seus dados corporativos crús, de maneira integrada e acumulativa, sem compromissos quanto ao volume, à taxa de armazenagem ou ao conteúdo. Caso contrário, se você arquivar seus dados em outro modelo, você vai acabar em um beco sem saída.

O DW foi “inventado” (descrito formalmente pela primeira vez acho que é mais o termo) por Bill Inmon, que propôs um modelo de dados para montar um DW.

Corporate Information Factory

Visão da arquitetura típica de um CIF.
Visão da arquitetura típica de um CIF.

Uma CIF, ou Fábrica Corporativa de Informações, é um banco dados e processos de ETL associados com algumas características particulares:

  • O modelo de dados é na 3NF (3a Forma Normal);
  • O dado é armazenado integrado e limpo;
  • Sem acesso direto do cliente ao dados do DW;
  • O consumo de dados pelo cliente é feito por Data Marts Dimensionais, derivados da CIF.

Era uma idéia natural, dado que a 3NF é uma maneira eficiente de se guardar dados relacionados entre si. Só que ele tem alguns problemas:

  • O dado gravado no DW não é o mesmo que existe no sistema de origem;
  • A 3NF é um modelo de dados muito bom para aplicações transacionais, mas muito ruim para DW por que é um método complexo e difícil, especialmente se precisar ser extendido;
  • Apesar de Inmon afirmar o contrário, CIFs tem grande custo/demora inicial, manutenção complexa
  • Para esses dias de Scrum, CIFs não são uma arquitetura apta a ser “agilizada”.

Dimensional Enterprise Data Warehouse

Como dito no começo deste post, Ralph Kimball advoga algo que agora podemos chamar de “atacado no varejo”:

  • O EDW é uma coleção de Data Marts (assuntos), que são “estrelas” Fato-Dimensão;
  • A integração dos dados é feito via barramento de dimensões;
  • O dado é armazenado integrado e limpo;
  • O cliente final tem acesso direto ao EDW, normalmente por alguma ferramenta gráfica, como Microstrategy ou PIR/Analyzer.
O Barramento Dimensional Corporativo (interpretação artística acima e exemplo de documentação abaixo.)
O Barramento Dimensional Corporativo (interpretação artística acima e exemplo de documentação abaixo.)

Ele resolveu muitas dificuldades da CIF:

  • Modelo dimensional é resiliente e flexível:
    • Acomoda mudanças de negócio;
    • Bom para análise por pessoas;
    • Bom para armazenamento por bancos;
  • Projeto modular, bottom-up
    • Começa pequeno e cresce organicamente;
    • Manutenção simples;
    • Apto a ser “agilizado”.

Mas mesmo assim ainda tem suas fraquezas:

  • Assim como na CIF, o dado gravado não é o mesmo que existe no sistema de origem;
  • O modelo de dados depende do processo de negócio e do entendimento deste processo (pelo cliente ou pelo desenvolvedor). Se o negócio ou seu entendimento muda, o modelo precisa mudar junto;
  • Mesmo sendo resiliente, essa resiliência tem limite;
  • Mesmo sendo bom para integrar dados, a integração depende de dimensões comuns que nem sempre existem, o que causa aumento de dimensões “iguais mas diferentes”.

CIF x EDW-D

Além de suas limitações particulares, ambos tem algumas fraquezas intrínsecas:

  • Dado é mascarado: ele é alterado e depois carregado;
  • ETL frágil: pode parar por “dado ruim” e re-início é complexo;
  • ETL pode ficar pesado e afetar janela de tempo.

Truco!

E agora? A proposta de Inmon é complexa e tende a matar o EDW sob seu próprio peso. A do Kimball espana em projetos grandes demais – e nos dias de hoje, grande demais é o novo médio. Não que eles sejam totalmente inadequados. As abordagens CIF e EDW-D respondem muito bem, até, para uma boa gama de problemas e necessidades. Elas apenas têm limitações que tornam tudo mais difícil (mas apenas em poucos casos impossíveis.)

Apresentando Daniel Linstedt & Seu Maravilhoso Data Vault

O cara é uma figura. Assista o vídeo dele aqui. Eu tomei contato com suas idéias através do Kettle Solutions, mas se eu tivesse assistido o vídeo antes, eu nem teria lido o material – sério. Tudo que ele faz – palestra, vídeo, aula etc. – parece coisa de Shop Time!!! Mas não compre ainda! Se você adotar Data Vault e adquirir o divertidíssimo curso on-line Mega-Promo, você ainda ganha uma fantástica empresa altamente produtiva!!

O fato é que a metodologia/técnica/teoria/coisa que ele inventou resolve todos esses problemas, muito bem. Claro que ela também tem suas limitações, mas até as limitações são coisas complicadas de se entender, de tão eficiente que DV é.

Eu sabia disso – eu consegui entender que DV é o modelo de dados ideal para uma CIF, que depois popula Data Marts dimensionais usados pelos clientes. Essa não era a minha dúvida. O problema era outro.

Como é que mais Trabalho…

Quando implementamos um DV, dobramos o tamanho do EDW.

Arquitetura do EDW Dimensional típico.
Arquitetura do EDW Dimensional típico.

Em um Data Warehouse Corporativo Dimensional temos um processo de ETL que lê das origens e grava em um modelo de dados dimensional, a partir do qual a bancada de exploração é montada. Quando incluímos um Data Vault na jogada, não nos livramos do ETL dimensional, mas tão somente o alteramos:

Arquitetura de um EDW extendida com um Data Vault entre as fontes e os Data Marts.
Arquitetura de um EDW extendida com um Data Vault entre as fontes e os Data Marts.

Louco, voces estão pensando, mas vocês já sabiam disso, não é?

…dá menos Trabalho?

Simples: tornando viável o impossível, e o difícil, fácil.

Quais são os maiores problemas de uma CIF? Modelo de dados e evolução complexas. Se você optou pela CIF no seu EDW, um DV te dá um modelo de dados simples, de evolução muito fácil.

Quais são os maiores problemas de um EDW Dimensional? As mudanças: sempre que o cliente pede algo novo, como incluir uma nova fonte de dados, não apenas o modelo de dados precisa passar por uma revisão e eventual ajuste, mas o processo de ETL também precisa ser revisto.

A Minha Experiência

Atualmente estou envolvido em um projeto de DW relativamente simples: municiar o cliente com cubos OLAP para que ele possa monitorar o desempenho da área em suas atividades. Temos só duas fontes de dados, mas em breve uma delas será desativada e tudo ficará na outra. Logo, nada muito complexo.

Adotamos uma gestão de projetos Scrum, que se baseia em iterações curtas (algumas semanas) para entrega de uma lista de objetivos reduzidos, previamente combinados com o usuário.

Não tenho nenhum problema em nenhum aspecto do projeto: ambientes ok, ferramentas ok, equipe nota 10, cliente fantástico. É o projeto dos sonhos de qualquer um – meu, inclusive.

Só tenho uma dificuldade: o modelo de dados. De tanto eu pestear meus chefes na empresa em que trabalho, eles me deixaram modelar o DW (ou Data Mart, melhor dizendo, já que há muita coisa da empresa que não entra nesse banco) e desenvolver o ETL, que eu comecei a fazer da forma que eu sempre disse que deveria ser feita.

Provei do meu próprio remédio – ele é muito bom, mas tem efeitos colaterais perigosos.

Métricas Misturadas

Espanei logo na primeira estrela.

Fiz tudo de acordo com o figurino: eu escolhi o processo de negócio e o grão, as métricas e as dimensões. Mas eu não fiquei satisfeito e refiz. Ficou ruim e refiz de novo. Voltei ao primeiro arranjo, mudei de novo, tentei outra coisa… Não conseguia chegar a um acordo sobre as métricas. Elas ficavam… estranhas, acho.

No dia seguinte, descansado, eu me toquei do que acontecera. A métrica que o processo de negócio comportava não era a métrica que o cliente queria explorar. Ora, que tolinho, dei mancada de amador, pensei eu.

Há!

Grão Grilado

Voltei ao início e ajustei a definição do processo de negócio para incluir mais coisas, e daí o grão, as métricas e as dimensões. Ficou melhor, mas ainda não resolveu. O novo entendimento sobre o processo de negócio que meu cliente queria analisar ainda não era suficiente. Pensando sobre o caso eu vi que, se ampliasse e ampliasse, até encampar tudo, o modelo ficaria estropiado.

Eu já estava há quase uma semana desenhando e redesenhando o modelo, testando alguns protótipos. Minha expectativa era fazer um ou dois protótipos, refinar meu entendimento do problema, do sistema de origem e da necessidade do cliente, e então jogá-los fora e redesenhar certo.

Aconteceu isso, mas não como eu esperava. Eu não convergia, não conseguia achar o “corte” do negócio que desse o que o cliente pedia.

Supernova

Sabem quando acende aquela lâmpada na cabeça do Patolino? Bom, sobre a minha cabeça acendeu uma supernova – foi o tal momento da epifania que eu descrevi acima. De repente ficou claro que eu não conseguia achar o corte certo porque simplesmente não existia corte certo. Era como se eu estivesse tentando temperar e fritar filé mignon para conseguir hambúrguer com fritas (com pão, queijo, tomate e maionese, tudo.) O cliente precisava de uma “visão” dos dados que não era disponível em um só processo de negócio. Eu ainda não tenho certeza se entendi bem o porque disso – se é um grande processo com várias etapas, ou se a análise do cliente é muito alto nível – mas o fato é que eu consegui andar quando eu quebrei os dados nos vários processos de negócio. Cada um passou a trazer um pouco do que o cliente queria, como uma fato atômica (sem divisão, mínima ou essencial.) Daí eu pude determinar os grãos, dimensões e métricas das várias estrelas necessárias. No final, eu desenhei uma estrela “Análise” que reunia as métricas contra as dimensões pedidas pelo cliente.

Hoje, meu processo de ETL tem três etapas:

  • Atualização das dimensões;
  • Carga dos novos fatos “atômicos”;
  • Carga da estrela Análise a partir das estrelas atômicas.

Ou seja, de uma forma ou de outra, eu acabei estabelecendo um Data Warehouse que acumula os dados, e uma estrela para análise, como um Data Mart.

Lixo, Lixo, Lixo

Esse projeto lidava com um tipo de sistema de origem que eu nunca havia trabalhado. Eu brinquei um tempo com vendas (usando a base de dados que evoluiria para a Beltrano S/A), algumas coisas com finanças e um projeto para uma empresa de telefonia, além de todos os outros que eu conheci, que envolviam banco, marketing, televisão etc. O sistema de origem desse projeto é um software de gestão de projeto, completo, com tudo, inclusive a pia da cozinha.

Eu não conhecia os tipos de fato necessário, e tinha só uma idéia do que seriam as dimensões. Por isso eu liguei para um grande amigo, dono de uma empresa de consultoria e treinametno em DW (ele cursou os treinamento do Kimball Group com o Kimball em pessoa) e discuti algumas idéias com ele. Melhor dizendo: admiti que estava perdido e não sabia por onde começar e ele me deu um caminho, que funcinou perfeitamente.

Mas houve uma consequência engraçada: uma das fatos era do tipo snapshot (foto), e acumula dados sobre projetos – coisas como data, cliente, líder, departamento etc. Um dos atributos dessa fato era o ID do projeto, que tipicamente vira uma dimensão degenerada. Outros dois eram o título do projeto e a descrição. Claro que daria para fazer uma dimensão Projeto para guardar esse campos, mas haviam vários outros atributos textuais que se ligavam aos dados de projeto, como estado, tipo de projeto, tipo de processo etc. Como essas coisas evoluem ao longo do tempo – não, pior: vão e vem, avançam de estado e retrocedem para depois avançar de novo, sem padrão – montar uma dimensão seria uma péssima idéia, porque ela cresceria com a fato.

Eu poderia adicionar os atributos diretamente na fato, degenerando tudo e mantendo coisas como empregados, departamentos e datas em dimensões regulares. Só que adicionar campos de texto à fato é garantia de destruir a performance. A tabela em questão é pequena, e cresce à taxa de milhares de linhas por dia, ou seja, quase nada. Mas há outras fatos do mesmo tipo (cheia de atributos textuais), uma das quais crescendo à (por enquanto) +30.000 linhas/dia.

A solução recomendanda por meu amigo, e que eu acatei, foi levar esses atributos para uma dimensão Junk (“lixo”), que eu acabei por fazer uma para cada atributo ou no máximo par de atributos (como título e descrição.) No final eu acabei com uma Junk Dimension Título, uma Junk Dimension Tipo, uma Junk Dimension Estado e assim por diante.

A minha estrela de acumulação estava ficando cheia de atributos descritivos que nunca entrariam em um barramento dimensional corporativo, que lembrava cada vez mais um arranjo hub-link-satellite (os elementos de um DV.)

Re-Retrabalho

Depois dos percalços iniciais eu consegui divisar um padrão no modelo dimensional e dividir com a equipe, para que mais gente pudesse entrar no projeto que até então estava inteiramente comigo.

Conforme o modelo foi ganhando forma, as extrações sendo desenhadas e o resultado apresentado ao cliente (Scrum, lembre-se), o cliente foi entendendo melhor sua necessidade e pedindo mudanças, sempre dentro das restrições impostas pelo Scrum. Mesmo assim, o modelo precisou ganhar uma fato que inicialmente não se acreditava necessário, redesenhar a dimensão Empregado pelo menos uma vez, sem contar os ajustes (além de mais duas mudanças programadas para breve), alterar algumas regras e adicionar vários filtros e correções para dados mal-comportados.

Bom, o suco da história é que o modelo ainda está crescendo (normal), mas também mudando o que já foi feito (anormal). Quero dizer, não é anormal mudar, mas não deveria ser comum precisar rever coisas demais. O ritmo de mudanças em coisas estabelecidas está caindo e deve tender a zero…

… mas e se não? E todas as vezes que precisamos truncar o histórico já acumulado para poder implementar um conceito refinado, uma regra revista? E quantas vezes mais isso vai acontecer?

DV To The Rescue!

Falo baseado em minha intuição, claro, mas estou certo que teria tido menos dificuldades iniciais e o impacto do retrabalho teria sido menor se eu tivesse adotado um DV desde o início. Coisas que teriam sido melhor incluem:

  • Início rápido: como os elementos do DV têm regras claras, nas duas primeiras semanas eu já teria colocado no ar no mínimo os cubos (minha tradução para hubs, como cubos de roda), elos (links) e satélites necessários para a primeira visão do cliente;
  • Histórico mais cedo: nas duas semanas seguintes, enquanto a carga do DV seguisse acumulando dados em produção, acredito que teria conseguido um modelo dimensional e uma extração para levar os poucos dados já no DV para uma estrela de análise, útil ao meu cliente;
  • Menos retrabalho: se eu notasse falta de algo no DV, em menos de uma hora eu conseguiria adicionar esse pedaço em produção, para seguir desenhando o Dimensional;
  • ETL simplificado para o DV: como eu uso o PDI, meu trabalho é medido com a dificuldade de construir uma transformação para fazer algo. O DV usa transformações-padrão para cubos (são sempre as mesmas, basta mudar os nomes da tabela e da chave), um gabarito (template) para elos e outro para os satélites (não há padrão xerocável, mas há um padrão de processo de desenvolvimento). Essas transformações são muito mais simples que as necessárias para carregar uma dimensão e mais simples ainda que uma que carrega fatos;
  • ETL simplificado para os Data Marts Dimensionais: ao contrário da situação em que o EDW Dimensional é carregado a partir do sistema de origem, agora ele seria carregado a partir do DV. As transformações que geram dimensões a partir do DV são praticamente padronizadas. É só copiar, colar e alterar o que for preciso – o processo muda pouco. A transformação para fato ainda serão mais complexas que para as dimensões, mas, de novo, por contar com uma fonte padronizada (o DV), ficariam mais simples e mais padronizadas;
  • Preservação do histórico: se for preciso refazer algo do dimensional, eu poderia jogar fora o modelo dimensional inteiro se fosse preciso, sem me preocupar em perder nenhum dos dados acumulados até então. Seria possível incluir no DV até mesmo coisas ainda não necessárias, e no futuro dispor imediatamente do histórico inteiro em novos Data Marts.

Conclusão

Como Bill Inmon propôs, ao definir um DW, um Data Warehouse é um depósito de dados corporativos, que acumula tudo que possa ser importante para a empresa, e os clientes da corporação que precisarem analisar esses dados devem fazê-los a partir de data marts preparados para tal. Ralph Kimball patronizou a popularização do BI através do desenvolvimento da Modelagem Dimensional.
Finalmente, Daniel Linstedt completou a visão de Bill Inmon com a criação da metodologia Data Vault.

Pelas implicações práticas e lógicas, e a partir da experiência que estou passando, afirmo que um Data Vault é uma necessidade de todo EDW porque torna possível o crescimento suave, progressivo do DW, simplificando o desenvolvimento dos processos e sua gestão.

Espero ter trazido alguma novidade ao compartilhar aqui minha experiência e minha percepção do problema de criar e evoluir um DW em uma empresa. Apreciaria muito ouvir/ler críticas, dúvidas e sugestões.

13 comentários sobre “Data Vault Para Quê?

  1. Muito boa sua abordagem. Existe um grande mito sobre a adoção ou não de um EDW, mas posso dizer que os grandes clientes entendessem a sua comparação entre o Armazém e o Supermercado metade dos nossos problemas de implementação estariam resolvidos. Parabéns excelente post.

    1. Muito obrigado, Washington. Como eu disse, foi uma epifania. Mexo com isso há mais de 10 anos, mas nunca tinha ficado tão claro quanto agora. Imagino que nem todas as pessoas percebam essa separação porque a maioria aprende sobre BI com fornecedores de ferramentas…

  2. Olá Fábio, comecei a engatinhar no Data Vault mas já tenho quase 16 anos de DW. Sou cearense mas moro há 20 anos em Portugal. Tentei verificar se alguém ou alguma empresa em Portugal está usando o Data Vault mas sem nenhuma confirmação ainda.
    A minha curiosidade e que gostaria que pudesses me ajudar com a sua experiência e conhecimento de mercado Brasil, é se aí já existe muito uso do Data Vault e quais as indústrias/áreas que estão a usar.

    Agradeço desde já a sua atenção e muito obrigada por existir para manter tão boas informações sobre esta área de IT que me apaixonei.

    1. Olá Andreina! Obrigado pela visita. Engraçado você falar que é cearense. Eu nasci em Manaus, mas meus pais se mudaram para Fortaleza quando eu não tinha nem três anos, de modo que eu me considero cearense. :-)

      Seja bem-vinda ao DV! Você conhece o WWDVC? O World Wide Data Vault Consortium é um congresso anual (https://wwdvc.com/) onde se contam os mais recentes “causos”. Ainda não vi notícia de nenhum brasileiro lá. Isto posto, eu conheço alguns casos aqui no Brasil, mas apenas dos meus alunos: há um no Rio de Janeiro (empresa de grande porte, multinacional), um em Minas Gerais (banco de crédito, pequeno porte), provavelmente uma concessionária de serviços públicos (no Ceará!) e mais dois em São Paulo (uma universidade, começando agora, e uma empresa de treinamentos.)

      Ainda não tomei conhecimento de nenhum outro que não seja de um aluno ou chegado próximo, mas deve haver. Bancos multinacionais são usuários de DV em outros países, então provavelmente suas projeções aqui também o são.

      E como anda a terra de Cabral nesses tempos de pandemia? Grande abraço!

      1. Olá novamente Fábio,

        Que alegria receber seu feedback. Achei que demoraria muito para obter um contato seu, primeiro por causa da data do artigo e depois porque achei que iria ter mais o que fazer que responder uma recém-chegada no mundo do DV. Muito obrigada desde já.

        Outra grande alegria é saber que se sente cearense, também tenho muito orgulho de ser “cabeça-chata”. Já morei duas vezes em SP, antes da universidade e depois, quando de um desamor no Ceará e me refugiei na capital paulista trabalhando na antiga Transbrasil, onde tive pela primeira vez o contato com o conceito EIS- Executive Information System. Já na altura, 1995, adorei o conceito e até fiz um pequenino brilharete quando num projeto piloto, passei os dados da Transbrasil Cargo para um software que se chamava Forest&Trees.

        Não conheço o WWDVC até hoje porque seguirei esta dica com afinco.

        Fui convidada para criar um piloto em DV, uma perninha de um DW que já trabalhei há 2 anos atrás e cujo ETL da perninha, está muito mal desenhado pra não dizer incompleto e incoerente. Entretanto o convite não veio da área de TI, mas sim do Gabinete de Gestão da Informação, uma área que é responsável por validar e garantir a qualidade dos dados internos e regulamentados pelas autoridades européias. Imaginas o desafio?
        Como diz um humorista mineiro: “forando” eu não conhecer a modelagem DV, não conhecer alguém que conheça, terei que lidar com as dificuldades que a direção de TI irá criar para eu aceder aos arquivos deltas que eles já possuem em tabelas Green Plum.
        Daí eu ter te(desculpa a intimidade mas com 22 de portugal, já não consigo usar o você com facilidade) pedido “socorro”.
        Queria saber de alguém que usa o DV e também conhece as modelagens Relacional(Inmon) e Dimensional(Kimball) para perguntar: “se voltasses atrás e tivesseses novamente a oportunidade de escolher entre as 3 modelagens, escolherias a DV?”.

        Do teu artigo, gostei muito dos esclarecimentos sobre as 3 diferentes visões: armazém, supermercado e DV, que seria um armazém mais ágil para futuros supermercados, se me permite o uso dos teus exemplos. Mas precisamente A DO REI o artigo, muito rico tecnicamente e muito bem escrito no sentido comunicativo, ou seja, descreves com simplicidade, com amor e humor pelo o que fazes. Parabéns.

        Com o meu histórico de ter iniciado no transacional e com a paixão que tive pelas cadeiras de base de dados na universidade, sempre me senti mais a vontade com os modelos relacionais em snow flake. Entretanto, já trabalhei com DW relacionais, Datamarts dimenionais (e doeu criar e não sei se senti satisfação no final, apesar do cliente não ter se queixado) e agora o desafio do DV, que gosto muito do conceito mas temo que quem escolheu(nem TIs nem Usuário final) o DV, não perceba que ele continuará a precisar de dois passos para disponibilizar dados para os usuários(utilizadores em Portugal).

        A terra de Cabral portou-se muito bem, como se diz por aqui, mas quando abriram todas as fases do desconfinamento, os casos na grande Lisboa, devidos aos bairros “satélites” que têm muitos imigrantes e população de menor renda e que moram em maior número de pessoas por casa, começaram a disparar e hoje a foto do momento, é que nadamos, nadamos e estamos muito próximos de morrer na praia ou melhor, voltarmos a nos confinar outra vez.

        Fica um convite: se um dia vier a Lisboa, fica convidado para o que preferir: almoço, jantar ou happy-hour e terei muito gosto em mostrar o olhar apaixonado de uma cearense que adotou uma “madrinha-pátria” Lisboa, que como diz outra cearense, não devia se chamar Lisboa e sim Lisótima.

        Bem, mais uma vez, desculpa, mas de cearense pra cearense: humor e falar muito, fazem parte do nosso DNA.

        Fábio, mais uma vez, muito obrigada e mais um pedido: tens como conseguir saber qual a instituição pública do Ceará que mencionaste? É que quando estava no Brasil, não era da área de BI e não tenho como questionar aos meus amigos e antigos colegas sobre uma modelagem que eles podem nunca ter ouvido falar, assim como eu, até dia 25/06/2020, 7 dias atrás.

        Obrigada,
        Andreina

      2. Oi Andreina, beleza? Vamos por partes:

        – Cearense é tagarela e galhofeiro: confere. :-)
        – Se eu voltasse no tempo, o que eu usaria? CIF baseada em Data Vault, com DM onde se aplicar. DM (Dimensional Modeling) não é coisa de grande porte, fim;
        – Desconforto de gente relacional ao construir dimensional: é a regra, sempre acontece;
        – Snow-flake: fuja, como foge o Diabo da Cruz;
        – A empresa cearense é uma de água, se não me engano. Vou confirmar e te conto;
        – Pode falar escorreitamente, adoro um bom português, no bom sentido! :-D
        – Obrigado pelo convite! Assim que eu for, eu vou cobrar!

        É isso. Depois te passo por e-mail os comentários detalhados, ok? E agora você já conhece alguém que conhece DV, DM etc. Relaxe, vai tudo dar certo. ;-)

Deixe uma resposta para marcogarcia0 Cancelar resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair /  Alterar )

Foto do Google

Você está comentando utilizando sua conta Google. Sair /  Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair /  Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair /  Alterar )

Conectando a %s