Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik programista
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 10 kwietnia 2026 09:56
Data zakończenia: 10 kwietnia 2026 09:57

Egzamin niezdany

Wynik: 18/40 punktów (45,0%)

Wymagane minimum: 20 punktów (50%)

Nowe

Analiza przebiegu egzaminu— sprawdź jak rozwiązywałeś pytania

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Tworząc raport w systemie zarządzania relacyjnymi bazami danych, umożliwia się

A. analizę wybranych danych

B. dodawanie danych do tabel

C. aktualizowanie danych w tabelach

D. usuwanie danych z tabel

Wykonywanie raportów w systemie obsługi relacyjnych baz danych nie polega na usuwaniu, dodawaniu ani aktualizowaniu danych. Usuwanie danych w tabelach jest operacją destrukcyjną, która trwale eliminuje informacje i nie sprzyja przechowywaniu ich do późniejszej analizy. Dodawanie danych to proces, który zwiększa objętość bazy danych, a nie koncentruje się na analizie już istniejących informacji. Z kolei aktualizacja danych polega na modyfikacji istniejących rekordów, co również nie ma bezpośredniego związku z tworzeniem raportów. Właściwe zrozumienie celu raportowania jest kluczowe dla efektywnego wykorzystania systemów bazodanowych. Często użytkownicy mylą procesy związane z utrzymywaniem baz danych z ich analizą. Dobrą praktyką jest oddzielanie operacji DML (Data Manipulation Language) od DQL (Data Query Language), które służy do analizy danych przy użyciu odpowiednich zapytań. Zastosowanie raportowania w systemach baz danych powinno być skupione na zrozumieniu i interpretacji danych, co pozwala na lepsze podejmowanie decyzji, zamiast na manipulacji danymi. Kluczowym aspektem jest umiejętność wyciągania wniosków z danych, które zostały już zgromadzone, a nie ich modyfikacja.

Pytanie 2

W języku SQL, jaki będzie efekt wykonania poniższego zapytania?

ALTER TABLE osoba DROP COLUMN grupa;

A. Zmieniona zostanie nazwa kolumny na grupa.

B. Usunięta zostanie kolumna grupa.

C. Zmieniona zostanie nazwa tabeli na grupa.

D. Dodana zostanie kolumna grupa.

Wybrana odpowiedź jest niepoprawna, ale nie martw się, to jest okazja do nauki. Zapytanie SQL w pytaniu nie dotyczyło zmiany nazwy tabeli ani kolumny, a także nie dotyczyło dodawania nowej kolumny. W języku SQL do zmiany nazwy tabeli używamy zapytania 'RENAME', natomiast do zmiany nazwy kolumny używamy 'ALTER TABLE' z dodatkiem 'RENAME COLUMN'. Dodawanie nowej kolumny wymaga natomiast użycia 'ALTER TABLE' z dodatkiem 'ADD COLUMN'. Wszystkie te operacje są ważne i niezbędne w różnych scenariuszach pracy z bazą danych. Jednak w tym przypadku mieliśmy do czynienia z instrukcją 'ALTER TABLE' z dodatkiem 'DROP COLUMN', które służy do usunięcia kolumny. Pamiętaj, że każde z tych zapytań ma inne skutki i odpowiednie zastosowania, więc ważne jest dokładne zrozumienie różnic między nimi.

Pytanie 3

W języku SQL polecenie INSERT INTO

A. wprowadza dane do tabeli.

B. dodaje tabelę.

C. aktualizuje rekordy określoną wartością.

D. dodaje pola do tabeli.

W SQL bardzo łatwo pomylić polecenia, bo wszystkie wyglądają dość podobnie, ale każde ma swoje wyraźne zadanie. INSERT INTO jest komendą typowo do pracy na danych, nie na strukturze bazy. Jeżeli ktoś myśli, że tym poleceniem „dodaje tabelę”, to miesza dwa różne obszary: definicję struktury i operacje na rekordach. Tworzenie nowej tabeli wykonuje się za pomocą CREATE TABLE, gdzie określamy nazwy kolumn, typy danych, klucze główne itd. INSERT zakłada, że tabela już istnieje i jest gotowa na przyjmowanie rekordów. Podobnie błędne jest kojarzenie INSERT z dodawaniem pól (kolumn) do tabeli. Modyfikacja struktury tabeli, czyli dokładanie nowych kolumn, zmiana typów, usuwanie kolumn, to domena polecenia ALTER TABLE. To jest tzw. DDL (Data Definition Language). Natomiast INSERT należy do DML (Data Manipulation Language), czyli tej części SQL, która operuje na danych: INSERT, UPDATE, DELETE, SELECT. Jeśli próbujemy INSERT-em „dodać pole”, to tak jakby śrubokrętem próbować wbijać gwóźdź – czasem coś się tam stanie, ale to w ogóle nie to narzędzie. Częstym nieporozumieniem jest też mylenie INSERT i UPDATE. UPDATE służy do aktualizacji istniejących rekordów, czyli zmiany wartości w wierszach, które już są w tabeli. Wykorzystuje się przy tym klauzulę WHERE, żeby wskazać, które rekordy mają zostać zmodyfikowane. INSERT natomiast zawsze tworzy nowy wiersz. Jeśli ktoś uważa, że INSERT „aktualizuje rekordy określoną wartością”, to tak naprawdę opisuje działanie UPDATE. W praktyce prowadzi to do błędów typu duplikowanie danych zamiast ich poprawiania. Moim zdaniem największy błąd myślowy polega na wrzucaniu wszystkiego, co „coś zmienia w bazie”, do jednego worka. Tymczasem w dobrze zaprojektowanym systemie bazodanowym wyraźnie rozdziela się operacje na schemacie (CREATE, ALTER, DROP) od operacji na danych (INSERT, UPDATE, DELETE). Zrozumienie tej różnicy jest kluczowe, żeby pisać poprawne i bezpieczne zapytania SQL. INSERT INTO zawsze oznacza: dodaj nowy rekord do istniejącej tabeli, z wartościami zgodnymi z jej strukturą i ograniczeniami.

Pytanie 4

Po zrealizowaniu polecenia użytkownik Jacek będzie miał możliwość

GRANT SELECT, INSERT ON baza1.mojaTabela TO 'Jacek'@'localhost';

A. usuwać tabelę i zakładać nową

B. modyfikować strukturę tabeli oraz dodawać nowe dane

C. usuwać rekordy z tabeli i przeglądać informacje

D. przeglądać dane w tabeli i wstawiać nowe dane

Polecenie GRANT SELECT, INSERT ON baza1.mojaTabela TO 'Jacek'@'localhost'; przyznaje użytkownikowi Jacek uprawnienia do przeglądania danych (SELECT) oraz wstawiania nowych danych (INSERT) do tabeli mojaTabela w bazie danych baza1. To oznacza, że Jacek nie ma możliwości usuwania tabeli ani zmiany jej struktury, co jest zarezerwowane dla uprawnień takich jak ALTER czy DROP. Zastosowanie tych uprawnień jest kluczowe w kontekście bezpieczeństwa i zarządzania danymi, ponieważ pozwala na kontrolowanie, kto może wykonywać określone operacje w bazie danych. Przykładem praktycznego zastosowania może być sytuacja, w której zespół programistów musi umożliwić pracownikom działu sprzedaży dostęp do danych klientów w tabeli, ale jednocześnie chce zapobiec przypadkowemu usunięciu lub modyfikacji struktury tabeli. W ten sposób, przyznając tylko uprawnienia SELECT i INSERT, administracja bazy danych może zapewnić odpowiedni poziom kontroli nad danymi, co jest zgodne z najlepszymi praktykami w zakresie zarządzania danymi i zabezpieczeń.

Pytanie 5

Relacja opisana jako: "Rekord z tabeli A może odpowiadać wielu rekordom z tabeli B. Każdemu rekordowi z tabeli B przyporządkowany jest dokładnie jeden rekord z tabeli A" jest relacją

A. jeden do jednego

B. wiele do wielu

C. nieoznaczoną

D. jeden do wielu

