Antes de modelar um banco de dados é necessário compreender como funcionam os modelos entidade / relacionamento. Este modelo fornece em forma de diagrama uma maneira de visualizar relações entre entidades e as relações ente seus atributos.

Entidades: Entidades representam todos objetos do mundo real como Cliente, Fornecedor, Aluno, Professor, Veículo, Imóvel, Mercadoria.

E como todo item do mundo real cada um destes objetos possuem características próprias que os qualificam e diferenciam, estas características são seus atributos.

Atributos são características de itens do mundo real como, cor, tamanho, idade, cpf, chassi, religião, nacionalidade, país de origem, naturalidade, escolaridade, etc

Como os objetos do mundo real estabelecem relações entre si, estas relações precisam ser identificadas e qualificadas, pois nem toda relação se dá de igual forma. Por exemplo, a relação pessoa/CPF é uma relação única (uma pessoa só pode ter um CPF) já a relação pai/filho pode ser diferente (uma pessoa pode ter, nenhum, um ou muitos filhos).

Como as relações entre estas entidades são diferenciadas convém qualificá-las, e a esta qualificação em termos de bancos de dados convencionou-se a chamar modelo entidade-relacionamento. Nesse modelo cada entidade possui uma ID única que o identifica como uma entidade única, uma pessoa por exemplo pode ter seu CPF como ID que o identifica de maneira única e exclusiva perante todas as outras pessoas.

Em um banco de dados para cada tipo de entidade, construímos uma tabela, e nesta tabela armazenamos todos os atributos (características) destas entidades. Por exemplo na tabela pessoa podemos ter para cada pessoa os atributos na tabela tais como: CPF, RG, Data de Nascimento, Nome, Mãe, Pai, Altura, Sexo. Suponto que esta pessoa seja o titular de um clube podemos ter uma segunda tabela, que seria a tabela de dependentes dessa pessoa, na tabela dependentes teríamos todos estes dados novamente “CPF, RG, Data de Nascimento, Nome, Mãe, Pai, Altura, Sexo” para esta pessoa, mais um atributo chave que identificaria de quem esta pessoa é dependente, então nesta tabela teríamos mais uma coluna “CPF do titular”.

O modelo seria o seguinte

Tabela Titular

Tabela Dependente

Note que a segunda tabela possui um ultimo atributo originado da primeira tabela, ou seja o CPF do titular que o identifica única e exclusivamente, serve para identificar na tabela dependente de qual titular esta pessoa é dependente, ou seja o campo “CPF Titular” está informando que a pessoa PSC é dependente de A B C, pois o CPF de A B C está no campo CPF Titular de P S C, indicando a relação entre ambos.

Para entender os modos de relacionamentos entre entidades, é preciso entender primeiramente o que está exemplificado acima, ou seja relacionamento entre entidades, é o modo de demonstrar as relações existentes entre entidades (seres e objetos do mundo real) retratados em nosso modelo.

Dito isto vamos aos modelos de relacionamento.

Relacionamento 1:1 ou um para um

Como falamos que cada tabela representa uma entidade, um relacionamento de 1:1 é uma relação entre uma tabela e outra tabela, ou entre uma entidade e outra em que a ocorrência em uma tabela corresponde a uma e só uma ocorrência em outra tabela.

 Por exemplo, uma mulher só pode possuir um esposo. e a um marido. só pode corresponder uma esposa. nesse modelo a chave que identifica uma destas duas entidades deverá ser armazenada como chave estrangeira "FK" na outra tabela, por exemplo, a ID ou CPF da pessoa pode ser armazenada na linha que contém o registro do cônjuge dessa pessoa, apontando que este indivíduo está casado única e exclusivamente à pessoa dona daquela ID ou CPF.

 Relacionamento 1:N ou um para muitos

Nesse modelo de relação para uma ocorrência em uma tabela, podem ocorrer várias ocorrências na outra tabela relacionada, como por exemplo: Um titular de um clube pode possuir vários dependentes {Esposa, Filho 1, Filho 2, ....}, e onde a recíproca é falsa, ou seja, para uma ocorrência na tabela Titular podem haver várias correspondências na tabela dependente, mas para cada ocorrência na tabela dependente, só pode haver uma ocorrência na tabela titular. Em termos práticos, pode-se exemplificar isto da seguinte maneira, um titular pode ter vários dependentes; mas um dependente, será sempre unica e exclusivamente, dependente de um único titular.

No exemplo abaixo demonstramos uma típica relação do tipo um para muitos, onde um funcionário pode pertencer a um único departamento, mas este mesmo departamento pode conter muitos funcionários.

Relacionamento N:N ou muitos para muitos

O famoso modelo de relacionamento da terceira tabela. É um modelo de vários para vários, onde um registro da tabela A pode ter vários relacionamentos com a tabela B, e do mesmo modo um relacionamento da tabela B pode ter vários relacionamentos na tabela A.

Um exemplo seria a relação alunos e disciplinas, um aluno frequenta várias disciplinas e uma disciplina pode conter vários alunos. Então cria-se uma terceira tabela que faz a associação aluno/disciplina.

Esta terceira tabela passa a ter a Chave Primária "PK" de aluno e disciplina em cada linha, ou seja cada linha é uma associação aluno disciplina.

A relação de muitos para muitos, se dá como nas tabelas abaixo, onde a Id de cada aluno é armazenada na segunda coluna na tabela de associação "TERCEIRA TABELA ALUNO / DISCIPLINA" e a ID de cada disciplina na terceira coluna. A terceira tabela se torna uma tabela associativa, onde cada linha corresponde a uma associação de aluno com disciplina, e cada aluno pode estar associado a tantas disciplinas quantas existirem e de igual maneira cada disciplina pode estar associada a tantos alunos quantos existirem.

 Em construção ....

Fonte: Sapo 1, Sapo 2 SQL Magazine