Os artigos dessa edição estão disponíveis somente através do formato HTML.
Simulado Projeto de Banco de Dados - Resposta e comentários
Na edição anterior propus um simulado sobre projeto de banco de dados, onde deveria ser construído um modelo lógico completo para o problema do mini-mundo apresentado e um desafio: os dez primeiros que mandassem o modelo lógico completo e de forma correta teriam seus nomes publicados no artigo.
Citei também que não há apenas uma resposta correta mas sim, que poderia haver várias formas de solução. Outro ponto importante e que deve também ser lembrado foi a seguinte dica: utilizar o bom senso para não inventar soluções mirabolantes para problemas que possam ser resolvidos de forma simples e se ater aos requisitos para não modelar o que não foi pedido na descrição do problema. Assim, o ideal é ter ao final da modelagem uma solução de fácil implementação e manutenção. A Figura 1 apresenta o modelo lógico completo.
Figura 1. Modelo Lógico
Comentários
Como você pode observar, a solução proposta utiliza os seguintes recursos do modelo lógico: Entidades fracas e fortes, Relacionamentos, Atributos, Atributos identificadores, Cardinalidades, Restrição de integridade e Atributos de relacionamentos.
Você pode perceber também que a maioria das entidades possui o atributo Codigo como identificador. Isso porque se observarmos na descrição do mini-mundo, veremos que o grupo empresarial já utiliza o campo código na maioria dos seus formulários (que são as entidades no modelo lógico). Nesse caso, como queremos mapear exatamente as regras de negócio do grupo empresarial, podemos colocar o atributo Codigo como atributo identificador.
Agora vamos a uma explicação do modelo lógico da Figura 1. Observando as descrições das entidades na Tabela 1, podemos entender de forma mais clara como os relacionamentos entre as entidades foram definidas no modelo lógico. Percebemos que clientes fazem pedidos de produção para determinados produtos e esses produtos são fabricados por uma ou mais fábricas do grupo empresarial. Vemos também cada pedido de produção é controlado por uma guia de produção para saber o que foi produzido e é relacionado a uma fábrica para indicar qual fábrica é responsável pelo pedido.
|
Cliente |
Responsável por armazenar as informações do cliente. |
|
Pedido Produção |
Responsável por armazenar as informações dos pedidos de produção dos produtos que um determinado cliente faz. |
|
Item Pedido |
Responsável por armazenar as informações dos itens (produtos) dos pedidos de produção. |
|
Produto |
Responsável por armazenar as informações de um determinado produto das fábricas de produção. |
|
Fabrica |
Responsável por armazenar as informações das fábricas do grupo empresarial. |
|
Guia Produção |
Responsável por armazenar as informações das guias de produção para controle dos pedidos de produção. |
|
Item Guia Produção |
Responsável por armazenar as informações dos itens (produtos) das guias de produção. |
Tabela 1. Descrição das Entidades
Todas as cardinalidades foram retiradas do próprio mini-mundo e as entidades que representam os itens são entidades fracas por serem detalhes das entidades fortes (ler série Projeto de Banco de Dados publicado nas edições 2 à 7 da SQL Magazine).
No relacionamento entre as entidades FABRICA e PRODUTO, podemos observar que existe um atributo de relacionamento chamado Produção Diária. Ele representa a produção diária de um determinado produto em uma determinada fábrica. Mas você pode estar pensando, porque não colocar esse atributo na entidade PRODUTO? Porque um mesmo produto pode ser produzido por mais de uma fábrica e ambos terem produções diárias diferentes.
Outro ponto importante que tínhamos que estar atentos é a respeito das restrições de integridade. No final da descrição do mini-mundo, são mencionadas algumas restrições que devem ser consideradas. O importante era colocá-las no lugar certo e identificar se é uma restrição de relacionamento ou de atributo. Ao todo são três restrições de integridade:
· A primeira restrição diz que um item de pedido não pode ter produtos que não são produzidos pela fábrica. Essa restrição é de relacionamento pois está diretamente ligada ao relacionamento entre as entidades ITEM PEDIDO e PRODUTO.
· A segunda restrição diz que os itens da guia de produção não podem ser diferentes dos itens do pedido ao qual a guia pertence. Essa restrição também é de relacionamento, estando ligada diretamente ao relacionamento entre as entidades ITEM GUIA PRODUCAO e PRODUTO.
· A terceira restrição diz que a data de produção não pode ser maior que a data de entrega da guia de produção. Neste caso, percebemos de imediato que se trata de uma restrição de atributo, pois está diretamente ligada ao atributo Data Producao.
Comentários sobre as Respostas dos Leitores
Recebi alguns e-mails contendo a resposta do modelo lógico. No geral, alguns modelos lógicos ficaram bastante parecidos com o modelo que estou apresentando, entretanto, ninguém acertou todo o modelo. Alguns pontos que gostaria de destacar são:
Cardinalidade
Alguns modelos estão com o relacionamento entre as entidades FABRICA e PRODUTO como obrigatório nos dois sentidos. Esse tipo de relacionamento nos diz que quando uma nova fábrica for cadastrada, será obrigatório relacionar pelo menos um produto que a mesma produz. Isso torna o modelo não flexível: não podemos cadastrar uma fábrica que ainda não está operacional, e que ainda não sabemos quais produtos ela irá produzir.
O mesmo problema foi encontrado na modelagem dos relacionamentos entre as entidades CLIENTE e PEDIDO. Como faríamos para cadastrar um potencial cliente, ou seja, aquele que ainda não fez nenhum pedido? Também precisamos deixar o relacionamento opcional.
Atributos
Alguns modelos não estavam com todos os atributos mapeados. Vale lembrar que é através deles que poderemos construir um modelo físico consistente, verificando quais atributos são obrigatórios ou opcionais e até mesmos se existem atributos multi-valorados ou compostos.
Outro fator importante é a limitação do nome dos atributos e também das entidades que encontrei em certos modelos. Por exemplo: capac ao invés de capacidade. No modelo lógico não devemos nos preocupar com o tamanho do nome pois devemos deixar o modelo o mais legível possível. Apenas no modelo físico teremos que ter essa preocupação por limitações do banco de dados.
Restrições de integridade
Outro fato é que os modelos também não possuíam as restrições de integridade especificadas. Como vimos na edição anterior, o modelo possui três restrições de integridade que deveriam ser modeladas.
Destaque
Dos modelos que recebi, merece destaque o da leitora Débora de Souza, pois foi o que mais chegou perto da solução. Um ponto interessante: a leitora relacionou as entidades ITEM_GUIA e ITEM_PEDIDO. Essa forma de modelagem expressa claramente que um item da guia de produção é um item de pedido. Para ficar completo faltou apenas uma restrição de integridade para informar que o item da guia deve ser um item do pedido de produção pertencente à guia de produção.
Conclusão
Este artigo tem como objetivo realizar uma avaliação sobre modelagem de banco de dados. Continuo aberto a comentários, dúvidas ou sugestões sobre o simulado. Se você conhecer alguma maneira mais eficaz de resolver essa questão, entre em contato para que possamos compartilhar a técnica com os demais leitores. Agradeço a todos que participaram e desejo bons estudos.