Relacja typu jeden do wielu oznacza, że jeden rekord z jednej tabeli (w tym przypadku tabela A) może być powiązany z wieloma rekordami z innej tabeli (tabela B). W opisanej sytuacji rekord z tabeli A może odpowiadać dowolnej liczbie rekordów z tabeli B, co ilustruje tę relację. Przykładem takiej relacji może być baza danych systemu zarządzania szkołą, gdzie jeden nauczyciel (rekord z tabeli A) może uczyć wielu uczniów (rekordy z tabeli B), ale każdy uczeń jest przypisany do jednego nauczyciela. Przy projektowaniu baz danych, stosowanie odpowiednich relacji jest kluczowe dla integralności i wydajności systemu. Dbałość o takie relacje przyczynia się do poprawy jakości danych oraz minimalizacji redundancji, co jest zgodne z zasadami normalizacji baz danych. W praktyce, relacje jeden do wielu są powszechnie stosowane w systemach CRM, ERP oraz wielu innych aplikacjach, które wymagają organizacji danych w sposób logiczny i praktyczny.

Pytanie 6

Zawarta baza danych składa się z trzech tabel oraz dwóch relacji. Aby uzyskać informacje o wszystkich lekarzach przypisanych do wybranego pacjenta, konieczne jest porównanie kluczy

A. Lekarze.id = Pacjenci.id

B. Lekarze.id = Pacjenci.Recepty_id

C. Lekarze.id = Recepty.id

D. Lekarze.id = Pacjenci.Lekarze_id

Błędne podejście do łączenia tabel w bazie danych może wynikać z niewłaściwego zrozumienia relacji kluczowych. Rozważmy odpowiedzi, które zakładają niepoprawne połączenia. Lekarze.id = Recepty.id jest błędne ponieważ identyfikator lekarza nie może być bezpośrednio związany z identyfikatorem recepty. Recepty są niezależnym bytem i ich klucze główne nie mają bezpośredniego związku z kluczami lekarzy. To samo dotyczy założenia Lekarze.id = Pacjenci.id które zakłada bezpośrednią relację między pacjentem a lekarzem przez ich identyfikatory co nie jest zgodne z typowymi strukturami baz danych. Każdy pacjent i lekarz ma swój unikalny identyfikator co oznacza brak bezpośredniej relacji między nimi, a relacja jest realizowana poprzez klucz obcy w tabeli Pacjenci. Ostatnia błędna opcja Lekarze.id = Pacjenci.Recepty_id znowu próbuje łączyć tabele poprzez klucze które nie są bezpośrednio związane. Recepty_id w tabeli Pacjenci odnosi się do konkretnej recepty przypisanej pacjentowi, a nie do lekarza. Takie błędne koncepcyjnie podejścia mogą prowadzić do nieprawidłowych wyników zapytań i utraty integralności danych co jest sprzeczne z dobrymi praktykami projektowania baz danych które zakładają jasno zdefiniowane i logicznie spójne relacje między tabelami przez odpowiednie klucze obce i podstawowe. Zrozumienie i poprawne stosowanie tych zasad jest kluczowe w efektywnym zarządzaniu i analizie danych w systemach relacyjnych.

Pytanie 7

Domyślny użytkownik, który posiada pełne uprawnienia do zarządzania bazą danych w systemie MySQL, to

A. sysadmin

B. root

C. admin

D. mysqld

W systemie MySQL domyślnym kontem z pełnymi uprawnieniami administracyjnymi jest użytkownik „root”, a nie różne nazwy kojarzone ogólnie z administracją systemu. Mylenie tych nazw wynika często z doświadczeń z innymi środowiskami, jak panele hostingowe czy systemy operacyjne, gdzie pojawiają się takie loginy jak „admin” czy „sysadmin”. W MySQL nazwa użytkownika jest jednak zdefiniowana bardzo konkretnie i historycznie utrwalił się właśnie „root” jako konto głównego administratora serwera bazodanowego. Login „admin” bywa używany w panelach typu phpMyAdmin, w panelach hostingowych albo w aplikacjach webowych, ale to są konta utworzone przez dostawcę hostingu lub programistę, a nie domyślne konto MySQL. Moim zdaniem to jedno z częstszych nieporozumień: ktoś loguje się do phpMyAdmin jako „admin” i zakłada, że taki użytkownik istnieje w samym MySQL jako konto systemowe, a tymczasem jest to po prostu użytkownik zdefiniowany w bazie o określonych uprawnieniach, nadanych ręcznie. Podobnie nazwa „sysadmin” kojarzy się z rolą administratora systemu albo domeny w różnych narzędziach, ale w MySQL taka nazwa nie jest żadnym standardem ani domyślną konfiguracją. Jeśli taki użytkownik istnieje, to tylko dlatego, że ktoś go sam stworzył. Natomiast „mysqld” to w ogóle nie jest użytkownik bazy w sensie konta SQL. Tak nazywa się proces serwera MySQL uruchamiany w systemie operacyjnym, często jako osobny użytkownik systemowy (np. user „mysql” w Linuksie). Ten użytkownik systemowy służy do uruchamiania usługi, dostępu do plików danych na dysku, ale nie loguje się do bazy jako klient SQL. Typowym błędem myślowym jest mieszanie użytkowników systemu operacyjnego, użytkowników paneli administracyjnych i użytkowników samego MySQL. Każda z tych warstw ma własny model uprawnień i własne nazwy kont. W pracy z bazami danych warto zawsze rozróżniać: kto jest użytkownikiem systemu (np. Linux), kto jest użytkownikiem serwera MySQL (root, app_user itd.), a kto użytkownikiem aplikacji webowej. Dopiero wtedy zarządzanie uprawnieniami i bezpieczeństwem staje się sensowne i przewidywalne.

Pytanie 8

Komenda skierowana do serwera bazy danych, która polega na zbieraniu, wyszukiwaniu lub zmienianiu danych w bazie, nosi nazwę

A. kwerendy

B. kolumny

C. kopii

D. formularza

Formularz to interfejs użytkownika, który umożliwia wprowadzanie informacji, ale nie jest związany z operacjami na bazach danych. To narzędzie wizualne, które może być używane do zbierania danych w sposób zorganizowany, jednak samo w sobie nie wykonuje żadnych operacji na danych w bazie. Koncepcja kolumny odnosi się do struktury tabeli w bazie danych, gdzie kolumny definiują typy danych przechowywanych w danej tabeli, ale nie są one powiązane z wykonywaniem zapytań czy operacji na danych. Kopią można określić duplikat danych lub backup, ale również nie ma ona zastosowania w kontekście wysyłania poleceń do serwera bazy danych. Istnieje ryzyko, że błędne zrozumienie terminów związanych z bazami danych prowadzi do mylnych interpretacji, co może skutkować trudnościami w pracy z danymi. Kluczowe jest zrozumienie, że kwerenda jest specyficznym poleceniem, które oddziałuje na strukturę danych, a nie narzędziem do ich wizualizacji czy opisu. Błędy te mogą prowadzić do niewłaściwego projektowania systemów baz danych oraz do ograniczonej efektywności w realizacji zadań związanych z zarządzaniem danymi.

Pytanie 9

Jak kwerenda SQL przedstawiona w ramce wpłynie na tabelę pracownicy?

ALTER TABLE pracownicy MODIFY plec char(9);

A. Zmieni typ danych kolumny plec na znakowy o stałej długości 9

B. Doda kolumnę plec ze znakowym typem danych o stałej długości 9

C. Doda kolumnę plec ze znakowym typem danych o zmiennej długości 9

D. Zmieni typ danych kolumny plec na znakowy o zmiennej długości 9

Inne odpowiedzi, które podałeś, dotyczą różnych operacji SQL, które nie mają związku z tym, co robi ALTER TABLE pracownicy MODIFY plec char(9). Musisz zrozumieć, że różnica między CHAR a VARCHAR jest dość istotna. CHAR ma stałą długość, to znaczy, że każda wartość w kolumnie zawsze ma tę samą liczbę znaków, uzupełnianą spacjami. Z kolei VARCHAR przechowuje dane o zmiennej długości, co może oszczędzać miejsce, ale wymaga więcej uwagi w zarządzaniu długością. Dodatkowo, jeśli chciałbyś dodać nową kolumnę, musiałbyś użyć polecenia ADD, a nie MODIFY. Ta różnica między dodawaniem a modyfikowaniem często myli początkujących w projektowaniu baz danych. Z mojego doświadczenia, wybór odpowiedniego typu danych i operacji jest kluczowy, bo źle przypisane polecenie może prowadzić do problemów z aplikacjami i zarządzaniem danymi. Tak że kluczowe jest zrozumienie, jak działają te polecenia SQL, żeby dobrze projektować efektywne bazy danych.

Pytanie 10

W tabeli klienci w bazie danych sklepu internetowego występują m.in. pola całkowite: punkty,
liczbaZakupow oraz pole ostatnieZakupy typu DATE. Klauzula WHERE do zapytania wybierającego klientów, którzy posiadają ponad 3000 punktów lub zrealizowali zakupy więcej niż 100 razy, a ich ostatnie zakupy miały miejsce przynajmniej w roku 2022 ma formę

