Wyniki egzaminu

Informacje o egzaminie:
  • Zawód: Technik informatyk
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 23 kwietnia 2026 10:04
  • Data zakończenia: 23 kwietnia 2026 10:07

Egzamin niezdany

Wynik: 6/40 punktów (15,0%)

Wymagane minimum: 20 punktów (50%)

Nowe
Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania
Udostępnij swój wynik
Szczegółowe wyniki:
Pytanie 1

Aby stworzyć warunek w zapytaniu wybierającym nazwiska wszystkich uczniów z klas początkowych (od pierwszej do trzeciej), można zastosować klauzulę

A. WHERE klasa >= 1 OR klasa <= 3
B. WHERE klasa IN (1, 3)
C. WHERE klasa BETWEEN 1 AND 3
D. WHERE klasa < 3
Zestawienie innych odpowiedzi w kontekście tego zapytania ujawnia typowe nieporozumienia dotyczące logiki operacji SQL. Klauzula "WHERE klasa < 3" jest nieprawidłowa, ponieważ obejmuje jedynie klasy 1 i 2, co oznacza, że nie uwzględnia uczniów z klasy 3, a więc nie spełnia wymagań pytania. Również użycie klauzuli "WHERE klasa IN (1, 3)" jest mylące, ponieważ wybiera tylko uczniów z klasy 1 i 3, pomijając klasę 2, co jest sprzeczne z definicją klas nauczania początkowego. Kolejna odpowiedź, "WHERE klasa >= 1 OR klasa <= 3", generuje dodatkowe zamieszanie, ponieważ jest logicznie błędna; w praktyce ten warunek zawsze będzie prawdziwy dla wszystkich klas, ponieważ każda klasa będzie spełniać przynajmniej jeden z tych warunków, co prowadzi do zwrócenia wszystkich uczniów, a nie tylko tych z nauczania początkowego. Takie nieprawidłowe użycie operatorów może prowadzić do nieefektywnych zapytań oraz zwiększonego obciążenia bazy danych, a także do niezamierzonych wyników. W przypadku pracy z bazami danych kluczowe jest zrozumienie, jak różne klauzule wpływają na zestaw danych i jakie mogą przynieść konsekwencje w kontekście wyników, co często wymaga starannej analizy oraz testowania zapytań przed ich wdrożeniem.

Pytanie 2

W tabeli pracownicy zdefiniowano klucz główny jako INTEGER z atrybutami NOT NULL oraz AUTO_INCREMENT. Dodatkowo zdefiniowano kolumny imie oraz nazwisko. W przypadku wykonania poniższej kwerendy SQL wprowadzającej dane, w której pominięto pole klucza, w bazie danych MySQL wystąpi:

INSERT INTO pracownicy (imie, nazwisko) VALUES ('Anna', 'Nowak');
A. ignorowanie polecenia, tabela nie ulegnie zmianie
B. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana wartość NULL
C. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana kolejna wartość naturalna
D. błąd związany z nieprawidłową liczbą kolumn
Kiedy pomijasz wartość klucza głównego w instrukcji INSERT, to naprawdę może to prowadzić do zamieszania, jeśli nie rozumiesz, jak działają klucze w bazach danych. Mówienie, że pojawi się błąd z nieprawidłową liczbą pól, to tak, jakbyś nie znał zasad działania tabel w MySQL. Jak masz klucz główny ustawiony na AUTO_INCREMENT, to naprawdę nie musisz go podawać, bo system zrobi to za Ciebie. Powinieneś wiedzieć, że klucz główny jest mega ważny do identyfikacji rekordów w tabeli i jest potrzebny, żeby wszystko działało jak należy. Z kolei druga błędna odpowiedź, która mówi, że MySQL zignoruje polecenie, pokazuje, że nie łapiesz koncepcji, jak silnik bazy danych zajmuje się brakującymi danymi. MySQL nie zignoruje tego, tylko zareaguje i przydzieli nową wartość klucza. A jeszcze jedna rzecz – przypisanie wartości NULL do klucza głównego to już w ogóle zła droga, bo klucz musi być unikalny i nigdy nie może być pusty. Tego rodzaju myślenie wskazuje na typowe błędy, które wynikają z niepełnego rozumienia działania kluczy w bazach danych i jak to się ma do wprowadzania nowych rekordów.

Pytanie 3

Konstrukcja w języku SQL ALTER TABLE USA... służy do

A. usunięcia tabeli USA
B. stworzenia nowej tabeli USA
C. nadpisania istniejącej tabeli USA
D. zmiany tabeli USA
Istnieje kilka mitów oraz powszechnych nieporozumień dotyczących polecenia ALTER TABLE, które mogą prowadzić do błędnych wniosków. Na przykład, usunięcie tabeli nie jest możliwe za pomocą ALTER TABLE, ponieważ do tego celu służy osobne polecenie DROP TABLE, które całkowicie eliminuje tabelę oraz wszystkie przechowywane w niej dane. Użytkownicy często mylą też modyfikację tabeli z jej nadpisywaniem, co jest błędne, ponieważ ALTER TABLE modyfikuje istniejącą strukturę tabeli, a nie ją zastępuje. Z kolei tworzenie nowej tabeli odbywa się za pomocą polecenia CREATE TABLE, co jest kompletnie odmiennym działaniem i nie ma związku z ALTER TABLE. Ważne jest, aby zrozumieć, że ALTER TABLE nie zmienia semantyki danych ani nie wpływa na istniejące rekordy w sposób destrukcyjny, chyba że podejmie się decyzję o usunięciu kolumn, co oczywiście wiąże się z utratą danych. Typowe błędy myślowe, które prowadzą do złych interpretacji, wynikają z niepełnego zrozumienia definicji dostępnych poleceń SQL oraz ich funkcji. W związku z tym, gruntowne opanowanie podstawowych poleceń SQL oraz ich kontekstu jest kluczowe do skutecznego zarządzania danymi w systemach bazodanowych.

Pytanie 4

Która wartość tekstowa nie pasuje do podanego w ramce wzorca wyrażenia regularnego?

(([A-ZŁŻ][a-ząęóżźćńłś]{2,})(-[A-ZŁŻ][a-ząęóżźćńłś]{2,})?)
A. Jelenia Góra
B. Nowakowska-Kowalska
C. Kasprowicza
D. Kowalski
Wszystkie pozostałe wartości tekstowe, takie jak Kowalski, Kasprowicza oraz Nowakowska-Kowalska, spełniają wymagania określone przez wzorzec wyrażenia regularnego. Kowalski to przykład pojedynczego nazwiska, które zaczyna się od dużej litery oraz zawiera wystarczającą liczbę małych liter, co czyni je poprawnym. Kasprowicza również jest poprawne, gdyż zawiera dużą literę na początku, a następnie dwa znaki małe, co jest zgodne z wymaganiami. Dodatkowo, oba nazwiska nie zawierają spacji ani innych znaków, które mogłyby zakłócić strukturę wyrażenia regularnego. Nowakowska-Kowalska jest przykładem podwójnego nazwiska, które jest również zgodne z wzorcem, ponieważ składa się z dwóch części, oddzielonych znakiem '-' i każda z nich zaczyna się od dużej litery, a następnie zawiera co najmniej dwa znaki małe. Obie części nazwiska spełniają wymagania dotyczące polskich znaków diakrytycznych oraz ilości liter, dlatego są one uznawane za poprawne. W związku z tym, nieprawidłowa odpowiedź 'Jelenia Góra' wyróżnia się jako jedyna, która narusza zasady ustalone przez wzorzec.

Pytanie 5

Jaką funkcję pełni funkcja CONCAT() w SQL?

A. wyodrębnianie podłańcucha znaków z tekstu wejściowego
B. przycinanie tekstu wyświetlanego
C. łącznienie tekstu wyświetlanego
D. usuwanie określonego tekstu
Wybór odpowiedzi, która twierdzi, że CONCAT() służy do przycinania tekstu, to typowe nieporozumienie. Ta funkcja wcale nie ma na celu zmniejszania długości łańcuchów tekstowych. Przycinanie to coś innego – tam usuwa się zbędne znaki na początku lub końcu ciągu, i korzysta się z funkcji jak TRIM(), LEFT() albo RIGHT(). Jeśli chcesz dobrze przetwarzać dane, to warto zrozumieć, że różne funkcje działają w różnych celach. Odpowiedź mówiąca o usuwaniu tekstu też jest nietrafiona, bo CONCAT() jedynie łączy ciągi, a usuwanie można zrobić innymi metodami, takimi jak REPLACE() czy SUBSTRING(). Co więcej, wyodrębnianie fragmentów tekstu to już domena funkcji jak SUBSTRING() czy CHARINDEX(), które pozwalają na wyciąganie konkretnych elementów według ustalonych kryteriów. Zrozumienie tych różnic jest kluczowe, żeby dobrze korzystać z funkcji tekstowych i zarządzać danymi w SQL.

