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: 12 czerwca 2026 09:17
  • Data zakończenia: 12 czerwca 2026 10:03

Egzamin zdany!

Wynik: 24/40 punktów (60,0%)

Wymagane minimum: 20 punktów (50%)

Nowe
Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania
Pochwal się swoim wynikiem!
Szczegółowe wyniki:
Pytanie 1

idnazwiskoimiedata_urubezpieczony
✏️ Edytuj📋 Kopiuj⛔ Usuń1KowalskiJan2005-12-181
✏️ Edytuj📋 Kopiuj⛔ Usuń2NowakAdam2005-10-101
✏️ Edytuj📋 Kopiuj⛔ Usuń3WisniewskiAntoni2005-06-140
✏️ Edytuj📋 Kopiuj⛔ Usuń4LipskaAnna2006-04-121
✏️ Edytuj📋 Kopiuj⛔ Usuń5TomaszewskiPawel2006-07-110
✏️ Edytuj📋 Kopiuj⛔ Usuń6KostarzJulia2006-03-201
✏️ Edytuj📋 Kopiuj⛔ Usuń7BorewiczPatryk2007-06-211
✏️ Edytuj📋 Kopiuj⛔ Usuń8KoperskiBartlomiej2001-09-100
Które zapytanie w języku MySQL usunie z tabeli uczniowie uczniów urodzonych w czerwcu?
A. DROP FROM `uczniowie` WHERE data_ur LIKE "06"
B. DELETE FROM `uczniowie` WHERE data_ur LIKE "%-06-%"
C. DROP FROM `uczniowie` WHERE data_ur == #-06-#
D. DELETE FROM `uczniowie` WHERE data_ur LIKE "?-06-?"
Poprawnie wskazane zapytanie korzysta z instrukcji DELETE oraz operatora LIKE z odpowiednim wzorcem: "%-06-%". W kolumnie data_ur mamy daty zapisane w standardowym formacie ISO: RRRR-MM-DD, np. 2005-06-14. W takim formacie miesiąc zawsze znajduje się na pozycjach 6–7 i jest zapisany jako dwucyfrowa liczba z wiodącym zerem. Wzorzec "%-06-%" oznacza: dowolny ciąg znaków przed, dokładnie „-06-” w środku, oraz dowolny ciąg znaków po. Dzięki temu trafiamy w wszystkie daty, gdzie miesiąc to 06, czyli czerwiec, niezależnie od roku i dnia. To jest bardzo praktyczne podejście, gdy przechowujemy datę w typie DATE i chcemy filtrować po miesiącu bez dodatkowych funkcji. W MySQL operator LIKE działa na wartościach tekstowych, ale typ DATE jest w takim kontekście automatycznie konwertowany do postaci tekstowej w formacie 'YYYY-MM-DD', więc wzorzec z myślnikami jest jak najbardziej poprawny. W realnych projektach częściej stosuje się funkcje DATE_FORMAT albo MONTH(data_ur) = 6, bo to jest czytelniejsze i mniej podatne na pomyłki w zapisie wzorca. Jednak w tym zadaniu celem jest zrozumienie, jak działa LIKE, wildcard „%” oraz jak wygląda rzeczywisty format przechowywania daty. Dobrą praktyką jest też zawsze używanie pojedynczych cudzysłowów w SQL (np. '%-06-%'), choć MySQL akceptuje też podwójne w pewnych konfiguracjach. Moim zdaniem warto zapamiętać ten sposób myślenia: patrzysz na rzeczywisty zapis danych w kolumnie i dopasowujesz wzorzec tak, żeby trafić dokładnie ten fragment, który Cię interesuje (tu: '-06-').

Pytanie 2

Tabela sklepy ma pola: nazwa, ulica, miasto, branza. Które zapytanie wybierze nazwy sklepów spożywczych wyłącznie we Wrocławiu?

A.
SELECT sklepy FROM branza='spożywczy' WHERE miasto='Wrocław';
B.
SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND miasto='Wrocław';
C.
SELECT nazwa FROM sklepy WHERE branza='spożywczy' OR miasto='Wrocław';
D.
SELECT sklepy FROM nazwa WHERE branza='spożywczy' BETWEEN miasto='Wrocław';
Pozostałe zapytania są błędne. OR zwróciłby wszystkie sklepy spożywcze (z dowolnego miasta) oraz wszystkie sklepy z Wrocławia (dowolnej branży). Zapisy SELECT sklepy FROM nazwa i użycie BETWEEN mają błędną składnię. Poprawne jest branza='spożywczy' AND miasto='Wrocław'.

Pytanie 3

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. Kowalski
B. Jelenia Góra
C. Nowakowska-Kowalska
D. Kasprowicza
Wyrażenie regularne, które zostało podane w pytaniu, to [A-ZŁŻ][a-ząęóżźćńłś]{2,}-[A-ZŁŻ][a-ząęóżźćńłś]{2,}. Wyrażenie to jest używane do walidacji polskich nazwisk, gdzie pierwsza litera musi być dużą literą z zakresu A-Z oraz polskimi znakami diakrytycznymi, następnie muszą występować co najmniej dwa znaki małe, również z zestawu polskich liter. Po pierwszej części, która odpowiada za pierwsze nazwisko, mamy opcjonalny fragment, który zaczyna się od znaku '-', co oznacza, że można podać drugie nazwisko, które także musi spełniać te same warunki. Przykład poprawnych wartości to Kowalski oraz Nowakowska-Kowalska. Wartość 'Jelenia Góra' nie pasuje do tego wzorca, ponieważ zawiera spację, która nie jest dozwolona w tym kontekście. Dodatkowo, spację można interpretować jako rozdzielenie dwóch słów, co wykracza poza przyjęty format. W związku z tym, prawidłowa odpowiedź to 'Jelenia Góra'.

Pytanie 4

Które z poniższych poleceń przyznaje użytkownikowi uczen najniższy poziom uprawnień w zakresie zmiany danych i struktury tabel?

A. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;
B. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
C. GRANT SELECT ON szkola.przedmioty TO uczen;
D. GRANT DROP ON szkola.przedmioty TO uczen;
Rozpatrując inne polecenia, które zostały zaproponowane, należy zauważyć, że każde z nich przyznaje użytkownikowi 'uczen' szerszy zakres uprawnień, co nie jest zgodne z założeniem nadawania minimalnych uprawnień. Przyznanie uprawnień DROP, jak w przypadku polecenia GRANT DROP ON szkola.przedmioty TO uczen, pozwoliłoby użytkownikowi usunąć tabelę 'przedmioty', co jest nieakceptowalne w kontekście użytkownika edukacyjnego. Takie działanie nie tylko zagrażałoby integralności bazy danych, ale również mogłoby prowadzić do utraty ważnych informacji. Podobnie, przyznanie uprawnień INSERT, jak w poleceniu GRANT INSERT, DROP ON szkola.przedmioty TO uczen, umożliwia użytkownikowi dodawanie nowych rekordów do tabeli, co w przypadku ucznia nie jest pożądane, ponieważ jego rola powinna być ograniczona do przeglądania danych. Co więcej, polecenie GRANT ALTER, SELECT ON szkola.przedmioty TO uczen zawiera uprawnienie ALTER, które pozwala na modyfikację struktury tabeli, co również nie powinno mieć miejsca w kontekście użytkownika, który jest tylko uczniem. Wszelkie te niepoprawne podejścia prowadzą do niebezpieczeństwa związane z nieautoryzowanymi zmianami w bazie danych, co jest sprzeczne z najlepszymi praktykami w zakresie zarządzania uprawnieniami i bezpieczeństwa danych. Warto pamiętać, że właściwe zarządzanie uprawnieniami nie tylko zabezpiecza dane, ale również usprawnia procesy edukacyjne, zapewniając odpowiedni dostęp do informacji w sposób kontrolowany.