A. WHERE punkty > 3000 AND liczbaZakupow > 100 AND ostatnieZakupy >= '2022-01-01'

B. WHERE punkty > 3000 AND liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'

C. WHERE punkty > 3000 OR liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'

D. WHERE (punkty > 3000 OR liczbaZakupow > 100) AND ostatnieZakupy >= '2022-01'

Analizując odpowiedzi, można zauważyć, że wiele z nich opiera się na błędnych założeniach dotyczących logiki operatorów w SQL. W przypadku pierwszej opcji, użycie operatora AND pomiędzy dwoma warunkami punktów i liczby zakupów sugeruje, że klient musi spełniać oba te warunki jednocześnie, co jest niezgodne z wymaganiami pytania. Odpowiedź ta nie uwzględnia, że wystarczy spełnić jeden z warunków, aby być zakwalifikowanym. W drugiej opcji, podobnie, zastosowanie operatora OR dla punktów i liczby zakupów, a następnie operatora AND dla daty, wprowadza w błąd, ponieważ nie uwzględnia subtelności dotyczących logiki kwerendy. Ponadto, w tej odpowiedzi pojawia się nieprawidłowe sformułowanie daty, gdzie zastosowanie '2022-01' nie jest wystarczające do prawidłowego porównania daty. W przypadku trzeciej odpowiedzi, użycie operatora OR dla wszystkich trzech warunków sprawia, że każdy klient, który ma chociażby jeden z tych warunków spełnionych, zostanie wybrany, co jest dalekie od zamierzonego celu. Z kolei ostatnia odpowiedź, chociaż wprowadza poprawne warunki, to wymaga od klientów spełnienia wszystkich jednocześnie, co jest niezgodne z zamysłem. Takie niepoprawne interpretacje wynikają często z nieścisłości w zrozumieniu operatorów logicznych oraz ich wzajemnych powiązań w SQL, co jest kluczowe w tworzeniu efektywnych i działających zapytań.

Pytanie 11

Czym jest proces normalizacji tabel w kontekście baz danych?

A. wizualizacja struktury bazy danych

B. wprowadzenie nowych rekordów do bazy

C. analiza i optymalizacja bazy danych

D. wyłącznie stworzenie tabel oraz relacji w bazie

Podczas analizy niepoprawnych odpowiedzi, istotne jest zrozumienie, dlaczego niektóre koncepcje są mylone z procesem normalizacji. Odpowiedzi sugerujące dodawanie rekordów do bazy oraz graficzne przedstawienie bazy nie mają związku z normalizacją, która koncentruje się na organizacji istniejących danych w sposób redukujący ich duplikację. Proces dodawania rekordów odnosi się do operacji DML (Data Manipulation Language) w SQL, podczas gdy normalizacja jest bardziej związana z teorią projektowania baz danych. Odpowiedź sugerująca, że normalizacja dotyczy jedynie tworzenia tabel i relacji, ignoruje złożoność tego procesu. Tworzenie tabel to tylko jeden z kroków w procesie normalizacji, który obejmuje również identyfikację zależności między danymi oraz eliminację niepożądanych redundancji. Niezrozumienie tego może prowadzić do nieefektywnej struktury bazy danych, co w perspektywie czasu skutkuje trudnościami w zarządzaniu danymi. Natomiast stwierdzenie, że normalizacja odnosi się jedynie do optymalizacji bazy danych, pomija jej fundamentalne założenia dotyczące integralności danych oraz eliminacji anomalii, które są kluczowe dla prawidłowego funkcjonowania systemów bazodanowych. W ten sposób można zauważyć, że mylenie tych pojęć prowadzi do błędnych wniosków na temat podstawowych zasad projektowania baz danych.

Pytanie 12

W systemie PHP złożono zapytanie SELECT do bazy przy pomocy funkcji mysqli_query. Jaką funkcję powinien wykorzystać użytkownik, aby ustalić liczbę rekordów, które zwróciło to zapytanie?

A. mysqli_fetch_row

B. mysqli_connect

C. mysqli_query

D. mysqli_num_rows

Funkcja mysqli_num_rows jest kluczowa w kontekście pracy z wynikami zapytań SQL w PHP. Umożliwia ona określenie liczby wierszy zwróconych przez kwerendę SELECT, co jest istotne, gdy chcemy dynamicznie dostosować zachowanie aplikacji na podstawie zrealizowanych zapytań. Przykładowo, po wykonaniu zapytania, można użyć mysqli_query do zrealizowania kwerendy, a następnie mysqli_num_rows do sprawdzenia, ile rekordów zostało zwróconych. Dzięki temu, programista może zdecydować, czy kontynuować przetwarzanie danych, czy też wyświetlić użytkownikowi komunikat o braku wyników. Jest to zgodne z dobrymi praktykami, ponieważ pozwala na wydajniejsze zarządzanie danymi oraz poprawia użytkowanie aplikacji. Użycie tej funkcji jest szczególnie ważne w aplikacjach, gdzie interakcja z użytkownikami jest kluczowa, a ich odpowiednie informowanie o statusie operacji bazodanowych może znacząco poprawić doświadczenie użytkownika.

Pytanie 13

Podaj dwa sposoby ochrony bazy danych Microsoft Access?

A. Zaszyfrowanie pliku bazy danych oraz wiadomości SMS z kodem autoryzacyjnym

B. Ustalenie hasła do otwarcia bazy danych oraz zabezpieczeń na poziomie użytkownika

C. Funkcje anonimowe oraz ustawienie hasła do bazy danych

D. Ustalenie zabezpieczeń na poziomie użytkownika i sesji

W analizie pozostałych odpowiedzi można zauważyć, że wiele z nich nie odnosi się do skutecznych metod ochrony bazy danych Microsoft Access. Na przykład, funkcje anonimowe nie są standardową metodą zabezpieczania baz danych. Anonimizacja danych może być stosowana w kontekście ochrony prywatności, ale nie zapobiega dostępowi do samej bazy danych. Ponadto, ustalenie hasła otwarcia bazy danych bez dodatkowych zabezpieczeń nie zapewnia pełnej ochrony, ponieważ łatwe do odgadnięcia hasła mogą być szybko złamane przez atakujących. W kontekście zabezpieczeń SMS z kodem autoryzującym, warto zauważyć, że ta metoda w zasadzie nie jest stosowana w Microsoft Access. Chociaż SMS-y z kodami mogą być skuteczne w autoryzacji na poziomie aplikacji lub systemów webowych, Access nie obsługuje takiej funkcji. Wprowadzenie takich środków może być mylące i nie prowadzi do rzeczywistego zabezpieczenia bazy danych. Podobnie, ustalenie zabezpieczeń na poziomie sesji, mimo że jest ważne w niektórych systemach, nie znajduje zastosowania w Access, który nie obsługuje bardziej zaawansowanych metod autoryzacji sesji, jak to ma miejsce w systemach zarządzania bazami danych wysokiego poziomu, takich jak SQL Server. W skrócie, brak znajomości funkcji i ograniczeń Microsoft Access prowadzi do zaproponowania nieefektywnych metod zabezpieczeń.

Pytanie 14

Zapytanie przedstawione poniżej zwróci wynik:

SELECT COUNT(cena) FROM uslugi;

A. średnią wartość cen usług w tabeli

B. liczbę wszystkich cen usług w tabeli

C. sumę wartości cen usług w tabeli

D. wszystkie wartości cen usług w tabeli

Pojawiające się nieporozumienia związane z interpretacją zapytania mogą prowadzić do błędnych wniosków. Wybór odpowiedzi, która zakłada, że zapytanie zwróci wszystkie ceny usług, jest nieprecyzyjny, ponieważ funkcja COUNT() nie wyświetla wszystkich wartości, a jedynie ich ilość. Z kolei odpowiedź sugerująca, że zapytanie oblicza średnią cenę usług, również jest błędna, ponieważ do obliczenia średniej stosuje się funkcję AVG(), a nie COUNT(). Dodatkowo, wybór opcji dotyczącej sumy cen usług jest mylący, gdyż do tego celu używa się funkcji SUM(). Zrozumienie, jak działają te funkcje, jest kluczowe w pracy z bazami danych. Funkcja COUNT() wykonuje zadanie zliczenia, co różni się od zadań agregacyjnych takich jak SUM() czy AVG(), które operują na wartościach liczbowych. Typowym błędem jest mylenie zadań zliczania z zadaniami obliczeniowymi, co może prowadzić do nieprawidłowych analiz danych. Dlatego ważne jest, aby przed sformułowaniem zapytania dobrze zrozumieć, jakie operacje są wykonywane na danych i jakie funkcje są do tego odpowiednie.

