Aulas‎ > ‎

13 - Modelo Relacional

Introdução
 
O modelo relacional foi criado por Edgar F. Codd, nos anos 70 e começou a ser usado com o advento dos bancos de dados relacionais, nos anos 80. A idéia de modelo relacional se baseia no princípio de que as informações em uma base de dados podem ser consideradas como relações matemáticas e que podem ser representadas, de maneira uniforme, através do uso de tabelas onde as linhas representam as ocorrências de uma entidade e as colunas representam os atributos de uma entidade do modelo conceitual.
 
As relações no modelo relacional são conjuntos de dados vistos como tabelas cujas operações são baseadas na álgebra relacional ( projeção, produto cartesiano, seleção, junção, união e subtração ) e que manipulam conjuntos de dados ao invés de um único registro, isto é, cada operação realizada afeta um conjunto de linhas e não apenas uma única linha, ainda que algumas operações possam afetar uma única linha ( conjunto com um único elemento ).

Da mesma forma, a resposta das operações de consulta são sempre na forma de uma tabela. As operações da álgebra relacional são implementadas por linguagens não procedurais de alto nível, sendo a SQL a linguagem padrão para os bancos de dados relacionais e universalmente usada, tendo sido padronizada pelo ANSI ( American National Standard Institute ).
 
Principais Vantagens do Modelo Relacional
 
Entre as principais vantagens do modelo relacional podemos citar:
 
  • Independência total dos dados;
  • Visão múltipla dos dados;
  • Redução acentuada na atividade de desenvolvimento. Particularmente para extração de dados para relatórios e consultas específicas do usuário;
  • Maior segurança no acesso aos dados;
  • Maior agilidade para consulta/atualização;
  • Qualidade dos dados garantida por restrições de integridade ( identidade, referencial e de domínio )

 

 As 12 Regras de Codd
 
Ao definir o modelo relacional, Codd estabeleceu 12 regras para determinação de um banco de dados relacional.

Estas regras são usadas portanto para se verificar a fidelidade de um banco de dados ao modelo relacional.

Na prática são poucos os gerenciadores de banco de dados que atendem a todas as 12 regras.

Na maior parte dos casos são atendidas no máximo 10 regras.
  1. Toda informação num banco de dados relacional é apresentada a nível lógico na forma de tabelas;
  2. Todo dado em um banco de dados relacional tem a garantia de ser logicamente acessível, recorrendo-se a uma combinação do nome da tabela, um valor de chave e o nome da coluna;
  3. Tratamento sistemático de valores nulos; ( ausência de informação )
  4. O dicionário de dados, catálogo, do banco de dados é baseado no modelo relacional;
  5. Há uma uma linguagem não procedural para a definição, manipulação e controle dos dados;
  6. Tratamento das atualizações de visões dos dados;
  7. Tratamento de alto nível para inserção, atualização e eliminação de dados;
  8. Independência física dos dados; ( mudança na memória e no método de acesso, criação de um novo índice, criação de uma nova coluna )
  9. Independência lógica dos dados;  ( mudança no tamanho de uma coluna )
  10. Restrição de Integridade; ( Identidade, Referencial e Domínio )
  11. Independência de Distribuição dos dados;
  12. Não subversão das regras de integridade ou restrições quando se usa uma linguagem hospedeira;
 
O Conceito de Chave no Modelo Relacional

Chaves e Índices
 
Chave - O conceito de chave designa um item de busca, ou seja, um dado que será usado para efetuar uma consulta no banco de dados. É um conceito lógico que só faz sentido para a aplicação e não existe fisicamente no banco de dados.
 
Índice - O conceito de índice está associado a um recurso físico usado para otimizar uma consulta no banco de dados. É um recurso físico, ou seja, um índice é uma estrutura de dados, ( endereços ), que existe fisicamente no banco de dados.
 
Existem diferentes tipos de chave em um modelo relacional. Vamos ver cada um dos tipos de chave abaixo:
 
Chave Primária: A chave primária é usada para identificar univocamente uma linha em uma tabela. A chave primária pode ser composta, ter vários atributos, ou simples, um único atributo. Por exemplo, o atributo CPF pode ser usado como chave primária para a tabela CLIENTES pois identifica um único cliente considerando que não existe mais de um cliente com o mesmo CPF.
 
Chave Secundária: A chave secundária é usada para acessar um conjunto de informações. Pode ser formada por um único atributo ou mais de um atributo que identifica(m) um subconjunto de dados em uma tabela. Normalmente, se cria um índice para uma chave secundária como forma de otimizar a consulta feita por aquela chave ao banco de dados. Por exemplo, podemos ter uma chave secundária formada pelo CEP para a tabela de CLIENTES pois esta chave identifica um subconjunto de clientes que residem em uma rua.
 
