Artigo SQL Magazine 5 - Projeto de Banco de Dados

Parte IV: Modelo Físico

Durante as edições anteriores você aprendeu a construir um modelo lógico (MER), através dos requisitos apurados na análise com o cliente. Vimos a importância de iniciar um projeto de banco de dados com este modelo, nos abstraindo de questões tecnológicas e com a atenção voltada exclusivamente ao domínio do problema.

Neste artigo iniciaremos o modelo físico, que é a transformação do modelo lógico em um formato que possa ser materializado em um banco de dados relacional. Ele apresenta uma preocupação de mais baixo nível, ou seja, a partir de agora são analisadas questões relacionadas à performance, ambiente físico, limitações do modelo relacional, entre outras, sem perder o foco na manutenção da integridade das regras de negócio. Algumas literaturas denominam essa transformação de mapeamento E/R - relacional.

O modelo físico pode ser utilizado como documentação do banco de dados, sendo o ideal criá-lo antes de iniciar a implementação, assunto que veremos nas próximas edições. No entanto, alguns profissionais pulam essa parte, ou realizam o modelo e a implementação em paralelo. O primeiro caso não é recomendável, pois o modelo físico pode revelar problemas na análise e apresenta uma boa oportunidade para corrigir erros antes da implementação, o que acaba sempre saindo mais barato. O segundo caso pode ser viável se uma situação semelhante já tiver sido modelada em outro projeto e um mesmo profissional fique responsável pelas duas atividades, evitando inconsistências entre o banco de dados e a documentação. Como em todo projeto, é importante que as alterações futuras no banco de dados sejam refletidas na documentação, para evitar sua obsolescência.

Veremos a seguir alguns passos para transformação do modelo lógico em físico. Ao construir vários projetos você ganha experiência e percebe que algumas etapas podem ser omitidas, otimizando o tempo de modelagem.

Iniciando o Modelo Físico

A partir de agora alguns elementos mudam de nome, no entanto, o conceito permanece o mesmo: entidades e atributos serão chamados de tabelas e campos, respectivamente. As tabelas vão identificar as entidades e alguns relacionamentos. O atributo identificador se torna chave primária da tabela. Conceitos como agregação, especialização e generalização não são suportados pelo modelo relacional e não existem no modelo físico.

O primeiro passo é a padronização na descrição dos elementos. O modelo lógico apresenta alguns atributos (como Preço Aluguel e Valor Multa) e entidades (como Pessoa Física e Pessoa Jurídica) cujos nomes possuem “espaço” em sua composição. Alguns bancos de dados relacionais possuem regras para nomeação de objetos, como o não uso de espaços e acentuação. Por esta limitação, deve haver uma convenção para nomes - no modelo, os espaços foram substituídos por “_” e os acentos foram eliminados (figura 1).

Chave Primárias

Por padrão, os atributos identificadores são mapeados como chaves primárias, como podemos ver nas tabelas Livro, Cliente e Nota Fiscal. No entanto, por questões de performance, isso nem sempre vai ocorrer. Por exemplo, as entidades Editora e Assunto receberam um novo campo, chamado Codigo, para representar a chave primária, substituindo os atributos identificadores Nome e Assunto. Na próxima edição veremos maiores considerações sobre a definição de chaves. Veja o modelo atualizado na figura 2.

Chaves Estrangeiras

Existem alguns elementos que são característicos do modelo físico. Um deles é a chave estrangeira (foreign key), recurso utilizado para ligar tabelas em um relacionamento. A idéia é criar um campo na tabela filho que recebe o conteúdo da chave primária da tabela pai, garantindo um valor comum nas duas tabelas e possibilitando ao banco de dados realizar o relacionamento. Por exemplo, na relação entre Editora (pai) e Livro (filho), este último receberá um novo campo, Cod_Editora, que será chave estrangeira. O mesmo acontece no relacionamento com Assunto, onde a tabela Livro receberá o campo Cod_Assunto (figura 2). Para entender na prática, observe o conteúdo da tabela Editora abaixo:

Para relacionar um livro com uma determinada editora, utilizamos a chave estrangeira conforme a tabela Livro abaixo:

Relacionamentos

Em todo relacionamento 1:N, a chave primária do lado 1 é exportada para o lado N, gerando uma chave estrangeira na tabela filho. Como vimos, a tabela Livro ganhou duas chaves estrangeiras: Cod_Editora e Cod_Assunto. A tabela Item_Nota_Fiscal possui um relacionamento 1:N com Livro e recebe a chave estrangeira ISBN_Livro.

Em relacionamentos 1:1 escolhe-se uma das tabelas para exportar a chave primária. O ideal é selecionar a tabela que possui menos campos na chave, causando assim maior performance na junção dos elementos. Por exemplo, no relacionamento entre Compra e Nota Fiscal, a primeira receberá o campo Numero_Nota_Fiscal como chave estrangeira. Se fosse o contrário, Nota_Fiscal receberia três novos campos, correspondentes a chave primária de Compra, composta por Cod_Cliente, ISBN_Livro e Dt_Hora.

