SQL Server 2008 – Parte 9 – Conceitos de MER e DER, Regras e Tipos de Relacionamentos

Olá pessoal, neste artigo veremos os conceitos do MER e do DER, as regras e seus tipos de relacionamentos. Acompanhem:

Percebeu que mudei o título do artigo para SQL Server 2008? É que (como há de se imaginar) mudei de versão de SQL! Lembrando que os conceitos e exemplos serão os mesmos, já que de uma versão para outra, não temos muitas diferenças.

MER – O MER (Modelo Entidade-Relacionamento) tem seu conceito baseado na teoria relacional de Codd. Resumindo, este conceito diz que a expressão da realidade se baseia no relacionamento existente entre as entidades, uma vez que essa realidade é dirigida pelos fatos determinados por tais relacionamentos.

Este conceito, que está relacionado principalmente aos bancos de dados, permite representar os tipos de relacionamentos existentes entre os dados de um sistema.

A evolução do modelo MER foi fundamentada em mecanismos de abstração, cujo conceito permite determinar quais partes da realidade são importantes para que o sistema de informações seja construído. Além disso, por meio do conceito de abstração também podemos determinar quais aspectos referentes à modelagem são importantes para modelarmos o ambiente.

Alguns dos mecanismos de abstração no qual se baseia a evolução do MER são agregação, classificação e generalização.

Após esses conceitos, podemos dizer que o objetivo principal do MER é definir um modelo de alto nível independente de implementação, tendo o modelo representado graficamente por um Diagrama de Entidade-Relacionamento, conhecido como DER.

DER – Como dito anteriormente, o DER nada mais é que a representação gráfica do modelo MER. Em termos conceituais podemos dizer que o DER é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é usado para representar o modelo conceitual do negócio. Abaixo temos um exemplo de um DER simples, que fiz abstraindo a idéia do artigo que vi na revista SQL Magazine, da Devmedia:

O DER da imagem acima foi feito no Visio 2007, mais iremos fazer um DER no SQL Server 2008 (lembrando que nada os impedem de usar outras versões do SQL).

Então abra sua versão do SQL Server e crie duas tabelas bem simples, como a imagem abaixo ilustra:

Adicione uma constraint Primary Key na tabela Vendas e uma constraint Foreign Key na tabela Pedidos, interligando assim as duas tabelas (veremos mais sobre relacionamentos daqui a pouco):

Lembrando que ao final do artigo será disponibilizado o script para download.

Pronto, temos nosso relacionamento! Agora vá ao Object Explorer, expanda a aba Databases, expanda a tabela Produtos, ao expandir a aba Database Diagrams você receberá uma mensagem apenas informando que seu database não contém objetos suportados para criar o DER e perguntando se você deseja cria-los, clique em Yes e aguarde:

Agora clique com o botão direito no Database Diagrams e clique em New Database Diagram. Irá aparecer uma janela para você adicionar as tabelas ao diagrama como a imagem abaixo ilustra:

Selecione as tabelas, clique em Add, em Close e veja o resultado:

Para exibir as tabelas como na imagem acima, é só clicar com o botão direito em cada uma, clicar em Table View e em Standard. Perceba que temos diversas opções de visualização das tabelas.

Assim temos nosso exemplo de DER.

Regras e Tipos de Relacionamentos – Os relacionamentos são responsáveis por definir uma ligação entre dois objetos pertencentes ao mundo real. Quando trabalhamos com aplicações construídas e administradas por um SGBD (Sistema Gerenciador de Banco de Dados), o relacionamento é o responsável por unir duas ou mais tabelas de banco de dados.

Importante citar que o grau de relacionamento entre duas entidades é determinado pela quantidade de ocorrências de uma entidade que está relacionada à outra. O grau de relacionamento entre entidades também é chamado de cardinalidade.

Obs: Abaixo são apresentados dois tipos de relacionamentos e no próximo artigo será apresentado mais um tipo e serão vistos exemplos práticos com os três tipos.

Tipos de Relacionamentos:

1:1 – No relacionamento 1:1 (um-para-um), cada um dos elementos de uma determinada entidade possui relacionamento com apenas um dos elementos de outra entidade.

1:N – No relacionamento 1:N (um-para-muitos), vamos imaginar duas entidades, as quais serão chamadas A e B. Neste relacionamento cada elemento da entidade A pode ter um relacionamento com vários elementos da entidade B. Entretanto, cada um dos elementos da entidade B pode estar relacionado a apenas um elemento da entidade A. No geral, este é tipo de relacionamento mais comum e mais usado pelas aplicações.

Regras de Relacionamento 1:N – Para que seja estabelecido um relacionamento de 1:N (um-para-muitos), temos que contar com duas tabelas, onde a primeira (1) obrigatoriamente terá uma coluna que use uma Primary Key (Chave Primária). Já na tabela que representa o relacionamento para muitos (N), deverá haver uma coluna referente à primeira tabela, a qual deve utilizar a Foreign Key (Chave Estrangeira) para que, assim, seja estabelecido o relacionamento entre ambas as tabelas.