Chave Candidata: A chave candidata é formada por um atributo que identifica uma única linha na tabela. Como uma tabela pode possuir mais de um atributo identificador único podemos ter várias chaves candidatas em uma única tabela, sendo que apenas uma das chaves candidatas pode ser escolhida para ser a chave primária da tabela. As demais chaves permanecem como chaves candidatas na tabela. Por exemplo, podemos ter uma chave candidata formada pela coluna NIT ( PISPASEP ) na tabela FUNCIONARIOS que possui como chave primária a coluna MATRICULA. Ambas identificam univocamente um linha na tabela FUNCIONARIOS, porem a chave NIT é candidata e a chave MATRICULA é a chave primária.
 
Chave Estrangeira: A chave estrangeira é formada por atributos que são chave primária em outra tabela, servindo assim para estabelecer relacionamentos entre as tabelas de um banco de dados. Assim, quando dizemos que duas tabelas estão relacionadas através de uma coluna devemos observar que em uma tabela esta coluna será chave primária e na outra tabela ela será uma chave estrangeira que fará a ligação entre as duas tabelas, estabelecendo o relacionamento. Por exemplo, podemos ter na tabela FUNCIONARIOS uma chave estrangeira COD_DEPTO que estabelece um relacionamento entre a tabela FUNCIONARIOS e a tabela DEPTOS, sendo que na tabela DEPTOS a coluna COD_DEPTO é a chave primária.
 
 
Regras de Integridade do Modelo Relacional
 
O modelo relacional possui duas regras de integridade descritas a seguir.
 
Integridade de Identidade -  A chave primária nao pode conter valores nulos. Como toda informação em um banco de dados relacionam precisa ter uma identidade exclusiva, a chave primária deve ser obrigatoriamente preenchida. Alem disso, a chave primária não deve ter valores repetidos em um tabela, de forma a garantir que exista apenas uma linha para cada valor definido para a chave primária.
 
Integridade Referencial - Se uma determinada tabela A possui uma chave estrangeira que estabelece relacionamento com uma tabela B, entao o valor da chave estrangeira da tabela A deve ser igual a um valor de chave primária na tabela B. Esta regra garante que as referencias de uma tabela para outra tabela sejam válidas, de forma que os relacionamentos sejam consistentes e não ocorra inconsistencia nos dados, como haver um funcionário alocado em um departamento que não existe. Assim, para todo valor de uma coluna que é chave estrangeira em uma tabela, deve haver um valor correspondente na coluna que é chave primária da tabela com a qual a chave estrangeira faz referencia.
 
Como nem sempre o relacionamento entre tabelas é obrigatório uma chave estrangeira pode possuir valor nulo.
 
É importante ressaltar que em um modelo relacional estas regras de integridade são garantidas pelo gerenciador de banco de dados de forma automática, sem a necessidade de se tratar estas regras no código da aplicação. Ou seja, o programador não precisa programar validações no sistema para garantir que estas regras sejam atendidas pois o próprio gerenciador de banco de dados cuida disso.

Integridade de Domínio - Restringe o conjunto de valores que podem ser gravados em uma coluna de uma tabela. Desta forma, somente os valores que pertencem ao domínio podem ser gravados na coluna da tabela. Outros valores não são permitidos e a atualização é desfeita pelo gerenciador de banco de dados. O domínio define um conjunto de valores. Quando este domínio é associado a uma coluna de uma tabela, somente os valores definidos para o domínio podem ser gravados na coluna. Este tipo de restrição garante a qualidade de dados na base de dados.
 
 
Características do Modelo Relacional
 
  • Uma tabela deve ser acessível por qualquer coluna, mesmo que não tenha sido definida como chave;
  • O relacionamento entre duas tabelas não existe fisicamente, pois o relacionamento é lógico e representado através de chaves estrangeiras;
  • Uso de linguagens não-procedurais e auto-contidas; ( SQL ) 
  • Um otimizador de consultas para definição do melhor plano de acesso aos dados;

 

Regras para Derivação do Modelo Conceitual para o Modelo Relacional
 
Nesta etapa é feita a transformação das entidades e relacionamentos do modelo E-R para o modelo relacional, no qual os dados são representados por tabelas. Para tanto, foram definidas regras para esta transformação de forma a atender às características do modelo relacional.
 