Pytanie 6

Określenie powiązań między tabelami w bazie danych MySQL realizuje klauzula

A. INDEX
B. PRIMARY KEY
C. REFERENCES
D. ORDER BY
Klauzula REFERENCES w systemie bazodanowym MySQL jest kluczowym elementem, który umożliwia ustanawianie relacji pomiędzy tabelami. Jej główną funkcją jest definiowanie kluczy obcych, które zapewniają referencyjną integralność danych. Klucz obcy wskazuje na kolumnę w innej tabeli, co pozwala na powiązanie dwóch zestawów danych. Na przykład, jeśli mamy tabelę 'Zamówienia', która zawiera kolumnę 'KlientID', możemy użyć klauzuli REFERENCES, aby wskazać, że ta kolumna odnosi się do kolumny 'ID' w tabeli 'Klienci'. Dzięki temu, przy dodawaniu lub aktualizowaniu rekordów w tabeli 'Zamówienia', system MySQL będzie sprawdzać, czy 'KlientID' ma odpowiadający mu rekord w tabeli 'Klienci'. Takie powiązanie zapobiega błędom związanym z nieistniejącymi danymi i umożliwia bardziej złożone zapytania, które łączą dane z różnych tabel. Klauzula REFERENCES jest częścią szerszych standardów SQL, które ułatwiają zarządzanie relacyjnymi bazami danych i są kluczowe w projektowaniu złożonych struktur danych.

Pytanie 7

W tabeli mieszkańcy zawierającej pola id, imie, nazwisko, ulica, numer, czynsz (wartość całkowita) należy zidentyfikować osoby zamieszkujące ulicę Mickiewicza pod numerami 71, 72, 80, których czynsz jest niższy niż
1000 zł. Jak będzie wyglądać klauzula WHERE w zapytaniu?

A. WHERE ulica = 'Mickiewicza' OR numer IN (71, 72, 80) OR czynsz < 1000
B. WHERE ulica = 'Mickiewicza' AND numer > 70 AND numer < 81 OR czynsz < 1000
C. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) OR czynsz < 1000
D. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) AND czynsz < 1000
Pojawiające się w odpowiedziach błędne koncepcje mogą prowadzić do niepoprawnych wyników w zapytaniach SQL, co jest istotne z punktu widzenia analizy danych. W przypadku użycia operatora OR, jak w niektórych z przedstawionych odpowiedzi, skutkuje to potencjalnym zwróceniem danych, które nie spełniają wszystkich wymaganych kryteriów. Na przykład, jeżeli zastosujemy klauzulę WHERE z OR, system zwróci wszystkie rekordy, które są na ulicy 'Mickiewicza' lub mają numer 71, 72 lub 80, niezależnie od wartości czynszu. To może prowadzić do błędnych interpretacji i niepoprawnych raportów. Podobnie, użycie warunków numerycznych, jak 'numer > 70 AND numer < 81', w połączeniu z OR dla czynszu, również nie dostarcza precyzyjnych wyników, ponieważ czyni je zbyt ogólnymi. Takie podejście może prowadzić do zwrócenia danych, które nie są zgodne z zamierzonymi kryteriami, co jest sprzeczne z zasadą maksymalnej precyzji w zapytaniach SQL. Dobre praktyki w programowaniu SQL wymagają, by warunki były ściśle określone i logicznie powiązane, aby zapewnić klarowność oraz wydajność zapytań. Błędy takie mogą prowadzić do nieefektywności w przetwarzaniu danych oraz do podejmowania niewłaściwych decyzji na podstawie niepoprawnych informacji.

Pytanie 8

W języku SQL, w wyniku wykonania poniższego zapytania:

ALTER TABLE osoba DROP COLUMN grupa;
A. zostanie dodana kolumna grupa
B. zostanie zmieniona nazwa tabeli na grupa
C. zostanie usunięta kolumna grupa
D. zostanie zmieniona nazwa kolumny na grupa
Pierwsza odpowiedź sugeruje, że kolumna 'grupa' zostanie dodana do tabeli, co jest błędne, ponieważ użycie słowa 'DROP' sugeruje usunięcie, a nie dodanie. W SQL do dodawania kolumn używa się komendy 'ADD', a nie 'DROP'. Druga odpowiedź, która stwierdza, że kolumna zostanie usunięta, jest poprawna, ale nie są podane inne aspekty jej działania. Trzecia odpowiedź dotyczy zmiany nazwy tabeli na 'grupa', co również jest niepoprawne, ponieważ komenda 'ALTER TABLE' z 'DROP COLUMN' nie ma na celu zmiany nazwy tabeli, lecz jedynie modyfikację jej struktury poprzez usunięcie kolumny. Zmiana nazwy tabeli wymagałaby użycia komendy 'RENAME'. Ostatnia odpowiedź, która mówi, że zmienia nazwę kolumny na 'grupa', jest również fałszywa, ponieważ do zmiany nazwy kolumny w SQL używa się komendy 'ALTER COLUMN' z 'RENAME', a nie 'DROP'. Tak więc, wszystkie te odpowiedzi zawierają błędne interpretacje dotyczące funkcji komendy 'ALTER TABLE DROP COLUMN', a zrozumienie tej komendy jest kluczowe dla prawidłowego zarządzania strukturą bazy danych.

Pytanie 9

Jakie polecenie SQL zmieni w tabeli tab wartość w kolumnie kol z Ania na Zosia?

A. UPDATE tab SET kol = 'Zosia' WHERE kol = 'Ania'
B. UPDATE tab SET kol = 'Ania' WHERE kol = 'Zosia'
C. ALTER TABLE tab CHANGE kol = 'Zosia' kol = 'Ania'
D. ALTER TABLE tab CHANGE kol = 'Ania' kol = 'Zosia'
Podane odpowiedzi, które nie wykorzystują odpowiedniej składni SQL lub koncepcji manipulacji danymi, są błędne. Na przykład, aktualizacja wartości 'Ania' na 'Zosia' za pomocą polecenia UPDATE tab SET kol = 'Ania' WHERE kol = 'Zosia' nie tylko nie osiągnie zamierzonego celu, ale również wprowadzi w błąd. W rzeczywistości, polecenie to nie zmieni żadnych danych, ponieważ nie ma rekordów, w których kolumna 'kol' zawierałaby wartość 'Zosia', a polecenie próbuje ustawić ją na 'Ania'. Z kolei użycie ALTER TABLE do zmiany wartości w kolumnie jest całkowicie niewłaściwe, ponieważ to polecenie służy do zmiany struktury tabeli, a nie danych w niej zawartych. Alteracja struktury bazy danych jest fundamentalnie różna od aktualizacji wartości w wierszach. Zrozumienie różnicy między tymi dwoma typami operacji jest kluczowe dla efektywnego zarządzania bazami danych. Typowe błędy myślowe obejmują mylenie operacji na danych z operacjami na strukturze bazy danych, co prowadzi do nieefektywnego i błędnego kodowania. Warto także zwrócić uwagę na zapewnienie integralności danych i stosowanie właściwych kryteriów, aby uniknąć przypadkowych modyfikacji lub usunięć danych.

Pytanie 10

Jakie zadanie wykonuje funkcja COUNT w języku SQL?

A. obliczenie wartości bezwzględnej w polu liczbowym
B. wyliczenie średniej wartości w danej kolumnie
C. liczenie znaków w polu tekstowym
D. zliczanie rekordów uzyskanych z kwerendy
Pierwsza z niepoprawnych odpowiedzi sugeruje, że funkcja COUNT zlicza znaki w polu tekstowym, co jest błędnym podejściem do definicji tej funkcji. W rzeczywistości, COUNT jest funkcją agregującą, która operuje na rekordach, a nie na pojedynczych znakach w danym polu. Aby zliczyć znaki, można użyć funkcji LEN lub CHAR_LENGTH, które są dedykowane do obliczania długości tekstu. Druga niepoprawna odpowiedź odnosi się do obliczania średniej wartości w kolumnie, co również jest nieprawidłowe. Funkcja do obliczania średniej wartości to AVG, która działa na liczbowych danych w wybranej kolumnie, a nie COUNT, który jedynie zlicza rekordy. Trzecia niepoprawna odpowiedź sugeruje obliczenie wartości bezwzględnej, co jest również mylące. Funkcje służące do obliczania wartości bezwzględnej to ABS, a nie COUNT. W kontekście SQL, istotne jest zrozumienie, że każda funkcja ma swoje konkretne przeznaczenie i należy je stosować zgodnie z ich definicjami, aby uzyskać prawidłowe wyniki w analizie danych.

Pytanie 11

W relacyjnych systemach baz danych, gdy dwie tabele są powiązane przez ich klucze główne, mamy do czynienia z relacją

