Um Guia Com os 10 Erros Mais Comuns de Modelagem de Dados
A modelagem de dados é o processo pelo qual representamos objetos ou entidades do sistema de informação e as conexões entre eles.
Tais entidades podem ser pessoas, produtos ou qualquer outra coisa relacionada ao negócio de uma empresa; independentemente do tipo de entidade, modelá-los corretamente resulta em um banco de dados poderoso configurado para recuperação rápida de informações, armazenamento eficiente e muito mais.
Dadas as vantagens que a modelagem de dados oferece para insights de banco de dados, é importante aprender como fazer modelagem de dados de forma eficaz. Aqui na DSA temos dois cursos focados em modelagem de dados. O curso Modelagem de Bancos de Dados Relacionais, Não Relacionais e Data Stores e o curso Análise de Dados com Microsoft Power BI e Clínica de BI.
Também temos uma introdução à modelagem de dados no Curso Gratuito de Power BI.
Neste guia, vamos apontar alguns erros importantes a serem evitados ao modelar os dados. Os modelos de dados são usados para representar entidades do mundo real, mas geralmente têm limitações. Evite esses erros comuns de modelagem de dados para manter a integridade dos dados e confiabilidade do processo de análise.
Boa leitura.
1- Não considerar modelos de dados de qualidade como um ativo
Às vezes otimizamos nossos modelos de dados para um caso de uso específico, como analisar dados de vendas, e usar o modelo rapidamente se torna mais complicado quando os analistas precisam analisar mais de uma perspectiva.
Por exemplo, pode ser difícil para os Analistas de Dados analisarem a interseção de vendas e chamadas de suporte se os modelos tiverem sido otimizados apenas para dados de vendas. Isso sem mencionar o tempo adicional, recursos e possíveis custos que podem ser necessários para fazer modelos adicionais quando um único modelo seria suficiente.
Para evitar esse tipo de ineficiência, reserve um tempo para garantir que seu modelo de dados ofereça aplicabilidade mais ampla e faça sentido financeiro a longo prazo.
2- Não considerar o uso dos dados
Uma das coisas mais difíceis da modelagem de dados é obter o equilíbrio certo entre interesses concorrentes, como:
- As necessidades de dados do(s) aplicativo(s)
- Metas de desempenho
- Como os dados serão recuperados
É fácil ficar tão consumido em considerar a estrutura dos dados que você gasta tempo insuficiente analisando como uma aplicação usará os dados e obtendo o equilíbrio certo entre consulta, atualização e processamento de dados.
Outra maneira de declarar esse erro é ter empatia insuficiente por outras pessoas que usarão o modelo de dados. Um bom modelo de dados considera todos os usuários e casos de uso de um aplicativo e é construído de acordo.
3- Sem esquema não significa sem modelo de dados
Os bancos de dados NoSQL (documento, chave-valor, coluna, etc.) tornaram-se um componente crítico da arquitetura de dados corporativos, dada a flexibilidade que oferecem para dados não estruturados.
Embora às vezes erroneamente sejam considerados bancos de dados “sem esquema”, é mais preciso pensar em bancos de dados NoSQL como permitindo esquema flexível. E embora alguns confundam esquemas de dados com modelos de dados, os dois têm funções diferentes.
Um esquema de dados instrui um mecanismo de banco de dados sobre como os dados no banco de dados são organizados, enquanto um modelo de dados é mais conceitual e descreve os dados e os relacionamentos entre os dados. Independentemente dessa confusão sobre como o esquema flexível pode afetar a modelagem de dados, assim como com um banco de dados relacional, os Arquitetos de Dados devem modelar dados em bancos de dados NoSQL.
Embora dependendo do tipo de banco de dados NoSQL, esse modelo de dados será simples (chave-valor) ou mais sofisticado (documento). Ensinamos sobre isso no curso Modelagem de Bancos de Dados Relacionais, Não Relacionais e Data Stores.
4- Falha ao compreender a importância dos dados semiestruturados
A maioria dos dados hoje não é estruturada ou semiestruturada, mas, como no erro número três, isso não significa que seu modelo de dados deva seguir esses mesmos formatos.
Embora possa ser conveniente adiar a reflexão sobre como estruturar seus dados na ingestão, isso quase inevitavelmente o prejudicará.
Você não pode evitar dados semiestruturados, mas a maneira de lidar com eles é aplicar rigor no modelo de dados, em vez de adotar uma abordagem prática durante a recuperação de dados. Ou seja, pode ser mais fácil modelar os dados semiestruturados do que tentar estruturá-los no momento da coleta e armazenamento.
5- Não planejar a evolução do modelo de dados
Dado o quanto de trabalho pode ser necessário para mapear um modelo de dados, pode ser tentador supor que o trabalho foi concluído quando você construiu o modelo de dados.
Mas a construção de ativos de dados é um processo contínuo porque à medida que as necessidades analíticas mudam com o tempo, o modelo também terá que ser ajustado.
Uma maneira de facilitar a evolução do modelo de dados é dividir e desacoplar as transformações de dados para tornar todo o processo mais fácil de construir, depurar e manter a longo prazo.
6- Mapeamento rígido da interface do usuário para os campos e valores dos dados
Não tenha medo de ‘pensar fora do banco de dados’.
Você não precisa necessariamente mapear sua interface do usuário diretamente para cada campo de dados e valor. Esse erro tende a resultar da fixação em seu modelo de dados e não na arquitetura de informações.
O problema também significa que você provavelmente está apresentando dados de maneiras mais intuitivas para o público da aplicação do que um mapeamento individual do modelo de dados.
7- Níveis de granularidade incorretos ou diferentes
Na análise, a granularidade refere-se ao nível de detalhe que podemos ver. Em um negócio SaaS, podemos, por exemplo, querer ver o nível de consumo do nosso serviço por dia, por hora ou por minuto.
Obter a quantidade certa de granularidade em um modelo de dados é importante porque, se for muito granular, você pode acabar com todos os tipos de dados desnecessários, dificultando a análise e a classificação de tudo.
Mas com pouca granularidade, você pode não ter detalhes suficientes para revelar detalhes ou tendências importantes. Agora adicione a possibilidade de que sua granularidade esteja focada em números diários, mas a empresa quer que você determine a diferença entre o consumo de pico e fora de pico.
Nesse ponto, você estaria lidando com granularidade mista e acabaria confundindo os usuários. Determinar seus casos de uso de dados exatos para usuários internos e externos é uma primeira etapa importante para decidir quantos detalhes granulares seu modelo precisa.
8- Padrões de nomenclatura inconsistentes ou inexistentes
Em vez de inventar uma convenção de nomenclatura exclusiva, é melhor seguir abordagens padrão com modelos de dados. Se as tabelas, por exemplo, não tiverem uma lógica consistente em como são nomeadas, o modelo de dados se tornará muito difícil de seguir.
Pode parecer inteligente criar convenções de nomenclatura obscuras que relativamente poucas pessoas entenderão imediatamente, mas isso inevitavelmente levará a confusão mais tarde, especialmente se novas pessoas forem incorporadas para trabalhar com esses modelos.
9- Não separar o conceito de chaves de índices
Em um banco de dados, chaves e índices têm funções diferentes.
As chaves impõem regras de negócios – é um conceito lógico. Os índices aceleram o acesso ao banco de dados – é um conceito puramente físico.
Como muitos confundem os dois, eles acabam não implementando chaves candidatas e, assim, reduzem os índices; no processo, eles também diminuem o desempenho. Implemente o menor número de índices que possam efetivamente suportar todas as chaves.
10- Começar tarde demais na modelagem de dados
Se o modelo de dados é o modelo para descrever os dados de uma aplicação e como esses dados interagem, faz pouco sentido começar a construir o aplicativo antes que um Arquiteto de Dados tenha definido completamente o modelo de dados. No entanto, isso é precisamente o que muitos fazem.
Compreender a forma e a estrutura dos dados é essencial para o desempenho do aplicativo e, em última análise, para a experiência do usuário. Essa deve ser a primeira consideração e nos traz de volta ao erro número um: não considerar modelos de dados de qualidade como um ativo.
Deixar de planejar o modelo de dados é essencialmente planejar o fracasso (e planejar fazer muitas refatorações posteriormente para corrigir os erros).
Equipe DSA
Referências: