Modelo relacional

Predefinição:Sem-notas O modelo relacional é um modelo de dados representativo (ou de implementação), adequado a ser o modelo subjacente de um Sistema Gerenciador de Banco de Dados (SGBD), que se baseia no princípio de que todos os dados estão armazenados em tabelas (ou, matematicamente falando, relações). Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos.

O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared Data Banks". Na verdade, o modelo relacional foi o primeiro modelo de dados descrito teoricamente, os bancos de dados já existentes passaram então a ser conhecidos como (modelo hierárquico, modelo em rede ou Codasyl e modelo de listas invertidas).

O modelo relacional para gerência de bases de dados (SGBD) é um modelo de dados baseado em lógica e na teoria de conjuntos.

Em definição simplificada, o modelo baseia-se em dois conceitos: conceito de entidade e relação - Uma entidade é um elemento caracterizado pelos dados que são recolhidos na sua identificação vulgarmente designado por tabela. Na construção da tabela identificam-se os dados da entidade. A atribuição de valores a uma entidade constrói um registro da tabela. A relação determina o modo como cada registro de cada tabela se associa a registros de outras tabelas.

Historicamente 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 em linguagem formal.

O modelo relacional foi inventado pelo Frank 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 estendido com características de orientação a 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 (relvars). 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 tabelas 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 de compra, 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 para ser chamada de chave primária e utilizada com preferência sobre as outras chaves candidatas, que são então chamadas de chaves alternativas.

Uma chave primária é 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: bancária

ID Cliente	ID Taxa	Nome Endereço	[Mais campos....]
1234567890	555-5512222	João Carlos Rua Principal nº 120	...
2223344556	555-5523232	Dorotéia Santos Avenida Principal nº 12	...
3334445563	555-5533322	Lisbela da Cruz Rua de trás nº123	...
4232342432	555-5325523	E. F. Codd Travessa principal nº 51	...
4265871131	555-5487333	franciwilliam projetada nº 1252	...

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 relvar, 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 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 Pedido Nota, 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 tabela Pedido Nota, e onde o Número da nota na tabela Pedido Nota é 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 sistemas 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 dos Estados Unidos baseado no DER.

Ver também

• Arquitetura de dados
• Administração de dados
• Modelagem de dados
• Banco de Dados

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.

Ligações externas

• A Relational Model of Data for Large Shared Data Banks
• IDEF1X
• DBDebunk
• DMoz
• Modelo Entrez de Database