Objetivo

O objetivo deste artigo é explicar de forma prática os principais conceitos dos bancos de dados relacionais. Tem muitas outras coisas e detalhes sobre os conceitos expostos aqui, mas esse é apenas um ponto de partida.

Se houverem dúvidas ou sugestões, enviem seus comentários (rodapé da página).

Bancos de Dados Relacionais x Bancos de Dados Orientados a Objeto

Nunca trabalhei com um banco de dados orientado a objeto. O único que “ouvi falar” no mercado foi o tal “Caché” da InterSystems, que nunca tive oportunidade de ver operando na prática e com grande volume de transações.

Quando começaram a evoluir as técnicas de projeto orientado a objeto, principalmente por causa da adoção da UML e começaram as discussões sobre persistência de objetos (Hibernate, por exemplo), começou-se a questionar muito se os bancos de dados relacionais (que já estavam vivos a mais ou menos umas 3 décadas) estariam prontos pra essa nova onda.

O fato é que estamos em 2009 e os bancos relacionais são mais usados do que nunca. Os sistemas legados que já começaram sem padrões, processos, metodologias estão todos escritos em BD’s relacionais e a chance de alguém querer reescrever sistemas com 10, 20 anos de vida é muito baixa.

Parece que a prática de mercado ficou em usar bancos de dados relacionais e mapeamento objeto/relacional para projetos com arquiteturas mais definidas.

Essa é a principal razão de eu ainda estar motivado para escrever isso.

Exemplos de Bancos de Dados Relacionais

• Sybase, SQL Server 2000 e 2005: São praticamente a mesma coisa. O SQL Server é quase uma “evolução” do Sybase, que teve uma parceria com a Microsoft para que surgisse o SQL Server. São muito similares. Geralmente usados por empresas que fazem questão em manter “tudo” da Microsoft, adotados por gente que evolui de bancos de dados locais (como Access). Muitas pessoas optam também pelo SQL Server pela facilidade de administração.
• Oracle: Considerado mais “enterprise” pela maioria. Possui melhores opções de gerenciamento de crescimento dos data files que o SQL Server, mas um pouco mais complexo de administrar que o primeiro.
• Firebird/Interbase: Praticamente a mesma coisa também. O Firebird foi originado pela abertura do código do Interbase pela Borland, o que deu uma forte popularizada entre desenvolvedores Delphi. Tem a vantagem de ser open-source e suportar uma carga quase tão grande (senão algumas vezes maior) que o próprio SQL Server. Pessoas que evitam a adoção do Firebird geralmente são pessoas que fogem de ferramentas Open Source.
• PostgreSQL: Open source também, disponivel praticamente desde sempre junto com algumas distros de Linux. Já tive oportunidade de mexer um pouco com esse banco e gostei muito. Parece-me até um pouco mais parrudo que o Firebird, porém roda muito melhor em linux do que Windows e tem uma grande dificuldade em drivers de qualidade para outras plataformas, pelo menos na época em que tive mais contato com ele (por volta de 2004). Não sei como está hoje.
• MySQL: Muito popular entre usuários PHP, é muito simples, muito rápido e muito pequeno. Nas primeiras versões ele tinha uma grande performance principalmente porque não fazia muita coisa (não tinha nem integridade referencial) hoje ele implementa esse e outros conceitos, porém não sei se é tão performático. Muito usado em pequenas aplicações. Também gratuíto. Não sei se a licensa dele é open-source.

Principais Conceitos de Bancos de Dados Relacionais

Tabelas ou Relações

Nos livros “acadêmicos” é comum chamar tabelas de “Relações”. Vou chamar de tabelas mesmo que é como é popularmente conhecido (já que esse artigo está muito, mas muito longe de ser acadêmico).

As tabelas são onde os dados são armazenados, dá pra comparar diretamente com uma planilha Excel, que tem colunas e linhas. Cada coluna possui o seu tipo de dados (serão detalhados posteriormente).

Geralmente para nomear tabelas usa-se palavras no singular. Exemplo: Cliente, Endereco, Pedido, ItemPedido. Não é muito bom nomear tabelas no plural, pois principalmente em nomes compostos, gera-se uma confusão enorme. Ex.: ItensPedido ou ItensPedidos?

Chave Primária (Primary Key)

É a principal forma (não a única) de se localizar dados numa tabela. Vamos pensar numa tabela de “Cliente” que possua as colunas Nome, Telefone, RazaoSocial. Podemos identificar o cliente unicamente através de um campo Codigo, ClienteID ou mesmo CPF/CPNJ (apesar de eu não gostar).

