Questão de Banco de Dados — Consultas e Comandos em SQL — CESPE / CEBRASPE 2024

SQL – Comando CREATE TABLE e Integridade Referencial

Gabarito: Certo. O comando CREATE TABLE gastos está sintaticamente correto e implementa fielmente os relacionamentos do modelo entidade-relacionamento: define a chave primária id_gasto e as chaves estrangeiras id_tipo_gasto_saude e id_hospital, que referenciam as tabelas tipo_gasto_saude e hospital, respectivamente. A sintaxe segue o padrão SQL para criação de tabelas com restrições de integridade.

O comando CREATE TABLE é a instrução da Linguagem de Definição de Dados (DDL) responsável por criar uma nova tabela no banco de dados relacional. Sua sintaxe básica é CREATE TABLE nome_da_tabela (definições de colunas e restrições). As definições de colunas incluem o nome, o tipo de dado e as restrições de nulidade (NULL ou NOT NULL). As restrições de tabela, como PRIMARY KEY e FOREIGN KEY, são declaradas após as colunas, podendo ser nomeadas com a cláusula CONSTRAINT.

A chave primária (PRIMARY KEY) identifica de forma única cada registro da tabela, garantindo que não haja duplicidade e que o valor não seja nulo. Já a chave estrangeira (FOREIGN KEY) estabelece o relacionamento entre tabelas: ela referencia a chave primária de outra tabela, garantindo a integridade referencial — ou seja, um valor inserido na coluna da chave estrangeira deve existir na tabela referenciada. No comando apresentado, a tabela gastos possui duas chaves estrangeiras: uma para tipo_gasto_saude (via id_tipo_gasto_saude) e outra para hospital (via id_hospital). Isso reflete os relacionamentos do diagrama, onde cada gasto está associado a um tipo de gasto e a um hospital.

Na prática, o comando cria a tabela com as seguintes colunas: id_gasto (chave primária), id_tipo_gasto_saude (chave estrangeira, não nula), id_hospital (chave estrangeira, não nula), ano, mes, valor_gasto e id_municipio. Todas as colunas, exceto a chave primária, são definidas como NOT NULL, o que é coerente com a obrigatoriedade de preenchimento dos dados no modelo. A restrição CONSTRAINT pk_gastos PRIMARY KEY (id_gasto) nomeia a chave primária, e as restrições CONSTRAINT fk_gastos_tipo_gasto FOREIGN KEY (id_tipo_gasto_saude) REFERENCES tipo_gasto_saude(id_tipo_gasto_saude) e CONSTRAINT fk_gastos_hospital FOREIGN KEY (id_hospital) REFERENCES hospital(id_hospital) nomeiam e definem as chaves estrangeiras.

A pegadinha que a banca poderia explorar é a ausência de uma chave estrangeira para id_municipio. No entanto, o enunciado afirma que o código cria a tabela "de acordo com os relacionamentos com as outras tabelas", e o diagrama pode não apresentar um relacionamento direto entre gastos e municipio — ou o relacionamento pode ser feito por outra via. Como o comando está correto em sua sintaxe e implementa os relacionamentos explícitos, a afirmação é verdadeira.

Guarde a distinção entre PRIMARY KEY e FOREIGN KEY: a primeira é única e identifica o registro; a segunda referencia outra tabela e garante a integridade referencial. É exatamente essa distinção que valida o comando apresentado.

Item — ✅ CERTO

O comando CREATE TABLE gastos está correto. Ele define a chave primária id_gasto e as chaves estrangeiras id_tipo_gasto_saude e id_hospital, que referenciam as tabelas tipo_gasto_saude e hospital. A sintaxe segue o padrão SQL, com a definição das colunas, seus tipos e restrições, e a declaração das constraints de integridade. Não há erro sintático ou de modelagem que invalide a criação da tabela conforme os relacionamentos do diagrama.

Gabarito: Certo.