Atividade de Fixação
Faça o DER da situação abaixo:
A empresa B&D deseja automatizar os seus processos. Nessa empresa a venda a um cliente pode conter vários tipos de produto e um tipo de produto pode fazer parte de várias vendas. A venda a um cliente é realizada em uma das lojas da empresa. Um produto pode ser fornecido por vários fornecedores e um fornecedor pode fornecer vários produtos. Cada produto em uma venda deve ter preço e quantidade. Cada venda deve ter o número da nota fiscal, data e valor total. Cada produto tem código, nome e descrição. Cada cliente tem um código, nome, telefone e endereço. Cada fornecedor tem código, razão social, telefone, CNPJ e endereço. Cada loja tem código, nome e CNPJ.
Passo 1
O enunciado pede que a gente faça o DER (Diagrama Entidade-Relacionamento) da situação da empresa B&D. Vou listar aqui, claramente, tudo que o enunciado dá e o que é pedido, para não nos perdermos:
- Pergunta: construir o DER que modele a situação descrita.
- Informações/dados fornecidos no enunciado:
- A venda a um cliente pode conter vários tipos de produto e um tipo de produto pode fazer parte de várias vendas. (ou seja, existe relação entre venda e produto com multiplicidade muitos-para-muitos)
- A venda a um cliente é realizada em uma das lojas da empresa. (venda está associada a uma loja)
- Um produto pode ser fornecido por vários fornecedores e um fornecedor pode fornecer vários produtos. (produto × fornecedor é muitos-para-muitos)
- Cada produto em uma venda deve ter preço e quantidade. (atributos da associação venda–produto)
- Cada venda deve ter o número da nota fiscal, data e valor total. (atributos da entidade venda)
- Cada produto tem código, nome e descrição. (atributos da entidade produto)
- Cada cliente tem um código, nome, telefone e endereço. (atributos da entidade cliente)
- Cada fornecedor tem código, razão social, telefone, CNPJ e endereço. (atributos da entidade fornecedor)
- Cada loja tem código, nome e CNPJ. (atributos da entidade loja)
Passo 2
Identificar as entidades principais (o que são “coisas” do mundo real que precisamos representar) e escolher uma chave primária para cada uma. Vou explicar o porquê de cada escolha de forma didática.
Conceito rápido: entidade = representação de um conjunto de objetos com mesmas propriedades (ex.: todos os clientes). Atributo = propriedade de uma entidade (ex.: telefone). Chave primária = atributo (ou conjunto) que identifica unicamente cada instância (ex.: código do cliente).
Entidades e atributos escolhidos:
- Cliente: tem código, nome, telefone, endereço. Vou usar o campo código como chave primária porque o enunciado já dá isso (é padrão em modelagem usar um código identificador).
- Produto: tem código, nome, descrição. Usarei código como chave primária.
- Fornecedor: tem código, razão social, telefone, CNPJ e endereço. Usarei código como chave primária (poderia ser o CNPJ, mas enunciado menciona código).
- Loja: tem código, nome e CNPJ. Usarei código como chave primária.
- Venda: tem número da nota fiscal, data e valor total. O número da nota fiscal identifica a venda, então usamos ele como chave primária.
Explicação amigável: escolhemos chaves óbvias dadas pelo enunciado (códigos e número de nota). Em provas, se o enunciado diz “tem código …” é sinal de que esse campo é PK.
Passo 3
Identificar as relações entre as entidades e as multiplicidades (cardinalidades). Vou explicar o que significa cada cardinalidade e por que escolhi.
Conceitos rápidos:
- Cardinalidade
: cada instância de A relaciona-se com no máximo uma de B e vice-versa. - Cardinalidade
: cada instância de A pode relacionar-se com muitas de B, mas cada B com no máximo uma de A. - Cardinalidade
(ou ): muitos para muitos.
Relações dadas pelo enunciado:
- Venda — Cliente: uma venda é feita a um cliente; um cliente pode ter muitas vendas. Logo é
. Em notação de venda para cliente, cada venda pertence a exatamente um cliente. - Venda — Loja: uma venda é realizada em uma das lojas; uma loja realiza muitas vendas. Logo
. - Venda — Produto: o enunciado diz explicitamente que “a venda a um cliente pode conter vários tipos de produto e um tipo de produto pode fazer parte de várias vendas” → isso é
. Quando há e existam atributos da associação (aqui preço e quantidade por produto na venda), devemos criar uma entidade associativa (tabela/entidade fraca da associação), normalmente chamada de ItemVenda ou VendaProduto. - Produto — Fornecedor: “um produto pode ser fornecido por vários fornecedores e um fornecedor pode fornecer vários produtos” →
. Também aqui costuma-se criar uma entidade associativa (por exemplo, Fornecimento ou ProdutoFornecedor). Se não há atributos extra, pode ficar só como relação , mas na implementação prática vira tabela associativa.
Vou anotar as cardinalidades resumidas (usando TeX):
- Cliente
Venda - Loja
Venda - Venda
Produto (representada por ItemVenda) - Produto
Fornecedor (representada por ProdutoFornecedor)
Passo 4
Construir a entidade associativa para Venda–Produto (ItemVenda) e explicar escolha de chave e atributos.
Porque criar ItemVenda? Regras: quando uma relação
tem atributos que pertencem à associação (aqui “preço” e “quantidade” de cada produto naquela venda), precisamos modelar isso como entidade associativa. Essa entidade receberá, no mínimo, as chaves das entidades que relaciona e os atributos da associação.
Definição de ItemVenda:
- Atributos obrigatórios: preço (o preço aplicado naquele item na venda), quantidade (quantidade vendida daquele produto naquela venda).
- Chave primária: combinação de número da nota fiscal da venda e código do produto — assim identificamos unicamente cada linha (cada produto numa venda). Alternativa seria criar um id_item, mas a combinação (num_nota_fiscal, produto_codigo) é natural e comum em provas.
Formalmente:
Explicação didática:
significa chave estrangeira (aponta para a venda e para o produto).
indica chave primária composta.
Passo 5
Construir a entidade associativa para Produto–Fornecedor (ProdutoFornecedor) e explicar.
A relação produto–fornecedor é
. Se não há atributos extras especificados no enunciado, em modelagem relacional prática criamos uma tabela associativa para implementar
. Mesmo sem atributos, é importante modelá-la explicitamente no DER.
Definição de ProdutoFornecedor:
- Atributos: usualmente apenas as FKs.
- Chave primária: combinação de produto e fornecedor.
Formalmente:
Observação: se a prova pedisse, poderíamos adicionar atributos na associação (ex.: data de início do fornecimento, preço de compra, etc.), mas o enunciado não pede.
Passo 6
Verificar integridade referencial e notas práticas (como calcular valor total da venda): explicar para prova como garantir consistência.
- Integridade referencial: as chaves estrangeiras em ItemVenda devem referenciar Venda.
e Produto. . Em ProdutoFornecedor, as FKs referenciam Produto. e Fornecedor. . - Cálculo de
da Venda: na prática, é a soma dos itens: Em provas, às vezes pede-se manter esse campo na entidade Venda (denormalização) ou calculá-lo dinamicamente; aqui o enunciado pediu que Venda tenha valor total, então mantemos o atributo e documentamos que ele deve ser consistente com a soma dos ItemVenda.
Passo 7
Montar o DER final em forma textual/relacional (passo prático para a prova: listar entidades com atributos e indicar relações e cardinalidades). Na seção seguinte (Resposta) coloco só o DER final, sucinto e direto, conforme você pediu.
Resposta
Relações e cardinalidades:
- Cliente
Venda (cada venda pertence a um cliente; cliente pode ter várias vendas). - Loja
Venda (cada venda é realizada em uma loja; loja faz várias vendas). - Venda
Produto, implementada por ItemVenda (ItemVenda armazena e para cada produto em cada venda). - Produto
Fornecedor, implementada por ProdutoFornecedor.