Não vou discutir aqui técnicas sobre como modelar uma tabela/chave primária. Isso fica mais pra frente.

Chave alternativa (Alternate Key, Unique Index)

É uma forma secundária de se localizar unicamente um registro. Ex.: Nossa tabela Cliente tem como chave primária um campo ClienteID, poderíamos definir uma chave alternativa como CPF/CNPJ, além de não podermos duplicar CPF e CNPJ, é uma outra forma de localizar um cliente.

A maioria dos bancos de dados relacionais implementa esse conceito através de “UNIQUE” indexes (create unique index), porém, é muito comum ver nas ferramentas de modelagem (ERWin, Embarcadero ERStudio) o termo “alternate key”.

Chave estrangeira (Foreign Key) / Integridade Referencial

Integridade referencial é um conceito que determina que para que um determinado dado exista numa tabela, deve haver um correspondente em outra. Ex.: Para que possa ser inserido um ClienteID na tabela Pedido, é necessário que exista um registro com o ClienteID informado na tabela Cliente.

Esse conceito é implementado através de chaves estrangeiras (foreign keys). As chaves estrangeiras nada mais são do que essas definições.

É muito importante definir as chaves estrangeiras no modelo de dados, é uma forma de tornar o banco íntegro e evitar uma série de falhas nas aplicações que acessam esse banco. É por aqui que algumas consistências simples entram no modelo, por exemplo:

• Faz sentido um pedido para um cliente que não existe? Aqui cabe uma FK.
• Faz sentido um registro na movimentação de conta corrente para uma conta que não existe? Aqui cabe outra FK.
• Faz sentido um endereço para um cliente que não existe?
• E assim sucessivamente.

Check Constraint

Alguns bancos implementam esse conceito. É uma forma de determinar quais são as informações possíveis numa coluna da tabela. Ex.: Tem um cliente com um campo Status, char(1). Nesse campo somente podem entrar os valores ‘A’ (ativo) e ‘I’ (inativo). É pela check constraint que impede-se de qualquer outra informação entrar nessa coluna.

Trigger

A maioria dos bancos de dados relacionais hoje implementam uma linguagem de programação no banco de dados. No caso do Oracle, o PL/SQL, do SQL server, o Transact SQL e outras.

A Trigger é uma forma de se escrever um código no banco de dados que execute de acordo com um evento. Ex.: Sempre que inserir um registro na tabela cliente, executa uma trigger. Sempre que excluir um registro de uma tabela, executa outra trigger.

Como usar uma trigger é uma discussão à parte que merece um artigo só pra ela. Não é muito difícil cair em armadilhas ao se criar triggers. Futuramente pretendo escrever um artigo só sobre isso.

Stored Procedure (ou somente Procedure)

É um pedaço de código, um programa que executa do lado do banco de dados (consumindo os recursos de processamento e memória do banco de dados).

Há defensores das procedures e gente que não quer elas de jeito nenhum em seus projetos. Essa é uma discussão muito mais complexa.

Geralmente, usa-se procedures por questões de performance, ou seja, invés de trazer todos os dados para a aplicação e processar lá, faz-se tudo no banco. Nem sempre isso é performatico. Existe uma série de poréns. O principal é saber qual é o conceito neste momento.

User Defined Functions (UDF’s) ou somente Functions

São funções, escritas na linguagem de programação dos bancos de dados, que geralmente permitem que as mesmas sejam usadas direto de statements SQL.

Ex.: Cria-se uma função HoraUtil, que recebe um datetime como parâmetro e de dentro da query, pode-se fazer chamadas a elas, exemplo:

select
  Data,
  HoraUtil(DataHora)
from
  MinhaTabela

Em alguns casos, UDF’s economizam muito, mas muito código redundante em queries, porém, também podem causar vários problemas de performance.

View

View é um recurso que permite que determinada expressão SQL seja armazenada no banco de dados e novas consultas podem ser feitas sobre ela.

É uma forma principalmente de “restringir” ou criar visões mais complexas de tabelas (inclusive joins) e permitir consultas futuras. Ex.: Imagine uma tabela cliente. Pode-se derivar dessa tabela uma view “ClientesAtivos”, de forma que a view liste somente os clientes ativos.

Geralmente é bom usar Views por questões de administração de banco. Pela aplicação geralmente é uma perda desnecessária de performance (pois pode gerar planos de execução de queries bem complexos).