Outra regra diz respeito à relações N:N. Nesse caso, cria-se uma tabela correspondente ao relacionamento e transpõe-se para ela as chaves primárias das entidades envolvidas. No modelo, os relacionamentos RESERVA, ALUGA e COMPRA serão transformados em três novas tabelas. Na figura 2 observa-se que essas tabelas herdaram as chaves primárias de Cliente e Livro. Vemos também que cada chave primária possui o atributo Data_Hora, existente inicialmente como identificador do relacionamento que deu origem às tabelas em questão.

No entanto, a criação da tabela Compra gera um obstáculo. Lembre-se que no modelo físico estamos no domínio da aplicação e começamos a encontrar problemas inerentes ao modelo relacional para armazenamento dos dados. Observe que a tabela Compra, neste momento, precisa guardar cada item comprado em um registro, sendo necessário vários registros para representar uma compra contendo vários livros. Dessa forma, se torna impossível manter o relacionamento 1:1 modelado logicamente com a entidade Nota Fiscal. Para resolver um obstáculo do mundo físico, esse relacionamento será convertido para 1:N, onde uma nota fiscal será representada por uma ou várias ocorrências da tabela Compra. No entanto, essa ainda não é a solução final - quando estudarmos a Normalização, veremos novas técnicas que transformarão ainda mais as características destas tabelas.

Especialização/Generalização

Como vimos na parte II, quando modelamos uma especialização são criadas novas entidades. Contudo, essas entidades podem ou não dar origem a tabelas no modelo físico. Por exemplo, observe que as entidades Pessoa Fisica e Pessoa Jurídica, especializações de Cliente, possuem comportamentos particulares: uma pessoa física contém um auto relacionamento, pois existem titulares e dependentes. Uma pessoa jurídica pode ser uma universidade, um centro educacional ou um curso. Além disso, elas possuem atributos próprios, característicos da regra de negócio.

Por terem comportamento e atributos diferentes, as entidades Pessoa Fisica e Pessoa Juridica se tornarão tabelas no modelo físico.

Como um banco de dados relacional não possui o conceito de especialização, uma tabela não pode herdar atributos, características ou comportamentos de outra tabela (que neste caso seria a tabela Cliente). Podemos então modelar de duas formas:

1. A tabela Cliente (generalização) deixa de existir e todos os seus atributos são repetidos nas tabelas Pessoa_Fisica e Pessoa_Juridica.
2. A tabela Cliente continua a existir, possuindo dois relacionamentos 1:1: um com a tabela Pessoa_Fisica e outro com a tabela Pessoa_Juridica. Essa solução é bastante utilizada pelos analistas, desenvolvedores e administradores de banco de dados

Seguiremos a segunda opção. Observe na figura 3 como ficou modelada a especialização da tabela Cliente.

Na especialização da entidade Pessoa Jurídica podemos observar que as subentidades Universidade, Centro Educacional e Curso existem apenas para representar tipos de cliente da livraria. Elas não possuem atributos, características ou comportamentos diferentes entre si, não fazendo sentido se tornarem tabelas. Criaremos então um novo campo (Tp_Pessoa_Juridica) na tabela Pessoa_Juridica, para indicar seu tipo (figura 3).

E se criássemos uma tabela auxiliar para os tipos de pessoa jurídica? Observe que o tipo de especialização desta entidade é total e exclusiva. Como foi mostrado na parte II do artigo, o tipo total significa que todas as possíveis subentidades estão modeladas, ou seja, não existe outro tipo de pessoa jurídica no negócio da livraria. Nesse caso não há a necessidade de criarmos uma tabela somente para conter três registros. Se o tipo de especialização não fosse total, outros tipos de pessoas jurídicas poderiam existir e neste caso a melhor solução seria criar a tabela auxiliar.

Observações sobre especialização:

• Podemos notar que os relacionamentos entre a tabela Cliente e as tabelas Pessoa_Fisica e Pessoa_Juridica não possuem nome, pois não foi encontrado um que expressasse uma idéia clara sobre a relação (figura 3). Na parte I vimos que a descrição é importante para a legibilidade do modelo, mas não é obrigatória.
• A cardinalidade do campo CNPJ mudou para 1:1, indicando sua obrigatoriedade na tabela Pessoa_Jurídica. No modelo lógico a cardinalidade era 0:1, pois as tabelas eram especializações e o cliente poderia ser físico ou jurídico.
• O campo Nome foi inserido na tabela Cliente, com o intuito de armazenar tanto o nome de pessoas físicas quanto a razão social. Isso foi feito em função da performance, pois uma consulta não precisará unir várias tabelas para recuperar o nome ou a razão social do cliente. Lembre-se que em telas de busca esse campo é muito utilizado.
• Na especialização de Livro, as subentidades Nacional e Importado apenas indicam a origem do livro. Assim como em Pessoa_Jurídica, um campo substituirá a especialização. Na verdade, esse campo já existe desde o modelo lógico e foi apenas renomeado para Fg_Importado (figura 2).

