Banco de Dados · FUNDATEC · 2019 | Questão sqc-qq467846

Banco de DadosDER - Diagrama de Entidade e Relacionamento

Código: qq467846
Banca: FUNDATEC
Órgão: Prefeitura de Porto Alegre - RS
Ano: 2019
Nível: Superior

Cargo: Auditor Fiscal da Receita Municipal - Bloco II

Sabe-se que, a partir do DER mostrado na Figura 6, foram criadas e populadas as tabelas correspondentes em um Sistema Gerenciador de Banco de Dados Relacional (SGBDR), tendose respeitado, rigorosamente, os conceitos do modelo relacional. Nesse caso, para criar a tabela "Aquisicao", bastou executar a seguinte declaração, em SQL padrão ANSI:

ACREATE TABLE Aquisicao (Produto_prod_codigo INT NOT NULL,Cliente_cli_codigo INT NOT NULL,aquisicao_quantidade_venda FLOAT NOT NULL,aquisicao_preco_venda FLOAT NOT NULL,aquisicao_data_hora DATE NOT NULL,PRIMARY KEY (aquisicao_data_hora, Produto_prod_codigo, Cliente_cli_codigo),FOREIGN KEY (Produto_prod_codigo) REFERENCES Produto (prod_codigo),FOREIGN KEY (Cliente_cli_codigo) REFERENCES Cliente (cli_codigo));
BCREATE TABLE Aquisicao (Produto_prod_codigo INT NOT NULL,Cliente_cli_codigo INT NOT NULL,aquisicao_quantidade_venda FLOAT NULL,aquisicao_preco_venda FLOAT NULL,aquisicao_data_hora DATE NOT NULL,PRIMARY KEY (Produto_prod_codigo, Cliente_cli_codigo),FOREIGN KEY (Produto_prod_codigo) REFERENCES Produto (prod_codigo),FOREIGN KEY (Cliente_cli_codigo) REFERENCES Cliente (cli_codigo));
CCREATE TABLE Aquisicao (Produto_prod_codigo INT PRIMARY KEY,Cliente_cli_codigo INT PRIMARY KEY,aquisicao_quantidade_venda FLOAT NOT NULL,aquisicao_preco_venda FLOAT NOT NULL,aquisicao_data_hora DATE PRIMARY KEY,FOREIGN KEY (Produto_prod_codigo) REFERENCES Produto (prod_codigo),FOREIGN KEY (Cliente_cli_codigo) REFERENCES Cliente (cli_codigo));
DCREATE TABLE Aquisicao (Produto_prod_codigo INT PRIMARY KEY REFERENCES Produto (prod_codigo),Cliente_cli_codigo INT PRIMARY KEY ) REFERENCES Cliente (cli_codigo),aquisicao_quantidade_venda FLOAT NULL,aquisicao_preco_venda FLOAT NULL,aquisicao_data_hora DATE PRIMARY KEY);
ECREATE TABLE Aquisicao (Produto_prod_codigo INT PRIMARY KEY REFERENCES Produto (prod_codigo) NOT NULL,Cliente_cli_codigo INT PRIMARY KEY ) REFERENCES Cliente (cli_codigo) NOT NULL,aquisicao_quantidade_venda FLOAT NOT NULL,aquisicao_preco_venda FLOAT NOT NULL,aquisicao_data_hora DATE NOT NULL);

Revelar gabarito e comentário

GabaritoA — CREATE TABLE Aquisicao ( Produto_prod_codigo INT NOT NULL, Cliente_cli_codigo INT NOT NULL, aquisicao_quantidade_venda FLOAT NOT NULL, aquisicao_preco_venda FLOAT NOT NULL, aquisicao_data_hora DATE NOT NULL, PRIMARY KEY (aquisicao_data_hora, Produto_prod_codigo, Cliente_cli_codigo), FOREIGN KEY (Produto_prod_codigo) REFERENCES Produto (prod_codigo), FOREIGN KEY (Cliente_cli_codigo) REFERENCES Cliente (cli_codigo) );

Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.

Tradução do DER para SQL: Tabela de Associação Muitos-para-Muitos com Atributos

Gabarito: letra A. A única alternativa que respeita as regras de negócio é a A, que define a chave primária composta por todos os três atributos que tornam cada aquisição única (produto, cliente e data/hora) e declara os demais atributos como NOT NULL, além de usar corretamente a sintaxe SQL para FOREIGN KEY.

A tabela "Aquisicao" modela um relacionamento muitos-para-muitos entre Produto e Cliente, com atributos associativos. Pelas regras de negócio:

Um cliente pode adquirir o mesmo produto mais de uma vez, em datas/horas diferentes → a chave primária deve incluir produto, cliente e data/hora.
Ao associar, sempre se armazena quantidade, preço e data/hora → esses atributos devem ser NOT NULL.
As chaves estrangeiras referenciam as tabelas Produto e Cliente.

NÃO CAIA NESSA!

A banca tenta levar o candidato a escolher a alternativa B, que usa apenas (produto, cliente) como chave primária. Isso viola a regra de que um mesmo produto pode ser adquirido pelo mesmo cliente em momentos diferentes, pois a chave não seria única. Além disso, a B coloca quantidade e preço como NULL, mas as regras dizem que esses dados sempre são armazenados na associação.

Alternativa A — ✅ Correta ⟵ GABARITO

Chave primária composta por aquisicao_data_hora, Produto_prod_codigo e Cliente_cli_codigo → atende à unicidade (cada combinação produto+cliente+data/hora é única).
Todos os atributos são NOT NULL, conforme as regras de negócio (quantidade, preço e data/hora sempre preenchidos).
As FOREIGN KEY estão corretamente declaradas, com a sintaxe padrão ANSI.

Alternativa B — ❌ Incorreta

Chave primária apenas por Produto_prod_codigo e Cliente_cli_codigo → impede que o mesmo cliente compre o mesmo produto em momentos diferentes (violação da regra 1).
aquisicao_quantidade_venda e aquisicao_preco_venda estão como NULL → as regras de negócio exigem que esses campos sejam preenchidos (regra 4).

Alternativa C — ❌ Incorreta

Sintaxe SQL inválida: três declarações PRIMARY KEY em colunas diferentes – uma tabela só pode ter uma chave primária. A linha que define aquisicao_data_hora DATE PRIMARY KEY e as demais com INT PRIMARY KEY gera erro de sintaxe.
Além disso, a chave primária não seria composta, mas sim múltiplas declarações, o que é proibido.

Alternativa D — ❌ Incorreta

Erro de sintaxe: parêntese fechado após INT PRIMARY KEY ) REFERENCES ... – quebra a definição da coluna e da foreign key.
A chave primária, da forma como está, só incluiria Produto_prod_codigo e aquisicao_data_hora (mas com sintaxe errada), não contemplando Cliente_cli_codigo como parte da PK.
aquisicao_quantidade_venda e aquisicao_preco_venda estão como NULL, contrariando as regras.

Alternativa E — ❌ Incorreta

Erro de sintaxe: parêntese fechado antes do REFERENCES na linha do Cliente_cli_codigo – Cliente_cli_codigo INT PRIMARY KEY ) REFERENCES... – a foreign key fica fora da definição da coluna.
A chave primária não é composta – cada coluna tem PRIMARY KEY individual, o que é inválido (apenas uma PK permitida).

Gabarito: letra A.

Link permanente: /questoes/qq467846