Pytanie 15

Zawarte polecenie SQL wykonuje

UPDATE Uczen SET id_klasy = id_klasy + 1;

A. ustalić wartość pola Uczen na 1

B. ustalić wartość kolumny id_klasy na 1 dla wszystkich rekordów w tabeli Uczen

C. zwiększyć o jeden wartość w kolumnie id_klasy dla wszystkich rekordów tabeli Uczen

D. powiększyć wartość pola Uczen o jeden

Analizując podane odpowiedzi, możemy zauważyć pewne błędne założenia co do działania polecenia SQL. Pierwsza z opcji sugeruje ustawienie wartości pola `Uczen` na 1, co jest nieprawidłowe, ponieważ polecenie nie odnosi się bezpośrednio do pola o nazwie `Uczen`, lecz dotyczy kolumny `id_klasy` w tabeli `Uczen`. Druga odpowiedź koncentruje się na zwiększeniu wartości pola `Uczen`, lecz polecenie nie zawiera odniesienia do pola o takiej nazwie, zajmuje się kolumną `id_klasy`. Trzecia możliwość mówi o ustawieniu wartości `id_klasy` na 1 dla wszystkich rekordów, co również jest nieprawidłową interpretacją, gdyż zgodnie z poleceniem SQL, wartość ta nie jest ustawiana na stałą wartość 1, ale jest zwiększana o 1. Często spotykanym błędem jest nieuwzględnianie specyfiki polecenia `UPDATE`, które modyfikuje istniejące dane, i mylenie go z `SET`, które może być używane w kontekście `INSERT`, jeżeli chcemy przypisywać stałe wartości. Aby uniknąć takich nieporozumień, zawsze warto dokładnie analizować składnię i logikę poleceń SQL.

Pytanie 16

W bazie danych znajduje się tabela ksiazki, która zawiera pola: tytul, id_autora, data_wypoz oraz id_czytelnika. Co dzień generowany jest raport dotyczący książek wypożyczonych w danym dniu, który prezentuje tylko tytuły książek. Która z poniższych kwerend SQL będzie odpowiednia do utworzenia tego raportu?

A. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E()

B. SELECT * FROM ksiazki

C. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()

D. SELECT tytul FROM ksiazki

Wybór innych kwerend nie spełnia wymagania, by uzyskać tylko tytuły wypożyczonych książek z konkretnego dnia. Kwerenda 'SELECT tytul FROM ksiazki;' zwraca wszystkie tytuły książek z tabeli, nie uwzględniając daty wypożyczenia. Takie podejście mogłoby prowadzić do nieefektywnego przetwarzania danych oraz przeciążenia systemu, ze względu na duże ilości danych. W kontekście baz danych, selekcja zbyt ogólnych danych jest niezalecana, ponieważ nie dostarcza istotnych informacji i nie spełnia wymagań użytkowników, prowadząc do frustracji. Kwerenda 'SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E();' zawiera błąd w nazwie funkcji, jako że 'CURRDATE_NT_E()' nie jest standardową funkcją SQL, co skutkuje błędem wykonania zapytania. Dodatkowo, nawet gdyby była poprawna, ta kwerenda zwracałaby więcej danych niż potrzebne, co znowu nie jest praktyką zgodną z efektywnym zarządzaniem danymi. Ostatnia propozycja, 'SELECT * FROM ksiazki;', również nie jest odpowiednia, ponieważ zwraca wszystkie kolumny z tabeli, a nie tylko tytuły książek, co skutkuje nieoptymalnym przetwarzaniem i brakiem precyzyjnych informacji. Kluczową lekcją jest to, że kwerendy w SQL powinny być precyzyjnie dopasowane do potrzeb użytkowników, aby minimalizować obciążenie bazy danych oraz maksymalizować użyteczność raportów.

Pytanie 17

Aby wyszukać w tabeli Pracownicy tylko te nazwiska, które kończą się na literę "i", można zastosować kwerendę SQL

A. SELECT nazwisko FROM Pracownicy WHERE nazwisko LIKE "%i%"

B. SELECT nazwisko FROM Pracownicy WHERE nazwisko LIKE "i"

C. SELECT nazwisko FROM Pracownicy WHERE nazwisko LIKE "%i"

D. SELECT nazwisko FROM Pracownicy WHERE nazwisko LIKE "i%"

Fajnie, że wybrałeś tę kwerendę SQL: 'SELECT nazwisko FROM Pracownicy WHERE nazwisko LIKE "%i";'. To jest naprawdę dobra robota, bo zastosowałeś operator LIKE w odpowiedni sposób. Wzorzec '%i' pozwala na wyszukiwanie nazwisk kończących się na literę 'i'. Ten symbol '%' to taki wildcard, który mówi SQL, żeby szukał czegokolwiek przed 'i', nawet niczego. To jest mega przydatne w codziennej pracy z bazami danych, bo często musimy wyciągać konkretne dane, żeby coś załatwić. Na przykład, jeśli chcemy stworzyć listę pracowników, którzy mają nazwiska kończące się na 'i', to ta kwerenda będzie strzałem w dziesiątkę. Pamiętaj, że dobrze jest testować swoje kwerendy na próbnych danych, żeby mieć pewność, że wyniki są takie, jakie chcemy.

Pytanie 18

Narzędzie używane do organizowania i przedstawiania danych z wielu wpisów w celu ich wydruku lub dystrybucji to

A. raport

B. makropolecenie

C. kwerenda

D. formularz

Kwerenda, formularz i makropolecenie to narzędzia, które mają zupełnie inne zadania niż raportowanie. Kwerenda to tak jakby pytanie do bazy danych, które pozwala wyciągać konkretne informacje z całkiem dużej ilości danych. Jej głównym celem jest raczej filtracja niż grupowanie danych, więc niekoniecznie nadaje się do tworzenia raportów. Formularz to interfejs, za pomocą którego możemy wprowadzać lub edytować dane, ale nie pomoże nam w grupowaniu czy ładnej prezentacji w formie raportu. Makropolecenie to natomiast zestaw instrukcji w Excelu, które mogą automatyzować powtarzalne zadania, co jest spoko, ale nie ma tu mowy o tworzeniu raportów. Widać więc, że każde z tych narzędzi ma swoje przeznaczenie i nie może zastąpić efektywnego raportu, który jest kluczowy w analizie danych.

Pytanie 19

Dodanie ograniczenia klucza obcego w taki sposób, aby kolumna Klasy_id z tabeli Uczniowie była powiązana z kolumną id w tabeli Klasy zostanie wykonane przy użyciu polecenia

A. ALTER TABLE Uczniowie DROP FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

B. ALTER TABLE Uczniowie ADD CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

C. ALTER TABLE Uczniowie ADD FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

D. ALTER TABLE Uczniowie DROP CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

Poprawnie wskazana składnia polecenia `ALTER TABLE Uczniowie ADD CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);` dokładnie odpowiada temu, co chcemy osiągnąć: dodać ograniczenie klucza obcego do już istniejącej tabeli. W SQL (np. w standardowym podejściu stosowanym w SQL Server, Oracle, wielu innych systemach) dodawanie klucza obcego odbywa się właśnie przez `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES ...`. Najpierw wskazujemy modyfikowaną tabelę (`Uczniowie`), potem nazwę nowego ograniczenia (`FKKlasy`), następnie kolumnę w tabeli podrzędnej (`Klasy_id`), a na końcu tabelę oraz kolumnę, do której się odwołujemy (`Klasy(id)`). Dzięki temu silnik bazy danych wie, że każda wartość w `Uczniowie.Klasy_id` musi mieć odpowiadający rekord w `Klasy.id`. To jest właśnie istota referencyjnej integralności danych. W praktyce takie powiązanie uniemożliwia np. dopisanie ucznia do nieistniejącej klasy albo usunięcie klasy, do której nadal przypisani są uczniowie (chyba że jawnie zdefiniujemy `ON DELETE CASCADE` czy inne zachowanie). Moim zdaniem warto też zwracać uwagę na nazewnictwo: prefiks `FK` w nazwie ograniczenia (`FKKlasy`) to dobra praktyka, bo od razu widać, że to klucz obcy, a nie np. unikalny indeks. W większych projektach przyjęcie spójnej konwencji, typu `FK_Uczniowie_Klasy`, bardzo ułatwia debugowanie błędów i analizę schematu. W codziennej pracy z bazami danych takie polecenie wykorzystuje się często po wczytaniu danych testowych albo po przebudowie tabel, gdy chcemy najpierw stworzyć strukturę bez ograniczeń, a potem krok po kroku dokładać klucze główne i obce. Warto też pamiętać, że przed dodaniem klucza obcego kolumna `Klasy_id` powinna mieć ten sam lub kompatybilny typ co `Klasy.id` (np. oba `INT`) i nie może zawierać wartości, które nie istnieją w tabeli `Klasy`, bo wtedy polecenie zakończy się błędem i klucz obcy nie zostanie utworzony.

