SóProvas


ID
910288
Banca
FCC
Órgão
DPE-SP
Ano
2013
Provas
Disciplina
Banco de Dados
Assuntos

Para responder às questões de números 58 e 59, utilize os comandos SQL abaixo.

CREATE TABLE times (id INTEGER, nome VARCHAR(20),cidade VARCHAR(20));
CREATE TABLE jogos (local VARCHAR(20), data VARCHAR(8), time1 INTEGER, time2 INTEGER, placar1 INTEGER, placar2 INTEGER);
INSERT INTO times VALUES(1, "santos fc", "santos");
INSERT INTO times VALUES(2, "palmeiras", "sao paulo");
INSERT INTO times VALUES(3, "guarani", "campinas");
INSERT INTO jogos VALUES("campinas", "20100504", 3, 1, 0, 2);
INSERT INTO jogos VALUES("santos", "20101220", 1, 2, 1, 1);
INSERT INTO jogos VALUES("campinas", "20110210",3,2,0,0);

Analise a impressão do resultado de uma query SQL efetuada após a execução dos comandos descritos (note que no exemplo as colunas estão separadas pelo símbolo | barra vertical).

campinas - guarani - 0 - 2 - santos fc
santos - santos fc - 1 - 1 - palmeiras
campinas - guarani - 0 - 0 - palmeiras

A query SQL capaz de produzir este resultado é

Alternativas
Comentários
  • -> na 2º linha está faltando a cidade que ocorreu o jogo (no caso santos)

    -> alguém pode explicar como se usa o "a." seria uma variável no meio do select?

    ->essa é a questão nº 58 dessa prova:

    http://www.resolucaodequestoes.com.br/includes/pdf/prova/fcc-2013-dpe-sp-agente-de-defensoria-administrador-de-banco-de-dados-prova.pdf

    vlws


  • A letra  "a"  seria um alias?

  • #rafoso

    o "a" seria como uma variável dentro do SQL.

    "SQL aliases are used to give a database table, or a column in a table, a temporary name.

    Basically aliases are created to make column names more readable."


    http://www.w3schools.com/sql/sql_alias.asp



  • Não é que essa gororoba funciona mesmo, testei aqui no SQL Server e funfou!!! É uma query bizarra, mas é uma query válida

  • Alguém sabe qual foi o erro da letra 'd'. Será que faltou o JOIN para unir as tabelas??

  • De gororoba não tem nada, subselects são importantíssimos e muito usados, não sei se para o caso passado, talvez fosse mais fácil um join (feito da forma correta), mas subquerys funcionam muito bem, principalmente quando você quer usar filtros (where) diferentes da query principal, muito útil para relatórios de estatísticas, claro que existem outras formas de fazer, mas esta é funcional.


    Harryson uma falha com certeza é não ter a comparação do JOIN (ON CAMPO TABELA 1 = CAMPO TABELA 2), mas não é só isso, como são tabelas de exemplo, teria que parar e pensar num join que trouxesse os dados requeridos, mas deve ser possível sim, quase tudo em SQL é.

  • Harrysson,

    Na verdade, o erro da letra "d", dentre outros, é devido ao fato de que a alternativa supõe que o nome dos times (o da casa e o do visitante) se encontram em tabelas separadas, o que não já nao faria nenhum sentido. Além do mais, na sequência, a mesma consulta tenta buscar ambos os nomes em uma só tabela, (que retornariam os nomes dos times corretamente), e tenta atribuí-los apelidos, que devem ser atribuidos a elementos como tabelas ou colunas, e não ao resultado da consulta.

    d) SELECT a.local, b.nome, a.placar1, a.placar2, c.nome FROM jogos a, (SELECT nome FROM times WHERE id = a.time1) b, (SELECT nome FROM times WHERE id = a.time2) c;

  • Mesmo após os comentários, não consegui enxergar nenhum erro na letra D. Depois vou rodar esse comando no BD p ver se vai funfar, já que a questão traz até os comandos de criação de tabela e de alimentação dos dados...

  • Realmente a consulta da alternativa D não funciona.
    Testei no Access (não riam!).
    Ao executar a consulta, o SGBD pediu valor dos "parâmetros" a.time1 e a.time2.
    Portanto, mesmo que sejam fornecidos valores (um para cada time), os nomes dos times não serão recuperados de maneira correta (serão exibidos, os nomes referentes aos valores fornecidos).


    Parece que a sintaxe e/ou a execução do comando SQL só permite que o alias de tabela seja usado (para determinar os valores) apenas nas expressões da cláusula SELECT e da cláusula WHERE (agradeço se alguém confirmar).

    Outra forma de fazer a consulta, especificando as subconsultas após "from" é esta: (consulta testada!)

    SELECT a.local, timeUm.nome, a.placar1, a.placar2, timeDois.nome
    FROM
         jogos a,
         (SELECT id, nome FROM times) timeUm,
         (SELECT id, nome FROM TIMES) timeDois
    WHERE a.time1 = timeUm.id and a.time2 = timeDois.id; 


    Acredito que a consulta da alternativa "a" é mais eficiente, pois nesta segunda solução é necessário, (pelo menos do ponto de vista teórico), o produto cartesiano de três tabelas.

  • Muito ruim de ler as alternativas, acabei respondendo alternativa D.

    Rodei a alternativa D no PostgreSQL e recebi a mensagem: "ERROR:  subquery in FROM cannot refer to other relations of same query level"

    O problema é que não há como fazer um JOIN na subquery sem ser um JOIN "explícito". 

    Funcionaria da seguinte forma:

    SELECT a.local, b.nome, a.placar1, a.placar2, c.nome 
      FROM jogos a
      JOIN (SELECT id, nome FROM times) b ON b.id = a.time1
      JOIN (SELECT id, nome FROM times) c ON c.id = a.time2;


  • Galera, o "a" não é uma variável no meio do SELECT, e sim um alias. Note que no FROM, a tabela jogos vem com o "a" logo após ser citada (atribuindo o alias "a" à tabela jogos), e no processamento interno, a cláusula FROM é executada ANTES do SELECT e do WHERE, por isso, este alias é utilizado nas duas cláusulas.

  • A) correta. Há 2 subconsultas muitos simples. Elas usam, respectivamente, os campos time1 e time2 de cada linha da consulta (SELECT) externa. A seguir, coloco uma solução alternativa:

     

    SELECT local, a.nome, j.placar1, j.placar2, c.nome
    FROM jogos j
    JOIN times a ON j.time1 = a.id
    JOIN times c ON j.time2 = c.id

     

    Consulta baseada em: http://stackoverflow.com/questions/9756997/sql-select-statement-with-two-foreign-key-taken-from-the-same-table

     

    B) incorreta. De início, a consulta seleciona todos os campos das duas tabelas, porém o exercício deseja apenas os campos local, time1, placar1, placar2 e time2.

     

    C) incorreta. Não é possível fazer uma junção regular (INNER JOIN) sem utilizar a cláusula WHERE. O produto cartesiano resultante será uma combinação de todas as linhas, entre outros problemas.

     

    D) O campos b.nome e c.nome estão fora do escopo da consulta externa. Para funcionar eles deveriam estar aninhados como estão na alternativa A.

     

    E) incorreta. Uso incorreto da expressão CASE.

  • Outra maneira, a título de curiosidade. Sem cláusula JOIN explícita:

     

    SELECT j.local, t1.nome, j.placar1, j.placar2, t2.nome
    FROM   times t1, times t2, jogos j
    WHERE  t1.id = j.time1
    AND    t2.id = j.time2