A. 1..1
B. n..1
C. 1..n
D. n..n
Błędne odpowiedzi 1..n, n..1 oraz n..n wskazują na różne typy relacji, które nie odpowiadają sytuacji opisanej w pytaniu. Relacja 1..n sugeruje, że jeden rekord w pierwszej tabeli może być powiązany z wieloma rekordami w drugiej tabeli. Przykładem może być relacja między tabelą 'Klienci' i 'Zamówienia', gdzie każdy klient może mieć wiele zamówień. Tego typu relacja nie jest możliwa z kluczem głównym, ponieważ klucz główny jest unikalny dla każdego rekordu. Podobnie, relacja n..1 oznacza, że wiele rekordów w pierwszej tabeli odnosi się do jednego rekordu w drugiej. Może to być interpretowane w kontekście danych, gdzie wiele produktów może być przypisanych do jednego dostawcy. W kontekście kluczy głównych, to również jest niepoprawne, ponieważ klucz główny w jednej tabeli powinien jednoznacznie identyfikować każdy rekord. Natomiast relacja n..n, która oznacza wiele rekordów w obu tabelach, jest również błędna w tym przypadku. Przykładem może być relacja między 'Użytkownikami' i 'Grupami', gdzie użytkownicy mogą należeć do wielu grup, a grupy mogą mieć wielu użytkowników. Żaden z tych typów relacji nie bierze pod uwagę unikalnych powiązań, które można osiągnąć tylko poprzez relację 1..1. Często błędy te wynikają z niepełnego zrozumienia zasad normalizacji baz danych oraz specyficznych zastosowań kluczy głównych, co prowadzi do błędnych wniosków o strukturze danych.

Pytanie 12

W języku SQL, aby wybrać wszystkie rekordy z tabeli B, w tym część wspólną z tabelą A, należy zastosować typ związku

Ilustracja do pytania
A. A FULL OUTER JOIN B
B. A LEFT JOIN B
C. A INNER JOIN B
D. A RIGHT JOIN B
W tym pytaniu pułapka polega na tym, że łatwo pomylić pojęcie części wspólnej z całością jednego ze zbiorów. Diagram pokazuje całą tabelę B (włącznie z przecięciem z A), a nie tylko przecięcie. W SQL typ złączenia określa, z której tabeli bierzemy wszystkie rekordy, a z której tylko te pasujące. To, że widzimy też obszar wspólny, jest naturalnym efektem działania złączeń zewnętrznych, ale nie oznacza jeszcze, że chodzi o `INNER JOIN`. Jeśli ktoś wybiera `A LEFT JOIN B`, to zwykle wynika z myślenia „chcę część wspólną i coś jeszcze”, ale myli kierunek. `LEFT JOIN` gwarantuje wszystkie rekordy z **lewej** tabeli (A), a z prawej (B) tylko dopasowane. Diagram z pytania pokazuje dokładnie odwrotną sytuację: komplet danych z B, a z A tylko tam, gdzie istnieje relacja. `A LEFT JOIN B` odpowiadałoby sytuacji, gdzie podświetlony jest cały zbiór A i przecięcie, a nie B. Z kolei `A INNER JOIN B` zwróciłby wyłącznie część wspólną A∩B, czyli tylko te rekordy, które mają dopasowanie po obu stronach. Na diagramie byłby wtedy zaznaczony wyłącznie środek, a nie cały zielony obszar B. To typowy błąd: utożsamianie każdego JOIN z „częścią wspólną”. INNER JOIN jest dobry, gdy interesują nas tylko powiązane dane (np. zamówienia, które mają istniejącego klienta), ale w zadaniu wyraźnie mowa o „wszystkich rekordach z B”. `A FULL OUTER JOIN B` idzie w drugą stronę – zwraca wszystko z A **i** wszystko z B, niezależnie od tego, czy jest dopasowanie, czy nie. To byłby diagram z zaznaczonymi obiema kółkami, czyli suma zbiorów A∪B. W standardzie SQL taki typ złączenia jest opisany jako pełne złączenie zewnętrzne i stosuje się go rzadziej, np. do porównywania różnic między dwiema tabelami. Tutaj jest to za szeroki zakres danych w stosunku do pytania. Poprawne podejście wymaga więc skojarzenia, że skoro chcemy wszystkie rekordy z tabeli B, to w zapisie `A ... JOIN B` tabela B musi być po tej stronie, która jest „obowiązkowa”. Właśnie to zapewnia `RIGHT JOIN`: pełny zestaw wierszy z prawej tabeli, plus dopasowania z lewej tam, gdzie istnieją. Świadome operowanie tymi pojęciami bardzo ułatwia projektowanie zapytań raportowych i unikanie nieoczekiwanych braków lub duplikacji danych.

Pytanie 13

W aplikacji PHP, która zarządza bazą danych, aby uzyskać numer błędu oraz jego opis po dokonaniu jakiejkolwiek operacji, jakie funkcje powinny być wykorzystane?

A. funkcje mysqli_error i mysqli_errno
B. funkcje mysqli_error i mysqli_error_number
C. tylko funkcję mysqli_error
D. funkcje mysqli_error i mysqli_connect_errno
Wybór funkcji mysqli_error i mysqli_connect_errno nie jest właściwy, ponieważ mysqli_connect_errno jest funkcją przeznaczoną do uzyskiwania numeru błędu połączenia z bazą danych, a nie błędu SQL. Użycie tej funkcji w kontekście operacji na bazie danych prowadzi do mylnego wniosku, że jej zastosowanie jest uniwersalne dla wszystkich błędów. W rzeczywistości, mysqli_connect_errno powinno być stosowane głównie podczas nawiązywania połączenia, natomiast dla błędów związanych z zapytaniami SQL właściwe są inne funkcje. Z kolei wskazanie tylko na funkcję mysqli_error nie jest wystarczające, ponieważ sama dostarcza jedynie opisu błędu, a nie jego numeru, co ogranicza możliwości analizy i diagnostyki. Użytkownicy często popełniają błąd myślowy, zakładając, że pojedyncza funkcja może spełnić wszystkie potrzeby związane z obsługą błędów. W prawidłowym procesie zarządzania błędami w programowaniu, kluczowe jest użycie zestawu funkcji, które dostarczają zarówno opisy, jak i kody błędów, co pozwala na bardziej wszechstronną reakcję na różne sytuacje awaryjne. Ignorowanie tej zasady może prowadzić do nieefektywnego debugowania i długotrwałych problemów w działaniu aplikacji.

Pytanie 14

Wbudowanym w pakiet XAMPP narzędziem służącym do zarządzania bazą danych jest

A. phpMyAdmin
B. pgAdmin
C. MySQL Workbench
D. SQLite
W tym pytaniu łatwo się pomylić, bo wszystkie podane nazwy są w jakiś sposób związane z bazami danych, ale tylko jedna z nich jest faktycznie wbudowana w XAMPP jako standardowe narzędzie. XAMPP to pakiet, który ma ułatwić uruchomienie lokalnego środowiska serwerowego (Apache, PHP, MySQL/MariaDB itd.) jednym instalatorem. Jego celem jest „postawienie” gotowego stosu webowego na komputerze programisty. Z tego powodu twórcy XAMPP dołączyli phpMyAdmin, bo jest lekkie, webowe i napisane w PHP, więc idealnie pasuje do tego ekosystemu. MySQL Workbench bywa mylony z narzędziami w XAMPP, bo też służy do zarządzania MySQL, ale jest to osobna, natywna aplikacja instalowana oddzielnie, dostarczana przez Oracle. Nie jest częścią XAMPP, nie uruchamia się z panelu XAMPP i nie działa w przeglądarce. To bardziej rozbudowane środowisko do projektowania schematów, administrowania serwerami MySQL, analizowania wydajności. Dla wielu początkujących wygląda „profesjonalniej”, ale w typowej instalacji XAMPP go po prostu nie ma. pgAdmin z kolei jest narzędziem do zarządzania PostgreSQL, a XAMPP domyślnie korzysta z MySQL/MariaDB, nie z PostgreSQL. Stąd pgAdmin nie ma żadnego naturalnego powiązania z XAMPP, występuje raczej w pakietach, które celują w środowisko PostgreSQL (np. instalatory Postgresa). Wybranie tej odpowiedzi zwykle wynika z myślenia: „to jakieś narzędzie do bazy, więc pewnie będzie pasować”, ale tu trzeba zwracać uwagę na konkretny silnik bazy danych. SQLite natomiast nie jest nawet narzędziem administracyjnym, tylko samym silnikiem bazy danych, w dodatku wbudowanym, plikowym. Można z niego korzystać w PHP, ale nie ma tu mowy o tym, że byłby to graficzny panel w XAMPP. Typowy błąd polega na wrzuceniu do jednego worka „wszystko co ma coś wspólnego z bazami” i zakładaniu, że to będzie interfejs do zarządzania. W praktyce warto rozróżniać: silnik bazy (MySQL, MariaDB, PostgreSQL, SQLite) od narzędzia klienckiego/administracyjnego (phpMyAdmin, MySQL Workbench, pgAdmin). W XAMPP, jako narzędzie wbudowane, występuje właśnie phpMyAdmin i to jego nazwę trzeba kojarzyć bezpośrednio z tym pakietem.