Pytanie 5

W PHP, przy wykonywaniu działań na bazie danych MySQL, aby zakończyć sesję z bazą, należy użyć

A. mysqli_close();
B. mysqli_commit();
C. mysqli_exit();
D. mysqli_rollback();
Podejście polegające na używaniu funkcji mysqli_exit() jest błędne, ponieważ taka funkcja nie istnieje w kontekście rozwiązań MySQL w PHP. Oprócz tego, wywołanie mysqli_commit() nie jest właściwą odpowiedzią, gdyż ta funkcja służy do potwierdzania transakcji, a nie do zamykania połączenia. Transakcje w MySQL są kluczowe dla zapewnienia integralności danych, ale ich zakończenie nie jest równoznaczne z zakończeniem połączenia. Z kolei funkcja mysqli_rollback() jest używana do wycofywania transakcji, co także nie dotyczy zamykania połączeń. Te nieprawidłowe odpowiedzi mogą wynikać z nieporozumienia dotyczącego ról poszczególnych funkcji w kontekście zarządzania transakcjami oraz połączeniami. Typowym błędem myślowym jest mylenie zamykania połączenia z zarządzaniem transakcjami; to dwa odrębne aspekty interakcji z bazą danych. Użytkownicy mogą błędnie zakładać, że każda funkcja związana z bazą danych ma na celu ich zamykanie, co prowadzi do niepoprawnych wniosków. Dlatego kluczowe jest zrozumienie różnicy pomiędzy zarządzaniem połączeniami a zarządzaniem transakcjami, co jest fundamentem efektywnej pracy z bazami danych w PHP.

Pytanie 6

Funkcja agregująca AVG wykorzystana w zapytaniu

SELECT AVG(cena) FROM uslugi;
ma na celu
A. znalezienie najwyższej ceny za usługi
B. zsumowanie wszystkich kosztów usług
C. wyliczenie średniej arytmetycznej cen wszystkich usług
D. obliczenie liczby dostępnych usług w tabeli
Funkcja agregująca AVG w języku SQL oblicza średnią arytmetyczną wartości w określonej kolumnie, w tym przypadku w kolumnie 'cena' tabeli 'uslugi'. W kontekście baz danych, obliczanie średniej jest kluczowym narzędziem analitycznym, które pozwala na uzyskanie ogólnego obrazu wartości danej kolumny. W praktyce, analiza średnich cen usług może być użyteczna dla menedżerów chcących dostosować strategię cenową lub dla działów finansowych oceniających wydajność sprzedaży. Przykładowo, jeżeli średnia cena usług wynosi 100 zł, a kolejny miesiąc przynosi spadek do 80 zł, jest to sygnał do analizy powodów obniżenia przychodów. Stosowanie funkcji AVG jest zgodne z najlepszymi praktykami w zakresie analizy danych, gdyż pozwala na podejmowanie decyzji opartych na faktach i liczbach. Warto również zauważyć, że do obliczeń średnich często używa się danych z różnych grup, co może pomóc w zrozumieniu trendów oraz wzorców w zachowaniach klientów na rynku.

Pytanie 7

Które polecenie MySQL sprawdza tabelę pod kątem błędów i uszkodzeń (bez jej naprawiania)?

A.
CHECK TABLE
B.
CHANGE TABLE
C.
FIX TABLE
D.
UPDATE TABLE
Polecenie CHECK TABLE sprawdza, czy tabela nie jest uszkodzona, i zwraca raport o ewentualnych błędach - samo jednak niczego nie naprawia. Zwykle wykonuje się je przed właściwą naprawą poleceniem REPAIR TABLE. Dlatego do diagnozy tabeli (bez naprawy) służy CHECK TABLE.

Pytanie 8

Jakie polecenie należy zastosować, aby w trakcie tworzenia tabeli dodać klucz obcy obejmujący wiele kolumn?

A. CONSTRAINT(nazwisko,imie) FOREIGN REFERENCES KEY osoby (nazwisko, imie)
B. CONSTRAINT(nazwisko,imie) FOREIGN KEY REFERENCES osoby (nazwisko, imie)
C. CONSTRAINT fk_osoba_uczen FOREIGN KEY (nazwisko, imie) REFERENCES osoby (nazwisko,imie)
D. CONSTRAINT fk_osoba_uczen FOREIGN KEY ON (nazwisko, imie) REFERENCES osoby (nazwisko,imie)
Wszystkie odpowiedzi inne niż 'CONSTRAINT fk_osoba_uczen FOREIGN KEY (nazwisko, imie) REFERENCES osoby (nazwisko,imie)' zawierają błędy, które mogą prowadzić do nieprawidłowego definiowania klucza obcego. Pierwsza odpowiedź niepoprawnie używa terminu 'FOREIGN REFERENCES KEY', co jest błędną konstrukcją, ponieważ nie istnieje taki termin w standardzie SQL. Poprawnym terminem jest 'FOREIGN KEY', który jasno wskazuje na rolę kolumn w kontekście relacji między tabelami. Dwie kolejne odpowiedzi błędnie zdefiniowały składnię definicji klucza obcego, używając niepoprawnych konstrukcji, takich jak 'ON' czy niewłaściwego umiejscowienia nazwy ograniczenia. Klucz obcy powinien być zdefiniowany w kontekście kolumn, które są nim objęte, a także powinien odnosić się do kolumn w innej tabeli, co w tych przypadkach nie zostało zrobione prawidłowo. Typowe błędy myślowe prowadzące do takich wniosków obejmują mylenie terminów i składni SQL, co może wynikać z braku znajomości standardów SQL lub po prostu z nieuwagi. Ważne jest, aby osoby pracujące z bazami danych dokładnie znały zasady składni oraz funkcje, jakie pełnią różne elementy definicji tabel i relacji, aby unikać takich błędów i zapewniać integralność danych.

Pytanie 9

Co jest charakterystyczne dla relacyjnej bazy danych?

A. używanie języka zapytań OQL
B. obecność klas, obiektów i metod
C. opis stanu wg obiektowego modelu danych
D. stosowanie kluczy głównych do identyfikacji rekordów
Pozostałe cechy opisują model OBIEKTOWY. Klasy, obiekty i metody oraz opis stanu wg obiektowego modelu danych należą do baz obiektowych. Język OQL to także świat obiektowy, a nie relacyjny (tam jest SQL). Bazę relacyjną wyróżnia stosowanie kluczy głównych do identyfikacji rekordów.

Pytanie 10

Które z poniższych poleceń pozwala na dodanie kolumny zadanie_kompletne do tabeli zadania?