Pytanie 20

W bazie danych dotyczącej pojazdów pole kolor w tabeli samochody może mieć wartości jedynie z definicji lakier. Aby nawiązać relację między tabelami samochody a lakier, należy użyć kwerendy

A. ALTER TABLE samochody ADD FOREIGN KEY barwa REFERENCES samochody.lakier;

B. ALTER TABLE samochody ADD FOREIGN KEY kolor REFERENCES lakier;

C. ALTER TABLE lakier ADD FOREIGN KEY (barwa) REFERENCES samochody(kolor);

D. ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);

Odpowiedź "ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);" jest poprawna, ponieważ prawidłowo definiuje klucz obcy w tabeli samochody, wskazując, że kolumna kolor w tej tabeli odnosi się do kolumny lakierId w tabeli lakier. Umożliwia to zapewnienie integralności referencyjnej, co oznacza, że wartości koloru w tabeli samochody będą mogły przyjmować tylko te wartości, które istnieją w tabeli lakier. Jest to standardowa praktyka w projektowaniu baz danych, która pomaga zapobiegać błędom, takim jak wprowadzenie koloru, który nie jest dostępny w zbiorze dozwolonych opcji. W praktyce, podczas dodawania nowego wpisu do tabeli samochody, system bazy danych automatycznie sprawdzi, czy dany kolor istnieje w tabeli lakier. Takie podejście zapewnia większą spójność danych oraz ułatwia zarządzanie them, zwłaszcza w większych aplikacjach, gdzie liczba potencjalnych wartości kolorów może być znaczna. Stosowanie kluczy obcych jest zgodne z zasadami normalizacji baz danych, co przyczynia się do ich efektywności i skalowalności.

Pytanie 21

Proces układania danych w bazie, który obejmuje tworzenie tabel, definiowanie relacji pomiędzy nimi oraz eliminację zbędnych danych i niespójnych powiązań, nazywany jest

A. normalizacją

B. sprawdzaniem integralności referencyjnej

C. sprawdzaniem spójności danych

D. nadmiarowością

Normalizacja to super ważny krok w robieniu baz danych. Chodzi o to, żeby uporządkować dane i pozbyć się zbędnych powtórzeń. Na przykład, jak mamy tabelę 'Klienci' i 'Zamówienia', to normalizacja pozwala połączyć te tabele tak, żeby info o klientach było tylko w jednym miejscu. Dzięki temu, każde zamówienie będzie przypisane do odpowiedniego klienta, co zmniejsza ryzyko zamieszania z danymi. Jak się stosuje zasady normalizacji, takie jak 1NF czy 2NF, to można uniknąć problemów, które mogą się pojawić przy aktualizowaniu, usuwaniu czy dodawaniu danych. Dobrze jest też regularnie sprawdzać, jak ma się struktura bazy, żeby była dostosowana do tego, co w danej chwili potrzebujemy. Tak naprawdę, normalizacja nie tylko dba o prawidłowość danych, ale też sprawia, że wszystko działa sprawniej.

Pytanie 22

Poniższe zapytanie zwróci

SELECT COUNT(cena) FROM uslugi;

A. wszystkie wartości cen usług w tabeli

B. łączną wartość cen usług w tabeli

C. średnią wartość cen usług w tabeli

D. liczbę wszystkich cen usług w tabeli

Zapytanie SQL "SELECT COUNT(cena) FROM uslugi;" jest skonstruowane w taki sposób, że używa funkcji agregującej COUNT, która zlicza liczbę niepustych wartości w kolumnie "cena" w tabeli "uslugi". Oznacza to, że wynik tego zapytania to liczba wierszy, w których kolumna "cena" nie jest pusta. Używanie funkcji COUNT jest standardową praktyką w SQL, gdy chcemy uzyskać ilość rekordów spełniających określone kryteria. W kontekście analizy danych, zrozumienie tego typu zapytań jest kluczowe, ponieważ pozwala na efektywne zbieranie statystyk, które mogą być później wykorzystane do podejmowania decyzji biznesowych. Na przykład, jeśli firma prowadzi usługi i chce wiedzieć, ile z nich ma przypisaną cenę, to to zapytanie dostarczy tej informacji. Warto także zwrócić uwagę, że funkcja COUNT jest często używana w połączeniu z innymi funkcjami agregującymi, takimi jak SUM czy AVG, w celu uzyskania bardziej kompleksowego obrazu danych.

Pytanie 23

Jaką wartość zwróci zapytanie z ramki wykonane na pokazanej tabeli? ```SELECT COUNT(DISTINCT wykonawca) FROM muzyka;```

A. 4

B. 0

C. 1

D. 3

Przy analizie zapytania SQL SELECT COUNTDISTINCT wykonawca) FROM muzyka; kluczowe jest zrozumienie funkcji COUNTDISTINCT. Ta funkcja zlicza unikalne wartości w określonej kolumnie co oznacza że nie uwzględnia powtórzeń. W analizowanym przypadku jesteśmy zainteresowani unikalnymi wykonawcami. Tabela zawiera czterech wykonawców ale Czesław Niemen pojawia się dwukrotnie co prowadzi do trzech unikalnych wpisów: Czesław Niemen Stan Borys i Mikołaj Czechowski. Częstym błędem jest nieuwzględnianie powtórzeń co prowadzi do błędnego założenia że liczba unikalnych wpisów jest równa ogólnej liczbie rekordów. Innym powszechnym nieporozumieniem jest różnica między funkcją COUNT a COUNTDISTINCT. Funkcja COUNT zlicza wszystkie wystąpienia w kolumnie niezależnie od powtórzeń co w tym przypadku dałoby wynik 4. Zrozumienie tych subtelności jest kluczowe dla poprawnego analizowania danych i tworzenia precyzyjnych raportów. Poprawne użycie COUNTDISTINCT odzwierciedla również dobrą praktykę w optymalizacji zapytań SQL szczególnie w kontekście dużych zbiorów danych gdzie wydajność jest kluczowa.

Pytanie 24

Kiedy należy użyć kwerendy SELECT DISTINCT, aby wybrać rekordy?

A. tak, aby w wskazanej kolumnie nie powtarzały się wartości.

B. uporządkowane w kolejności malejącej lub rosnącej.

C. pogrupowane.

D. obecne w bazie tylko raz.

Kwerenda SELECT DISTINCT jest używana w SQL do zwracania unikalnych rekordów z określonej kolumny lub kolumn. Głównym celem tej kwerendy jest eliminacja duplikatów z wyników zapytania, co jest szczególnie przydatne w sytuacjach, gdy interesuje nas uzyskanie listy unikalnych wartości, na przykład nazwisk pracowników w firmie, których można znaleźć w tabeli „Pracownicy”. Dzięki zastosowaniu DISTINCT, wynik zapytania dostarczy tylko różne nazwiska, eliminując powtarzające się wystąpienia. W kontekście dobrych praktyk w projektowaniu baz danych, korzystanie z DISTINCT pozwala na efektywniejsze analizowanie danych oraz lepsze zrozumienie struktury informacji w tabelach. Użycie SELECT DISTINCT może również pomóc w optymalizacji zapytań, szczególnie w rozbudowanych bazach danych, gdzie występowanie duplikatów może prowadzić do zafałszowania wyników analiz. Przykład praktyczny to zapytanie: SELECT DISTINCT kraj FROM Klienci, które zwróci wszystkie różne kraje, w których znajdują się klienci, co jest kluczowe w analizach geolokalizacyjnych.

Pytanie 25

Utworzono bazę danych z tabelą mieszkancy, która zawiera pola: nazwisko, imie, miasto. Następnie zrealizowano poniższe zapytanie do bazy: ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Poznań' UNION ALL SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Kraków';``` Wskaź, które zapytanie zwróci te same dane.

A. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto HAVING 'Poznań' OR 'Kraków';```

B. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto BETWEEN 'Poznań' OR 'Kraków';```

C. ```SELECT nazwisko, imie FROM mieszkancy AS 'Poznań' OR 'Kraków';```

D. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Poznań' OR miasto='Kraków';```

Zapytanie SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Poznań' OR miasto='Kraków'; jest poprawne, ponieważ umożliwia uzyskanie danych mieszkańców, którzy znajdują się w jednym z dwóch zadanych miast. Użycie operatora 'OR' pozwala na połączenie dwóch warunków, co sprawia, że zapytanie zwróci mieszkańców zarówno z Poznania, jak i z Krakowa. Takie podejście jest zgodne z zasadami SQL i umożliwia elastyczne filtrowanie danych. Alternatywnie, zastosowanie operatora UNION ALL w pierwszym zapytaniu łączy wyniki z dwóch oddzielnych zapytań, co jest również poprawne, ale może być mniej wydajne w przypadku dużych zbiorów danych. Używając UNION ALL, zwracane są wszystkie wiersze, w tym duplikaty, natomiast w przypadku zapytania z OR, uzyskujemy wiersze spełniające przynajmniej jeden z warunków. Dobrą praktyką jest testowanie zapytań w rzeczywistej bazie danych, aby ocenić ich wydajność i poprawność. W kontekście standardów SQL, takie zapytania są zgodne z definicjami języka zapytań i są stosowane do przetwarzania danych w relacyjnych bazach danych.

Pytanie 26

Przedstawione polecenie MySQL ma za zadanie

 ALTER TABLE ksiazki
 MODIFY tytul VARCHAR(100) NOT NULL;

A. zmienić nazwę kolumny w tabeli ksiazki.

B. dodać do tabeli ksiazki kolumnę tytul.

C. usunąć kolumnę tytul z tabeli ksiazki.

D. zmienić typ kolumny tytul w tabeli ksiazki.

Cóż, niestety, Twoja odpowiedź jest błędna. Warto zwrócić uwagę, że ALTER TABLE, które widzisz w poleceniu, służy do modyfikacji istniejących tabel, a nie do dodawania nowych kolumn czy ich usuwania. Instrukcja MODIFY wskazuje na zmianę definicji kolumny, a nie jej nazwy. Dlatego odpowiedzi mówiące o dodawaniu nowej kolumny albo usuwaniu istniejącej są nietrafione. To, co jest w pytaniu, to zmiana typu kolumny 'tytul' na VARCHAR(100) oraz dodanie ograniczenia NOT NULL. Zmiana nazwy kolumny też tu nie pasuje, bo nie ma słowa kluczowego RENAME, które by na to wskazywało. Więc jedyna poprawna odpowiedź to ta, która mówi o zmianie typu kolumny 'tytul'.

Pytanie 27

W tabeli mieszkancy znajdują się dane o osobach z całego kraju. Aby ustalić, ile unikalnych miast występuje w tej tabeli, trzeba zapisać kwerendę

A. SELECT COUNT(miasto) FROM mieszkancy;

B. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;

C. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;

D. SELECT DISTINCT miasto FROM mieszkancy;

Wybór odpowiedzi "SELECT COUNT(DISTINCT miasto) FROM mieszkancy;" jest naprawdę trafny. Używasz funkcji COUNT razem z DISTINCT, co pozwala na zliczenie tylko unikalnych miast w tabeli 'mieszkancy'. Funkcja COUNT liczy wszystkie wiersze, a DISTINCT usuwa duplikaty, dzięki czemu dostajemy dokładną liczbę miast. Fajnie jest to wykorzystać, gdy analizujesz dane demograficzne – wtedy wiesz, jakie masz rozkłady w różnych miastach. W bazach danych to standardowy sposób, bo dzięki temu unikasz powielania danych i masz lepsze analizy. Ważne jest też, żeby pamiętać o wydajności zapytań; połączenie DISTINCT z COUNT może być bardziej efektywne niż próba szukania duplikatów później. No i zasady normalizacji bazy danych? One rzeczywiście pomagają w tym, żeby dane były uporządkowane, co ułatwia ich przetwarzanie i analizowanie.

Pytanie 28

Utworzono bazę danych z tabelą mieszkańcy, która zawiera pola: nazwisko, imię oraz miasto. Następnie przygotowano poniższe zapytanie do bazy:
SELECT nazwisko, imie FROM mieszkańcy WHERE miasto='Poznań' UNION ALL SELECT nazwisko, imie FROM mieszkańcy WHERE miasto='Kraków';
Wskaż zapytanie, które zwróci takie same dane.

A. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto HAVING 'Poznań' OR 'Kraków';

B. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto BETWEEN 'Poznań' OR 'Kraków';

C. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto='Poznań' OR miasto='Kraków';

D. SELECT nazwisko, imie FROM mieszkańcy AS 'Poznań' OR 'Kraków';

Wybór błędnych odpowiedzi wynika z nieprawidłowego zrozumienia podstawowych zasad użycia operatorów w SQL oraz sposobu, w jaki warunki filtracji danych powinny być konstruowane. Zapytanie, które wykorzystuje BETWEEN, jest stosowane do porównywania wartości w określonym zakresie, ale w tym przypadku nie jest możliwe wskazanie dwóch różnych wartości, jak w przypadku miast. Operator OR w kontekście BETWEEN nie ma zastosowania, co sprawia, że ta koncepcja jest fundamentalnie błędna. Z drugiej strony, użycie HAVING jest niewłaściwe, ponieważ służy do filtrowania wyników po agregacji danych, a nie do bezpośredniej filtracji na podstawie wartości. Dodatkowo, konstrukcja SELECT z aliasem 'Poznań' OR 'Kraków' jest syntaktycznie niepoprawna, ponieważ operator OR nie może być użyty w tym kontekście. Typowym błędem w myśleniu jest mylenie operatorów logicznych i ich zastosowania w różnych kontekstach zapytań SQL. Zrozumienie, kiedy używać WHERE, HAVING oraz jak działa składnia zapytań, jest kluczowe dla poprawnego pisania i optymalizacji zapytań baz danych.

Pytanie 29

Która z funkcji SQL nie przyjmuje żadnych argumentów?

A. year

B. now

C. len

D. upper

Funkcja SQL 'now' jest funkcją, która zwraca bieżącą datę i czas. Jest to przykład funkcji, która nie pobiera żadnych argumentów, co oznacza, że jej działanie jest niezależne od jakichkolwiek wartości wejściowych. W praktyce, użycie tej funkcji pozwala na uzyskanie aktualnego znacznika czasu w zapytaniach SQL, co jest szczególnie przydatne w kontekście logowania zdarzeń w bazach danych, generowania raportów lub wstawiania danych z bieżącą datą i czasem do tabeli. Na przykład, w poleceniu SQL 'INSERT INTO logi (data_czas) VALUES (now());' wstawiamy aktualny czas do kolumny 'data_czas'. Stosowanie funkcji, które nie wymagają argumentów, jak 'now', jest zgodne z najlepszymi praktykami, ponieważ upraszcza kod i minimalizuje ryzyko błędów związanych z przekazywaniem niepoprawnych argumentów.

Pytanie 30

W systemie baz danych dla sklepu znajduje się tabela artykuly, która zawiera kolumnę o nazwie nowy. Jak należy skonstruować zapytanie, aby przypisać wartość TRUE dla tego pola w każdym rekordzie?

A. UPDATE artykuly SET nowy=TRUE

B. INSERT INTO artykuly VALUE nowy=TRUE

C. UPDATE nowy FROM artykuly VALUE TRUE

D. INSERT INTO nowy FROM artykuly SET TRUE

Odpowiedzi sugerujące użycie UPDATE nowy FROM artykuly VALUE TRUE; oraz INSERT INTO nowy FROM artykuly SET TRUE; są błędne z kilku powodów. Pierwsza z nich jest nieprawidłowa, ponieważ nie spełnia składni SQL. W SQL nie można bezpośrednio użyć 'FROM' w kontekście aktualizacji wartości w tabeli. Prawidłowa składnia wymaga wskazania tabeli, której kolumny mają być aktualizowane, a nie pole 'nowy' jako osobnej jednostki. Z kolei, odpowiedź bazująca na INSERT INTO nowy FROM artykuly SET TRUE; jest również błędna, ponieważ INSERT INTO jest używane do dodawania nowych rekordów do tabeli, a nie do aktualizacji ich wartości. W tej sytuacji nie jest możliwe dodanie wartości do kolumny 'nowy' bez wskazania konkretnej tabeli i odpowiednich wartości. Kolejna odpowiedź, INSERT INTO artykuly VALUE nowy=TRUE; nie jest zgodna ze składnią SQL, ponieważ wymaga podania zarówno kolumn, do których mają być wprowadzane wartości, jak i wartości dla innych kolumn, które mogą być obecne w tabeli. Typowe błędy myślowe prowadzące do takich odpowiedzi obejmują brak znajomości odpowiednich klauzul SQL i mylenie pojęć związanych z aktualizacją danych oraz dodawaniem nowych rekordów. Dlatego ważne jest, aby podczas pracy z SQL dokładnie zrozumieć różnice między tymi operacjami, co jest fundamentalne dla efektywnego zarządzania danymi w bazach danych.

