Modelo relacional
Keywords: Modelo relacional, Banco de dados, Banco de dados relacional, CEP, Chave, Cidade, Cliente, Conjunto, DER, Diagramação
| Conteúdo |
O modelo relacional
O modelo relacional para gerenciamento de bancos de dados (DBMS) é um modelo de dados baseado em lógica de predicados e na teoria de conjuntos.
Outros modelos são o modelo hierárquico e o modelo em rede. Alguns sistemas utilizando estas arquiteturas antigas ainda estão em operação hoje em data centers com alto volume de dados ou onde sistemas existentes são tão complexos que o custo de migração para o modelo relacional é proibitivo; existem ainda os novos modelos baseados em orientação ao objeto, apesar que muitos destes são kits de construção de also DBMS, ao invés de um DBMS propriamente dito.
O modelo relacional foi o primeiro modelo de banco de dados formal. Depois que ele foi definido, modelos formais foram feitos para descrever bancos de dados hierárquicos e em rede. Estes modelos existiam antes do modelo relacional, mas somente passaram a ter modelos formais depois que o modelo relacional foi definido.
O modelo relacional foi inventado por Dr. Ted Codd e subsequentemente mantido e aprimorado por Chris Date e Hugh Darwen como um modelo geral de dados. No Terceiro Manifesto (1995) eles mostraram como o modelo relacional pode ser extendido com características de orientação ao objeto sem comprometer os seus princípios fundamentais.
A linguagem padrão para os bancos de dados relacionais, SQL, é apenas vagamente remanescente do modelo matemático. Atualmente ela é adotada, apesar de suas restrições, porque ela é antiga e muito mais popular que qualquer outra linguagem de banco de dados.
A principal proposição do modelo relacional é que todos os dados são representados como relações matemáticas, isto é, um subconjunto do produto Cartesiano de n conjuntos. No modelo matemático (diferentemente do SQL), a análise dos dados é feita em uma lógica de predicados de dois valores (ou seja, sem o valor nulo); isto significa que existem dois possíveis valores para uma proposição: verdadeira ou falsa. Os dados são tratados pelo cálculo relacional ou álgebra relacional.
O modelo relacional permite ao projetista criar um modelo lógico consistente da informação a ser armazenada. Este modelo lógico pode ser refinado através de um processo de normalização. Um banco de dados construído puramente baseado no modelo relacional estará inteiramente normalizado. O plano de acesso, outras implementações e detalhes de operação são tratados pelo sistema DBMS, e não devem ser refletidos no modelo lógico. Isto se contrapõe à prática comum para DBMSs SQL nos quais o ajuste de desempenho frequentemente requer mudanças no modelo lógico.
Os blocos básicos do modelo relacional são o domínio, ou tipo de dado. Uma tupla é um conjunto de atributos que são ordenados em pares de domínio e valor. Uma relvar (variável relacional) é um conjunto de pares ordenados de domínio e nome que serve como um cabeçalho para uma relação. Uma relação é um conjunto desordenado de tuplas. Apesar destes conceitos matemáticos, eles correspondem basicamente aos conceitos tradicionais dos bancos de dados. Uma relação é similar ao conceito de tabela e uma tupla é similar ao conceito de linha.
O princípio básico do modelo relacional é o princípio da informação: toda informação é representada por valores em relações. Assim, as relvars não são relacionadas umas às outras no momento do projeto. Entretanto, os projetistas utilizam o mesmo domínio em vários relvars, e se um atributo é dependente de outro, esta dependência é garantida através da integridade referencial.
Banco de dados exemplo
Um exemplo, bem simples da descrição de algumas relvars e seus atributos:
Cliente(ID Cliente, ID Taxa, Nome, Endereço, Cidade, Estado, CEP, Telefone)
Pedido de compra(Número do pedido, ID Cliente, Fatura, Data do pedido, Data prometida, Status)
Item do pedido(Número do pedido, Número do item, Código do produto, Quantidade)
Nota fiscal(Número da nota, ID Cliente, Número do pedido, Data, Status)
Item da nota fiscal(Número da nota,Número do item,Código do produto, Quantidade vendida)
Neste projeto nós temos cinco relvars: Cliente, Pedido, Item do pedido, Nota fiscal e Item da nota fiscal. Os atributos em negrito e sublinhados são chaves candidatass. Os itens sublinhados sem negrito são as chaves estrangeiras.
Normalmente uma chave candidata é escolhida arbitrariamente e escolhida para ser chamada de chave primária e utilizada preferencialmente, sendo que as outras chaves candidatas são chamadas chaves alternativas.
Uma chave candidata é um identificador único que garante que nenhuma tupla será duplicada; isto faz com que o relacionamento em algo denominado um multiconjunto, porque viola a definição básica de um conjunto. Uma chave pode ser composta, isto é, pode ser formada por vários atributos. Abaixo temos um exemplo tabular da nossa variável exemplo Cliente; um relacionamento pode ser abstraído como um valor que pode ser atribuído a uma relvar.
Exemplo: Cliente
ID Cliente ID Taxa Nome Endereço [More fields....] ================================================================================================== 1234567890 555-5512222 João Carlos Rua Marmelo, 120 ... 2223344556 555-5523232 Dorotéia Santos Avenida Carambola,12 ... 3334445563 555-5533322 Lisbela da Cruz Rua Goiabeiras,123 ... 4232342432 555-5325523 E. F. Codd Rua Mangabeiras,51 ...
Se nós tentarmos inserir um novo cliente com o ID 1234567890, isto irá violar o projeto da relvar pois ID Cliente é uma chave primária e nós já temos um cliente com o número 1234567890. O DBMS deve rejeitar uma transação como esta e deve acusar um erro de violação da integridade.
As chaves estrangeiras são condições de integridade que garantem que o valor de um atributo é obtido de uma chave candidata de outra relvarr, por exemplo na relvar Pedido o atributo ID Cliente é uma chave estrangeira. Uma união é uma operação que retorna a informação de várias relvars de uma vez. Através da união de relvars do exemplo acima podemos consultar no banco de dados quais são os clientes, pedidos e notas. Se nós queremos apenas as tuplas de um cliente específico, podemos especificar isto utilizando uma condição de restrição.
Se queremos obter todos os pedidos do cliente 1234567890, podemos consultar o banco de dados de forma que este retorne toda linha na tabela de Pedidos com ID Cliente igual a 1234567890 e agrupar a tabela de pedidos com a tabela de itens de pedido baseado no Número do pedido.
Existe uma imperfeição no projeto de banco de dados acima. A tabela de notas contém um atributo número do pedido. Assim, cada tupla na tabela de notas terá um pedido, o que implica em precisamente um pedido para cada nota. Mas na realidade uma nota pode ser criada a partir de muitos pedidos, ou mesmo para nenhum pedido em particular. Adicionalmente um pedido contém um número de nota, implicando que cada pedido tem uma nota correspondente. Mas novamente isto não é verdadeiro no mundo real. Um pedido é às vezes pago através de várias notas, e às vezes pago sem um nota. Em outras palavras podemos ter muitas notas por pedido e muitos pedidos por nota. Isto é um relacionamento vários-para-vários entre pedidos e notas. Para representar este relacionamento no banco de dados uma nova tabela deve ser criada com o propósito de especificar a correspondência entre pedidos e notas:
PedidoNota(Número do pedido,Número da nota)
Agora, um pedido tem um relacionamento um-para-vários para a tabela PedidoNota, assim como o Cliente tem para a tabela de pedidos. Se quisermos retornar todas as notas de uma pedido específico, podemos consultar no banco de dados todos os pedidos cujo Número do pedido é igual ao Número do pedido na tapela PedidoNota, e onde o Número da nota na tabela PedidoNota é igual à Número da nota na tabela Notas.
A normalização de banco de dados é normalmente realizada quando projeta-se um banco de dados relacional, para melhorar a consistência lógica do projeto do banco de dados e o desempenho transacional.
Existem dois sistemais mais comuns de diagramação que ajudam na representação visual do modelo relacional: O diagrama de entidade-relacionamento DER, e o diagrama correlato IDEF utilizado no método IDEF1X criado pela Força aérea americana baseado no DER.
Headline text
Referências
- Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387.
- Introduction to Database Systems. Date, C. J. 7th ed. 1999.