A. INSERT INTO zadania VALUES zadanie_kompletne
B. ADD COLUMN zadanie_kompletne WITH zadania
C. ALTER TABLE zadania ADD COLUMN zadanie_kompletne int
D. CREATE INDEX zadania ADD COLUMN zadanie_kompletne int
Dodanie kolumny do istniejącej tabeli w relacyjnej bazie danych może być realizowane za pomocą polecenia ALTER TABLE. To polecenie jest standardem SQL i jest wspierane przez większość systemów zarządzania bazami danych, takich jak MySQL, PostgreSQL, Oracle czy Microsoft SQL Server. W przypadku zapytania 'ALTER TABLE zadania ADD COLUMN zadanie_kompletne int', polecenie to modyfikuje strukturę tabeli 'zadania', dodając nową kolumnę o nazwie 'zadanie_kompletne', która będzie przechowywać dane typu całkowitego (int). Praktycznym przykładem zastosowania tego polecenia może być system zarządzania projektami, w którym chcemy śledzić status zadań. Po dodaniu tej kolumny, możemy wprowadzać wartości 0 lub 1, które mogą reprezentować, czy zadanie zostało ukończone, czy nie. Użycie ALTER TABLE jest niezbędne, gdyż inne polecenia, takie jak CREATE INDEX czy INSERT INTO, służą do innych celów, takich jak tworzenie indeksów lub wstawianie danych, a nie do modyfikacji struktury tabeli. W praktyce, aby upewnić się, że zmiany są zgodne z wymaganiami systemu, zaleca się zawsze wykonanie kopii zapasowej bazy danych przed przeprowadzeniem operacji na strukturze tabeli.

Pytanie 11

Tabela ksiazki ma kolumny tytul, autor, cena (liczbowa). Która kwerenda zwróci TYLKO tytuły książek tańszych niż 50?

A.
SELECT * FROM ksiazki WHERE cena < 50;
B.
SELECT tytul FROM ksiazki WHERE cena > '50 zł';
C.
SELECT tytul FROM ksiazki WHERE cena < 50;
D.
SELECT ksiazki FROM tytul WHERE cena < '50 zł';
Skoro w wyniku mają być TYLKO tytuły, po SELECT podajemy jedną kolumnę tytul, a nie *. Kolumna cena jest liczbą, więc porównujemy ją z liczbą bez cudzysłowów: SELECT tytul FROM ksiazki WHERE cena < 50; zwróci tytuły książek tańszych niż 50. Dlatego ta kwerenda jest poprawna.

Pytanie 12

W relacyjnych bazach danych encja jest przedstawiana przez

A. kwerendę.
B. relację.
C. tabelę.
D. rekord.
Nieprawidłowe odpowiedzi wskazują na pewne nieporozumienia dotyczące definicji podstawowych elementów relacyjnych baz danych. Rekord, chociaż jest istotnym składnikiem tabeli, nie reprezentuje encji, lecz pojedynczą instancję encji. Mylne jest również utożsamianie tabeli z relacją, ponieważ relacja w kontekście teorii zbiorów odnosi się do zbioru krotek, podczas gdy tabela jest fizycznym i trwałym przedstawieniem tychże zbiorów w bazie danych. Kwerenda natomiast to instrukcja używana do uzyskiwania danych z bazy danych, a nie do ich reprezentacji. To podejście do zrozumienia modeli relacyjnych może prowadzić do błędnych wniosków w projektowaniu baz danych. Dla przykładu, nieumiejętność rozróżnienia między tabelą a rekordem może skutkować niewłaściwym modelowaniem danych, co wpłynie negatywnie na wydajność i integralność bazy danych. Warto zwrócić uwagę na znaczenie właściwego stosowania terminologii oraz zrozumienie struktury danych w relacyjnych bazach danych, co jest kluczowe dla efektywnego zarządzania danymi i ich relacjami.

Pytanie 13

W systemie baz danych sklepu znajdują się dwie tabele powiązane ze sobą relacją: produkty oraz oceny. Tabela oceny zawiera dowolną liczbę ocen wystawionych przez klientów dla konkretnego produktu, które są zdefiniowane przez pola: id, ocena (pole numeryczne), produktID (klucz obcy). Aby uzyskać maksymalną ocenę dla produktu o ID równym 10, należy użyć zapytania

A. COUNT MAX SELECT ocena FROM oceny WHERE produktID = 10;
B. MAX SELECT ocena FROM oceny WHERE produktID = 10;
C. SELECT MAX COUNT(ocena) FROM oceny WHERE produktID = 10;
D. SELECT MAX(ocena) FROM oceny WHERE produktID = 10;
W odpowiedziach błędnych występują różne nieporozumienia dotyczące składni SQL oraz sposobu korzystania z funkcji agregujących. Przykładowo, pierwsza propozycja "MAX SELECT ocena FROM oceny WHERE produktID = 10;" jest niepoprawna, ponieważ nie przestrzega właściwej składni SQL. Słowo kluczowe MAX() powinno być używane jako funkcja, a nie jako część polecenia SELECT. Z kolei trzecia odpowiedź "COUNT MAX SELECT ocena FROM oceny WHERE produktID = 10;" również nie ma sensu, ponieważ COUNT() jest inną funkcją agregującą, która zlicza rekordy, a nie znajduje maksymalnej wartości. Kolejna sugestia, "SELECT MAX COUNT(ocena) FROM oceny WHERE produktID = 10;", jest niepoprawna z tego samego powodu - nie można użyć MAX() i COUNT() razem w taki sposób. Często takie nieprawidłowe podejścia wynikają z nieporozumienia dotyczącego funkcji agregujących i ich zastosowania w kontekście SQL. Kluczowe jest, aby rozumieć, że funkcje takie jak MAX() i COUNT() służą do różnych celów: MAX() znajduje najwyższą wartość, podczas gdy COUNT() zlicza wystąpienia danej wartości. Dlatego niezbędne jest solidne zrozumienie działania tych funkcji oraz ich odpowiedniego użycia w zapytaniach SQL, co stanowi fundament dobrych praktyk w analizie danych w relacyjnych bazach danych.

Pytanie 14

W PHP, aby połączyć się z bazą danych MySQL przy użyciu biblioteki mysqli, w zapisie zamieszczonym poniżej, w miejscu litery 'c' powinno się wpisać

Ilustracja do pytania
A. nazwę użytkownika
B. nazwę bazy danych
C. hasło użytkownika
D. lokalizację serwera bazy danych
W języku PHP używając biblioteki mysqli do połączenia z bazą danych MySQL, jako drugi argument funkcji mysqli należy podać nazwę użytkownika. Konstruktor mysqli przyjmuje pięć głównych argumentów: lokalizację serwera, nazwę użytkownika, hasło użytkownika, nazwę bazy danych oraz opcjonalne port i socket. Nazwa użytkownika jest kluczowa, ponieważ określa, który użytkownik bazy danych będzie używany do połączenia. Najczęściej używanym użytkownikiem przy lokalnych połączeniach testowych jest 'root', ale w środowiskach produkcyjnych stosuje się bardziej restrykcyjne podejście, tworząc dedykowane konta z ograniczonymi uprawnieniami dostępowymi. Korzystając z odpowiednich danych uwierzytelniających, można także lepiej logować działania i zarządzać prawami dostępu. Dobra praktyka wymaga, aby hasło było przechowywane bezpiecznie, np. w plikach konfiguracyjnych poza dostępem zewnętrznym, a dane użytkownika zawsze były szyfrowane przy przesyłaniu. Znajomość poprawnej konfiguracji połączenia z bazą danych jest kluczowa dla bezpieczeństwa i wydajności aplikacji.

