Olá caros leitores! Vamos em frente com a série de artigos sobre Modelagem de Dados. Essa parte da transformação entre modelos é a parte mais interessante da modelagem. Aqui começa “de verdade” a surgir, finalmente, o banco de dados propriamente dito. Em especial a tradução dos relacionamentos (assunto que começo a abordar hoje) é o que deixa mais claro os conceitos vistos na modelagem conceitual, ou modelagem lógica.

Um relacionamento nada mais é do que uma “ligação” entre duas entidades (agora, Tabelas) que juntas criam informações complexas. Como o assunto agora é tabela física do banco de dados, nos temos que construir nossa base de forma “conectada”. Para isso nós usamos as famosas CHAVES. As chaves tem variações e diferentes finalidades. De forma rápida vou explicar um pouco sobre cada tipo de chave:

Chave Primária: A chave primária é o que chamávamos na modelagem lógica de “atributo identificador”. Geralmente é um campo da tabela que armazena uma informação única, que não se repete em nenhum outro registro daquela mesma tabela. Desta forma ele serve como identificador daquele registro.

Chave Composta: A chave composta é formada pela chave primária e por alguma outra informação que também é unica na tabela. Os dois campos juntos, formam uma chave composta. Este tipo de chave é usado com mais frequencia em tabelas provenientes de relacionamentos N:N [vários para vários] (veremos mais á frente).

Chave Estrangeira: Esta chave é um campo em uma tabela que armazena o conteúdo da chave prímária de outra tabela. Chave estrangeira é sinônimo de relacionamento entre tabelas. Se há relacionamento há chave estrangeira.

A primeira coisa que define a forma como voce vai traduzir o relacionamento é a cardinalidade das entidades (assunto abordado no começo da série).

Cardinalidade 1:N (Um-Para-Varios): Indica a adição de um campo na tabela correspondente ao “lado N”. Esse campo será uma chave estrangeira e vai armazenar a chave primária da tabela do “lado 1”. Veja um esquema relacional que exemplifica esse tipo de cardinalidade:

Funcionario (CodFuncionario, NomeFunc)

Ramal (CodRamal, CodFuncionario, NumeroRamal)

CodFuncionario referencia Funcionario

Observe: Segundo a notação de Esquema Relacional, campo sublinhado indica Chave Primária. No esquema relacional da tabela Ramal temos dois campos sublinhados (indicando que os dois forma a chave primática). O campo CodFuncionario no entanto é uma chave estrangeira, porque ele armazena um valor que identifica um registro na tabela Funcionario.

Cardinalidade N:N (Vários-Para-Vários): Este tipo de relacionamento gera uma terceira tabela. Neste caso nenhum dos lados do relacionamento vai armazer chave estrangeira (como no 1:N). O que vai acontecer é que cria-se uma nova tabela, que vai armazenar as chaves de ambos os lados. Veja um esquema relacional que exemplifica esse tipo de cardinalidade:

Funcionario(CodFuncionario, NomeFunc)

Projeto(CodProjeto, TituloProjeto)

Participacao(CodFuncionario,CodProjeto)

CodFuncionario referencia Funcionario

CodProjeto referencia Projeto

Observe: Segundo este esquema relacional, um funcionario pode participar de varios projetos, sendo que em um projeto pode-se ter vários funcionarios. Neste caso cria-se mais uma tabela, que vai juntar as duas chaves do relacionamento. No exemplo, cria-se a tabela “Participacao” que indica o funcionario e qual projeto ele participa.

Cardinalidade 1:1 (Um-Para-Um): Esse tipo de cardinalidade em grande maioria dos casos nao justifica um relacionamento. Mas pode ser implementado por questoes de organização dos dados. Veremos futuramente na parte de Normalização, como resolver relacionamentos 1:1..

No próximo artigo, continuamos a fazer a tradução de relacionamentos . Até breve.