Modelo relacional
Origem: Wikipédia, a enciclopédia livre.
Índice |
[editar] O modelo relacional
O modelo relacional para gerência de bancos de dados (SGBD) é um modelo de dados baseado em lógica de predicados e na teoria de conjuntos.
Históricamente ele é o sucessor do modelo hierárquico e do modelo em rede. Estas arquiteturas antigas são até hoje utilizadas em alguns data centers com alto volume de dados, onde a migração é inviabilizada pelo custo que ela demandaria; existem ainda os novos modelos baseados em orientação ao objeto, que na maior parte das vezes são encontrados como kits de construção de SGBD, ao invés de um SGBD propriamente dito.
O modelo relacional foi o primeiro modelo de banco de dados formal. Somente depois seus antecessores, os bancos de dados hierárquicos e em rede, passaram a ser também descritos em linguagem formal.
O modelo relacional foi inventado pelo 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 à objeto sem comprometer os seus princípios fundamentais.
A linguagem padrão para os bancos de dados relacionais, SQL, do inglês structured query language, é 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.
[editar] 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, Factura, 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 candidatas. 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.
[editar] 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.
[editar] Headline text
[editar] 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.