Pytanie 15

W tabeli Recepta pola Imię oraz Nazwisko odnoszą się do pacjenta, dla którego recepta została wystawiona. Jaką kwerendę należy wykorzystać, aby dla wszystkich recept uzyskać datę ich wystawienia oraz imię i nazwisko lekarza, który je wystawił?

Ilustracja do pytania
A. SELECT Imie, Nazwisko, DataWystawienia FROM Recepta
B. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id
C. SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id
D. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta
Zauważyłem, że dobrze zrozumiałeś, jak skonstruować kwerendę SQL, która łączy dane lekarza z datą wystawienia recepty. Użycie klauzuli JOIN to kluczowa sprawa, bo dzięki temu możesz połączyć tabele Recepta i Lekarz na podstawie odpowiednich kluczy. Dzięki temu dostajesz imię i nazwisko lekarza, który wypisał daną receptę. Klauzula SELECT, którą używasz, wskazuje, co chcesz zobaczyć – w tym przypadku Imie i Nazwisko z tabeli Lekarz oraz Datę Wystawienia z tabeli Recepta. To jest naprawdę podstawowa umiejętność, która pomaga w pracy z relacyjnymi bazami danych. Z mojego doświadczenia, umiejętność tworzenia takich zapytań, pomoże nie tylko w nauce, ale i w przyszłej pracy, bo baza danych rzadko jest prosta i często trzeba łączyć różne dane. I jeszcze jedna rzecz: używanie JOIN w odpowiedni sposób może przyspieszyć działanie zapytań, co jest ważne, gdy mamy do czynienia z dużą ilością danych.

Pytanie 16

Jak zabezpieczyć CREATE USER, aby nie utworzyć konta, gdy już istnieje?

A.
CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'haslo';
B.
CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'haslo';
C.
CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'haslo';
D.
CREATE USER 'anna'@'localhost' IDENTIFIED BY 'haslo';
Aby nie utworzyć konta, które już istnieje (i uniknąć błędu), używa się klauzuli IF NOT EXISTS: CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'haslo';. Gdy użytkownik istnieje, polecenie zostanie pominięte. Dlatego poprawny jest wariant z IF NOT EXISTS.

Pytanie 17

Dana jest tabela studenci o polach id_albumu, ubezpieczenie. Modyfikacja w kolumnie ubezpieczenie polegająca na zmianie wierszy bez wartości (NULL) na ciąg znaków „brak” zostanie wykonana kwerendą

A. ALTER TABLE studenci MODIFY COLUMN ubezpieczenie='brak' NOT NULL;
B. UPDATE studenci SET ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
C. ALTER TABLE studenci ADD ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
D. UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak';
Prawidłowa kwerenda używa instrukcji UPDATE z klauzulą SET oraz warunkiem w części WHERE: „UPDATE studenci SET ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;”. To dokładnie odpowiada temu, co chcemy zrobić: zaktualizować istniejące rekordy w tabeli, tylko w tych wierszach, gdzie kolumna ubezpieczenie ma wartość NULL. UPDATE służy właśnie do modyfikowania danych w tabeli, a nie do zmiany jej struktury. Kluczowy jest tu warunek WHERE ubezpieczenie IS NULL – bez tego zmienilibyśmy wartość ubezpieczenie na „brak” we wszystkich wierszach, co byłoby poważnym błędem. W SQL porównanie z NULL odbywa się zawsze przez IS NULL lub IS NOT NULL, a nie przez operator =, bo NULL oznacza „brak danych”, a nie konkretną wartość.
Moim zdaniem warto zapamiętać ten schemat, bo w praktyce pracy z bazami danych bardzo często trzeba „sprzątać” dane: zastępować wartości NULL jakimiś domyślnymi opisami, np. „nieznany”, „nie dotyczy”, „brak danych”. Przykładowo: UPDATE klienci SET telefon='brak' WHERE telefon IS NULL; albo UPDATE pracownicy SET premia=0 WHERE premia IS NULL;. To jest ten sam wzorzec działania. Dobrą praktyką jest też najpierw wykonać SELECT z tym samym warunkiem WHERE, żeby zobaczyć, które rekordy zostaną zmodyfikowane, zanim puścimy właściwy UPDATE.
W projektowaniu baz danych przyjęło się, że UPDATE służy do zmiany zawartości wierszy, a ALTER TABLE do zmiany struktury tabeli (dodawanie kolumn, zmiana typów, kluczy itp.). Mieszanie tych dwóch ról prowadzi potem do dziwnych błędów. W standardowym SQL nie ma możliwości aktualizacji tylko części wierszy poprzez ALTER TABLE, dlatego tutaj jedynym sensownym, poprawnym i zgodnym z dobrymi praktykami rozwiązaniem jest właśnie użycie UPDATE z warunkiem WHERE ubezpieczenie IS NULL.

Pytanie 18

W jakim celu stosuje się kwerendę SELECT DISTINCT?

A. aby posortować rekordy rosnąco lub malejąco
B. aby pogrupować rekordy
C. aby w wskazanej kolumnie nie powtarzały się wartości w wyniku
D. aby wybrać rekordy występujące w bazie tylko raz
Pozostałe opisy dotyczą innych mechanizmów SQL. Grupowanie rekordów (np. do liczenia sum) realizuje GROUP BY, a porządkowanie wyniku - ORDER BY. DISTINCT nie zakłada też, że dane w bazie są unikalne - przeciwnie, to ON odsiewa powtórzenia już w wyniku zapytania.

Pytanie 19

Na zaprezentowanej tabeli dotyczącej samochodów wykonano zapytanie SQL SELECT

SELECT model FROM samochody WHERE rocznik=2016;
Jakie wartości zostaną zwrócone w wyniku tego zapytania?
Ilustracja do pytania
A. Czerwony, grafitowy
B. Punto, Corsa, Astra, Corolla, Yaris
C. Punto, Corsa, Corolla
D. Fiat, Opel, Toyota
Zapytanie SQL, które podałeś, czyli SELECT model FROM samochody WHERE rocznik=2016, jest zaprojektowane tak, żeby wyciągnąć z tabeli samochody wszystkie modele aut z rocznika 2016. To ogranicza wynik tylko do tych modeli, które spełniają ten właśnie warunek. Patrząc na dostarczoną tabelę, widzimy, że modele z rocznika 2016 to Punto, Corsa i Corolla. Więc z tego zapytania otrzymamy tylko te trzy modele. W realnym świecie, zapytania SQL są mega przydatne przy filtrowaniu danych w bazach. Zrozumienie, jak pisać zapytania SELECT, jest naprawdę ważne, zwłaszcza dla analityków i administratorów. Dobrze jest znać zasady budowania zapytań, żeby były one jasne i precyzyjne, bo to pozwala lepiej zarządzać i analizować dane. Ta wiedza to podstawa w analizie danych, gdzie umiejętność wyciągania odpowiednich informacji jest kluczowa do podejmowania dobrych decyzji biznesowych.

Pytanie 20

Jakie z poniższych stwierdzeń poprawnie opisuje zdefiniowaną tabelę?

