Foram encontradas 24.967 questões.
Sobre a otimização (tuning) de consultas em bancos de dados relacionais, avalie as afirmações apresentadas a seguir:
I. Consultas com múltiplas condições de seleção conectadas pelo operador lógico OR podem não utilizar índices eficientemente e podem ser otimizadas dividindo-as em uma união (UNION) de consultas separadas.
II. O uso desnecessário da cláusula DISTINCT pode ser evitado sem alterar o resultado em alguns casos, o que é benéfico, pois DISTINCT frequentemente causa uma operação de ordenação onerosa.
III. Consultas aninhadas correlacionadas são sempre mais eficientes do que suas versões não aninhadas ou reescritas como JOINs, pois o SGBD otimiza sua execução avaliando a subconsulta apenas uma vez.
IV. Expressões aritméticas ou comparações envolvendo valores NULL ou substrings em cláusulas WHERE podem, em alguns casos, impedir que o otimizador de consulta utilize índices relevantes.
É correto o que se afirma em:
Provas
Subconsultas e aliases são recursos essenciais em SQL, empregados tanto na estruturação de consultas complexas quanto na resolução de dependências entre escopos interno e externo. Com base nisso, analise as afirmações a seguir:
I. Subconsultas podem ser utilizadas nas cláusulas WHERE, HAVING e FROM, sendo geralmente necessário atribuir um alias quando posicionadas em FROM, especialmente para permitir referência a seus campos.
II. O operador EXISTS avalia como verdadeira a condição sempre que a subconsulta retornar ao menos uma tupla, mesmo que composta exclusivamente por valores NULL.
III. O uso de aliases em subconsultas correlacionadas é necessário para garantir a correta referência cruzada entre os escopos interno e externo da consulta.
IV. O operador IN compara um valor escalar com os resultados de uma subconsulta, sendo sensível à presença de NULL, o que pode influenciar o resultado lógico da expressão.
É correto o que se afirma em:
Provas
Provas
Provas
Provas
Provas
Uma Secretaria da Fazenda esta estruturando seu banco de dados para garantir a integridade e a eficiência das consultas sobre as fiscalizações historicamente realizadas. Para isso, foi criada uma estrutura relacional robusta, da qual fazem parte as tabelas abaixo. Considera-se que uma empresa pode ser fiscalizada várias vezes.
CREATE TABLE EMPRESA (
id_empresa INT PRIMARY KEY,
nome VARCHAR(255) NOT NULL
);
CREATE TABLE FISCALIZACAO (
id_fiscalizacao INT PRIMARY KEY,
id_empresa INT,
data_fiscalizacao DATE NOT NULL,
status VARCHAR(20) NOT NULL,
FOREIGN KEY (id empresa) REFERENCES EMPRESA (id empresa) ON DELETE CASCADE
Em condições ideais, um comportamento correto resultante dessa estrutura é:
Provas
Provas
Provas
idempresa (INT): Identificador único da empresa
nome_empresa (VARCHAR): Nome da empresa
valor imposto (DECIMAL.): Valor do imposto pago
data pagamento (DATE): Data do pagamento (formato padrão ISO (YYYY-MM-DD))
categoria (VARCHAR): Categoria do imposto (exemplo: "ICMS", "ISS", "IPI")
O contador precisa de um relatório que mostre o total de impostos pagos por categoria em 2024, ordenado pelo valor total de forma decrescente. Considerando que o banco de dados está aberto e em condições ideais, o comando SQL que atende a necessidade do contador é:
Provas
Caderno Container