Caros colegas. Estive ausente da coluna nesses 3 meses por motivos profissionais, mas aqui estou, e darei continuidade à série sobre Modelagem.

No artigo anterior vimos como traduzir os relacionamentos. Para concluir essa etapa, vamos às recomendações:

• Tradução de relacionamentos é orientada sempre pela cardinalidade mínima.
• Se houverem relacionamentos 1:1, verifique se não é melhor fundir as 2 tabelas em uma única.
• A chave primária é colocada sempre na tabela que corresponde ao lado N do relacionamento 1:N.
• Relacionamentos N:N sempre geram uma terceira, com as chaves primárias das 2 tabelas originais.
• Se necessário, escreva o esquema relacional do seu banco de dados, antes de gerar suas tabelas.

A tradução de generalizações/especializações tem alguns aspectos particulares que devemos analisar.

Entidade: Pessoa - Atributos: Código, Nome, Endereço e Telefone

Entidade: Pessoa Jurífica - Atributos: Todos os atributos de Pessoa, CNPJ, IE, Razão Social

As entidades Pessoa Física e Jurídica são especializações da entidade Pessoa. Como representar isso no banco de dados?

Bem, nesse caso temos 2 alternativas:

1) Criar uma única tabela para todas as especializações e incluir um campo diferenciador: Seria juntar todos os tipos de Pessoa, em uma única tabela e acrescentar mais um campo para identificar a Pessoa. Exemplo:

Pessoa: Código, TipoDePessoa, Nome, Endereço, Telefone, CPF, RG, CNPJ, IE, RazaoSocial

2) Criar uma tabela para cada especialização e definir mais um campo identificador

Pessoa: Código, Nome, Endereço, Telefone

Pessoa_Juridica: CodPessoa, CNPJ, IE, RazaoSocial

A vantagem da primeira alternativa é que não precisaremos fazer junções da tabela generalizada (Pessoa) com a tabela especializada (Pessoa Física ou Jurídica) quando precisarmos de informações específicas. Outra vantagem é que a chave primária da tabela Pessoa fica armazenada somente 1 vez no banco de dados. A desvantagem é que, ao fazermos uma consulta no banco de dados, a linha inteira (todos os campos) são carregados na memória, mas sabemos que haverão campos em branco, dependendo do tipo de Pessoa cadastrada.

Na segunda alternativa, há a necessidade de fazer junções quando formos obter todas as informações de uma Pessoa. Porém, a vantagem é que teremos somente os dados necessários sem a necessidade de carregar todos os campos na memória, gerando mais acessos ao banco de dados. As chaves primárias de Pessoa são repetidas nas tabelas especializadas e, quando houver atualização das informações de uma pessoa, haverá a necessidade de criar uma instrução para cada tabela especializada.

A escolha de um dos tipos de tradução para generalizações/especializações irá depender do projeto que está sendo construído e dos recursos disponíveis para quem está modelando. Nada impede que as duas alternativas sejam usadas no mesmo projeto de banco de dados, uma alternativa pra cada caso de tabelas generalizadas.

Concluídas as etapas de tradução entre modelos, temos o banco de dados formado, com suas tabelas, campos e relacionamentos.

No próximo artigo falarei sobre como refinar o seu modelo relacional e também sobre a Normalização do seu banco de dados.

Observações:

Nesta série de artigos, eu faço uma análise de alto nível sobre a Modelagem de Dados sem aprofundar-me nos processos de modelagem. Se for do seu interesse, vale a pena pesquisar o conteúdo específico sobre cada etapa que descrevi nessa série.

Se você me enviou e-mails e não obteve resposta, peço a gentileza de reenviar. Faço questão de responder a todas as mensagens, apesar do pouco tempo hábil.

Até a próxima!