CREATE TABLE dane (kolumna INTEGER(3));
A. Tabela ma jedną kolumnę, która zawiera tablice z trzema elementami.
B. Tabela o nazwie dane zawiera trzy kolumny typu całkowitego.
C. Tabela o nazwie dane posiada jedną kolumnę liczb całkowitych.
D. Kolumny tabeli dane są nazywane: kolumna 1, kolumna2, kolumna3.
Odpowiedź jest prawidłowa, ponieważ w zdefiniowanej tabeli 'dane' mamy jedną kolumnę o nazwie 'kolumna', której typ danych to INTEGER. Wartość 3 w definicji INTEGER(3) oznacza, że kolumna może przechowywać liczby całkowite, a nie liczb o długości 3, co często jest mylone. W praktyce INTEGER w SQL nie ma ograniczenia do przechowywania tylko trzech cyfr; to po prostu sugeruje, że przyjmuje się, iż liczby będą miały długość do trzech cyfr, co jest w rzeczywistości ignorowane, ponieważ SQL nie narzuca takich ograniczeń. Wartości w tej kolumnie mogą być zarówno jednocyfrowe, jak i trzycyfrowe. W kontekście projektowania baz danych, dobrą praktyką jest nadawanie kolumnom zrozumiałych nazw oraz dokładne określanie ich typów danych, co ułatwia późniejsze zarządzanie danymi. Poprawne zdefiniowanie tabeli jest kluczowe dla wydajności bazy danych oraz jej integralności, dlatego dla kolumny INTEGER nie ma potrzeby dodatkowego określania ograniczeń, chyba że są one wymagane w kontekście aplikacyjnym.

Pytanie 21

Baza danych przechowuje dane multimedialne (duże ilości danych binarnych). Którego typu danych należy użyć dla takich pól?

A.
BLOB
B.
ENUM
C.
DOUBLE
D.
LONGTEXT
Do przechowywania dużych danych binarnych - obrazów, dźwięku, plików - służy typ BLOB (Binary Large Object). W odróżnieniu od typów tekstowych nie zakłada kodowania znaków, więc nadaje się do surowych bajtów. W MySQL ma warianty (TINYBLOB, MEDIUMBLOB, LONGBLOB) o różnej pojemności. Dlatego dla danych multimedialnych właściwy jest BLOB.

Pytanie 22

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

SELECT MAX(wiek) - MIN(wiek) FROM uczestnicy;
A. różnicę wieku pomiędzy najstarszym a najmłodszym uczestnikiem
B. ilość najstarszych uczestników
C. średnią wartość wieku uczestników
D. najmłodszy i najstarszy wiek uczestników
Prawidłowa odpowiedź to różnica wieku pomiędzy najstarszym i najmłodszym uczestnikiem, ponieważ zapytanie SQL wykorzystuje funkcje agregujące MAX oraz MIN na kolumnie wieku. Funkcja MAX(wiek) zwraca najwyższą wartość wieku w zbiorze danych, co odpowiada wiekowi najstarszego uczestnika, podczas gdy MIN(wiek) zwraca najniższą wartość, czyli wiek najmłodszego uczestnika. Różnica tych dwóch wartości daje nam dokładny wynik, przedstawiający zakres wieku w grupie uczestników. Tego typu analizy są niezwykle przydatne w kontekście organizacji zawodów, gdzie zrozumienie różnorodności wiekowej może wpłynąć na planowanie sekcji rywalizacyjnych czy strategii marketingowych. Rekomenduje się, aby w praktyce wykorzystać podobne zapytania do analizy demografii uczestników, co może pomóc w lepszym dostosowaniu wydarzeń do potrzeb grupy docelowej oraz w analizie trendów w uczestnictwie w różnych kategoriach wiekowych.

Pytanie 23

Model, w którym wszystkie dane są zapisane w jednej tabeli, określa się mianem

A. relacyjnym
B. sieciowym
C. jednorodnym
D. hierarchicznym
Model jednorodny to taka podstawowa struktura w bazach danych, gdzie wszystko trzymamy w jednej tabeli. To się fajnie sprawdza w prostych aplikacjach, bo wtedy relacje między danymi są dość oczywiste. Klasycznym przykładem może być baza kontaktów, gdzie każdy ma swoje info w jednym miejscu. Dzięki temu mamy łatwy dostęp do danych i prosto nimi zarządzać. Z mojego doświadczenia, to rozwiązanie jest super efektywne, ale jak system staje się większy i złożony, to zaczynają się schody. Wtedy inne modele, jak relacyjne, mogą mieć więcej sensu. W branży często korzysta się z modelu jednorodnego, zwłaszcza tam, gdzie szybki dostęp do danych jest kluczowy, a sztywne struktury tylko przeszkadzają. Na codzień to naprawdę przydatna rzecz, jak ktoś nie chce się męczyć z komplikacjami.

Pytanie 24

Polecenie SQL:

GRANT SELECT, INSERT, UPDATE, DELETE ON klienci TO adam@localhost
Przedstawione polecenie SQL nadaje użytkownikowi adam@localhost prawa:
A. do manipulowania danymi bazy danych klienci
B. do zarządzania strukturą tabeli klienci
C. do manipulowania danymi w tabeli klienci
D. do zarządzania strukturą bazy danych klienci
Polecenie SQL przedstawione w pytaniu to GRANT, które jest używane do nadawania uprawnień użytkownikom w systemach zarządzania bazami danych. W tym przypadku użytkownikowi adam@localhost przyznawane są prawa SELECT, INSERT, UPDATE oraz DELETE na tabeli klienci. Oznacza to, że adam ma pełne prawo do manipulowania danymi w tej tabeli, co obejmuje możliwość odczytu danych (SELECT), dodawania nowych rekordów (INSERT), aktualizacji istniejących danych (UPDATE) oraz usuwania danych (DELETE). W kontekście relacyjnych baz danych, te operacje są kluczowe dla zarządzania danymi. Przykładowo, jeśli adam chciałby dodać nowego klienta, użyłby polecenia INSERT. Jeśli natomiast chciałby zaktualizować dane istniejącego klienta, wykorzystałby polecenie UPDATE. Standardy SQL precyzują, że każde z tych uprawnień pozwala użytkownikowi na określone interakcje z danymi, co jest niezbędne dla efektywnego zarządzania informacjami w bazie danych, a także zapewnia bezpieczeństwo poprzez kontrolę dostępu do wrażliwych danych.

Pytanie 25

Na ilustracji pokazano relację jeden do wielu. Łączy ona