Estas regras garantem que o modelo relacional estará adequado, alinhado com o modelo conceitual e sem inconsistências. O resultado desta etapa é um diagrama de tabelas, contendo as tabelas, chaves primárias, chaves estrangeiras e restrições de integridade, formando assim o modelo lógico que servirá de base para o projeto físico do Banco de Dados.
 
Mapeamento das Entidades - Toda entidade torna-se uma tabela levando todos os atributos definidos na entidade que tornam-se colunas na tabela criada. O identificador da entidade torna-se a chave primária da tabela que não permitirá repetição de valores e nem valores nulos.
 
Mapeamento de Atributos - Os atributos das entidades e dos relacionamentos devem ser gerados de forma que minimizem o consumo de espaço de armazenamento e torne mais eficiente a consulta de dados. Devem ser consideradas as características do gerenciador de banco de dados que será utilizado para implementar o banco de dados físico. Devem ser escolhidos o tipo de dado e tamanho adequados para cada coluna criada na tabela.
 
Mapeamento de Relacionamentos
- O mapeamento dos relacionamentos implica na transformação de atributos das entidades em colunas nas tabelas e, em casos específicos, implica também na criação de novas tabelas a partir de relacionamentos e entidades associativas. Existem diferentes abordagens dependendo da cardinalidade do relacionamento:
 
  • Relacionamentos que possuem atributos - Estes relacionamentos se tornam tabelas no caso de relacionamentos n:n. No caso de relacionamentos 1:n os atributos do relacionamento são transferidos para a tabela que possui cardinalidade n;

  • Relacionamentos são representados por chaves estrangeiras ( Foreign Key ) – Todo atributo correspondente à chave primária de outra relação, base para a integridade referencial, é definido como uma chave estrangeira );

  • Relacionamento 1 para 1 ( 1:1 ) - Uma das entidades envolvidas no relacionamento carrega o atributo identificador que deve ser definido com chave estrangeira na tabela criada para a entidade fazendo referencia à chave primária da tabela criada para a outra entidade. O Critério para escolher qual tabela receberá a chave estrangeira depende do negócio que está sendo modelado, sendo necessária análise caso a caso. Porém em geral se escolhe a tabela onde faz mais sentido colocar o atributo, entidade mais importante para o negócio.

  • Relacionamento 1 para Muitos ( 1:N ) - A entidade cuja cardinalidade é N recebe o atributo identificador da entidade com cardinalidade 1 que será mapeado como uma chave estrangeira na tabela criada para a entidade com cardinalidade N. Alem disso, recebe os atributos do relacionamento se houve. Caso seja a entidade com cardinalidade N seja uma entidade fraca, então ela recebe o atributo identificador da entidade com cardinalidade 1 que deve ser mapeado de forma a compor a chave primária da tabela criada para a entidade com cardinalidade N, como forma de manter a dependência funcional em relação à entidade com cardinalidade 1.

  • Relacionamento Muitos para Muitos ( M:N ) - Deve ser criada uma tabela que recebe os atributos identificadores das entidades que participam do relacionamento, sendo criada a chave primária composta pelas colunas derivadas dos atributos identificadores. Alem disso, a tabela recebe todos os atributos do relacionamento, se existirem. Este é o único caso em que um relacionamento se torna uma tabela, em todos os demais casos, são criadas chaves estrangeiras nas tabelas a fim de estabelecer os relacionamentos.
 
  • Relacionamentos Múltiplos ( Ternário, Quaternário, etc. )- Deve ser criada uma tabela que recebe tantos atributos identificadores quantas foram as entidades que participam do relacionamento. A chave primária desta tabela é composta por todos os atributos identificadores. É o caso de relacionamentos ternário, quaternários, etc.

  • Relacionamento Auto-relacionamento - Incluir a chave primária da entidade na própria entidade como chave estrangeira, gerando uma estrutura de acesso a partir dessa chave.

Mapeamento de Generalização/Especialização - Deve ser criada uma tabela para a entidade pai e uma tabela para cada entidade filha. Os atributos comuns às entidades filhas devem ser mapeados na tabela criada para a entidade pai. As tabelas criadas para cada entidade filha devem receber o atributo identificador da entidade pai na composição da chave primária e receber também os atributos específicos da entidade filha correspondente. A entidade pai e a entidade filha também podem ser mapeadas para uma única tabela. 
 
Mapeamento de Agregações - normalmente gera uma nova tabela que representa a agregação. Esta tabela normalmente faz relacionamento com uma tabela associativa;
 
ċ
modelo_relacional.brM
(35k)
Fernando Siqueira,
22 de abr de 2014 17:50
Comments