Modelagem de Dados 7 - Transformação entre Modelos, parte 2, por Mauri Gonçalves

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 nao é melhor fundir as 2 tabelas em uma unica.
- 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çoes/especializações é tem alguns aspectos particulares que devemos analisar.
Primeiramente vamos supor uma entidade com especializações:

Entidade: Pessoa
Atributos: Codigo, Nome, Endereço e Telefone

Entidade: Pessoa Fisica
Atributos: Todos os atributos de Pessoa, CPF, RG

Entidade: Pessoa Jurífica
Atributos: Todos os atributois de Pessoa, CNPJ, IE, Razao 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 unica tabela para todas as especializações e incluir um campo diferenciador: Seria juntar todos os tipos de Pessoa, em uma unica tabela e acrescentar mais um campo para identificar a Pessoa. Exemplo:

Tabela	Campos
Pessoa	Codigo, TipoDePessoa, Nome, Endereço, Telefone, CPF, RG, CNPJ, IE, RazaoSocial

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

Tabela	Campos
Pessoa	Codigo, Nome, Endereço, Telefone
Pessoa_Fisica	CodPessoa, CPF, RG
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 haverao 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, porem 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. Porem as chaves primárias de Pessoa, são repetidas nas tabelas especializadas e quando houverem 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 esta sendo construido e dos recursos disponiveis 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.

Concluida as etapas de tradução entre modelos, temos o banco de dados formado, com suas tabelas, campos e relacionamentos.
No proximo artigo falarei sobre como refinar o seu modelo relacional e tambem falarei 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 conteudo especifico sobre cada etapa que descrevi nessa série.
- Se voce me enviou e-mails e não obteve resposta, peço a gentileza de reenviar. Faço questão de responder á todas as mensagens, apesar do pouco tempo hábil.

Até a próxima ! :)