Considere o esquema relacional simplificado de um banco de dados de uma Universidade, contendo, ao menos, as seguintes tabelas: Departamentos (ID_Departamento, Nome, Localizacao) Professores (ID_Professor, Nome, ID_Departamento) Alunos (ID_Aluno, Nome, ID_Professor_Orientador) Entre outras restrições que devem ser consideradas, sabe-se que alunos podem ser orientados por professores e que todo professor pertence a um departamento. Considerando-se o esquema relacional apresentado, o trecho de código em linguagem SQL DDL que respeita todas as restrições de integridade citadas é
- A)CREATE TABLE Departamentos ( ID_Departamento INT PRIMARY KEY, Nome VARCHAR(100), Localizacao VARCHAR(100) ); CREATE TABLE Professores ( ID_Professor INT PRIMARY KEY, Nome VARCHAR(100), ID_Departamento INT ); CREATE TABLE Alunos ( ID_Aluno INT PRIMARY KEY, Nome VARCHAR(100), ID_Professor_Orientador INT );
Errada, porque não cria nenhuma FOREIGN KEY, então não garante nem a relação professor-departamento nem a orientação do aluno.
- B)CREATE TABLE Departamentos ( ID_Departamento INT PRIMARY KEY, Nome VARCHAR(100), Localizacao VARCHAR(100) ); CREATE TABLE Professores ( ID_Professor INT PRIMARY KEY, Nome VARCHAR(100), ID_Departamento INT, FOREIGN KEY (ID_Departamento) REFERENCES Departamentos(ID_Departamento) ); CREATE TABLE Alunos ( ID_Aluno INT PRIMARY KEY, Nome VARCHAR(100), ID_Professor_Orientador INT, FOREIGN KEY (ID_Professor_Orientador) REFERENCES Professores(ID_Professor) );
Certa, porque define FOREIGN KEY em Professores para Departamentos e em Alunos para Professores, respeitando as restrições do enunciado.
- C)REATE TABLE Departamentos ( ID_Departamento INT PRIMARY KEY, Nome VARCHAR(100), Localizacao VARCHAR(100) ); CREATE TABLE Professores ( ID_Professor INT PRIMARY KEY, Nome VARCHAR(100), ID_Departamento INT ); CREATE TABLE Alunos ( ID_Aluno INT PRIMARY KEY, Nome VARCHAR(100), ID_Professor_Orientador INT, FOREIGN KEY (ID_Professor_Orientador) REFERENCES Professores(ID_Professor) );
Errada, porque só liga Alunos a Professores e deixa Professores sem vínculo com Departamentos.
- D)CREATE TABLE Departamentos ( ID_Departamento INT PRIMARY KEY, Nome VARCHAR(100), Localizacao VARCHAR(100) ); CREATE TABLE Professores ( ID_Professor INT PRIMARY KEY, Nome VARCHAR(100), ID_Departamento INT ); CREATE TABLE Alunos ( ID_Aluno INT PRIMARY KEY, Nome VARCHAR(100), ID_Professor_Orientador INT );
Errada, porque não cria nenhuma restrição de chave estrangeira, permitindo registros inconsistentes nas relações citadas.
- E)CREATE TABLE Departamentos ( ID_Departamento INT PRIMARY KEY, Nome VARCHAR(100), Localizacao VARCHAR(100) ); CREATE TABLE Professores ( ID_Professor INT, Nome VARCHAR(100), ID_Departamento INT, PRIMARY KEY (ID_Professor), FOREIGN KEY (ID_Departamento) REFERENCES Departamentos(ID_Departamento) ); CREATE TABLE Alunos ( ID_Aluno INT PRIMARY KEY, Nome VARCHAR(100), ID_Professor_Orientador INT );
Errada, porque até cria a FOREIGN KEY de Professores para Departamentos, mas esquece a ligação de Alunos com Professores.
Gabarito: B
Em SQL DDL, não basta criar as tabelas: você precisa também amarrar as chaves estrangeiras para garantir a integridade referencial. É isso que evita, por exemplo, um professor apontar para um departamento que não existe, ou um aluno ter um orientador fantasioso que nunca foi cadastrado. Sem essa amarração, o banco até funciona, mas vira uma festa sem lista na porta. No esquema dado, há duas regras importantes: todo professor pertence a um departamento e alunos podem ser orientados por professores. Logo, a tabela Professores precisa ter uma FOREIGN KEY em ID_Departamento referenciando Departamentos(ID_Departamento), e a tabela Alunos precisa ter uma FOREIGN KEY em ID_Professor_Orientador referenciando Professores(ID_Professor). A alternativa B é a correta porque implementa exatamente essas duas restrições de integridade referencial. Além disso, mantém as chaves primárias nas tabelas principais, que é o esperado para identificação única dos registros. Esse é o padrão clássico cobrado em concurso: identificar a dependência entre tabelas e traduzir isso em FOREIGN KEY. As demais alternativas falham por omitir uma ou ambas as chaves estrangeiras, deixando o esquema sem proteção contra inconsistências. Em banco de dados relacional, isso viola a ideia central de integridade referencial, muito ligada ao modelo relacional de Codd e ao uso de constraints em DDL.