BOMBOLOM.COM

(databases) Theory: 2 - Base de dados Relaccional (Relational Databases)

Este é um post de José Lopes.

Este post serve para explicar um pouco o que é afinal uma base de dados relaccional e alguma terminologia que lhe está associada. É interessante ter uma ideia deste tipo de base de dados e do seu sistema de gestão para posteriormente compreender melhor o processo de design (que irei tratar noutro post).

A base de dados relaccional é presentemente a mais utilizada no mundo das bases de dados.

Tal supremacia deve-se, entre outros factores, à:

Este tipo de base de dados usa como o nome indica o modelo relaccional. Este modelo é um modelo matemático, cujo nome significa tabelas e não relacções como poderia dar a entender. Isto é uma confusão comum.

O relaccional implica uma colecção ordenada de n-coisas (n-tuples).
Exemplificando este tipo de colecções:

Se escrevermos estas n-coisas uma sobre outra obtemos algo que se parece com uma tabela:

Europa Portugal Euro
América do Sul Brasil Real

Esta é a imagem conceptual deste tipo de base de dados. Podemos dizer que num modelo relaccional a informação é expressada utilizando somente tabelas e todas as operações que possamos fazer produzem outras tabelas.

Vamos definir alguma terminologia antes de avançarmos mais.

Esquematizando:

A utilização de tabelas permite uma elevada uniformidade do modelo, pois como podemos ver no esquema anterior, os valores nas linhas representam uma única associação, ou por outras palavras, representam valores individuais ou estado da entidade e nada mais do que dessa entidade (podemos considerar como um acontecimento da entidade com certos valores), enquanto os valores nas colunas restringem-se a um determinado domínio (como as Regiões).

O termo 'imagem conceptual' vem da teoria implicita no modelo relaccional que, do seu pedestal teórico, considera não haver colunas especiais nem mecanismos de ponteiros para associar informação. Isto não podia estar mais longe da realidade.

Embora o mentor deste modelo, Edgar F. Codd, tenha redigido as que ficaram conhecidas como as 12 Regras de Codd (link em Inglês) para definir os requesitos necessários para um produto ser considerado como uma base de dados relaccional, verdade seja dita que nenhum produto existente as preenche na totalidade.

Isto poderá ser devido a alguma subjectividade no texto destas regras mas é de certeza devido aos criadores dos produtos utilizarem mecanismos de optimização (os tais optimizadores) visando a performance. Isto vai ao ponto de criarem tabelas de indexação internas ao sistema de gestão e à utilização de colunas especiais nas tabelas de informação, recorrendo a chaves primárias e a chaves externas, que não existem na imagem conceptual.

É neste contexto que surgem as chaves primárias (primary keys) e as chaves externas (foreign keys). Qualquer sistema de gestão de base de dados faz um uso extensivo destes dois conceitos.

Uma chave primária não é mais do que os valores de uma certa coluna da tabela que asseguram que não haja duas linhas impossíveis de distinguir, ou seja, esses valores têm obrigatoriamente de ser únicos. A chave primária é aquilo que identifica um registo na tabela garantindo a sua unicidade.

Não se trata de uma questão de repetição do registo na tabela. A função principal deste tipo de chaves é garantir a consistência da base de dados, por modo a que o sistema de gestão não fique bloqueado por não conseguir distinguir os registos, daí a unicidade.

Normalmente, por uma questão de lógica visual, a primeira coluna de uma tabela é composta por chaves primárias. Claro que isto não é obrigatório pois podemos definir qualquer coluna para o efeito, é mais por uma questão de leitura lógica.

Os sistemas de gestão (DBMS) utilizam internamente uma indexação, para mecanismos internos de optimização e consolidação, adicionando uma coluna extra no início de cada tabela. Isto contudo não é uma chave primária, é algo interno que o utilizador não controla nem vê.

Fazendo um pequeno à parte e tomando o exemplo de um sistema Oracle, podemos fazer uso desta indexação (através de um comando PL/SQL) para obter resultados muito mais rápidos uma vez que recuperamos os registos de uma forma directa sem o recurso a nenhum método associativo. A Oracle utiliza um número com um tamanho definido para a indexação.

Na minha opinião não aconselho o uso desta técnica por duas razões principais:

Fechando este à parte, não é demais de mencionar a importância de uma escolha correcta da chave primária para uma boa consistência da base de dados. Irei voltar a escrever sobre as chaves primárias e como as escolher no post que se seguirá sobre o processo de design de uma base de dados.

As chaves externas são valores numa coluna da tabela que representam uma relacção desta tabela com outra. Com um pequeno esquema compreende-se logo:

Na coluna tipo da tabela vinhos temos chaves externas, ou seja, os valores que temos nesta coluna vêm da tabela tipos. Isto é definido quando se constrói a base de dados, limitando os valores possíveis para a coluna tipo da tabela vinhos aos existentes na tabela tipos.

Como podemos observar não existe nenhum constrangimento de unicidade, podemos ter a mesma chave externa várias vezes na tabela vinhos. Atenção que na tabela tipos a coluna existente é constituída por chaves primárias.

Para concluir, este conceito de chaves e tabelas vai ser importante no que diz respeito à normalização da base de dados, sendo outro ponto inerente ao design da base de dados.

31.05.2008 | Ler mais | Comentários | Tags , ,

Voltar à Página principal | Made with PyBlosxom