Ilustracja do pytania
A. klucz podstawowy id tabeli filmy z kluczem podstawowym id tabeli rezyserzy
B. klucz obcy rezyserzy_id tabeli filmy z kluczem obcym id tabeli rezyserzy
C. klucz obcy rezyserzy_id tabeli filmy z kluczem podstawowym id tabeli rezyserzy
D. klucz podstawowy id tabeli filmy z kluczem obcym rezyserzy_id tabeli rezyserzy
W kontekście relacji jeden do wielu w bazach danych często dochodzi do nieporozumień związanych z błędnym przypisaniem kluczy. Klucz podstawowy w jednej tabeli nigdy nie może być kluczem obcym w innej relacji tego typu, ponieważ klucz podstawowy musi być unikalny i jednoznacznie identyfikować rekord w swojej tabeli. Podobne błędy pojawiają się przy przypisywaniu klucza obcego jako odnoszącego się do innego klucza obcego, co nie jest prawidłowym podejściem, ponieważ klucz obcy powinien odnosić się do klucza podstawowego w innej tabeli, aby zapewnić integralność referencyjną. Klucz obcy nie może być kluczem podstawowym w relacji jeden do wielu, ponieważ naruszałoby to zasadę unikalności wymaganej dla klucza podstawowego. Częstym błędem jest także mylenie kierunku relacji, co prowadzi do projektowania niepraktycznych struktur danych, które są trudne do zarządzania i skalowania. Prawidłowe zastosowanie kluczy obcych i podstawowych oraz zrozumienie ich roli w strukturze bazy danych stanowi fundament dla efektywnego modelowania danych, co jest zgodne z najlepszymi praktykami w projektowaniu systemów zarządzania relacyjnymi bazami danych. Kluczowe jest, aby projektanci baz danych byli świadomi tych zasad i potrafili je stosować w praktyce, aby uniknąć problemów z integralnością danych i późniejszymi trudnościami przy ich modyfikacji lub rozszerzaniu struktury bazy danych. Poprawne zrozumienie relacji między tabelami oraz ich implementacja jest niezbędna dla utrzymania spójności i wydajności systemów bazodanowych w długim okresie użytkowania.

Pytanie 26

Jakie zadanie ma funkcja PHP o nazwie mysql_select_db()?

A. wyznaczyć tabelę, z której będą pozyskiwane dane
B. wyznaczyć bazę, z której będą pozyskiwane dane
C. uzyskać dane z bazy danych na podstawie zapytania
D. nawiązać połączenie między bazą danych a serwerem SQL
Tutaj mamy parę pomyłek związanych z funkcją <span>mysql_select_db()</span>. Po pierwsze, mylisz ją z tym, jak łączymy bazę danych z serwerem SQL. W rzeczywistości, połączenie robi się przez <span>mysql_connect()</span>, a <span>mysql_select_db()</span> ma za zadanie pokazać, która z baz, które już mamy, ma być użyta. Kolejna sprawa to błędne zrozumienie, jak wyciągamy dane z bazy. Robimy to za pomocą funkcji jak <span>mysql_query()</span>, więc wybór bazy danych i ściąganie danych to dwa różne etapy. Mylenie bazy danych z tabelą też wprowadza w błąd, bo baza to tak naprawdę pojemnik dla tabel, a nie jedna konkretna tabela. Moim zdaniem, zrozumienie tej hierarchii jest kluczowe, żeby dobrze działać z bazami. Te nieporozumienia mogą skutkować poważnymi kłopotami, jak złe zapytania czy problemy z dostępem do danych. Lepiej wcześniej przejrzeć dokumentację i standardy SQL, bo one jasno tłumaczą różnice między połączeniem z serwerem, wyborem bazy danych a kwerendami.

Pytanie 27

W relacyjnym modelu baz danych, termin krotka odnosi się do

A. wszystkich wierszy tabeli łącznie z wierszem nagłówkowym
B. liczby rekordów w danej tabeli
C. wszystkich kolumn tabeli, które zawierają atrybuty danego obiektu
D. wierszy tabeli, z wyjątkiem wiersza nagłówkowego, w którym znajdują się nazwy kolumn
W relacyjnym modelu baz danych, krotka odnosi się do jednego wiersza tabeli, który przechowuje zestaw atrybutów (kolumn) dla danego obiektu. Każda krotka jest zbiorem wartości, które są powiązane z określonymi kolumnami. Krotki stanowią fundamentalny element relacyjnych baz danych, w których dane są zorganizowane w formie tabel, co ułatwia ich przechowywanie, przetwarzanie oraz zapytania. Na przykład, w tabeli przechowującej informacje o klientach, każda krotka mogłaby zawierać dane takie jak imię, nazwisko, adres e-mail i numer telefonu. Wartości te są ze sobą powiązane i tworzą kompletny zestaw informacji dotyczący jednego klienta. Zgodnie z normami SQL, krotki są często przetwarzane za pomocą instrukcji SELECT, które umożliwiają pobieranie, modyfikację i zarządzanie danymi na poziomie pojedynczych wierszy. Krotki są nie tylko podstawą struktury danych, ale również fundamentem, na którym opierają się operacje na bazach danych, co czyni je kluczowym pojęciem w projektowaniu oraz zarządzaniu relacyjnymi bazami danych.

Pytanie 28

W bazie danych sklepu internetowego, w tabeli klienci znajdują się m.in. pola całkowite: punkty, liczbaZakupow oraz pole ostatnieZakupy o typie DATE. Klauzula WHERE dla zapytania wybierającego klientów, którzy mają ponad 3000 punktów lub dokonali zakupów więcej niż 100 razy, a ich ostatnie zakupy miały miejsce co najmniej w roku 2022, przyjmuje postać

A. WHERE punkty > 3000 AND liczbaZakupow > 100 AND ostatnieZakupy >= '2022-01-01'
B. WHERE (punkty > 3000 OR liczbaZakupow > 100) AND ostatnieZakupy >= '2022-01'
C. WHERE punkty > 3000 OR liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'
D. WHERE punkty > 3000 AND liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'
Odpowiedź ta jest poprawna, ponieważ zastosowano w niej właściwą logikę warunków w klauzuli WHERE. Aby wybrać klientów, którzy spełniają co najmniej jeden z dwóch pierwszych warunków (posiadają więcej niż 3000 punktów lub wykonali więcej niż 100 zakupów), używamy operatora OR. Z kolei ostatni warunek, dotyczący daty ostatnich zakupów, musi łączyć się z poprzednimi za pomocą operatora AND. Oznacza to, że aby klient został uwzględniony w wynikach, musi spełniać przynajmniej jeden z warunków dotyczących punktów lub liczby zakupów, a równocześnie musi mieć ostatnie zakupy dokonane w roku 2022 lub później. Takie podejście jest zgodne z dobrymi praktykami w SQL, w których operator OR jest wykorzystywany do łączenia warunków alternatywnych, a AND do warunków koniecznych. Na przykład, jeśli chcemy analizować dane klientów w kontekście programów lojalnościowych, takie zapytanie pozwoliłoby nam na wyodrębnienie najbardziej aktywnych klientów, co może być przydatne przy planowaniu kampanii marketingowych.

Pytanie 29

Aby w MySQL nadać użytkownikowi prawo do nadawania i modyfikowania uprawnień innym użytkownikom, należy użyć klauzuli:

A.
TRIGGER
B.
ALL PRIVILEGES
C.
FLUSH PRIVILEGES
D.
GRANT OPTION
Pozostałe opcje dotyczą czego innego. TRIGGER to wyzwalacz uruchamiany automatycznie przy zmianie danych w tabeli - nie ma związku z nadawaniem praw. ALL PRIVILEGES przyznaje wszystkie uprawnienia do obiektu, ale samo w sobie nie pozwala przekazywać ich dalej. FLUSH PRIVILEGES przeładowuje uprawnienia z tablic systemowych po ręcznych zmianach - to czynność administracyjna, nie delegowanie. Prawo nadawania uprawnień innym daje WITH GRANT OPTION, dlatego to ono jest poprawne.

Pytanie 30

Co daje użytkownikowi nadanie w MySQL roli DBManager?

