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). \text{Cliente}(\text{codigo (PK)},\\ \text{nome},\\ \text{telefone},\\ \text{endereco})
  • Produto: tem código, nome, descrição. Usarei código como chave primária. \text{Produto}(\text{codigo (PK)},\\ \text{nome},\\ \text{descricao})
  • 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). \text{Fornecedor}(\text{codigo (PK)},\\ \text{razao\_social},\\ \text{telefone},\\ \text{CNPJ},\\ \text{endereco})
  • Loja: tem código, nome e CNPJ. Usarei código como chave primária. \text{Loja}(\text{codigo (PK)},\\ \text{nome},\\ \text{CNPJ})
  • 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. \text{Venda}(\text{num\_nota\_fiscal (PK)},\\ \text{data},\\ \text{valor\_total})
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 1:1: cada instância de A relaciona-se com no máximo uma de B e vice-versa.
  • Cardinalidade 1:N: cada instância de A pode relacionar-se com muitas de B, mas cada B com no máximo uma de A.
  • Cardinalidade N:M (ou M:N): muitos para muitos.
Relações dadas pelo enunciado:
  1. Venda — Cliente: uma venda é feita a um cliente; um cliente pode ter muitas vendas. Logo é \text{Cliente } 1 : N \text{ Venda}. Em notação de venda para cliente, cada venda pertence a exatamente um cliente.
  2. Venda — Loja: uma venda é realizada em uma das lojas; uma loja realiza muitas vendas. Logo \text{Loja } 1 : N \text{ Venda}.
  3. 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 é N:M. Quando há N:M 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.
  4. Produto — Fornecedor: “um produto pode ser fornecido por vários fornecedores e um fornecedor pode fornecer vários produtos” → N:M. 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 N:M, mas na implementação prática vira tabela associativa.
Vou anotar as cardinalidades resumidas (usando TeX):
  • Cliente 1 : N Venda
  • Loja 1 : N Venda
  • Venda N : M Produto (representada por ItemVenda)
  • Produto N : M 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 N:M 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:
\text{ItemVenda}(\text{num\_nota\_fiscal (FK)},\\ \text{produto\_codigo (FK)},\\ \text{preco},\\ \text{quantidade},\\ \text{PK}(\text{num\_nota\_fiscal},\text{produto\_codigo}))
Explicação didática: \text{FK} significa chave estrangeira (aponta para a venda e para o produto). \text{PK}(\ldots) indica chave primária composta.

Passo 5

Construir a entidade associativa para Produto–Fornecedor (ProdutoFornecedor) e explicar.
A relação produto–fornecedor é N:M. Se não há atributos extras especificados no enunciado, em modelagem relacional prática criamos uma tabela associativa para implementar N:M. 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:
\text{ProdutoFornecedor}(\text{produto\_codigo (FK)},\\ \text{fornecedor\_codigo (FK)},\\ \text{PK}(\text{produto\_codigo},\text{fornecedor\_codigo}))
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. \text{num\_nota\_fiscal} e Produto. \text{codigo}. Em ProdutoFornecedor, as FKs referenciam Produto. \text{codigo} e Fornecedor. \text{codigo}.
  • Cálculo de \text{valor\_total} da Venda: na prática, \text{valor\_total} é a soma dos itens: \text{valor\_total} = \sum_{\text{cada item da venda}} (\text{preco} \times \text{quantidade})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

\text{Cliente}(\text{codigo (PK)},\\ \text{nome},\\ \text{telefone},\\ \text{endereco})
\text{Produto}(\text{codigo (PK)},\\ \text{nome},\\ \text{descricao})
\text{Fornecedor}(\text{codigo (PK)},\\ \text{razao\_social},\\ \text{telefone},\\ \text{CNPJ},\\ \text{endereco})
\text{Loja}(\text{codigo (PK)},\\ \text{nome},\\ \text{CNPJ})
\text{Venda}(\text{num\_nota\_fiscal (PK)},\\ \text{data},\\ \text{valor\_total},\\ \text{cliente\_codigo (FK)},\\ \text{loja\_codigo (FK)})
\text{ItemVenda}(\text{num\_nota\_fiscal (FK)},\\ \text{produto\_codigo (FK)},\\ \text{preco},\\ \text{quantidade},\\ \text{PK}(\text{num\_nota\_fiscal},\text{produto\_codigo}))
\text{ProdutoFornecedor}(\text{produto\_codigo (FK)},\\ \text{fornecedor\_codigo (FK)},\\ \text{PK}(\text{produto\_codigo},\text{fornecedor\_codigo}))
Relações e cardinalidades:
  • Cliente 1 : N Venda (cada venda pertence a um cliente; cliente pode ter várias vendas).
  • Loja 1 : N Venda (cada venda é realizada em uma loja; loja faz várias vendas).
  • Venda N : M Produto, implementada por ItemVenda (ItemVenda armazena \text{preco} e \text{quantidade} para cada produto em cada venda).
  • Produto N : M Fornecedor, implementada por ProdutoFornecedor.

Exercícios relacionados