Na véspera do início de um novo ciclo do curso preparamos um pequeno material autoral com conselhos importantes sobre a construção de bancos de dados. Esperamos que este material seja útil para você.
Bancos de dados estão em toda parte: de blogs e diretórios simples a sistemas de informação robustos e grandes redes sociais. Não importa tanto se o banco de dados é simples ou complexo, mas sim como projetá-lo corretamente. Quando um banco é projetado sem cuidado e sem um entendimento claro do objetivo, ele não é apenas ineficaz, mas o trabalho subsequente com o banco se tornará um verdadeiro tormento, uma floresta intransponível para os usuários. Aqui estão algumas dicas sobre a construção de bancos de dados que ajudarão a criar um produto útil e fácil de usar.
1. Defina qual é a finalidade da tabela e qual é sua estrutura
Hoje, métodos de desenvolvimento como Scrum ou RAD (desenvolvimento rápido de aplicativos) ajudam as equipes de TI a desenvolver bancos de dados rapidamente. No entanto, na pressa, é muito tentador mergulhar imediatamente na construção do banco, tendo uma ideia vaga do que realmente é o objetivo e quais devem ser os resultados finais.
É como se a equipe estivesse focada em um trabalho eficaz e rápido, mas isso é uma ilusão. Quanto mais rápido e fundo mergulhar no projeto, mais tempo será necessário para identificar e corrigir erros no projeto do banco.
Portanto, a primeira coisa a decidir é definir o objetivo do seu banco de dados. Para que tipo de aplicativo o banco está sendo desenvolvido? O usuário vai apenas trabalhar com registros e necessita de atenção às transações, ou está mais interessado na análise de dados? Onde o banco deve ser implantado? Ele vai monitorar o comportamento dos clientes ou gerenciar relacionamentos entre eles?
Quanto mais cedo a equipe de design responder a essas perguntas, mais suave e tranquila será o processo de design do banco de dados.
2. Quais dados escolher para armazenamento?
Planeje com antecedência. Pense sobre o que o site ou sistema fará no futuro, para o qual o banco de dados está sendo projetado. É importante ir além dos simples requisitos do documento técnico. Mas, por favor, não comece a pensar imediatamente sobre todos os possíveis tipos de dados que o usuário pode armazenar. Em vez disso, considere se os usuários poderão escrever posts, carregar documentos ou fotos, ou trocar mensagens. Se sim, o banco de dados precisa ter espaço reservado para isso.
Trabalhe com a equipe, departamento ou organização que futuramente irá apoiar o banco de dados projetado. Comunique-se com pessoas em diferentes níveis, desde especialistas em atendimento ao cliente até chefes de departamento. Assim, com o feedback, você terá uma compreensão clara dos requisitos da empresa.
Inevitavelmente, as necessidades dos usuários dentro de um mesmo departamento entrarão em conflito. Se você enfrentar isso, não tenha medo de se apoiar em sua própria experiência e encontrar um compromisso que satisfaça todas as partes e atenda ao objetivo final do banco de dados. Tenha certeza de que, no futuro, você receberá +100500 de karma e uma montanha de biscoitos.
3. Modele os dados com cautela
Há alguns pontos-chave a se considerar ao modelar dados. Como já discutido antes, a finalidade do banco de dados determina quais métodos usar na modelagem. Se estamos projetando um banco de dados para o processamento transacional online (OLTP), ou seja, para criação, edição e exclusão de registros, devemos utilizar a modelagem de transações. Se o banco de dados deve ser relacional, é melhor aplicar a modelagem multidimensional.
Durante a modelagem, são construídos modelos conceituais (CDM), físicos (PDM) e lógicos (LDM).
Modelos conceituais descrevem entidades e tipos de dados que incluem, bem como as relações entre eles. Separe seus dados em pedaços lógicos – isso torna a vida muito mais fácil.
O principal é a medida, não exagere.
Se uma entidade é muito difícil de classificar com uma única palavra ou frase, é hora de usar subtipos (entidades filhas).
Se a entidade possui vida própria, atributos que descrevem seu comportamento e aparência, bem como relações com outros objetos, pode-se usar não apenas o subtipo, mas também o supertipo (entidade pai).
Ignorar essa regra pode confundir outros desenvolvedores em seu modelo, e eles não entenderão completamente os dados e as regras de como coletá-los.
Modelos conceituais são implementados por meio de modelos lógicos. Esses modelos funcionam como um mapa para o design da base de dados física. No modelo lógico, as entidades de dados empresariais são destacadas, os tipos de dados são definidos e as regras-chave que regulam as relações entre os dados são estabelecidas.
Em seguida, o modelo lógico de dados é associado à plataforma de SGBD (sistema de gerenciamento de banco de dados) escolhida previamente, de gestão de bases de dados) resultando no Modelo Físico. Este descreve o método de armazenamento físico dos dados.
4. Use tipos de dados apropriados
Aplicar um tipo de dado incorreto pode levar a dados menos precisos, dificuldades na junção de tabelas, sincronização de atributos e ao aumento dos tamanhos dos arquivos.
Para garantir a integridade da informação, o atributo deve conter apenas tipos de dados aceitáveis. Se a idade for inserida no banco de dados, certifique-se de que a coluna armazene números inteiros com no máximo 3 dígitos.
Crie o mínimo de colunas vazias com valor NULL. Se você criar todas as colunas como NULL, isso é um erro grave. Se você realmente precisar de uma coluna vazia para executar uma função de negócio específica, quando os dados são desconhecidos ou ainda não fazem sentido, fique à vontade para criá-la. Afinal, não podemos preencher antecipadamente as colunas 'Data de falecimento' ou 'Data de demissão', não somos adivinhos que podem apontar para o céu :-).
A maioria dos softwares de modelagem (ER/Studio, MySQL Workbench, SQL DBM, gliffy.com) permite criar protótipos de áreas de dados. Assim, garante-se não apenas o tipo de dado correto, a lógica do aplicativo e um bom desempenho, mas também a definição necessária do valor.
5. Prefira o natural
Ao decidir qual coluna em uma tabela escolher como chave, preste sempre atenção aos campos que o usuário pode editar. Nunca os escolha como chave — é uma má ideia. Qualquer coisa pode acontecer, e você deve garantir a unicidade.
É melhor usar uma chave natural ou de negócios (natural key). Ela tem um significado semântico, desta forma você evita duplicações no banco de dados.
A menos que a chave de negócios não seja única (nome, sobrenome, cargo) e se repita em diferentes linhas da tabela ou precise ser alterada, a chave primária deve ser uma chave artificial gerada (artificial key).
6. Normalize com moderação
Para organizar eficazmente os dados em um banco de dados, é necessário seguir um conjunto de recomendações e normalizar o banco de dados. Existem cinco formas normais a serem seguidas.
Com a normalização, você evitará redundância e garantirá a integridade dos dados utilizados no aplicativo ou site.
Como sempre, tudo deve ser moderado, até mesmo a normalização. Se houver muitas tabelas no banco de dados com chaves únicas iguais, você exagerou e normalizou demais o banco de dados. A normalização excessiva prejudica o desempenho do banco de dados.
7. Teste cedo, teste frequentemente
Um plano de teste e testes adequados devem fazer parte do desenho do banco de dados.
É melhor testar o banco de dados por meio da Integração Contínua (Continuous Integration). Modele o cenário 'Um dia na vida do banco de dados' e verifique se todos os casos limite são tratados, quais interações dos usuários são prováveis. Quanto mais cedo você encontrar bugs, mais tempo e dinheiro economizará.
Estas são apenas sete dicas pelas quais você pode projetar um excelente banco de dados em termos de desempenho e eficiência. Se você segui-las, evitará a maioria das dores de cabeça no futuro. Essas dicas são apenas a ponta do iceberg na modelagem de bancos de dados. Existem inúmeras dicas. Quais você utiliza?
Fonte: habr.com
