Obiekt bazy danych, którego głównym przeznaczeniem jest drukowanie lub wyświetlanie zestawień danych, to

Poprawna odpowiedź to „raport”, bo właśnie ten obiekt bazy danych jest przeznaczony typowo do estetycznego drukowania lub wyświetlania gotowych zestawień danych. W typowych systemach bazodanowych, takich jak Microsoft Access czy różne narzędzia klasy RAD, formularze służą głównie do wprowadzania i edycji danych, kwerendy do ich wyszukiwania i filtrowania, a raporty do prezentacji wyników w uporządkowanej, czytelnej formie. Raport ma własny projekt układu: nagłówki, stopki, grupowanie po polach (np. po kliencie, dacie, dziale), sumy częściowe i końcowe, numerację stron, a często także pola obliczeniowe. To jest dokładnie to, czego potrzebujemy, gdy chcemy przygotować np. wydruk faktur, miesięczne zestawienie sprzedaży, raport obecności pracowników albo raport kasowy do działu księgowości. Z mojego doświadczenia raport traktuje się jako końcowy produkt pracy z danymi – użytkownika końcowego zwykle nie interesują tabele czy relacje, tylko czy dostanie przejrzysty wydruk lub PDF, który można wysłać dalej. Dobre praktyki mówią, żeby w raportach nie upychać logiki biznesowej ani skomplikowanych obliczeń, tylko oprzeć je na dobrze przygotowanych kwerendach. Raport powinien być możliwie prosty, czytelny i stabilny – tak, żeby zmiana sposobu liczenia odbywała się w warstwie zapytań, a nie w każdym raporcie osobno. W narzędziach BI (np. Power BI, Tableau, ale też klasyczne Crystal Reports) idea jest podobna: raport to warstwa prezentacji, która korzysta z danych z bazy, modelu analitycznego albo widoków SQL. W praktyce w firmach raporty są podstawą podejmowania decyzji, więc poprawne zrozumienie ich roli w bazie danych jest naprawdę kluczowe.