Neste segundo capítulo da primeira sessão da TechXperience, David Ortega Cruz O objetivo do projeto é desenvolver um modelo para a organização, projeto e estrutura de mesas para o processamento de dados.
Modelagem de tabela
Ao projetar as tabelas das diferentes camadas, temos que levar em conta uma questão muito importante: o SCD (Slowly Changing Dimension) ou a historificação. A historificação está determinando como refletimos as mudanças que os dados sofrem em nossas tabelas de destino. Existem diferentes opções, as principais são:
- Tipo 1: Sobre escrever. As informações que mudam na linha são atualizadas. Normalmente tem uma data de entrada e uma data de atualização.
- Tipo 2: Adicionar fileira. Uma nova linha é adicionada com uma data de início e fim, que indicará o período de validade do registro.
- Tipo 3: Adicionar coluna. Uma coluna é adicionada com o valor anterior que o campo tinha antes da mudança.
- Tipo 4: Histórico de mudanças. Há uma tabela com as mudanças que foram feitas nos registros.
Um aspecto muito importante no desenvolvimento é avaliar corretamente qual tipo de histórico a ser utilizado. Pode ser necessário conhecer o status dos registros no passado, realizar o pré-processamento no passado ou nas visualizações para fazer comparações com datas passadas. Geralmente, é usado um tipo 2, ou seja, uma nova linha é criada para cada mudança e seu intervalo de datas válido é marcado.
No tipo 2 há dois tipos de versão, um tipo de versão por períodos com uma data de início e fim do registro. E um tipo de versão, na qual é feita uma foto diária com uma data de encerramento marcando o dia. A historificação implica que o volume das mesas crescerá dia a dia. Isto torna necessário a realização de um estudo volumétrico. Com este estudo, você pode ver quantos registros e espaço são carregados nas diferentes tabelas a cada dia, a fim de evitar quando mais espaço será necessário. Nos casos em que é feito um instantâneo diário dos dados, é comum usar tabelas divididas por dias para maior eficiência. No outro caso, com uma data de início e fim, às vezes são usadas tabelas históricas para armazenar dados antigos e não saturar a tabela principal.
Outro aspecto relacionado à historificação é como identificar que um registro passou por mudanças. Se a tabela é muito grande em colunas, comparar coluna por coluna com o novo recorde é muito demorado. Portanto, um campo chamado Hash é normalmente usado, que contém o hash ou MD5 de todos os campos principais do registro, removendo os campos Chave primária e os campos de auditoria. Com isto você só tem que hash a nova linha e comparar um único campo para saber, se o novo registro tem que ser inserido ou não.
Também é necessário realizar um estudo dos campos de origem para a escolha correta dos tipos de dados. Isto é muito importante para o desempenho das consultas e para o espaço ocupado pelas mesas. O superdimensionamento das colunas em excesso, fará com que o espaço disponível nunca seja preenchido e será um desperdício de espaço.
Uma dimensão de tempo é criada com um roteiro e com um amplo conjunto de datas futuras, para cruzar as referências por data. Nesta tabela de dimensões, geralmente contém a data, dia, mês, ano, trimestre, período de quatro meses, semana e dia da semana. Esta dimensão é essencial para visualizações posteriores com cálculo de data por diferentes opções de tempo.
Nomenclatura de tabelas e campos
Outro aspecto muito importante a ter em mente é a nomenclatura das tabelas e campos. Alguns clientes geralmente têm documentos ou equipes de gerenciamento de dados com regras de nomenclatura para tabelas e colunas. Caso você não tenha um, deve ter cuidado com os nomes, pois eles devem ser representativos. Geralmente não devem ter mais de 30 caracteres. Além disso, deve ser acordado com a equipe que fará a manutenção do banco de dados e dos clientes. Como haverá campos em outros bancos de dados de clientes que já têm um nome, alguns nomes devem seguir esse nome. Porque às vezes acontece que o mesmo campo em um DWH é chamado por vários nomes diferentes, o que dificulta a compreensão e confunde o cliente. Se forem usadas palavras longas, é importante usar abreviações apropriadas. Evite nomear tabelas e campos apenas com iniciais, pois isso dificulta a compressão e pode levar a erros em muitos casos.
s vezes uma palavra-chave é usada como prefixo ou sufixo nos campos para indicar se é um código, descrição, data, quantidades, ou bandeira. Um exemplo de prefixos, ID significa ID de registro, CD significa código, DS para descrição, MT para métrica, DT para data ou IS para IS. bandeira. Também é comum que as tabelas sejam prefixadas com um prefixo para indicar se é uma tabela de dimensões, tabela de fatos, tabela de auditoria, tabela auxiliar, etc. Um exemplo de prefixos para tabelas, AUX significa tabela auxiliar, FACT significa tabela de fatos, DIM significa tabela de dimensões ou AUD significa tabela de auditoria.
Glossário de Negócios (dicionário de negócios)
De acordo com a nomenclatura das tabelas e campos, é necessário fazer um Glossário Empresarial, ou seja, um dicionário empresarial dos campos. Isto assegura que sabemos o que significa cada tabela e nome de campo, assim como informações relevantes sobre suas origens. Isso facilita a leitura do que cada campo é, assim como a compreensão dos desenvolvedores e da equipe de manutenção. Este Glossário Empresarial pode ser usado para unificar os diferentes campos nos diferentes modelos de dados para que todos usem o mesmo nome para o mesmo campo. Não que cada um o chame à sua própria maneira e então você tem n vezes um campo chamado de maneiras diferentes.
É muito importante fazer a documentação técnica e funcional, refletindo os modelos de dados, suas origens e documentando os processos. Estes documentos devem ser atualizados, não somente quando o projeto é realizado, mas também quando correções ou melhorias são feitas. Estes aspectos da arquitetura e modelagem de dados podem parecer triviais, mas às vezes não são levados em conta ou passam despercebidos. Isto resulta na re-arquitetura e remodelação de bancos de dados, levando a atrasos e refazendo processos de carregamento de dados.
Tratamento de erros na modelagem de tabelas
Uma questão importante é o que fazer com os registros que têm erros ou não estão de acordo com a qualidade dos dados. Isto já implica, criar tabelas de erros para armazenar aqueles registros que não são carregados nas tabelas normais e qual é a razão para isto. Normalmente, os registros que não cumprem não são salvos, mas é sempre uma boa prática salvar aqueles que não cumprem porque em algum momento alguém vai perguntar por que eles não aparecem.