Apenas salientando: diferente da Primary Key, colunas que usam a Foreign Key aceitam a inserção de valores repetidos.

N:N – O relacionamento N:N (muitos-para-muitos) possui uma característica diferente dos outros. Neste caso, os dados estão diretamente relacionados ao fato, e não as entidades, como observamos nos outros tipos de relacionamentos vistos anteriormente.

Importante destacar que podem não haver associação de fatos nas situações em que os relacionamentos são de caráter condicional. Neste caso, a cardinalidade deve ser determinada por meio de uma ampla análise quanto à possibilidade de ocorrerem relacionamentos.

Regras de Relacionamento N:N – Para estabelecer este tipo de relacionamento, devemos ter três tabelas, sendo que a terceira é responsável por relacionar as outras duas. Para isso, é preciso que essas duas primeiras tabelas contenham uma coluna que seja chave primária.

As colunas que são chaves primárias na primeira e na segunda tabela devem ser colunas com chave estrangeira na terceira. Assim, esta tabela terá duas chaves estrangeiras, as quais formam uma chave primária composta.

Vimos os tipos de relacionamentos existentes, vamos fazer agora os exemplos práticos com eles.

1:1 Lembrando que neste relacionamento, cada um dos elementos de uma entidade só pode se relacionar com apenas um elemento de outra entidade. Então, consideremos as tabelas Clientes e Documentos, em que cada um dos clientes pode ter apenas um documento (considerando que nesta tabela um mesmo cliente não pode ter mais de um documento), assim como cada um dos documentos só pode pertencer a apenas um cliente.

Confira nas imagens abaixo a criação das tabelas, das constraints e inserção de alguns registros:

Perceba que na tabela Documentos criei uma Foreign Key (chave estrangeira) se relacionando com a Primary Key da tabela Clientes. Veja como ficarão as tabelas:

Assim temos o relacionamento de um-para-um.

1:N – Como dito no artigo anterior, neste relacionamento, que é um dos mais comuns hoje em dia, cada elemento da entidade “A” pode ter um relacionamento com vários elementos da entidade “B”. Em contrapartida, cada um dos elementos da entidade B pode estar relacionado a apenas um elemento da A. Dito isto, consideremos a tabela Clientes já criada e agora vamos criar a tabela Telefones, já que neste caso cada cliente pode ter vários telefones, mais cada telefone pode pertencer a um, e somente um cliente.

Confira nas imagens a seguir a criação da tabela Telefones, com suas constraints, a inserção de alguns registros e o resultado da consulta a ela:

Assim temos o relacionamento de um-para-muitos.

N:N – Relembrando, neste relacionamento, que é diferente dos outros, os dados estão diretamente relacionados ao fato, e não às entidades, como os outros dois anteriores. Seguindo as regras deste tipo de relacionamento, temos que, obrigatoriamente, criar três tabelas, já que a terceira tem a responsabilidade crucial de fazer o relacionamento entre as outras duas.

Para uma melhor compreensão, vamos usar novamente a tabela Clientes e a tabela Pedidos, criada no artigo anterior. Com elas, temos a seguinte situação: um cliente pode fazer diversos pedidos, ao passo que um pedido pode ser feito por diversos clientes.

Como já temos as tabelas criadas, vamos apenas criar a terceira tabela, denominada ClientesXPedidos, responsável por interliga-las. Veja as imagens a seguir de sua criação, inserção de registros (note que ela conterá apenas as chaves das duas outras tabelas) e posterior consulta:

Perceba na imagem acima que os mesmos campos, IdCliente e IdPedido, são chaves primárias e também são chaves estrangeiras, criando assim o relacionamento entre as tabelas Cliente e Pedido.

Assim temos o relacionamento de muitos-para-muitos. Difícil? Não né.

Disponibilizo o script para download do DER  e o script comentado com os exemplos práticos dos tipos de relacionamentos existentes, clicando aqui.

Na próxima parte de nosso minicurso de SQL Server (agora 2008 :P) veremos as associação entre tabelas, por meio das cláusulas JOIN, como INNER JOIN, LEFT JOIN, RIGHT JOIN, entre outras, aguardem!

Assim finalizo o artigo. Muito obrigado a todos!

Um abraço, e até o próximo artigo.

Wellington Balbo de Camargo

wellingtonbalbo@gmail.com

14 comentários em “SQL Server 2008 – Parte 9 – Conceitos de MER e DER, Regras e Tipos de Relacionamentos

  1. Qual a diferenca nos diagramas MER e DER?
    Ja ouvi que o MER é mais abastrato e livre de BD, alem de permitir n:n. O DER pode ser mais “amarrado” ao bd e o q era n:n se torna tabela, vida normalizacao.
    Qual o certo, poderia complementar com exemplos dos dois?

    Curtir

  2. Cara vc está de parabéns por suas aulas, só gostaria de tirar uma duvida, no exemplo de cardinalidade 1:1 um cliente está aceitando vários documentos, isso não está errado? Já agradecendo, valew!

    Curtir

Expresse sua opinião!

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s