Saltar para o conteúdo

Modelo relacional

Origem: Wikipédia, a enciclopédia livre.

Omodelo relacionalé ummodelo de dadosrepresentativo (ou de implementação), adequado a ser o modelo subjacente de umSistema Gerenciador de Banco de Dados(SGBD), que se baseia no princípio de que todos os dados estão armazenados emtabelas(ou,matematicamentefalando,relações). Toda sua definição é teórica e baseada nalógica de predicadose nateoria dos conjuntos.

O conceito foi criado porEdgar Frank Coddem1970,sendo descrito no artigo "Relational Model of Data for Large Shared Data Banks". Na verdade, omodelo relacionalfoi 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 redeouCodasylemodelo de listas invertidas).

O modelo relacional para gerência de bases de dados (SGBD) é um modelo de dados baseado emlógicae nateoria 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 domodelo hierárquicoe domodelo em rede.Estas arquiteturas antigas são até hoje utilizadas em algunsdata centerscom alto volume de dados, onde a migração é inviabilizada pelo custo que ela demandaria; existem ainda os novos modelos baseados emorientaçã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 porChris DateeHugh Darwencomo um modelo geral de dados. NoTerceiro 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 linguagempadrãopara os bancos de dados relacionais,SQL,é apenas vagamente remanescente domodelo matemático.Atualmente ela é adotada, apesar de suas restrições, porque ela é antiga e muito mais popular que qualquer outralinguagem de banco de dados.

A principal proposição do modelo relacional é que todos osdadossão representados como relações matemáticas, isto é, umsubconjuntodoproduto Cartesianodenconjuntos.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 valornulo); isto significa que existem dois possíveis valores para umaproposição:verdadeira ou falsa. Os dados são tratados pelo cálculo relacional ouálgebra relacional.

O modelo relacional permite aoprojetistacriar um modelo lógico consistente dainformaçãoa ser armazenada. Este modelo lógico pode ser refinado através de um processo denormalização.Umbanco de dadosconstruído puramente baseado no modelo relacional estará inteiramente normalizado. Oplano de acesso,outras implementações e detalhes de operação são tratados pelo sistemaDBMS,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 odomínio,outipo de dado.Umatuplaé um conjunto deatributosque 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. Umarelaçã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 detabelae uma tupla é similar ao conceito delinha.

O princípio básico do modelo relacional é o princípio da informação: toda informação é representada porvaloresem relações (relvars). Assim, as relvars não são relacionadas umas às outras no momento do projeto. Entretanto, os projetistas utilizam o mesmodomínioem vários relvars, e se um atributo é dependente de outro, esta dependência é garantida através daintegridade referencial.

Banco de dados exemplo

[editar|editar código-fonte]

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)

Nesteprojetonó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ãochaves candidatas.Os itens sublinhados sem negrito são aschaves estrangeiras.

Normalmente umachave candidataé escolhida arbitrariamente para ser chamada dechave primáriae utilizada com preferência sobre as outras chaves candidatas, que são então chamadas de chaves alternativas.

Umachave primáriaé um identificador único que garante que nenhumatuplaserá duplicada; isto faz com que orelacionamentoem algo denominado ummulticonjunto,porque viola a definição básica de umconjunto.Umachavepode 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

[editar|editar código-fonte]
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 tentarmosinserirum novo cliente com o ID1234567890,isto irá violar o projeto da relvar poisID Clienteé umachave primáriae nós já temos um cliente com o número1234567890.ODBMSdeve rejeitar umatransaçãocomo esta e deve acusar um erro de violação da integridade.

Aschaves estrangeirassão condições de integridade que garantem que o valor de um atributo é obtido de umachave candidatade outrarelvar,por exemplo na relvar Pedido o atributoID Clienteé uma chave estrangeira. Umauniã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 podemosconsultarno 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 cliente1234567890,podemos consultar o banco de dados de forma que este retorne toda linha na tabela de Pedidos comID Clienteigual a1234567890e agrupar a tabela de pedidos com a tabela de itens de pedido baseado noNú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 nomundo 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 relacionamentovários-para-váriosentre 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 relacionamentoum-para-váriospara 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 cujoNúmero do pedidoé igual aoNúmero do pedidona tabela Pedido Nota, e onde oNúmero da notana tabela Pedido Nota é igual àNúmero da notana tabela Notas.

Anormalização de banco de dadosé normalmente realizada quando projeta-se umbanco de dados relacional,para melhorar aconsistêncialógica do projeto do banco de dados e o desempenho transacional.

Existem dois sistemas mais comuns dediagramaçãoque ajudam na representação visual do modelo relacional: O diagrama de entidade-relacionamentoDER,e o diagrama correlatoIDEFutilizado no método IDEF1X criado pelaForça Aérea dos Estados Unidosbaseado no DER.

  • 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

[editar|editar código-fonte]