Pytanie 31

Wartość atrybutu w tabeli, który pełni rolę klucza głównego

A. musi być unikalna

B. nigdy nie jest innego typu niż numeryczny

C. może przyjmować wartość null (NULL)

D. jest używana do szyfrowania zawartości tabeli

Klucz podstawowy w bazach danych to coś, co naprawdę musi być unikalne, żeby każda informacja w tabeli była dobrze zidentyfikowana. Przykładowo, w tabeli 'Klienci' mamy kolumnę 'ID_klienta'. To jest dobry klucz podstawowy, bo każdy klient musi mieć swój własny numer, żeby nie było sytuacji, gdzie dwóch klientów ma ten sam identyfikator. Gdyby klucz podstawowy był taki sam dla różnych rekordów, mogłoby to wywołać spore zamieszanie przy aktualizacjach czy usuwaniu danych. Warto też pamiętać, że są takie rzeczy jak indeksy, które mogą pomóc w zapewnieniu, że klucz podstawowy jest unikalny i przyspiesza wyszukiwanie danych. Można użyć kluczy naturalnych, które mają sens w kontekście danych, albo kluczy syntetycznych, które system tworzy sam, jak na przykład GUID-y. Z mojego doświadczenia, to znajomość tych zasad naprawdę pomaga w lepszym projektowaniu baz danych.

Pytanie 32

Jakiego wyniku można się spodziewać po wykonaniu zapytania na przedstawionej tabeli?

SELECTCOUNT(DISTINCT wykonawca)
FROM`muzyka`;

ID	tytul_plyty	wykonawca	rok_nagrania	opis
1	Czas jak rzeka	Czesław Niemen	2005	Przyjdź W Taka Noc itp.
2	Ikona	Stan Borys	2014
3	Aerolit	Czesław Niemen	2017	Winylowa reedycja płyty "Aerolit"
4	Journey	Mikołaj Czechowski	2013

A. 1

B. 0

C. 4

D. 3

Zapytanie SQL SELECT COUNT(DISTINCT wykonawca) FROM muzyka; służy do zliczenia unikalnych wartości w kolumnie wykonawca w tabeli muzyka. W kontekście dostarczonej tabeli istnieje trzech różnych wykonawców: Czesław Niemen Stan Borys i Mikołaj Czechowski. Funkcja COUNT w połączeniu z DISTINCT pozwala na zliczenie jedynie unikalnych wystąpień wartości co oznacza że pomimo dwukrotnego wystąpienia Czesława Niemena zostanie on policzony tylko raz. Takie podejście jest kluczowe w analizie danych gdzie istotne jest rozważenie jedynie niepowtarzających się wartości na przykład w analizach raportów dotyczących różnorodności portfolio wykonawców w wytwórni muzycznej. Dobre praktyki w SQL zalecają użycie DISTINCT w sytuacjach wymagających precyzyjnego określenia różnorodności danych w kolumnie co nie tylko wspiera dokładność analiz ale również optymalizuje wydajność zapytań poprzez redukcję ilości danych do przetworzenia. Zrozumienie tego mechanizmu jest istotne w zarządzaniu bazami danych oraz w analizach biznesowych.

Pytanie 33

W tabeli o nazwie pracownicy zdefiniowano klucz główny w typie INTEGER z atrybutami NOT NULL oraz AUTO_INCREMENT. Dodatkowo zdefiniowane zostały pola imie oraz nazwisko. W przypadku wykonania podanej kwerendy SQL, która dodaje dane i pomija pole klucza, w bazie danych MySQL nastąpi

INSERT INTO pracownicy (imie, nazwisko)
VALUES ('Anna', 'Nowak');

A. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana wartość NULL

B. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana kolejna wartość naturalna

C. zignorowanie polecenia, tabela nie ulegnie zmianie

D. błąd związany z niewłaściwą liczbą pól

W przypadku tabeli z kluczem głównym typu INTEGER z atrybutem AUTO_INCREMENT, kiedy wprowadzamy nowy rekord i pomijamy pole klucza głównego, baza danych MySQL sama automatycznie przydziela kolejną wartość liczbową dla tego pola. AUTO_INCREMENT to mechanizm, który zapewnia, że każdemu nowemu rekordowi przypisana jest unikalna wartość klucza głównego, zaczynając od wartości początkowej, zwykle 1, i zwiększając ją o 1 z każdym nowym rekordem. Jest to niezwykle użyteczne w sytuacjach, gdy zależy nam na unikalności wartości kluczy głównych, co zapewnia integralność danych i unika konieczności ręcznego określania wartości klucza przy każdym nowym wpisie. Takie podejście jest zgodne ze standardami dobrych praktyk, ponieważ minimalizuje ryzyko błędów związanych z duplikacją danych. Przykładowo, jeśli do tabeli pracownicy dodajemy rekord z danymi pracownika, nie musimy się martwić o wartość identyfikatora, co znacznie upraszcza proces zarządzania danymi. Mechanizm AUTO_INCREMENT jest zatem kluczowy w kontekście zarządzania bazami danych, zapewniając automatyzację i integralność danych.

Pytanie 34

Aby zwiększyć wydajność operacji na bazie danych, należy dla pól, które są często wyszukiwane lub sortowane

A. utworzyć indeks

B. dodać klucz obcy

C. stworzyć osobną tabelę przechowującą tylko te pola

D. dodać więzy integralności

Tworzenie indeksu na polach, które często przeszukujesz lub sortujesz, to naprawdę ważna rzecz, jeśli chodzi o wydajność baz danych. Indeksy działają trochę jak spis treści w książkach – pozwalają systemowi szybko znaleźć te dane, których potrzebujesz, bez przeszukiwania całego folderu. Dzięki nim zapytania SELECT mogą iść jak burza, co ma ogromne znaczenie w aplikacjach, gdzie liczy się czas. Przykład? Jeśli zrobisz indeks na kolumnie 'email' w tabeli 'Users', to znacznie szybciej odnajdziesz użytkowników po adresie email. W praktyce warto też regularnie monitorować, jak działają te indeksy i je optymalizować, na przykład usuwając te, które są zbędne, żeby nie przeciążać bazy danych. Dobrze jest pamiętać, że przy dodawaniu lub aktualizowaniu danych, indeksy mogą trochę spowolnić działanie, więc lepiej używać ich z głową.

Pytanie 35

W jaki sposób można ocenić normalizację przedstawionej tabeli?

FirmaAdres
Forbotul. Krótka 11, 22-222 Warszawa
Marbotul. Długa 5, 33-333 Warszawa

A. Tabela znajduje się w pierwszej postaci normalnej

B. Tabela jest w trzeciej postaci normalnej

C. Tabela nie została znormalizowana

D. Tabela znajduje się w drugiej postaci normalnej

Pierwsza postać normalna wymaga aby wszystkie wartości atrybutów w rekordzie były atomowe czyli nieredukowalne Tabela przedstawiona w zadaniu nie spełnia tego wymogu ponieważ adresy nie są rozbite na osobne elementy takie jak ulica miasto i kod pocztowy co uniemożliwia bardziej złożoną manipulację danymi oraz precyzyjne wyszukiwanie Druga postać normalna wymaga aby wszystkie atrybuty nie będące częścią klucza głównego były w pełni funkcjonalnie zależne od całego klucza Tabela z pytania nie spełnia tych kryteriów ponieważ istnieje redundancja i brak wyraźnej struktury Klucz główny w dobrze zaprojektowanej tabeli bazy danych powinien jednoznacznie identyfikować każdy wiersz co nie jest widoczne w tej strukturze Trzecia postać normalna idzie krok dalej eliminując zależności przechodnie między atrybutami co w przypadku tej tabeli również nie ma zastosowania Problemem tutaj jest brak rozdzielenia danych na mniejsze tabele co prowadzi do redundancji i potencjalnych błędów przy aktualizacji danych często określanych jako anomaly W dobrze znormalizowanej bazie danych oddzielenie informacji takich jak dane adresowe umożliwia lepszą organizację danych ich spójność oraz zwiększa efektywność operacji na bazie danych