Agregação

A agregação não existe no modelo físico. Como vimos na edição anterior, só existe agregação para relacionamentos com cardinalidade N:N, os quais se tornaram tabelas no modelo físico. Sendo assim, não é mais necessário existir a agregação para que haja um relacionamento entre Compra e Nota_Fiscal (figura 4).

A agregação indica que para existir o relacionamento entre as entidades Nota Fiscal e Compra é necessário que haja no mínimo uma compra efetuada. No modelo físico deve-se manter essa regra.

Entidades Fracas

Foi visto que as entidades fracas dependem das entidades fortes para existir. No modelo físico, a chave primária de uma tabela fraca contém sempre uma cópia da chave primária da tabela forte. Por exemplo, a tabela Item_Nota_Fiscal será identificada pelos campos Numero_Nota_Fiscal, que é chave primária da tabela Nota_Fiscal, e Código, que individualiza cada item da nota (figura 4). Observe que esse conceito é diferente de chave estrangeira, que não faz parte da chave primária da tabela filho. Além disso, um item de nota precisa de um número de nota para fazer sentido, o que não acontece com chaves estrangeiras.

Observe na figura 4 que a tabela Item_Nota_Fiscal e seu relacionamento com Nota_Fiscal possuem a mesma representação visual do modelo lógico, indicando que ela é uma tabela fraca. Isso significa que alguns recursos visuais do modelo lógico podem ser reutilizados para deixar o modelo físico mais legível.

Restrição de Integridade / Regra de Derivação

Observe nas figuras 1 à 4 que algumas restrições de integridade (RIs) foram retiradas. O motivo é que os relacionamentos que possuem RIs no modelo lógico foram transformados em tabelas. Logo, como uma RI não é representada ao lado de uma tabela, somente as restrições referentes aos atributos permaneceram no modelo. Vale lembrar que todas as RIs, representadas graficamente ou não, devem ser especificadas no dicionário de dados. Veja o modelo atualizado na figura 5.

Normalmente, no mapeamento das regras de derivação (RDs), os campos calculados são eliminados do modelo físico e passam a constar somente no dicionário de dados. Em alguns casos, por motivos de performance, esse campo é criado fisicamente na tabela. Essa é a análise principal sobre um campo calculado: se ele será ou não transformado em um campo físico.

No modelo, somente o atributo Total do relacionamento Compra possui RD. Já que esse campo apenas mostra o total de uma determinada compra e não tem grande utilização, vamos deixá-lo como calculado e retirá-lo do diagrama.

Auto relacionamento

Em todo auto relacionamento, a tabela receberá um novo campo como chave estrangeira, o qual terá um relacionamento com a chave primária da própria tabela. Na figura 6, a tabela Pessoa_Fisica tem um novo campo chamado Cod_Cliente_Titular. Quando esse campo for nulo, o cliente será titular; quando estiver preenchido, o cliente será um dependente. Nesse caso, o campo receberá o valor de algum outro registro da próprio tabela.

Outras convenções para o modelo físico

Note que as convenções utilizadas neste artigo não são únicas. Existem diversos padrões para a elaboração de modelos físicos, como os três tipos abaixo:

Modelo Físico sem campos – É utilizado por programadores que desejam representar somente os relacionamentos entre as tabelas. Uma vantagem é que há uma economia de espaço na visualização de modelos extensos.

Modelo Físico com campos sem seus tipos – É o nosso caso. Geralmente utilizado quando estamos iniciando a construção do modelo físico, esse modelo deixa a definição de tipos para a fase de implementação.

Modelo Físico com campos e seus tipos – É o modo mais completo de visualização, visto que ficam explícitos os tipos de dados a serem utilizados, os campos e os relacionamentos entre as tabelas.

Conclusão

É importante ter em mente que não existe o melhor modelo ou a melhor implementação para um banco de dados. Muitas soluções podem ser levantadas para um mesmo problema e todas podem estar corretas sob diferentes pontos de vista. Assegure-se de, antes de iniciar a implementação, questionar o modelo mais de uma vez, identificando a maior quantidade de cenários possíveis. Se a equipe chegou até o final do modelo físico e ainda não detectou nenhum erro, é muito provável que o problema do cliente não tenha sido analisado corretamente.

Na próxima edição daremos continuidade ao modelo físico, discutindo a normalização e considerações sobre performance. Até lá.

Referencias

Vinicius Lourenço de Sousa é analista de sistemas e desenvolvedor Delphi/Java em projetos Web e Off-Line, utilizando os bancos de dados Interbase, Oracle 9i e DB2/AS400, na DBA Engenharia de Sistemas. É Pós-Graduado em Análise, Projetos e Gerência de Sistemas pela PUC-RJ e possui certificação BrainBench em Delphi e RDBMS.