A. możliwość monitorowania serwera
B. wszystkie operacje na bazach danych
C. tworzenie kont użytkowników i ustawianie haseł
D. wszystkie operacje na bazach i na użytkownikach serwera
Rola DBManager w MySQL daje użytkownikowi prawo do WSZYSTKICH operacji na BAZACH danych (tworzenie, modyfikowanie, usuwanie baz i ich zawartości) - to rola zarządzania danymi, lecz nie kontami innych użytkowników. Zapamiętaj: DBManager rządzi bazami, ale nie zarządza użytkownikami serwera.

Pytanie 31

W zapytaniu SQL, umieszczonym w ramce, symbol gwiazdki wskazuje, że w wyniku tego zapytania

Ilustracja do pytania
A. zostanie pokazane pole o nazwie "*" (gwiazdka)
B. zostaną wyświetlone wszystkie wpisy z tabeli mieszkańcy
C. zostanie pominięty warunek dotyczący imienia
D. zostaną wyświetlone wszystkie kolumny tabeli mieszkańcy
W kontekście zapytań SQL często dochodzi do błędów interpretacyjnych związanych z użyciem znaku gwiazdki (*). Niektóre osoby mogą błędnie zakładać, że znak ten ma inne zastosowanie niż wyświetlanie wszystkich kolumn, co prowadzi do nieporozumień. Pierwszym błędnym założeniem jest myśl, że znak gwiazdki zignoruje warunek w klauzuli WHERE; SQL jest językiem deklaratywnym i każde zapytanie wykonuje się zgodnie z jego składnią, uwzględniając podane warunki filtracji danych. Zapytanie SELECT * FROM mieszkańcy WHERE imie='Anna'; zawsze będzie selekcjonować rekordy, gdzie imię jest równe 'Anna', niezależnie od tego, co jest umieszczone po SELECT. Innym błędnym rozumieniem jest przekonanie, że znak gwiazdki wyświetli kolumnę o nazwie '*'. W rzeczywistości SQL nie rozpoznaje '*' jako nazwy kolumny, lecz jako symbol zastępczy dla wszystkich kolumn w tabeli. Takie podejście byłoby przeciwne samej naturze języka SQL, który jest precyzyjny i zorientowany na strukturalne przetwarzanie danych. Dobre praktyki branżowe zalecają także stosowanie jawnego nazywania kolumn w zapytaniach produkcyjnych, co zwiększa czytelność i bezpieczeństwo zapytania, zwłaszcza gdy bazy danych są duże i złożone.

Pytanie 32

 SELECT model FROM samochody WHERE rocznik > 2017 AND marka = "opel"; 

Tabela samochody zawiera rekordy przedstawione na obrazie. Wydając przedstawione zapytanie SQL zostaną zwrócone dane:
idklasa_idmarkamodelrocznik
11fordka2017
22seattoledo2016
33opelzafira2018
42fiat500X2018
53opelinsignia2017
A. opel zafira
B. zafira
C. zafira; insignia
D. opel zafira; opel insignia
Gratulacje, twoja odpowiedź jest poprawna. Zapytanie SQL 'SELECT model FROM samochody WHERE rocznik > 2017 AND marka = 'opel';' ma na celu wyświetlenie modelu samochodu marki 'opel' z roku produkcji późniejszego niż 2017. Analizując dostępną tabelę, możemy zauważyć, że tylko model 'zafira' spełnia oba kryteria. W tym przypadku wykorzystaliśmy dwa kluczowe elementy języka SQL, tj. instrukcję SELECT i klauzulę WHERE. Instrukcja SELECT służy do zapytań o konkretne dane z bazy, a klauzula WHERE to powszechnie stosowane narzędzie do filtrowania wyników zapytania według określonych kryteriów. Jest to bardzo praktyczny aspekt SQL, który pozwala na wydobywanie tylko tych danych, które są potrzebne, co jest niezwykle przydatne przy dużych bazach danych.

Pytanie 33

Jednym z kluczowych identyfikatorów wpisu w bazie danych jest pole

A. klucza obcego
B. relacji
C. numeryczne
D. klucza podstawowego
Numeryczne identyfikatory, choć mogą być stosowane jako klucze podstawowe, nie są wystarczające, aby określić jednoznacznie rekord w bazie danych. Wiele rekordów może mieć ten sam identyfikator numeryczny, zwłaszcza w przypadku, gdy nie jest on unikalny. Klucze relacji odnoszą się do powiązań między tabelami, ale nie są bezpośrednio związane z jednoznacznym identyfikowaniem rekordu. Klucz obcy to atrybut w tabeli, który odnosi się do klucza podstawowego innej tabeli, co jest ważne dla zapewnienia spójności danych, ale nie identyfikuje bezpośrednio rekordu w tabeli, w której się znajduje. Ostatecznie klucz podstawowy jest jedynym elementem, który może jednoznacznie zidentyfikować rekordu w bazie danych, podczas gdy inne wymienione odpowiedzi mogą jedynie wspierać strukturę lub powiązania danych, ale nie spełniają fundamentalnej roli identyfikacyjnej. Mylne jest również myślenie, że klucz podstawowy może być dowolnym typem pól; klucz powinien być odpowiednio dobrany, by zapewnić unikalność i stabilność, co jest kluczowe dla integralności bazy danych.

Pytanie 34

Który użytkownik domyślnie posiada pełne uprawnienia do zarządzania bazą danych w systemie MySQL?

A. sysadmin
B. admin
C. mysqld
D. root
Pozostałe nazwy nie są domyślnym kontem administratora MySQL. „admin” i „sysadmin” brzmią wiarygodnie, ale MySQL nie zakłada ich automatycznie - to konta, które ewentualnie trzeba utworzyć samemu. „mysqld” w ogóle nie jest użytkownikiem, lecz nazwą procesu (demona) serwera MySQL działającego w systemie. Konto z pełnymi uprawnieniami tworzone domyślnie przy instalacji to root, dlatego to ono jest poprawne.

Pytanie 35

Które zapytanie SQL wybiera nazwiska z tabeli klient, które mają co najmniej jedną literę i zaczynają się na literę Z?

A. SELECT nazwisko FROM klient WHERE nazwisko='Z_?'
B. SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z_%'
C. SELECT nazwisko FROM klient WHERE nazwisko='Z?'
D. SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z%'
Zastosowanie zapytań, które nie wykorzystują operatora LIKE w odpowiedni sposób, prowadzi do błędnych wniosków i nieprawidłowych wyników. Na przykład, użycie zapytania SELECT nazwisko FROM klient WHERE nazwisko='Z_?'; i SELECT nazwisko FROM klient WHERE nazwisko='Z?'; jest mylące, ponieważ w tych przypadkach znak podkreślenia (_) jest interpretowany jako znak zastępczy reprezentujący dokładnie jeden dowolny znak. Oznacza to, że te zapytania będą szukały nazwisk, które zaczynają się na Z, ale mają łącznie tylko dwa lub trzy znaki, co nie spełnia wymogu przynajmniej jednoliterowego nazwiska. Tego rodzaju nieścisłości mogą wynikać z niepełnego zrozumienia działania operatorów w SQL. Kolejnym błędem jest zapytanie SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z_%';, które również ogranicza wynik do nazwisk składających się przynajmniej z trzech znaków, co nie spełnia wymagań zadania. W praktyce, takie pomyłki mogą prowadzić do nieefektywnego wyszukiwania i obniżenia jakości aplikacji, co skutkuje frustracją użytkowników i zwiększonymi kosztami rozwoju. Kluczowe jest zrozumienie, jak działają różne znaki wieloznaczne oraz ich zastosowanie w kontekście konkretnych zadań, aby skutecznie i precyzyjnie przeszukiwać dane w bazie.

