Artigos Banco de Dados Introdução a projeto de banco de dados - Revista SQL Magazine 101 - Parte 1
Demais posts desta série:
Introdução a projeto de banco de dados - Parte 2
Artigo no estilo: Curso

De que se trata o artigo

O artigo apresenta as melhores práticas no desenvolvimento de um projeto de banco de dados relacional. Neste sentido, o artigo ajuda o arquiteto de dados a projetar os modelos de bancos de dados considerando boas práticas para garantir o êxito do projeto.


Em que situação o tema é útil

É especialmente útil desde o início do projeto de um sistema de banco de dados relacional.

Resumo DevMan

Quais são as melhores escolhas ao projetar o esquema para um banco de dados relacional? Qual é o fundamento para decidir em favor de um e contra alguma outra alternativa?

Em face a grande variedade de recomendações e especificações dadas pelos desenvolvedores de Sistemas de Gerenciamento de Banco de Dados, como Oracle, Microsoft, IBM entre outros, é muito fácil ignorar os fundamentos básicos de banco de dados relacionais.

Neste série de artigos serão apresentados os conceitos de tipos de dados simples e complexos, e também sobre as chaves primárias e chaves estrangeiras, que são extremamente importantes para manter o banco de dados íntegro e com bom desempenho.

Também será vista uma introdução à normalização de banco de dados e as cinco formas normais. É discutido também outros usos possíveis para um banco de dados em um projeto, por exemplo, como um repositório de dados de configuração ou de registro.

Encontrei mais um artigo muito interessante na internet. Na verdade, desta vez encontrei este artigo em um local realmente vasto de literaturas técnicas disponíveis para todos os profissionais. Estou falando do IBM developerWorks (ver seção Referências Bibliográficas).

O artigo encontrado é do autor Philipp K. Janert (ver seção Referências Bibliográficas), que fala sobre alguns conceitos práticos no projeto de banco de dados. Este primeiro artigo trata dos tipos de dados simples e complexos e também uma visão sobre as chaves primária e estrangeira.

Philipp é Consultor de Projetos de Software, programador de servidores e arquiteto. Seu interesse específico é a identificação, criação, transmissão e das melhores práticas de engenharia de software. Ele mantém o site www.BeyondCode.org e seus artigos foram publicados em IEEE Software, Linux Journal, e no site O'Reilly Network. Ele possui um Ph.D. em Física Teórica da Universidade de Washington em Seattle.

Mas é claro que não poderia simplesmente fazer uma tradução. Me preocupei em agregar informações ao artigo e torná-lo mais agradável e rico para você, leitor da SQL Magazine. Vamos ao que interessa.

Nesta série, Phillip discute algumas práticas gerais que encontrou durante sua trajetória profissional e percebeu que são particularmente úteis. Nenhuma dessas práticas é específica para um produto de qualquer fornecedor e tudo deve, portanto, ser aplicável, independentemente de qual implementação de banco de dados está sendo usada.

As chaves primárias e assuntos afins

Um banco de dados relacional (RDB) armazena dois tipos de informação - dados e relacionamentos. Podemos considerar dados como sendo os nomes de clientes, números de inventário, descrição de itens, e assim por diante, que o aplicativo usa. Já os relacionamentos se referem às chaves primárias e chaves estrangeiras que o banco de dados precisa para encontrar registros de dados e relacioná-los uns aos outros.

Conceitos básicos sobre relacionamentos

Para efeitos de modelagem de dados, os relacionamentos devem ser praticamente transparentes. Na verdade, o conhecimento purista de banco de dados não faz distinção entre dados e relacionamentos. No entanto, você vai ver que os relacionamentos são mais eficientes para a administração e manutenção, bem como em termos de desempenho de execução, ter alguns campos adicionais que servem como chaves para o banco de dados.

Cada tabela deve ter uma chave primária: um atributo ou combinação de atributos que são garantidos como sendo únicos e não nulos. Em geral, é útil introduzir uma chave substituta (surrogate key – ver Nota DevMan 1) - um atributo de tabela que não tem nenhum significado para a regra de negócio, mas simplesmente serve como identificador único para cada registro na tabela. Este é o relacionamento a que me refiro.

Os requisitos para uma chave primária são muito rigorosos. Uma chave primária deve:

• Existir;

• Ser única;

• Não deve mudar ao longo do tempo.

As chaves substitutas ajudam a mitigar o fato de que os dados reais da aplicação quase nunca cumprem estes requisitos. Nem toda pessoa tem um Número de Seguridade Social (os que estão fora os EUA), as pessoas mudam seus nomes, e outras informações importantes.

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 pode haver vários objetos na base de dados correspondente 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 objecto.

...
Quer ler esse conteúdo completo? Tenha acesso completo