Relatórios: Últimos Livros Catalogados

Neste relatório você vê os últimos livros que foram catalogados num determinado período

Código SQL #

SELECT 
  DATE_FORMAT(i.dateaccessioned, '%d/%m/%Y') AS 'Data de Inclusão',
  diario.total_dia AS 'Total de Itens no Dia',
  i.barcode AS 'Cód. de Barras',
  i.itemcallnumber AS 'Nº de Chamada',
  b.title AS 'Título',
  b.author AS 'Autor'
FROM items i
LEFT JOIN biblio b ON i.biblionumber = b.biblionumber
LEFT JOIN (
  SELECT DATE(dateaccessioned) AS data_ref, COUNT(itemnumber) AS total_dia
  FROM items
  GROUP BY DATE(dateaccessioned)
) diario ON DATE(i.dateaccessioned) = diario.data_ref
WHERE DATE(i.dateaccessioned) BETWEEN <<Data inicial|date>> AND <<Data final|date>>
ORDER BY DATE(i.dateaccessioned) DESC, b.title ASC

O que o relatório deve mostrar? #

Ao clicar em RUN ele vai abrir duas opções de data inicial e final.

Nesta tela é que você define qual é o período que você quer analisar. Escolhi o mês de Janeiro de 2026 e ele me retornou 19 itens catalogados. Meu Relatório mostra: A data em que o livro foi catalogado na coluna “Data de inclusão”, o total de itens NAQUELE dia (ou seja, naquele dia do print catalogamos 01 livro);

Mas aqui no dia 12/01 foram catalogados 09 livros no total. Compreende? Ele também me fornece o código de barras das obras daquele dia, o número de chamada, título e autor. Isso facilita pra nós sabemos o básico do item para checar qualquer informação ou criar uma planilha estatísticas de determinada pessoa. (Facilita também no caso de professores para checar seus alunos que trabalham numa mesma base do Koha).

Em resumo essa query funciona como um contador diário de itens catalogados. O que acha de entender didaticamente o que cada parte do código faz? (Isso te ajuda a compreender a lógica e o padrão e longo prazo você pode montar novas formas de relatório…)

Antes de mais nada: Planilhas #

Antigamente nós usávamos muito os sistemas de planilhas do computador. Mais antigamente ainda, usávamos tabelas de papel mesmo. Então o que estamos fazendo é exatamente isso mas de uma maneira mais “rápida” e usando o poder computacional a nosso favor.

No banco de dados do Koha cada “tabela” é como se fosse uma aba de planilha desses programas. E a nossa query usa três dessas abas:

A aba items que é uma linha para cada exemplar físico (ou seja, cada código de barras colado é um item).

A aba biblio que é uma linha de planilha para cada título (ou seja, a “ficha catalográfica”, sem se importar com quantos exemplares existem). Explico ainda mais esmiuçado: Um “Brás Cubas” é uma (01) linha em biblio. Mas pode existir 10 códigos de barra distintos em items para (Brás Cubas, biblio 01) entendeu?

Dito isso, nós fazemos uma subconsulta dentro desse relatório > Criamos uma tabela temporária só pra esse relatório. Criada na hora.

Parte 01 – O Select (Escolhendo quais colunas que vão aparecer no relatório) #

SELECT 
  DATE_FORMAT(i.dateaccessioned, '%d/%m/%Y') AS 'Data de Inclusão',
  diario.total_dia AS 'Total de Itens no Dia',
  i.barcode AS 'Cód. de Barras',
  i.itemcallnumber AS 'Nº de Chamada',
  b.title AS 'Título',
  b.author AS 'Autor'

Pensa comigo que você tem uma planilha gigante (a tabela items) com um monte de colunas, tipo 30, 40 colunas… o SELECT é você dizendo: “eu só quero ver estas 06 colunas aqui, ignore o resto”.

Agora detalhe a detalhe:

i.dateacessioned: Essa coluna já existe na tabela items e guarda a data em que o item entrou no acervo. O i. antes é só pra dizer “essa coluna é da tabela items” (é o apelido de items, mas logo mais explico).

DATE_FORMAT(…, ‘%d/%m/%y’) é uma função, ou seja, é uma “máquina de transformar coisas”. Então ela pega a data que tá guardada em um jeito que não é o comum pra nós (2026-06-19) e devolve na forma em que estamos acostumados (19/06/2026). Só estética, não muda o dado.