Pytanie 36

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

Ilustracja do pytania
A. Lekarze.id = Pacjenci.Lekarze_id
B. Lekarze.id = Recepty.id
C. Lekarze.id = Pacjenci.Recepty_id
D. Lekarze.id = Pacjenci.id
Odpowiedź Lekarze.id = Pacjenci.Lekarze_id jest poprawna, ponieważ w bazach danych relacyjne połączenie między tabelami jest realizowane przez klucze obce. Tabela Pacjenci zawiera kolumnę Lekarze_id, która jest kluczem obcym odnoszącym się do kolumny id w tabeli Lekarze. Dzięki temu połączeniu możemy określić, który lekarz jest przypisany do danego pacjenta. W praktyce oznacza to, że możemy wykonywać zapytania SQL, które łączą te tabele i wyświetlają dane wszystkich lekarzy przypisanych do konkretnego pacjenta. Przykładowe zapytanie SELECT może wyglądać tak SELECT Lekarze.imie Lekarze.nazwisko FROM Pacjenci INNER JOIN Lekarze ON Pacjenci.Lekarze_id = Lekarze.id WHERE Pacjenci.id = [id_pacjenta]. Takie podejście jest zgodne z dobrymi praktykami projektowania baz danych zgodnie z zasadami normalizacji co zwiększa spójność i integralność danych. Poprawne użycie kluczy obcych jest fundamentalne w kontekście zarządzania relacjami między danymi oraz umożliwia przeprowadzanie bardziej złożonych analiz danych z różnych tabel w sposób wydajny i bezpieczny.

Pytanie 37

W tabeli psy znajdują się kolumny: imie, rasa, telefon_wlasciciela, rok_szczepienia. Jakie polecenie SQL należy zastosować, aby uzyskać numery telefonów właścicieli psów, które były szczepione przed rokiem 2015?

A. SELECT psy FROM rok_szczepienia < 2015
B. SELECT imie, rasa FROM psy WHERE rok_szczepienia > 2015
C. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia > 2015
D. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015
Wybór odpowiedzi 'SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015' jest poprawny, ponieważ spełnia wszystkie kryteria zawarte w pytaniu. Kluczowym elementem jest zastosowanie klauzuli WHERE, która filtruje wyniki do tych, gdzie rok szczepienia jest mniejszy niż 2015. Używając SELECT, wybieramy tylko kolumnę 'telefon_wlasciciela', co odpowiada na konkretną potrzebę, jaką jest uzyskanie numerów telefonów właścicieli psów, które były szczepione przed określoną datą. W praktyce, takie zapytanie może być użyteczne w sytuacjach np. przypominania właścicielom o konieczności szczepień, co wpisuje się w szerszy kontekst zarządzania zdrowiem zwierząt. Dobre praktyki w SQL obejmują również staranność przy określaniu warunków filtracji, aby zminimalizować ryzyko błędnych wyników. Warto także pamiętać o indeksowaniu kolumn w bazie danych, co może przyspieszyć wykonywanie takich zapytań, zwłaszcza w dużych zbiorach danych.

Pytanie 38

Poniższy fragment kodu PHP funkcjonuje poprawnie i ma na celu wyświetlenie na stronie internetowej informacji pobranych kwerendą z bazy danych. Ile pól zostanie wyświetlonych na stronie?

$ile = mysqli_num_rows($zapytanie);
for ($i = 0; $i < $ile; $i++) 
{
    $wiersz = mysqli_fetch_row($zapytanie); 
    echo "<p>Klient: $wiersz[0] $wiersz[1], adres: $wiersz[2] </p>";
}
A. Z czterech pól
B. Z jednego pola
C. Z trzech pól
D. Z dwóch pól
Wybranie niepoprawnych odpowiedzi, takich jak 'z jednego pola' czy 'z dwóch pól', może wynikać z niepoprawnego zrozumienia struktury danych zwracanych przez funkcję mysqli_fetch_row. Odpowiedzi te sugerują, że użytkownik może nie dostrzegać, że funkcja ta zwraca wszystkie kolumny z wiersza jako elementy tablicy, co ma kluczowe znaczenie w kontekście przetwarzania wyników zapytań. Odpowiedzi wskazujące na jedno lub dwa pola mogą prowadzić do błędnych wniosków, ponieważ ignorują one pełny zakres danych, które są dostępne w każdym wierszu. W praktyce, często umieszcza się w bazie danych więcej informacji, a każda kolumna odpowiada innemu atrybutowi obiektu, na przykład klienta. Dlatego jeśli zapytanie SQL zwraca trzy kolumny, to oczekiwanym wynikiem powinno być właśnie wyświetlenie tych trzech, co podkreśla istotność precyzyjnego formułowania zapytań i poprawnego odczytywania wyników. Zrozumienie struktury danych jest kluczowe dla poprawnego odczytu wyników i ich późniejszego wykorzystania, co potwierdzają standardy związane z programowaniem w PHP oraz obsługą baz danych.

Pytanie 39

Co musi zawierać kolumna pełniąca funkcję klucza głównego w tabeli?

A. inny typ niż pozostałe kolumny
B. wyłącznie liczby
C. wartości unikalne
D. ciągłą numerację
Klucz główny musi jednoznacznie identyfikować każdy wiersz, więc jego wartości muszą być UNIKALNE (i niepuste). Dzięki temu da się bez pomyłki wskazać konkretny rekord. Dlatego kolumna klucza głównego musi zawierać wartości unikalne.

Pytanie 40

Dostępna jest tabela zatytułowana wycieczki, zawierająca kolumny nazwa, cena oraz miejsca (jako liczba dostępnych miejsc). Aby wyświetlić jedynie nazwy wycieczek, których cena jest poniżej 2000 złotych oraz posiadają co najmniej cztery dostępne miejsca, należy zastosować zapytanie

A. SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4
B. SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4
C. SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3
D. SELECT * FROM wycieczki WHERE cena < 2000 OR miejsca > 3
Wybrana odpowiedź jest prawidłowa, ponieważ wykorzystuje operator AND, który jest kluczowy dla spełnienia obu warunków jednocześnie: cena musi być niższa niż 2000 zł, a liczba wolnych miejsc musi być większa niż 3. Dzięki temu zapytanie działa zgodnie z zamierzeniem, wyświetlając tylko te wycieczki, które rzeczywiście spełniają oba kryteria. Dodatkowo, wybór kolumny 'nazwa' zamiast wszystkich kolumn (jak w przypadku użycia *) optymalizuje zapytanie, co jest dobrym podejściem w kontekście wydajności bazy danych. W przypadku większych zbiorów danych, ograniczenie liczby zwracanych kolumn do tych faktycznie potrzebnych jest zgodne z zasadami dobrych praktyk w zakresie projektowania zapytań SQL. Można to zaobserwować na przykład w aplikacjach rezerwacji, gdzie użytkownicy są zainteresowani tylko kluczowymi informacjami o dostępnych wycieczkach. W związku z tym, poprawna konstrukcja zapytania nie tylko spełnia wymogi funkcjonalne, ale także wpływa na wydajność i czytelność kodu.