Pytanie 15

W tabeli produkt znajdują się artykuły wyprodukowane po roku 2000, posiadające pola nazwa oraz rok_produkcji. Jakie zapytanie SQL pokaże listę artykułów wyprodukowanych?

Ilustracja do pytania
A. w roku 2017
B. przed rokiem 2017
C. w latach innych niż 2017
D. po roku 2017
Analizując działanie zapytania SQL niektóre z błędnych odpowiedzi wynikają z nieprawidłowego zrozumienia funkcji SUBSTR. Funkcja ta pobiera podciąg z konkretnej pozycji w ciągu znaków. W przypadku zapytania SELECT * FROM produkt WHERE SUBSTR(rok_produkcji3 2)=17; zapytanie koncentruje się na dwóch cyfrach rozpoczynających się od trzeciej pozycji. Błędne podejście polegające na sądzeniu że zapytanie wybiera przedmioty wyprodukowane po roku 2017 wynika z braku uwzględnienia faktu że operacja porównania jest wykonywana na wyekstraktowanym podciągu a nie na całym roku. To prowadzi do konkluzji że tylko przedmioty z końcówką roku 17 będą zwrócone. Inne błędne rozumienie sugeruje że przedmioty produkowane przed rokiem 2017 zostaną wybrane co jest niepoprawne ponieważ operacja SUBSTR jasno określa że porównanie dotyczy właśnie roku z końcówką 17. Istotne jest by zrozumieć że tego typu zapytanie nie jest w stanie określić pełnego zakresu dat a jedynie dokładność do dwóch określonych cyfr w danym formacie. W SQL kluczową rolę odgrywa dokładna analiza struktury danych oraz formatów by uniknąć takich nieporozumień. Dzięki temu można zoptymalizować zapytania SQL oraz uzyskać precyzyjne wyniki co jest podstawowym celem w zarządzaniu danymi.

Pytanie 16

Do tabeli pracownicy wpisano rekordy. Co zostanie wyświetlone po uruchomieniu kwerendy SQL SELECT podanej poniżej?

SELECT SUM(pensja) FROM pracownicy WHERE pensja > 4000;
idimienazwiskopensja
1AnnaKowalska3400
2MonikaNowak1300
3EwelinaNowakowska2600
4AnnaPrzybylska4600
5MariaKowal2200
6EwaNowacka5400
A. Wartość 5400, czyli najwyższa pensja pracownika.
B. Dwie wartości: 4600 i 5400, jako pensje pracowników wyższe niż 4000.
C. Wartość 10000, czyli suma pensji pracownika o id=4 oraz o id=6.
D. Wartość 19500, czyli suma wszystkich pensji pracowników.
Niestety, twoja odpowiedź nie jest poprawna. W przypadku tej konkretnej kwerendy, została użyta funkcja agregująca SUM(), która zwraca sumę wartości dla określonego zestawu wierszy, nie jednak wartości indywidualne. Dlatego odpowiedź mówiąca o wyświetleniu dwóch wartości jako pensje pracowników wyższych niż 4000 jest niepoprawna - kwerenda agregująca nie zwróci wartości indywidualnych. Odpowiedź mówiąca o wyświetleniu sumy wszystkich pensji pracowników jest również błędna, ponieważ w kwerendzie jest zastosowany warunek WHERE, który ogranicza zestaw danych do tych, gdzie pensja przekracza 4000. Wyświetlenie najwyższej pensji pracownika również nie jest poprawne, ponieważ nie została użyta funkcja MAX, która zwraca najwyższą wartość w zestawie. Kluczowe jest zrozumienie, jak działają różne operatory i funkcje w SQL i kiedy ich używać. W tym przypadku funkcja SUM() zastosowana do kolumny 'pensja' zwraca sumę pensji dla pracowników, którzy zarabiają więcej niż 4000.

Pytanie 17

Wykonanie zapytania SQL: DELETE FROM mieszkania WHERE status=1; spowoduje usunięcie

A. pola o nazwie status w tabeli mieszkania
B. rekordów, gdzie pole status ma wartość 1, z tabeli mieszkania
C. tabeli mieszkania w bazie danych
D. tabel, w których pole status ma wartość 1, z bazy danych mieszkania
Wiele osób błędnie interpretuje znaczenie polecenia DELETE w SQL, co prowadzi do mylnych wniosków. Na przykład, stwierdzenie, że polecenie to usunie tabelę mieszkania z bazy danych, jest niewłaściwe. W rzeczywistości kwerenda DELETE jest stosowana do usuwania konkretnych rekordów z tabeli, a nie samej tabeli. Aby usunąć całą tabelę, stosuje się polecenie DROP TABLE, które ma zupełnie inną funkcję i konsekwencje. Ponadto, twierdzenie, że polecenie usunie pole o nazwie status, jest również błędne. W SQL pole DELETE działa na poziomie rekordów, a nie kolumn, co oznacza, że można usunąć tylko dane wierszy, a nie struktury tabeli. Innym nieporozumieniem jest sugestia, że cała baza danych mieszkań zostanie zmodyfikowana. Każda tabela w bazie danych jest niezależna, a operacje na jednej tabeli nie mają wpływu na inne, chyba że są powiązane kluczami obcymi. Właściwe zrozumienie działania kwerendy DELETE oraz zasad przeprowadzania operacji na bazach danych jest kluczowe w programowaniu i administracji bazami danych, aby unikać niezamierzonych skutków i zapewnić integralność danych.

Pytanie 18

Jakie jest oznaczenie typu stało-znakowego w SQL?

A. time
B. text
C. bool
D. char
Typy text, time oraz bool są niepoprawne w kontekście pytania o stało-znakowy typ danych w SQL. Typ text jest używany do przechowywania łańcuchów o zmiennej długości i jest zaprojektowany do przechowywania większej ilości tekstu, niż typ char. Oznacza to, że text może zawierać znacznie więcej danych, w zależności od implementacji systemu zarządzania bazą danych, jednak nie jest on typem stało-znakowym, co wyklucza go z omawianego pytania. Typ time, z drugiej strony, jest używany do przechowywania danych czasowych, które obejmują godziny, minuty, sekundy oraz, w niektórych przypadkach, ułamki sekundy. Nie ma on żadnego związku z przechowywaniem łańcuchów znaków, a jego zastosowanie jest całkowicie odmienne, koncentrując się na operacjach związanych z czasem. Typ bool jest kolejnym przykładem nieodpowiedniego wyboru. Służy on do przechowywania wartości logicznych, które mogą przyjmować jedynie dwie opcje: prawda (true) lub fałsz (false). Ten typ danych jest używany w kontekście warunków oraz decyzji logicznych, a nie do przechowywania tekstu. Dlatego też, w kontekście pytania o typ stało-znakowy, żaden z wymienionych typów poza char nie jest odpowiedni.

Pytanie 19

Uprawnienia obiektowe przyznawane użytkownikom serwera bazy danych mogą umożliwiać lub ograniczać

A. zmieniać role i konta użytkowników
B. realizować operacje na bazie, takie jak wstawianie lub modyfikowanie danych
C. przechodzić uprawnienia
D. wykonywać polecenia, takie jak tworzenie kopii zapasowej
Uprawnienia obiektowe w systemach baz danych są kluczowym aspektem zarządzania bezpieczeństwem i dostępem do danych. Odpowiedzi dotyczące modyfikacji ról i kont użytkowników, dziedziczenia uprawnień czy wykonywania instrukcji takich jak tworzenie kopii zapasowej, nie odnoszą się bezpośrednio do istoty uprawnień obiektowych. Modyfikacja ról i kont użytkowników jest zazwyczaj związana z uprawnieniami administracyjnymi, a nie obiektowymi. Role i konta użytkowników są koncepcjami wyższego poziomu, które służą do grupowania uprawnień i nie są zazwyczaj zarządzane na poziomie obiektów. Dziedziczenie uprawnień jest bardziej złożonym mechanizmem, który dotyczy hierarchii obiektów i nie jest bezpośrednio związane z podstawowym pojęciem uprawnień obiektowych. Ponadto, wykonywanie instrukcji takich jak tworzenie kopii zapasowej, to działanie administracyjne, które zazwyczaj wymaga odrębnych uprawnień niż te, które dotyczą operacji na danych. Typowym błędem jest pomylenie uprawnień obiektowych z uprawnieniami administracyjnymi, co prowadzi do nieporozumień w zakresie ich zastosowania oraz w kontekście bezpieczeństwa danych. Właściwe zrozumienie tych różnic jest kluczowe dla skutecznego zarządzania dostępem w bazach danych oraz dla zapewnienia ich bezpieczeństwa i integralności.

