Artigos Banco de Dados Modelagem de Bancos Relacionais: conheça algumas boas práticas
Por que eu devo ler este artigo:A arquitetura de um banco de dados é algo mais abrangente do que normalmente as equipes de desenvolvimento costumam estimar. Existem muitas variáveis que não são previstas no início do projeto, outras vão surgindo no meio do caminho e se não tivermos consciência de alguns “pilares” da construção e da monitoração, estamos fadados a trocar toda a solução por outra, sem às vezes ter tempo de analisar qual foi o real problema. Este artigo apresenta, de uma forma geral, as boas práticas aplicadas à modelagem de projetos de banco de dados, desde as discussões iniciais com os times de negócio, até a construção e manutenção de dados, com foco no modelo relacional. Essa discussão é útil em todo projeto de banco de dados, dos mais simples aos mais complexos, onde se deseje um projeto sustentável ao longo dos anos.

Desde a abstração conceitual dos requisitos de negócios, é preciso mapear os dados que farão parte do escopo do projeto de forma a se conseguir um modelo flexível com o melhor desempenho possível, além de uma boa integração entre os componentes e a definição da melhor tecnologia a ser adotada. Sistemas grandes ou pequenos serão comprometidos pela forma como tudo foi estruturado e projetado: o sistema gerenciador, o SQL utilizado, as chaves escolhidas para as tabelas, o dimensionamento do espaço (volumetria) do que será utilizado ao longo dos anos, memória, capacidade do servidor, a visibilidade da eficiência e eficácia do negócio que darão sinais de que foram feitas as escolhas certas ou que precisamos mudar o rumo, paralelização com as integrações entre os times de Inteligência / Analytics / BI.

Outro fato é que com o tempo, o sistema muda e evolui naturalmente. Tudo aquilo que pensamos no início em relação ao banco de dados precisa ser evoluído também ou repensado, dependendo de como foi feito.

Evitar certos vícios e práticas pouco adequadas ou não pensadas para o ambiente dos dados pode comprometer o êxito de todo o projeto, ou ao longo do tempo se tornar uma grande pedra no sapato de toda a equipe. É o caso das más escolhas de tipos de dados, tamanho de tabelas, entre outros, que veremos mais a frente nesse artigo. Com base em um banco de dados relacional, vamos relembrar algumas boas práticas que podem garantir o uso ao longo dos anos, aliviando o trabalho dos DBAs, ADs e do próprio SGBD.

Encontrando a arquitetura ideal – modelagem

Definir o modelo de dados junto com as equipes de desenvolvimento e os times de negócios parece algo bem óbvio, mas é o ponto primordial que sempre acaba impactado pela falta de comunicação entre esses mundos, que precisam estar bem conectados.

É a fase de mais alto nível de um projeto, trata-se de se colocar no lugar do cliente, imaginar e entender o que é o produto, qual será o seu uso, como de fato o resultado final afetará a vida do seu cliente, e então tornar-se parte do projeto, acompanhando todas as reuniões de discussões da evolução. Isso lhe dará uma ideia ampla e lhe permitirá traçar caminhos para o gerenciamento, a monitoração do ambiente, os KPI’s (Key Performance Indicator) tão importantes para tomada de decisão.

De posse do conhecimento e entendimento do resultado final, vamos para os componentes internos da área de gestão de dados, que será o ponto central da documentação do projeto de banco de dados. Na medida em que avançam as discussões e o projeto vai tomando forma, precisamos ter clareza com as normas, padrões adotados e compartilhados pela empresa, bem como as ferramentas que servirão de base para os times e para o pessoal da área de dados (AD).

O pessoal que cuida da gerência dos dados precisa oficializar um lugar compartilhado onde todos da empresa tenham acesso fácil aos documentos, normas e padrões, e os mesmos devem ser mantidos atualizados, seja numa ferramenta corporativa ou na nuvem. Nesse repositório teremos, por exemplo, os primeiros modelos conceituais, lógicos e físicos que estão em fase de desenvolvimento, bem como e-mails de decisões importantes tomadas em reuniões do produto, regras de negócio que precisam ser divulgadas, arquivos PDF, arquivos do Erwin ou outra ferramenta CASE, etc.

Precisamos também de um controlador de versões de arquivos, pois as alterações estruturais do banco serão constantes e será inevitável manter um histórico, compartilhar links de scripts SQL com outras áreas, configurar ferramentas de deploy contínuo. Enfim, é aqui que entra um GIT ou SVN para criar o repositório central de scripts SQL.

Continuamos descendo um pouco mais nessa hierarquia da arquitetura e modelagem, e agora vamos pensar um pouco sobre os padrões de nomenclatura para objetos (databases, schemas, tabelas, triggers, functions, etc.) a serem adotados pela companhia que facilitará as próximas fases do projeto. Será fácil, por exemplo, um desenvolvedor reconhecer que um campo criado no banco é de determinado tipo de dados apenas olhando o nome do campo, ou que uma sequence no padrão “seq_table1_idt” é um gerador de ID (Identification) para a tabela “TABLE1”. Mais alguns exemplos para mostrar melhor o que chamamos de padronização de nomenclatura:

  • num_clicks: número de cliques que é um inteiro ou um number;
  • des_store: campo varchar que fará uma descrição da loja;
  • tablename_pk: facilidade para encontrar Primary Keys consultando as views de dicionário;
  • tableorigem_tabledestino_fk: facilidade para entender que a FK se trata de chave estrangeira que provem da “tableorigem” para “tabledestino”;
  • nomedatabela: ...

    Quer ler esse conteúdo completo? Tenha acesso completo