Os dez erros mais comuns em projeto de Banco de Dados - Revista SQL Magazine 102 - Parte 2

Este artigo apresenta cinco dos dez erros mais comuns no processo de modelagem de um banco de dados, tanto no tocante à modelagem, quanto à manutenção e também o desempenho geral do banco de dados.

Demais posts desta série:
Os dez erros mais comuns em projeto de Banco de Dados - Parte 1
Artigo no estilo: Curso

De que se trata o artigo

Este artigo apresenta cinco dos dez erros mais comuns no processo de modelagem de um banco de dados, tanto no tocante à modelagem, quanto à manutenção e também o desempenho geral do banco de dados. Para isso, discutiremos tópicos associados ao uso da coluna auto-incremento como sua única chave, não utilização das características do SQL para proteger a integridade de dados, não uso de stored procedures para acessar dados, dentre outros.

Em que situação o tema é útil

Durante o desenvolvimento de um modelo de dados, evitar certos vícios e práticas pouco adequadas é especialmente útil para que o projeto como um todo alcance o êxito desejado ou que, ao menos, o retrabalho seja o mínimo possível.

Resumo DevMan

No artigo anterior foram apresentados os cinco primeiros erros mais comuns em projetos de banco de dados. Neste artigo serão apresentados os cinco erros finais.

É muito comum encontrarmos sistemas em que, ao invés do arquiteto de dados procurar por uma informação no mundo real que consiga definir um registro como sendo único, ele decida por utilizar colunas do tipo autoincremento para modelar a chave primária de uma tabela. Outra falha bastante comum é não utilizar das características da linguagem SQL para implementar a proteção da integridade de dados. A linguagem SQL é bastante poderosa e concentrar as regras de integridade de dados no próprio banco de dados, além de melhorar o desempenho, garante confiabilidade.

Ainda neste assunto, também é comum deixar toda a regra de negócio na camada da aplicação prevenindo ataques hacker na forma de SQL Injection.

Não podemos deixar de citar também a tentativa “preguiçosa” de construir objetos genéricos no banco de dados, principalmente em stored procedures, onde se tenta utilizar o mesmo código para efetuar alterações em diferentes tabelas, apenas passando parâmetros ao código.

Finalmente falaremos sobre o famigerado problema de falta de testes, ou seja, para garantir a entrega do sistema dentro do prazo, deixa-se de lado a qualidade do código.

Continuando nossa saga de apresentar os dez erros mais comuns no projeto de bancos de dados apresentarei os cinco erros restantes. Na edição passada trabalhamos sobre temas como má concepção / planejamento e o não uso da normalização de dados.

Neste segundo e último artigo de nossa série serão abordados os seguintes erros:

1. Usar coluna auto-incremento como sua única chave;

2. Não utilizar as características do SQL para proteger a integridade de dados;

3. Não usar stored procedures para acessar dados;

4. Tentativa de construção de objetos genéricos;

5. Falta de testes.

Usar coluna auto-incremento como sua única chave

A Primeira Forma Normal (1FN) dita que todas as linhas em uma tabela devem ser unicamente identificáveis. Assim, cada tabela deve ter uma chave primária. O SQL Server permite que você defina uma coluna numérica como uma coluna do tipo IDENTITY (identidade), que gera automaticamente um valor único para cada linha. Alternativamente, você pode usar NEWID() (ou NEWSEQUENTIALID()) para gerar um valor de 16 bytes aleatório e único para cada linha. Estes tipos de valores, quando usados como chaves, são o que são conhecidos como chaves substitutas (ver Nota DevMan 1). A palavra substituto significa "algo que substitui" e, neste caso, uma chave substituta deve ser o substituto para uma chave natural.

Nota DevMan 1: Surrogate key – chave substituta

A chave substituta (surrogate key) em um banco de dados é um identificador único para qualquer entidade do mundo modelado ou um objeto no banco de dados. A chave substituta não é derivada dos dados da aplicação.

Uma distinção importante entre uma chave substituta e uma chave primária depende se o banco de dados é um banco de dados atual (como os transacionais, ou on-line) ou um banco de dados temporal (conhecido como bando de dados históricos). Uma vez que um banco de dados atual armazena somente dados atuais válidos, há uma correspondência um-para-um entre uma chave substituta no mundo modelado e a chave primária do banco de dados. Neste caso, a chave substituta pode ser utilizada como uma chave primária. Numa base de dados temporal, no entanto, existe uma relação muitos-para-um entre as chaves primárias e as chaves substitutas. Uma vez que podem haver vários objetos na base de dados correspondentes a uma chave substituta única, não podemos usar o substituto como uma chave primária; outro atributo é necessário, para além do substituto, identificar exclusivamente cada objeto.

Alguns estudiosos argumentam que uma chave substituta deve ter as seguintes características:

- O valor é único para todo o sistema, portanto, nunca reutilizado;

- O valor é gerado pelo sistema;

- O valor não é manipulável pelo usuário ou aplicação;

- O valor não contém nenhum significado semântico;

- O valor não é visível para o usuário ou aplicação;

- O valor não é composto de vários valores de domínios diferentes.

Em um banco de dados atual, a chave substituta pode ser a chave primária gerada pelo sistema de gerenciamento de banco de dados e não derivada dos dados do aplicativo no banco de dados. O único motivo de se ter uma chave substituta é o de atuar como a chave primária. É também possível que a chave substituta exista além do UUID gerado pelo banco de dados (por exemplo, um número de RH para cada empregado que não seja o UUID de cada empregado)."

[...] continue lendo...

Artigos relacionados