Pytanie 20

W języku PHP, aby nawiązać połączenie z bazą danych MySQL przy użyciu biblioteki mysqli, w poniższym zapisie w miejsce litery 'c' należy wpisać:

$a = new mysqli('b', 'c', 'd', 'e');
A. adres serwera bazy danych
B. hasło dla użytkownika
C. nazwa bazy danych
D. nazwa użytkownika
Wybór odpowiedzi dotyczącej 'nazwa bazy danych', 'hasło użytkownika' i 'lokalizacja serwera bazy danych' nie jest poprawny, bo żaden z tych elementów nie odnosi się do drugiego argumentu w konstruktorze mysqli. Zrozumienie połączeń z bazą danych jest kluczowe przy programowaniu w PHP. 'Nazwa bazy danych' to czwarty argument, więc dotyczy tego, do której bazy chcemy się podłączyć. 'Hasło użytkownika' to trzeci argument, który jest potrzebny, żeby się autoryzować. A 'lokalizacja serwera bazy danych' to pierwszy argument, który mówi, gdzie znajduje się serwer, najczęściej będzie to 'localhost', na którym działa nasza aplikacja. Błędne wnioski mogą się brać z niepełnego zrozumienia struktury połączeń w PHP.

Pytanie 21

Jak wykonanie zapytania SQL przedstawionego poniżej wpłynie na tabelę pracownicy?

ALTER TABLE pracownicy MODIFY plec char(9);
A. Zmieni typ danych kolumny plec na znakowy o zmiennej długości 9.
B. Zmieni typ danych kolumny plec na znakowy o stałej długości 9.
C. Utworzy kolumnę plec o typie znakowym o zmiennej długości 9.
D. Utworzy kolumnę plec o typie znakowym o stałej długości 9.
Odpowiedź jest poprawna, ponieważ polecenie ALTER TABLE zmienia istniejącą kolumnę w tabeli pracownicy. W szczególności, polecenie MODIFY plec char(9) modyfikuje typ danych kolumny plec na znakowy o stałej długości 9. Oznacza to, że każda wartość przechowywana w tej kolumnie będzie miała dokładnie 9 znaków (wypełnionych np. spacjami, jeśli wartość będzie krótsza). W praktyce zapewnia to jednolitą długość dla przechowywanych danych, co może być korzystne w przypadku, gdy wymagane jest zachowanie spójności długości, na przykład przy przechowywaniu kodów pocztowych lub identyfikatorów. Standardy projektowania baz danych zalecają używanie odpowiednich typów danych, aby zminimalizować przestrzeń dyskową oraz przyspieszyć operacje na danych. Warto zauważyć, że w przypadku kolumny char(9) nie można wprowadzić wartości dłuższej niż 9 znaków, co zapobiega niezgodnościom danych.

Pytanie 22

Funkcja agregująca MIN w SQL ma na celu obliczenie

A. liczby wierszy, które zostały zwrócone przez kwerendę
B. wartości najmniejszej w kolumnie wynikowej kwerendy
C. długości tekstu w rekordach zwróconych przez kwerendę
D. średniej wartości różnych pól w rekordzie zwróconym przez zapytanie
W odpowiedziach, które nie zostały wybrane, pojawia się szereg błędnych interpretacji dotyczących funkcji agregującej MIN. Wartość długości znaków w rekordach nie ma bezpośredniego związku z funkcją MIN. Funkcje takie jak LENGTH mogą być używane do obliczania długości ciągów znakowych, lecz nie są one związane z MIN, który skupia się na wartościach liczbowych. Liczba wierszy zwróconych przez kwerendę odnosi się do użycia funkcji COUNT, a nie MIN. Liczenie rekordów jest inną operacją, która służy do zliczania wszystkich wierszy spełniających określone kryteria. Z kolei średnia wartości różnych pól rekordu, uzyskiwana przy użyciu funkcji AVG, również jest odmienną operacją, która nie ma związku z działaniem MIN. Te pomyłki mogą wynikać z nieporozumienia dotyczącego podstawowych funkcji agregujących w SQL, które są kluczowe w analizie danych. Każda z tych funkcji ma swoje specyficzne zastosowania i zrozumienie ich różnic jest fundamentalne dla efektywnej pracy z bazami danych. Niezrozumienie, co dokładnie robi funkcja MIN, może prowadzić do błędnych wniosków w analizach oraz do niepoprawnych zapytań w projektach bazodanowych.

Pytanie 23

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 zmiennej 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 stałej 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 24

Wskaż zapytanie, które z tabeli klienci wybierze wyłącznie nazwiska trzech najlepszych klientów, czyli takich, którzy posiadają najwięcej punktów na swoim koncie (pole całkowite punkty)?

A. SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC
B. SELECT nazwisko FROM klienci LIMIT 3
C. SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3
D. SELECT nazwisko FROM klienci ORDER BY punkty DESC LIMIT 3
Analiza niepoprawnych odpowiedzi ujawnia szereg kluczowych błędów w interpretacji zapytania SQL. W pierwszym przypadku, 'SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC;' następuje nieprawidłowa składnia, ponieważ klauzula LIMIT powinna być umieszczona po klauzuli ORDER BY. Taki błąd sprawia, że zapytanie nie zostanie zrealizowane przez system baz danych. Kolejna odpowiedź, 'SELECT nazwisko FROM klienci LIMIT 3;', pomija istotny element sortowania, dlatego zwróci po prostu pierwsze trzy nazwiska z tabeli, bez względu na ilość punktów. Takie podejście jest mało efektywne, ponieważ nie identyfikuje najlepszych klientów na podstawie ich punktów, co jest kluczowe dla analizy jakości klientów. Ostatnia odpowiedź, 'SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3;', znów koncentruje się na sortowaniu alfabetycznym nazwisk zamiast na punktach, co nie spełnia kryteriów określonych w pytaniu. Takie błędy ukazują typowe nieporozumienia w zakresie funkcji SQL, gdzie kluczowe jest rozróżnienie pomiędzy różnymi metodami sortowania i ograniczania wyników. Istotne jest, aby w analizach danych zawsze zwracać uwagę na odpowiednie kryteria oraz zasady, które mają realny wpływ na proces podejmowania decyzji.

Pytanie 25

Dane są zapisy w tabeli uczniowie, które zostały przedstawione na rysunku. Jaki będzie rezultat wykonania podanego zapytania SQL?

Ilustracja do pytania
A. Dane 4, 3, 4, 3
B. Liczba wierszy równa 4
C. Wartość 3.5
D. Suma ocen równa 14
W kontekście przedstawionego zapytania SQL błędne jest oczekiwanie że wynikiem będzie dane 4 3 4 3 lub suma ocen równa 14. Wynika to z faktu że funkcja AVG() służy do obliczania średniej a nie zwracania poszczególnych wartości ani ich sumy. Często spotykanym błędem jest mylenie funkcji agregujących takich jak AVG() SUM() COUNT() z prostym wyborem danych. Funkcje agregujące przetwarzają dane aby dostarczyć zagregowany wynik zamiast zwracać pojedyncze rekordy. Zapytanie SELECT AVG(ocena) jest skonstruowane aby obliczyć średnią wartość kolumny ocena przez co nie zwraca pełnego zestawu danych ani ich sumy. Co więcej liczba wierszy równa 4 sugerowałaby użycie funkcji COUNT() która zlicza liczbę rekordów. Zrozumienie różnic między tymi funkcjami jest kluczowe w analizie danych i konstruowaniu zapytań SQL. SQL oferuje różne sposoby manipulacji i analizy danych a skuteczne korzystanie z tych narzędzi wymaga jasnego zrozumienia ich funkcji i zastosowań. Tylko przez właściwe zrozumienie celu każdej funkcji można poprawnie interpretować i analizować dane w kontekście rzeczywistych scenariuszy biznesowych i technicznych.

Pytanie 26

W dostępnej tabeli mieszkań znajdują się kolumny o nazwach: adres, metraż, liczba_pokoi, standard, status, cena. Wykonanie podanej kwerendy SQL SELECT spowoduje, że zostaną wyświetlone