AS ‘Data de Inclusão’: O AS é só um apelido para o cabeçalho da coluna no resultado. Sem isso, a coluna apareceria com um código que você teria dificuldade de entender (ex: DATE_FORMAT(i.dateaccessioned…). Com o AS você explica pra quem vai ler o relatório o título daquilo. Em português limpo seria “DATE_FORMAT…. é pra ser lido COMO ‘Data de Inclusão’. Se quiser poderia ser “Data de cadastro”, “Data de catalogação” … Com AS você escolhe o nome que quer ver.

diario.total_dia: Essa coluna não existe em nenhuma outra parte do banco de dados de verdade. Ela é fabricada a partir da parte 3 (a subconsulta). Aqui deve vir o resultado dessa subconsulta, mas estão só criando. (mais pra baixo explico).

i.barcode, i.itemcallnumber : São colunas comuns da tabela items: são o código de barras e o número de chamada do item.

b.title, b.author: Essas aqui são da tabela biblio (perceba que não começa com i, mas sim com b). E aí talvez você se pergunte “Por que título e autor não estão na tabela items? No Koha um livro com 5 cópias vai gerar cinco linhas (ou cinco códigos de barra diferentes) , mas em outra tabela, a tabela biblio ela só gera 1 linha (1 título > 1 autor). Repetir título/autor 5 vezes seria desperdício. Por isso eles ficam separados e precisamos “juntar” as duas tabelas. (que é exatamente a parte2)

Juntando as tabelas (Join) #

FROM items i
LEFT JOIN biblio b ON i.biblionumber = b.biblionumber

FROM items i: Ou “quero chamar a tabela items de i pra abreviar e chamar assim” isso vai evitar que eu escreva toda vez “items.barcode” por exemplo… usando apenas i.barcode.

LEFT JOIN biblio b agora eu quero grudar a tabela biblio do lado, e vou chamá-la de b.

Mas grudar como? é isso que o ON define:

ON i.biblionumber = b.bilionumber >> grude a linha de items com a linha biblio que tiver o mesmo número de biblionumber.

Pensa em duas planilhas separadas com uma coluna em comum (tipo um codigo de ligação). O JOIN é o Excel fazendo um PROCV/VLOOKUP automático: para cada item, ele procura em biblio o título e autor que combinam com aquele biblionumber.

E por que LEFT e não só JOIN?

O JOIN puro (conhecido como INNER JOIN) só mostra o item se achar correspondência em biblio. Já o LEFT JOIN mostra todos os itens, mesmo que não ache correspondência (nesse caso, título e autor ficariam vazios/NULL)

À esquerda é obrigatório (items) e à direita é opcional (biblio). Por que fiz assim? Por que é uma boa prática de segurança, você não quer que um item desapareça do relatório só porque o registro bibliográfico dele tem algum problema. (inclusive ajuda a encontrar o referido item e arrumar rs)

E por fim:

Parte 3 – A Subconsulta #

LEFT JOIN (
  SELECT DATE(dateaccessioned) AS data_ref, COUNT(itemnumber) AS total_dia
  FROM items
  GROUP BY DATE(dateaccessioned)
) diario ON DATE(i.dateaccessioned) = diario.data_ref

Essa aqui é a parte mais “avançada” do relatório, então vamos devagar:

O que é uma subconsulta? É um SELECT dentro de outro SELECT. O banco de dados roda essa parte de dentro primeiro, ela vira uma tabelinha temporária (que existe só durante essa consulta), e depois essa tabelinha é tratada como se fosse uma tabela normal, por isso dá pra fazer LEFT JOIN nela também. Vamos isolar a parte de dentro:

SELECT DATE(dateaccessioned) AS data_ref, COUNT(itemnumber) AS total_dia
FROM items
GROUP BY DATE(dateaccessioned)

Imagina que a tabela items tá assim (bem simples)

O GROUP BY DATE (dateacessioned) faz o seguinte:agrupa as linhas que tem a mesma data, como se fizesse “pilhas”, uma pilha para cada dia diferente.

Pilha do dia 15: itens 1, 2 e 4 => Total de 3 itens.

Pilha do dia 16: Item 3 => Total de 1 item.

E o COUNT (itemnumber) conta quantos itens tem em cada pilha.

Resultado dessa subconsulta

Viu? Ela transformou “uma linha por item” em “uma linha por dia, com o total”. É um resumo. Facilita muito. diario é só o apelido que vamos usar para essa tabela resumo (como fizemos com i e b anteriormente. E o ON DATE (i.dateaccessioned) = diario.data_ref faz o mesmo PROCV de antes: para cada item da tabela principal, vai lá no resumo diario e busca “quantos itens entraram nesse mesmo dia que esse item entrou”, e cola esse número do lado.

É por isso que, no resultado final, um item individual (uma linha) consegue mostrar um total que é de outras linhas também (o total do dia). É um truque.

Parte 4 – O WHERE (Quando) #

WHERE DATE(i.dateaccessioned) BETWEEN <<Data inicial|date>> AND <<Data final|date>>

WHERE = “onde”, ou seja, sou eu pedindo pra mostrar só as linhas que cumpre a condição que eu estou procurando. (É o filtro).

BETWEEN ___ AND ___ = Entre a data x e a data y (precisamos das duas pontas da data).

<<Data inicial|date>> e <<Data final|date>> isso aqui já não é SQL propriamente, mas uma sintaxe, uma regra, própria dos relatórios do Koha. Quando você roda esse relatório na interface, o Koha enxerga esses <<…>> e mostra dois campinhos de calendário pra você escolher as datas, sem precisar editar o código.

Importante: Esse filtro só vai agir depois que a subconsulta diario já calculou os totais usando todos os itens de todos os tempos (sem filtro nenhum). Então o número de Total de itens no dia vai continuar correto e completo, mesmo que você filtre o relatório pra mostrar só uma semana. O filtro só decide quais linhas finais aparecem na tela, não interfere no cálculo do resumo.

Parte 5 – ORDER BY (Ou como devemos organizar?) #

ORDER BY DATE(i.dateaccessioned) DESC, b.title ASC

ORDER BY : Ordene por/ Organize as linhas do resultado nessa ordem.

Você pode ordenar mais de um critério, e a ordem que você escreve importa: primeiro critério manda, segundo critério só desempata.

DATE(i.dateaccessioned) DESC: primeiro critério : ordene pela data. DESC: De maneira decrescente, do mais recente para o mais antigo (tipo um feed). b.title ASC é o segundo critério, quero que dentro do mesmo dia ordene pelo título em ordem alfabética. ASC = crescente (ou seja: De A para Z).

Então o que fizemos foi só organizar as coisas “ordene por uma data, de maneira que mostre o mais novo para o mais antigo, então organize em ordem alfabética por título.”