Pytanie 36

Fragment kodu SQL wskazuje, że klucz obcy

… FOREIGN KEY (imie) REFERENCES obiekty (imiona) …

A. znajduje się w tabeli obiekty

B. jest odniesieniem do siebie samego

C. jest przypisany do kolumny obiekty

D. wiąże się z kolumną imiona

Odpowiedź wskazująca, że klucz obcy łączy się z kolumną 'imiona' jest prawidłowa, ponieważ definicja klucza obcego w SQL stanowi, że odwołuje się on do kolumny w innej tabeli, w tym przypadku do kolumny 'imiona' w tabeli 'obiekty'. Klucz obcy jest używany do ustanowienia relacji między dwiema tabelami, co poprawia integralność danych i umożliwia tworzenie bardziej złożonych zapytań. Na przykład, jeśli mamy tabelę 'uczniowie' z kolumną 'imie', a tabela 'obiekty' zawiera kolumnę 'imiona' jako klucz podstawowy, to możemy użyć klucza obcego, aby zapewnić, że każde imię w tabeli 'uczniowie' odnosi się do istniejącego rekordu w tabeli 'obiekty'. Dobrą praktyką jest zawsze stosowanie kluczy obcych w celu minimalizacji błędów danych i zapewnienia ich spójności. Użycie kluczy obcych jest zgodne z zasadami normalizacji baz danych, które dążą do eliminacji redundancji i poprawy organizacji danych.

Pytanie 37

Na podstawie tabeli Towar wykonano następujące zapytanie SQL. Jaki będzie wynik tej operacji?

 SELECT nazwa_towaru FROM `Towar` WHERE cena_katalogowa < 65 ORDER BY waga DESC;

ID	nazwa_towaru	cena_katalogowa	waga	kolor
1	Papier ksero A4	11	2.3	biel
2	Zeszyt A5	4.2	0.13	wielokolorowy
3	Zeszyt A5 w linie	3.5	0.12	niebieski
4	Kredki 24 kolory	9	0.3	wielokolorowy
5	Plecak szkolny	65.5	1.3	zielony

A. Papier ksero A4, Kredki 24 kolory, Zeszyt A5, Zeszyt A5 w linie

B. Zeszyt A5, Zeszyt A5 w linie, Kredki 24 kolory, Papier ksero A4

C. Zeszyt A5 w linie, Zeszyt A5, Kredki 24 kolory, Papier ksero A4

D. Papier ksero A4, Kredki 24 kolory, Zeszyt A5 w linie, Zeszyt A5

Twoja odpowiedź jest niepoprawna. Wydaje się, że nie zrozumiałeś, jak działa zapytanie SQL w kontekście selekcji i sortowania danych. Zapytanie to zwracałoby nazwy towarów, które spełniają warunek ceny katalogowej mniejszej niż 65. Następnie sortuje te towary od najcięższego do najlżejszego. W przypadku podanej tabeli towary, które spełniają te warunki to: Papier ksero A4 (waga 2.3), Kredki 24 kolory (waga 0.3), Zeszyt A5 (waga 0.13) i Zeszyt A5 w linie (waga 0.12). Błędne odpowiedzi sugerują, że nie zrozumiałeś, w jaki sposób zapytanie SQL sortuje wyniki na podstawie wagi. Istotne jest zrozumienie, że SQL pozwala na filtrowanie danych za pomocą różnych operatorów, takich jak 'mniejszy od', a następnie sortowanie tych wyników za pomocą różnych kryteriów. W tym przypadku sortowanie odbywa się od najcięższego do najlżejszego towaru. Upewnij się, że rozumiesz te koncepcje, ponieważ są one kluczowe w pracy z bazami danych.

Pytanie 38

W bazie danych samochodów pole kolor z tabeli samochody przyjmuje wartości kolorów jedynie ze słownika lakier. Aby połączyć tabele samochody i lakier relacją należy, zastosować kwerendę

A. ALTER TABLE samochody
   ADD FOREIGN KEY kolor REFERENCES lakier;

B. ALTER TABLE samochody
   ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);

C. ALTER TABLE samochody
   ADD FOREIGN KEY barwa REFERENCES samochody.lakier;

D. ALTER TABLE lakier
   ADD FOREIGN KEY (barwa) REFERENCES samochody(kolor);

A. A.

B. C.

C. B.

D. D.

Odpowiedź B jest prawidłowa, ponieważ ciało odpowiedzi zawiera prawidłową składnię SQL do połączenia dwóch tabel: 'samochody' i 'lakier'. W przypadku relacji między tabelami, klucz obcy w jednej tabeli odpowiada kluczowi głównemu w drugiej tabeli. W tym przypadku, pole 'kolor' w tabeli 'samochody' jest kluczem obcym, który odwołuje się do klucza głównego w tabeli 'lakier' (założenie: 'lakierId'). W praktyce, połączenie tabel na podstawie relacji między kluczem obcym a kluczem głównym jest fundamentalnym aspektem projektowania bazy danych, umożliwiającym sprawną organizację i odnajdywanie danych. Dobrą praktyką jest utrzymanie integralności referencyjnej, zapewniającej, że relacje między tabelami są zawsze spójne. To z kolei umożliwia realizację zapytań złożonych, które łączą dane z wielu tabel w celu uzyskania potrzebnych informacji.

Pytanie 39

Który z czynników ma negatywny wpływ na efektywną współpracę w zespole?

A. podział ról i obowiązków

B. efektywna komunikacja

C. rywalizacja między członkami zespołu

D. wzajemny szacunek

Wzajemny szacunek, skuteczna komunikacja oraz przydzielenie ról i odpowiedzialności to kluczowe elementy, które wspierają dobrą współpracę w zespole. Wzajemny szacunek zapewnia, że członkowie zespołu czują się doceniani, co zwiększa ich motywację do pracy i otwartość na pomysły innych. Skuteczna komunikacja to fundament, na którym opiera się każdy projekt; możliwość wymiany informacji, konstruktywnej krytyki oraz współpracy w podejmowaniu decyzji to elementy, które podnoszą jakość pracy zespołu. Przydzielenie ról i odpowiedzialności pozwala na klarowne określenie oczekiwań i zadań, co minimalizuje chaos i sprzyja efektywności. Zrozumienie, że współpraca opiera się na zaufaniu oraz otwartości, jest kluczowe dla sukcesu. Często zespoły, które nie wdrażają tych zasad, doświadczają nieporozumień, co prowadzi do konfliktów oraz frustracji. Przykładem może być sytuacja, w której członkowie zespołu nie znają jasno swoich ról, co prowadzi do powielania działań lub pomijania ważnych zadań, marnując czas i zasoby. Aby zapobiec takim problemom, zespoły powinny regularnie spotykać się w celu omówienia postępów, oczekiwań oraz wszelkich trudności, które mogą się pojawić, co pomaga w budowaniu pozytywnej atmosfery i wspólnej odpowiedzialności za projekt.

Pytanie 40

Jakiego rodzaju oprogramowanie narzędziowe powinno być zainstalowane, aby umożliwić użytkownikowi przeprowadzanie operacji na zgromadzonych danych?

A. Obiektowy System Zarządzania Bazą Danych

B. Otwarty mechanizm komunikacji bazy danych

C. System Zarządzania Bazą Danych (SZBD)

D. Klucz obcy

Klucz obcy to dość ciekawe zagadnienie, które dotyczy relacji między tabelami w bazach danych. Dzięki niemu można powiązać różne rekordy, ale nie jest to coś, co działa samodzielnie. To nie jest jakieś oprogramowanie, które można zainstalować i oczekiwać, że wszystko będzie działać. Z kolei Obiektowy System Zarządzania Bazą Danych (OSZBD) to inny temat, który opiera się na podejściu obiektowym. Może być przydatny, ale nie jest powszechnym rozwiązaniem. Samo otwarte mechanizmy komunikacji bazy danych też w sumie nie zapewnia skutecznego zarządzania danymi. Błędem jest myślenie, że wybór nieodpowiednich elementów, takich jak klucz obcy czy te mechanizmy, załatwi sprawę. Efektywna praca z danymi w praktyce wymaga wyboru SZBD, który jest stworzony do tego, żeby skutecznie zarządzać danymi i nie pomijanie tego prowadzi do nieporozumień.

Rozpocznij nowy egzamin

Powrót do strony głównej