Ilustracja do pytania
A. metraż oraz cena tych mieszkań, które mają więcej niż 3 pokoje
B. wszystkie informacje oprócz adresu tych mieszkań, które mają więcej niż 3 pokoje
C. wszystkie informacje dotyczące mieszkań, które mają co najmniej 3 pokoje
D. metraż oraz cena tych mieszkań, które mają co najmniej 3 pokoje
Błędne interpretacje mogą wynikać z niezrozumienia działania podstawowych elementów składni SQL. Pierwszym powszechnym błędem jest założenie że kwerenda SELECT bez jawnego określenia kolumn zwróci wszystkie dane. W rzeczywistości musimy dokładnie wskazać które kolumny nas interesują tak jak w zapytaniu SELECT metraz cena. Pominięcie tego prowadzi do nieprawidłowego założenia że zwrócone zostaną wszystkie dane rekordów co wprowadza w błąd. Kolejnym błędem jest mylenie operatorów logicznych. W treści kwerendy użyto operatora większe niż który powoduje że zwrócone zostaną mieszkania z ilością pokoi większą niż trzy. Interpretacja że obejmuje to również trzy pokoje jest błędna i wynika z nieznajomości różnicy między operatorami większe bądź równe a tylko większe. Ponadto błędnym założeniem jest przekonanie że pomijane kolumny jak adres zostaną automatycznie dołączone chyba że zostały wyraźnie wykluczone co jest niezgodne z zasadami działania instrukcji SELECT. Zrozumienie tych aspektów jest kluczowe w pracy z SQL gdzie precyzyjne sformułowanie zapytań wpływa znacząco na jakość i trafność uzyskanych danych oraz efektywność operacji na bazach danych. Należy dbać o poprawną konstrukcję zapytań aby unikać błędów prowadzących do niepotrzebnego obciążenia systemu oraz uzyskiwania nieprawidłowych wyników analizy danych co może mieć poważne konsekwencje w kontekście biznesowym lub badawczym. Poprawne posługiwanie się składnią SQL jest kluczowe dla efektywności pracy z bazami danych

Pytanie 27

Komenda kierowana do serwera bazy danych, mająca na celu zbieranie, wyszukiwanie lub edytowanie danych w bazie, nazywana jest

A. kwerendą
B. kopią
C. formularzem
D. kolumną
W odpowiedziach, które nie są poprawne, pojawiają się koncepcje, które nie są związane z procesem pobierania i zarządzania danymi w bazach danych. Formularz, na przykład, to zazwyczaj interfejs użytkownika, który umożliwia wprowadzanie danych do systemu, ale nie jest samodzielnym poleceniem do zarządzania danymi. W praktyce, formularze są używane w aplikacjach frontendowych, aby zbierać dane od użytkowników, które następnie mogą być przesyłane do bazy danych, ale same w sobie nie są mechanizmem do wykonywania operacji na danych. Kolumna to pojęcie odnoszące się do struktury tabeli w bazie danych, wskazujące na konkretne pole, które przechowuje wartości zmiennej, natomiast nie jest odpowiedzią na pytanie o działania na danych. Kopia z kolei odnosi się do procesu duplikacji danych, co jest istotne w kontekście tworzenia kopii zapasowych, ale nie definiuje funkcji związanej z bezpośrednim dostępem do danych w bazie. Te nieporozumienia mogą prowadzić do błędnych wniosków o funkcjonalności baz danych. Zrozumienie, że kwerenda jest głównym narzędziem do interakcji z danymi, pozwala uniknąć zamieszania z innymi terminami, które pełnią różne role w zarządzaniu danymi.

Pytanie 28

Jakie jest zastosowanie zapytania z klauzulą JOIN?

A. wywołać funkcję agregującą
B. określić klucz obcy dla tabeli
C. pozyskać dane z dwóch tabel, które są ze sobą powiązane
D. uzyskać wynik tylko z jednej tabeli
Zapytania z klauzulą JOIN są fundamentalnym narzędziem w relacyjnych bazach danych, umożliwiającym łączenie danych z różnych tabel na podstawie określonych warunków. Klauzula JOIN pozwala na uzyskanie wyników, które są wynikiem relacji między tabelami, co jest kluczowe w przypadku, gdy dane są rozproszone w różnych miejscach. Na przykład, w przypadku bazy danych e-commerce, możemy mieć jedną tabelę z informacjami o klientach i inną z zamówieniami. Używając JOIN, możemy połączyć te dwie tabele, aby uzyskać pełen obraz zamówień dokonanych przez konkretnego klienta. W praktyce, korzystanie z JOIN jest zgodne z zasadami normalizacji bazy danych, co przyczynia się do efektywnego zarządzania danymi i minimalizowania redundancji. Przy właściwym zastosowaniu, JOIN może również poprawić wydajność zapytań, limitując ilość danych do przesłania, kiedy to tylko niezbędne informacje są łączone w jeden wynik. To podejście jest zgodne z najlepszymi praktykami w inżynierii oprogramowania oraz zarządzaniu danymi.

Pytanie 29

SELECT count(*) FROM Uczniowie WHERE srednia = 5;
Wynikiem uruchomienia przedstawionego zapytania SQL jest:
A. Suma ocen uczniów, których średnia ocen wynosi 5.
B. Liczba wszystkich uczniów.
C. Średnia ocen wszystkich uczniów.
D. Liczba uczniów, których średnia ocen wynosi 5.
Poprawnie – to zapytanie zwraca liczbę uczniów, których kolumna „srednia” ma wartość równą dokładnie 5. Funkcja agregująca COUNT(*) w SQL nie liczy sumy ani średniej, tylko po prostu zlicza wiersze spełniające warunek w klauzuli WHERE. W tym przypadku tabela Uczniowie jest filtrowana warunkiem srednia = 5, więc do liczenia trafiają wyłącznie rekordy uczniów, którzy mają średnią ocen równą 5. Dopiero na takim przefiltrowanym zbiorze wykonywany jest COUNT(*), który zwraca jedną liczbę – ile takich rekordów istnieje. Moim zdaniem to jedno z najczęściej używanych połączeń: WHERE + COUNT(*), bo w praktyce non stop chcemy wiedzieć „ile jest elementów spełniających warunek”. W raportach, panelach administracyjnych, dashboardach – np. ile jest klientów z określonym statusem, ilu użytkowników ma aktywne konto, ilu pracowników ma premię powyżej jakiegoś progu itd. Warto też zauważyć, że COUNT(*) liczy wszystkie wiersze, niezależnie od tego, czy jakieś inne kolumny są NULL, a kluczowe jest tylko to, że warunek WHERE jest spełniony. Dobrą praktyką jest zawsze dokładne określanie warunku filtrowania, bo drobna zmiana, np. srednia >= 5 zamiast srednia = 5, całkowicie zmienia znaczenie zapytania. W projektowaniu baz danych i zapytań SQL takie precyzyjne myślenie o warunkach i funkcjach agregujących jest absolutną podstawą profesjonalnej pracy z danymi.

Pytanie 30

Rozważ tabelę pracownicy. Jakie jest polecenie MySQL, które usuwa wszystkie wpisy z tabeli, gdzie pole rodzaj_umowy jest puste?

A. DELETE FROM pracownicy WHERE rodzaj_umowy IS NULL
B. DROP pracownicy WHERE rodzaj_umowy IS NULL
C. DELETE pracownicy WHERE rodzaj_umowy ='brak'
D. DROP pracownicy FROM rodzaj_umowy = 0
Aby usunąć wszystkie rekordy z tabeli pracownicy, dla których pole rodzaj_umowy pozostaje puste, czyli ma wartość NULL, używamy polecenia DELETE FROM pracownicy WHERE rodzaj_umowy IS NULL. Klauzula DELETE FROM jest standardowym poleceniem SQL, które służy do usuwania danych z bazy danych. W tym przypadku warunek IS NULL jest kluczowy, ponieważ wskazuje, że chcemy usunąć jedynie te rekordy, w których pole rodzaj_umowy nie zawiera żadnej wartości. Warto zauważyć, że NULL w SQL oznacza brak wartości, co różni się od innych typów wartości, jak na przykład 0 czy pusty ciąg tekstowy. Przykład praktyczny użycia tego polecenia: jeśli w tabeli mamy pracowników z różnymi rodzajami umowy, w tym także takich, którzy nie mają przypisanego rodzaju, to powyższe polecenie usunie ich z bazy danych. Tego rodzaju operacje są niezwykle ważne w kontekście utrzymania bazy danych, gdyż pozwalają na eliminację nieaktualnych lub niekompletnych danych, co w efekcie prowadzi do poprawy jakości przechowywanych informacji i ułatwia późniejsze zapytania do bazy. Takie podejście jest zgodne z dobrymi praktykami w zakresie zarządzania danymi i normami ANSI SQL.

Pytanie 31

Podane zapytanie SQL przyznaje użytkownikowi adam@localhost uprawnienia:

GRANT SELECT, INSERT, UPDATE, DELETE
ON klienci TO adam@localhost
A. do manipulowania danymi w tabeli klienci
B. do manipulowania danymi bazy danych klienci
C. do zarządzania strukturą tabeli klienci
D. do zarządzania strukturą bazy danych klienci
Pozostałe opcje wskazują na zarządzanie strukturą bazy danych lub tabeli co w kontekście podanego polecenia SQL nie jest prawidłowe Zarządzanie strukturą bazy danych odnosi się do operacji takich jak tworzenie usuwanie lub modyfikowanie tabel indeksów i innych obiektów bazy danych Przykłady takich operacji to polecenia CREATE ALTER i DROP które zmieniają definicję strukturalną tabel lub innych obiektów bazodanowych W przypadku zarządzania strukturą tabeli moglibyśmy mówić o dodawaniu nowych kolumn zmienianiu typu danych istniejących kolumn czy zmianach w kluczach indeksach Tego typu zmiany nie są objęte poleceniem GRANT SELECT INSERT UPDATE DELETE które koncentruje się wyłącznie na manipulacji danymi w istniejącej strukturze Dlatego też typowym błędem myślowym jest utożsamianie operacji na danych z operacjami modyfikującymi strukturę bazy danych takimi jak dodawanie tabel czy kolumn Operatorzy SQL są precyzyjnie zdefiniowani i rozdzieleni na kategorie manipulacji danymi DML oraz definicji danych DDL co jest kluczowym rozróżnieniem w pracy z bazami danych

Pytanie 32

Co uzyskujemy po wykonaniu zapytania SQL?

Ilustracja do pytania
A. całkowitą liczbę uczniów
B. liczbę uczniów, których średnia ocen wynosi 5
C. suma ocen uczniów, których średnia ocen wynosi 5
D. średnią wszystkich ocen uczniów
Analizując błędne koncepcje w tym pytaniu warto zwrócić uwagę na mechanizmy działania zapytań SQL które często są mylnie interpretowane. Zapytanie SELECT count(*) nie zwraca liczby wszystkich uczniów lecz tylko tych którzy spełniają określone warunki tutaj średnia ocen wynosi 5. Wybór SELECT count(*) jest kluczowy ponieważ w odróżnieniu od funkcji takich jak AVG() czy SUM() nastawiony jest na zliczanie wierszy a nie na obliczanie wartości średnich czy sum. Mylnym przekonaniem może być że tak skonstruowane zapytanie zwraca średnią ocen wszystkich uczniów; do tego celu służyłaby funkcja AVG(). Podobnie błędne byłoby oczekiwanie że zwróci sumę ocen studentów z daną średnią. Suma wymagałaby użycia funkcji SUM() i odpowiednich modyfikacji zapytania. Często popełnianym błędem jest także niedostrzeżenie że zapytanie z klauzulą WHERE ogranicza wyniki do podzbioru danych co jest kluczowe dla jego poprawnej interpretacji. Zrozumienie tych różnic jest istotne dla efektywnego wykorzystania SQL w praktyce zawodowej i unikania błędów analitycznych.

Pytanie 33

Przedstawione zapytanie SELECT wykonane na tabeli przechowującej dane o uczestnikach konkursu ma za zadanie wybrać

SELECT MAX(wiek) - MIN(wiek) FROM uczestnicy;
A. liczbę najstarszych uczestników.
B. różnicę wieku pomiędzy najstarszym i najmłodszym uczestnikiem.
C. minimalny oraz maksymalny wiek uczestników.
D. średnią arytmetyczną wieku uczestników.
Niestety, podane odpowiedzi nie są poprawne. Zapytanie SQL, które zostało przedstawione, korzysta z funkcji agregujących MAX i MIN, by znaleźć maksymalną i minimalną wartość wieku, a następnie oblicza różnicę między nimi. Taka operacja nie daje nam informacji o minimalnym i maksymalnym wieku uczestników (odpowiedź #1), nie oblicza również średniej arytmetycznej wieku uczestników (odpowiedź #3), ani nie zwraca liczby najstarszych uczestników (odpowiedź #4). W każdym z tych przypadków, zapytanie musiałoby być sformułowane w inny sposób. Na przykład, do obliczenia średniego wieku uczestników, użylibyśmy funkcji AVG. Dlatego ważne jest zrozumienie, jak działają różne funkcje agregujące w SQL i jakie informacje mogą dostarczyć, aby poprawnie interpretować wyniki zapytań SQL. Pamiętaj, że błędne zrozumienie tego, co robi dane zapytanie SQL, może prowadzić do niepoprawnej interpretacji danych, co w konsekwencji może prowadzić do błędnych decyzji biznesowych lub analitycznych.

Pytanie 34

W pokazanym fragmencie zapytania w języku SQL, polecenie SELECT ma na celu uzyskanie wyników z komendy SELECT COUNT(wartosc) FROM....?

A. liczbę rekordów
B. średnią wartości w tabeli
C. średnią wartości w kolumnie wartosc
D. sumę wartości w kolumnie wartosc
W analizowanych odpowiedziach, wybór średniej tabeli, sumy w kolumnie wartosc oraz średniej w kolumnie wartosc jest niepoprawny z uwagi na różnice między funkcjami agregującymi. Średnia tabeli oznaczałaby zliczenie wartości i ich podzielenie przez liczbę elementów, co w przypadku użycia COUNT nie ma miejsca, ponieważ COUNT nie oblicza średniej, a jedynie zlicza ilość rekordów. Dodatkowo, funkcja SUM, która zlicza sumę wartości w określonej kolumnie, wymaga użycia innej syntaktyki, na przykład SELECT SUM(wartosc) FROM... Ponadto, gdyby celem zapytania było zwrócenie średniej wartości w kolumnie wartosc, należałoby użyć zapytania SELECT AVG(wartosc) FROM..., które jest odrębną funkcją od COUNT i ma zupełnie inny cel. W związku z tym, każda z wymienionych odpowiedzi, które sugerują zwrócenie średniej lub sumy, są technicznie błędne, ponieważ nie odpowiadają na zapytanie, które jest skoncentrowane na zliczaniu ilości wierszy, co jest fundamentalną funkcjonalnością polecenia COUNT w systemach baz danych.

Pytanie 35

W tabeli psy znajdują się kolumny: imię, rasa, telefon_właściciela, rok_szczepienia. Jakie polecenie SQL należy zastosować, aby znaleźć numery telefonów właścicieli psów, które zostały zaszczepione przed 2015 rokiem?

A. SELECT telefon_właściciela FROM psy WHERE rok_szczepienia > 2015
B. SELECT imię, rasa FROM psy WHERE rok_szczepienia > 2015
C. SELECT psy FROM rok_szczepienia < 2015
D. SELECT telefon_właściciela FROM psy WHERE rok_szczepienia < 2015
Wybór odpowiedzi, które nie są zgodne z wymaganiami pytania, zazwyczaj wynika z nieprawidłowego zrozumienia zarówno struktury zapytania SQL, jak i kontekstu problemu. Na przykład, pierwsza odpowiedź sugeruje użycie 'SELECT psy FROM rok_szczepienia < 2015', co jest błędne, ponieważ polecenie to nie zawiera kolumn, które chcemy wybrać, a także nieprawidłowo formułuje warunek. SQL wymaga, aby w klauzuli SELECT wskazać konkretne kolumny, a nie całą tabelę. Kolejna odpowiedź, wskazująca na 'SELECT imię, rasa FROM psy WHERE rok_szczepienia > 2015', jest również błędna, ponieważ zamiast telefonów właścicieli, wybiera dane dotyczące imion i ras psów oraz zawiera niewłaściwy warunek dotyczący roku szczepienia. Z kolei ostatnia odpowiedź zawiera błąd w interpretacji, wybierając telefony właścicieli psów, które były szczepione po 2015 roku, co jest sprzeczne z założeniem problemu. Tego typu błędy myślowe, jak pomylenie kryteriów wyboru lub wybór nieodpowiednich kolumn, mogą prowadzić do nieprawidłowych wyników w bazach danych. Aby skutecznie korzystać z SQL, kluczowe jest zrozumienie, jak funkcjonują podstawowe konstrukcje zapytań oraz jak poprawnie stosować warunki filtrowania w kontekście wymaganych rezultatów. Właściwe umiejscowienie warunków w klauzuli WHERE oraz precyzyjne definiowanie wybieranych kolumn to fundamenty, które każdy, kto pracuje z bazami danych, powinien opanować.

Pytanie 36

W kolumnie, która pełni funkcję klucza głównego w tabeli, powinny się znajdować

A. ciągłe numery.
B. liczby.
C. wartości unikalne.
D. inny typ niż inne kolumny.
Wybór odpowiedzi, że klucz główny musi mieć ciągłą numerację, jest nie do końca poprawny. To nie spełnia podstawowych zasad w projektowaniu baz danych. Jasne, że ciągła numeracja może pomóc w zapewnieniu unikalności, ale to nie jest absolutnie wymagane. Klucz główny może mieć różne typy danych, na przykład tekstowe identyfikatory, jak kody czy UUID, które nie są numerowane w zwykły sposób, ale są nadal unikalne. Wiele systemów baz danych pozwala na tworzenie kluczy głównych na podstawie naturalnych danych, takich jak adresy e-mail czy numery identyfikacyjne. Inna niepoprawna kwestia to myślenie, że klucz główny zawsze musi być liczbą. Tak, liczby są często używane jako identyfikatory, ale to nie jedyna opcja. Czasem używa się wartości tekstowych albo kombinacji różnych typów danych. To też mylące, że klucz główny powinien mieć inny typ niż inne kolumny. Klucz główny nie musi być innym typem, jego głównym celem jest unikalność, a nie zgodność typów. Rozumienie, co właściwie oznacza klucz główny i jakie ma funkcje, jest kluczowe dla skutecznego projektowania baz danych, żeby uniknąć błędów, które mogą później prowadzić do problemów z danymi.

Pytanie 37

Kto z wymienionych zajmuje się stałym przygotowaniem systemu bazy danych do działania w produkcji, zarządzaniem kontami użytkowników oraz instalowaniem nowych wersji systemu bazodanowego?

A. Twórcy narzędzi programistycznych
B. Administratorzy serwerów oraz sieci komputerowych
C. Projektanci i programiści Systemu Zarządzania Bazą Danych
D. Administratorzy systemu bazy danych
Administratorzy systemu bazy danych (DBA) odgrywają kluczową rolę w zarządzaniu bazami danych w organizacji. Ich głównym zadaniem jest zapewnienie ciągłej dostępności systemu bazy danych, co obejmuje zarówno przygotowanie środowiska do pracy produkcyjnej, jak i monitorowanie jego wydajności. DBA są odpowiedzialni za zarządzanie użytkownikami, co oznacza, że tworzą i usuwają konta użytkowników oraz przydzielają odpowiednie uprawnienia dostępu, co jest istotne dla bezpieczeństwa danych. Dodatkowo, DBA instalują nowe wersje systemu bazodanowego, co wiąże się z aktualizacjami oprogramowania, które często zawierają poprawki błędów oraz nowe funkcje. Przykładem takiej praktyki jest regularne tworzenie kopii zapasowych danych oraz ich przywracanie w przypadku awarii. DBA muszą także znać standardy i dobre praktyki branżowe, takie jak modelowanie danych czy optymalizacja zapytań SQL, co wpływa na efektywność działania bazy danych. Współpraca z innymi działami IT, takimi jak programiści czy inżynierowie systemowi, jest również niezbędna dla sprawnego funkcjonowania systemów opartych na bazach danych.

Pytanie 38

Jak utworzyć klucz obcy na wielu kolumnach podczas definiowania tabeli?

A. CONSTRAINT (nazwisko, imie) FOREIGN KEY REFERENCES osoby (nazwisko, imie)
B. CONSTRAINT fk_osoba_uczen FOREIGN KEY ON(nazwisko, imie) REFERENCES osoby (nazwisko, imie)
C. CONSTRAINT (nazwisko, imie) FOREIGN REFERENCES KEY osoby (nazwisko, imie)
D. CONSTRAINT fk_osoba_uczen FOREIGN KEY(nazwisko, imie) REFERENCES osoby (nazwisko, imie)
Pierwsza z niepoprawnych odpowiedzi zawiera błąd w składni, ponieważ nieprawidłowo łączy elementy definicji klucza obcego oraz niepoprawnie używa słowa kluczowego 'REFERENCES' przed 'FOREIGN KEY', co narusza standard SQL. W drugiej niepoprawnej odpowiedzi również występuje błąd w kolejności słów kluczowych, co czyni konstrukcję naruszającą zasady składni SQL. W trzeciej odpowiedzi z kolei mamy do czynienia z błędnym użyciem 'ON', które nie jest częścią definicji klucza obcego w tym kontekście. Ponadto, konstrukcja 'FOREIGN REFERENCES KEY' nie ma sensu w kontekście SQL, ponieważ nie istnieje pojęcie 'REFERENCES' obok 'FOREIGN KEY'. W związku z tym, wszystkie trzy niepoprawne odpowiedzi nie spełniają wymogów poprawnej definicji klucza obcego, co prowadzi do problemów z integralnością danych i błędami podczas wykonywania zapytań w bazie danych. Rekomendowane jest zawsze przestrzeganie standardów SQL i testowanie zapytań w bezpiecznym środowisku przed ich zastosowaniem w produkcji.

Pytanie 39

Dla jakich nazwisk użyta w zapytaniu klauzula LIKE jest poprawna?

SELECT imie FROM mieszkancy WHERE imie LIKE '_r%';
A. Rafał, Rebeka, Renata, Roksana
B. Gerald, Jarosław, Marek, Tamara
C. Arleta, Krzysztof, Krystyna, Tristan
D. Krzysztof, Krystyna, Romuald
Niepoprawne odpowiedzi wynikają z niezrozumienia działania klauzuli LIKE w SQL która umożliwia wyszukiwanie wzorców znakowych Wzorzec '_r%' użyty w zapytaniu oznacza że imię musi mieć dowolny znak na pierwszej pozycji a 'r' na drugiej oraz dowolną liczbę znaków po 'r' Niezgodne imiona w innych odpowiedziach nie spełniają tego wzorca gdyż mają inne litery na drugiej pozycji lub brakuje im odpowiedniej struktury na przykład imiona takie jak Rafał Rebeka czy Renata posiadają 'r' na pierwszej pozycji a Marek Jarosław i Romuald mają 'r' w dalszej części imienia Typowym błędem przy korzystaniu z LIKE jest mylne użycie symboli podkreślenia i procenta które mają różne znaczenia Podkreślenie oznacza dokładnie jedną dowolną literę podczas gdy procent może zastępować dowolną sekwencję liter Innym częstym nieporozumieniem jest próba używania LIKE tam gdzie bardziej odpowiednie byłyby inne funkcje tekstowe SQL jak na przykład SUBSTRING które umożliwiają bardziej precyzyjne operacje Kluczowe jest również zrozumienie znaczenia indeksowania dla optymalizacji zapytań LIKE i unikanie wzorców które mogą prowadzić do nieefektywnych pełnych skanów tabel co może znacząco wpłynąć na wydajność systemu

Pytanie 40

Do naprawy i optymalizacji bazy danych w MySQL stosuje się polecenie:

A. mysqlcheck
B. mysqladmin
C. mysqldump
D. mysqlslap
W tym pytaniu łatwo się pomylić, bo wszystkie wymienione narzędzia są związane z MySQL, ale pełnią zupełnie inne role. Kluczowe jest rozróżnienie: co służy do testowania, co do backupu, co do administracji, a co do samej naprawy i optymalizacji struktur tabel. Wiele osób z rozpędu wybiera mysqldump, bo kojarzy się z „ratowaniem” bazy, ale mysqldump to typowe narzędzie do wykonywania kopii zapasowej w postaci skryptu SQL. Generuje plik z poleceniami CREATE TABLE i INSERT, który potem można odtworzyć, ale ono nie naprawia ani nie optymalizuje istniejących tabel na serwerze. To jest backup, a nie konserwacja struktury. Podobnie mylące bywa mysqladmin. To narzędzie administracyjne, służy do wykonywania operacji na poziomie serwera: można nim zatrzymać serwer, sprawdzić status, wyczyścić logi, przeładować uprawnienia, zmienić hasło roota i tym podobne rzeczy. Natomiast ono nie wykonuje operacji typu REPAIR TABLE czy OPTIMIZE TABLE na konkretnej bazie czy tabeli. To raczej „panel sterowania” serwerem niż śrubokręt do tabel. mysqlslap z kolei jest jeszcze czymś innym – to narzędzie do testów obciążeniowych. Używa się go do benchmarków, czyli sprawdzania, jak serwer MySQL reaguje na określoną liczbę zapytań, ilu wątków, jakie opóźnienia. Można dzięki niemu ocenić wydajność konfiguracji, ale ono nie dotyka struktury tabel w sensie naprawy czy optymalizacji. Typowy błąd myślowy przy tym pytaniu polega na wrzuceniu wszystkich narzędzi „mysql*” do jednego worka: skoro coś jest do MySQL, to pewnie da się tym wszystko zrobić. W praktyce dobre podejście administracyjne zakłada specjalizację: do backupu używa się mysqldump lub narzędzi typu xtrabackup, do testów wydajności mysqlslap, do ogólnych komend serwerowych mysqladmin, a do naprawy i optymalizacji struktur tabel właśnie mysqlcheck. Świadome rozróżnianie tych narzędzi bardzo ułatwia później diagnozowanie problemów z bazą i planowanie regularnych zadań utrzymaniowych.