Wyniki egzaminu

Informacje o egzaminie:
  • Zawód: Technik programista
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 24 kwietnia 2026 13:27
  • Data zakończenia: 24 kwietnia 2026 13:51

Egzamin zdany!

Wynik: 20/40 punktów (50,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

Podczas tworzenia tabeli, do pola, które ma automatycznie przyjmować następne liczby całkowite, należy wprowadzić atrybut

A. NOT NULL
B. NULL
C. PRIMARY KEY
D. AUTO_INCREMENT
Właściwość AUTO_INCREMENT w bazach danych, takich jak MySQL, jest kluczowym elementem, który umożliwia automatyczne zwiększanie wartości liczbowej w polu, co jest szczególnie przydatne przy tworzeniu identyfikatorów dla rekordów. Gdy pole jest oznaczone jako AUTO_INCREMENT, każda nowa wartość wstawiana do tego pola jest automatycznie zwiększana o jeden w porównaniu do ostatniej wprowadzonej wartości. Na przykład, jeśli ostatni rekord miał identyfikator 5, to nowy rekord otrzyma identyfikator 6. Umożliwia to uniknięcie ręcznego zarządzania numeracją identyfikatorów i minimalizuje ryzyko ich powtórzenia, co jest kluczowe dla zachowania integralności danych. Praktycznie, stosowanie AUTO_INCREMENT w tabelach, które przechowują dane o użytkownikach, zamówieniach czy transakcjach, zapewnia wydajność oraz spójność w zarządzaniu unikalnymi identyfikatorami. Dobrą praktyką jest również łączenie AUTO_INCREMENT z PRIMARY KEY, aby zapewnić, że każdy rekord w tabeli jest unikalny i łatwy do identyfikacji.

Pytanie 2

Przedstawione zapytanie MySQL ma za zadanie

ALTER TABLE ksiazki MODIFY tytul VARCHAR(100) NOT NULL;
A. usunąć kolumnę tytul z tabeli ksiazki.
B. zmienić nazwę kolumny w tabeli ksiazki.
C. zmienić typ kolumny tytul w tabeli ksiazki.
D. dodać do tabeli ksiazki kolumnę tytul.
Zapytanie ALTER TABLE ksiazki MODIFY tytul VARCHAR(100) NOT NULL; często bywa mylone z innymi operacjami na strukturze tabeli, bo wszystkie tego typu polecenia wyglądają do siebie dość podobnie. Warto więc uporządkować, co ono dokładnie robi, a czego na pewno nie robi. W MySQL słowo kluczowe MODIFY służy do zmiany definicji istniejącej kolumny, czyli głównie jej typu danych, długości, atrybutów takich jak NOT NULL, domyślna wartość czy np. AUTO_INCREMENT. Kluczowe jest to, że nazwa kolumny pozostaje taka sama, modyfikujemy tylko jej właściwości techniczne. Częsty błąd myślowy polega na wrzucaniu do jednego worka wszystkich operacji ALTER TABLE i zakładaniu, że każde takie polecenie może np. usuwać lub dodawać kolumny. Do usuwania kolumny służy jednak zupełnie inna składnia: ALTER TABLE nazwa_tabeli DROP COLUMN nazwa_kolumny;. Tutaj nie ma słowa MODIFY, więc zapytanie z pytania na pewno nie usuwa kolumny tytul. Podobnie z dodawaniem nowej kolumny – używa się słowa kluczowego ADD, np. ALTER TABLE ksiazki ADD tytul VARCHAR(100);. W naszym przypadku kolumna tytul już musi istnieć, bo inaczej MODIFY zakończy się błędem. Pojawia się też czasem przekonanie, że MODIFY zmienia nazwę kolumny. W MySQL do zmiany nazwy wykorzystuje się ALTER TABLE ... CHANGE stara_nazwa nowa_nazwa typ;, gdzie trzeba podać zarówno starą, jak i nową nazwę oraz pełną definicję typu. W poleceniu z zadania nazwa tytul występuje tylko raz i nigdzie nie ma nowej nazwy, więc nie ma tu mowy o zmianie nazwy, a jedynie o modyfikacji typu i atrybutu NOT NULL. Dobrą praktyką w pracy z SQL jest dokładne kojarzenie słów kluczowych: ADD – dodaj, DROP – usuń, CHANGE – zmień nazwę i definicję, MODIFY – zmień definicję bez ruszania nazwy. Mylenie tych pojęć prowadzi później do niepotrzebnych błędów w migracjach bazy, a czasem nawet do utraty danych, dlatego warto mieć te różnice naprawdę dobrze poukładane w głowie.

Pytanie 3

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

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

Pytanie 4

Z tabel Klienci oraz Uslugi należy wyodrębnić tylko imiona klientów oraz odpowiadające im nazwy usług, które kosztują więcej niż 10 zł. Kwerenda uzyskująca te informacje ma formę

Ilustracja do pytania
A. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id
B. SELECT imie, nazwa FROM klienci, uslugi WHERE cena < 10
C. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id WHERE cena > 10
D. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = klienci.id
Odpowiedź 4 jest prawidłowa, ponieważ prawidłowo wykorzystuje składnię SQL do połączenia dwóch tabel oraz filtrowania danych na podstawie podanego warunku. Kwerenda używa JOIN, aby połączyć tabele Klienci i Uslugi na podstawie wspólnej kolumny uslugi_id, co jest zgodne z zasadami relacyjnej bazy danych, gdzie klucz obcy w jednej tabeli odnosi się do klucza głównego w innej tabeli. Następnie, kwerenda stosuje filtrację WHERE cena > 10, co pozwala na wybór tylko tych rekordów, gdzie cena usługi przekracza 10 zł. Jest to zgodne z praktyką selektywnego pobierania danych, co jest kluczowe w optymalizacji zapytań i skutecznym zarządzaniu zasobami bazy danych. Zastosowanie takich technik jest standardem w branży, umożliwiając efektywne zarządzanie dużymi zbiorami danych oraz zwiększenie wydajności aplikacji poprzez ograniczenie liczby zwracanych wierszy do tych, które spełniają określone kryteria. Zrozumienie i umiejętność implementacji takich zapytań SQL to podstawowa umiejętność dla specjalistów IT pracujących z bazami danych.

Pytanie 5

Wynik wykonania zapytania SQL to

SELECT count(*) FROM Uczniowie WHERE srednia = 5;
A. średnia ocen wszystkich uczniów
B. liczba uczniów, których średnia ocen wynosi 5
C. całkowita liczba uczniów
D. suma ocen uczniów, których średnia ocen to 5
Zarówno pierwsza, jak i druga odpowiedź nie są zgodne z logiką zapytania SQL. Pierwsza odpowiedź sugeruje, że wynik zapytania to liczba wszystkich uczniów. Jest to nieprawidłowe, ponieważ zapytanie liczy tylko tych uczniów, którzy mają średnią ocen równą 5, a nie wszystkich uczniów. Tego rodzaju myślenie prowadzi do błędnych wniosków o zakresie danych, które zliczamy. Z kolei druga odpowiedź wskazuje na średnią ocen wszystkich uczniów, co również jest błędne, ponieważ zapytanie nie oblicza średniej, lecz jedynie liczy liczby spełniające określony warunek. Tego rodzaju nieporozumienia mogą prowadzić do nieprawidłowych analiz, które mogą wpływać na podejmowanie decyzji, szczególnie w kontekście edukacyjnym, gdzie dane są kluczowe dla oceny postępów uczniów. Trzecią odpowiedzią jest liczba uczniów z konkretną średnią, co w rzeczywistości jest celem naszego zapytania, natomiast czwarta odpowiedź, mówiąca o sumie ocen uczniów, również nie ma podstaw w tym kontekście, ponieważ zapytanie nie wykonuje operacji dodawania, lecz liczy rekordy. Kluczowe jest zrozumienie, jak różne operacje w SQL wpływają na wyniki i jak poprawne formułowanie zapytań może prowadzić do uzyskania pożądanych danych.

Pytanie 6

Polecenie DBCC CHECKDB 'sklepAGD', Repair_fast) w systemie MS SQL Server

A. zweryfikuje spójność danej tabeli oraz naprawi uszkodzone rekordy
B. sprawdzi spójność bazy danych i naprawi uszkodzone indeksy
C. zweryfikuje spójność danej tabeli
D. potwierdzi spójność bazy danych i utworzy kopię zapasową
Odpowiedzi sugerujące, że polecenie DBCC CHECKDB sprawdza spójność jedynie określonej tabeli są nieprecyzyjne, ponieważ w rzeczywistości działa na całej bazie danych. Choć istnieje możliwość sprawdzania poszczególnych tabel za pomocą innych poleceń, DBCC CHECKDB jest narzędziem, które analizuje całą strukturę bazy danych wraz z jej indeksami i danymi. Twierdzenie, że to polecenie jedynie sprawdza spójność bazy danych oraz wykonuje kopię bezpieczeństwa, jest mylące. DBCC CHECKDB nie tworzy kopii zapasowych, a jego głównym celem jest identyfikacja i raportowanie błędów, co jest kluczowe w kontekście utrzymania zdrowia bazy danych. Użytkownicy mogą zatem błędnie zakładać, że polecenie zapewnia automatyczną naprawę danych, co w rzeczywistości wymaga zastosowania dodatkowych opcji naprawy, takich jak Repair_fast lub Repair_rebuild. Ponadto, niektóre odpowiedzi wskazują na naprawę uszkodzonych rekordów, co nie jest precyzyjne, ponieważ DBCC CHECKDB zajmuje się głównie naprawą indeksów oraz strukturalnych problemów w bazie danych, a nie pojedynczych rekordów. Rzetelne zrozumienie tych różnic jest kluczowe dla skutecznego zarządzania bazą danych i unikania nieporozumień dotyczących działania narzędzi diagnostycznych w MS SQL Server.

Pytanie 7

Jakie zadania programistyczne należy realizować po stronie serwera?

A. Ukrywanie oraz odkrywanie elementów strony w zależności od bieżącej pozycji kursora
B. Walidacja danych wpisanych w pole tekstowe w czasie rzeczywistym
C. Zapisanie danych pobranych z aplikacji internetowej do bazy danych
D. Zmiana stylu HTML na stronie spowodowana ruchem kursora
Zapis danych z aplikacji internetowej w bazie to super ważna sprawa. Ogólnie mówiąc, to serwer się tym zajmuje. To on trzyma i zarządza informacjami, które wysyłamy, jak się rejestrujemy czy wypełniamy jakieś formularze. Kiedy użytkownik coś wpisuje, te dane muszą lecieć do serwera, gdzie są przetwarzane i lądować w bazie danych. Przykładowo, w relacyjnych bazach danych, jak MySQL czy PostgreSQL, używa się zapytań SQL do zarządzania tymi danymi, co ułatwia ich późniejsze szukanie. Warto też pamiętać o bezpieczeństwie – serwer musi robić walidację danych, żeby nie dać się nabrać na ataki typu SQL Injection. No i architektura MVC świetnie pokazuje, jak ważne jest miejsce serwera dla danych. Zapis danych to po prostu kluczowy element w działaniu aplikacji webowych.

Pytanie 8

Jakiej funkcji w języku PHP należy użyć, aby nawiązać połączenie z bazą danych pod nazwą zwierzaki?

A. $polacz = mysqli_connect('localhost', 'root', '', 'zwierzaki')
B. $polacz = sql_connect('localhost', 'root', '', 'zwierzaki')
C. $polacz = server_connect('localhost', 'root', '', 'zwierzaki')
D. $polacz = db_connect('localhost', 'root', '', 'zwierzaki')
Funkcje zaproponowane w odpowiedziach 1, 2 i 3 nie są poprawne, ponieważ nie istnieją w standardowej bibliotece PHP do obsługi baz danych MySQL. Przykład $polacz = db_connect('localhost', 'root', '', 'zwierzaki'); sugeruje, że istnieje funkcja o nazwie db_connect, co jest mylnym przekonaniem. Tego typu nazewnictwo może powstać z pomyłki lub z nieznajomości dokumentacji PHP, a także z prób tworzenia własnych abstrakcji, które jednak wymagają dodatkowej implementacji. W przypadku drugiej odpowiedzi, $polacz = sql_connect('localhost', 'root', '', 'zwierzaki'); również nie jest poprawne, ponieważ nie istnieje funkcja sql_connect w żadnej wersji PHP. Może to wynikać z mylenia terminologii, ponieważ wielu programistów używa terminów SQL i MySQL zamiennie, nie zdając sobie sprawy, że MySQL jest specyficzną implementacją obsługi SQL. Ostatnia sugestia, $polacz = server_connect('localhost', 'root', '', 'zwierzaki'); jest także nieprawidłowa, ponieważ taka funkcja nie istnieje w kontekście PHP i jest przykładem błędnego wnioskowania, które może prowadzić do dezorientacji wśród programistów. W programowaniu niezwykle istotne jest trzymanie się udokumentowanych funkcji i standardów, aby uniknąć problemów z kompatybilnością, wydajnością oraz bezpieczeństwem aplikacji. Dlatego kluczowe jest zapoznanie się z dokumentacją PHP oraz zrozumienie, jak poprawnie łączyć się z bazami danych, aby móc efektywnie korzystać z ich możliwości.

Pytanie 9

Które dane zostaną wybrane w wyniku działania kwerendy na przedstawionych rekordach?

SELECT id FROM samochody WHERE rocznik LIKE "2%4";
idmarkamodelrocznik
1FiatPunto2016
2FiatPunto2002
3FiatPunto2007
4OpelCorsa2016
5OpelAstra2003
6ToyotaCorolla2016
7ToyotaCorolla2014
8ToyotaYaris2004
A. Wszystkie identyfikatory.
B. Tylko identyfikator równy 8.
C. Identyfikatory równe 7 oraz 8.
D. Brak danych.
Prawidłowa odpowiedź wskazuje, że w wyniku działania kwerendy zostaną wybrane rekordy z id równymi 7 oraz 8, ponieważ oba te roczniki zaczynają się cyfrą 2 i kończą na 4, co spełnia warunek LIKE '2%4'. W SQL operator LIKE umożliwia wyszukiwanie wzorców w danych tekstowych i jest bardzo użyteczny w sytuacjach, gdy nieznana jest pełna wartość, a tylko jej część. W praktycznych aplikacjach, takich jak systemy zarządzania bazami danych, często stosuje się ten operator do filtrowania wyników na podstawie niepełnych informacji. Na przykład, jeżeli chciałbyś zidentyfikować wszystkie pojazdy z określonym rocznikiem, użycie LIKE może szybko zawęzić wyniki. Używanie tego operatora w połączeniu z innymi funkcjami SQL, jak GROUP BY czy JOIN, pozwala na kompozycję bardziej złożonych zapytań, co jest standardem w analityce danych.

Pytanie 10

Jaką wiadomość należy umieścić w przedstawionym fragmencie kodu PHP zamiast znaków zapytania? $a=mysql_connect('localhost','adam','mojeHasło'); if(!$a) echo "?????????????????????????";

A. Błąd połączenia z serwerem SQL
B. Wybrana baza danych nie istnieje
C. Błąd w przetwarzaniu zapytania SQL
D. Rekord został pomyślnie dodany do bazy
Wybranie innej opcji niż 'Błąd połączenia z serwerem SQL' jest mylne, ponieważ każda z tych odpowiedzi nie odnosi się do kontekstu błędu połączenia z bazą danych. Stwierdzenie 'Wybrana baza nie istnieje' sugeruje, że połączenie z serwerem SQL zostało nawiązane, ale nie udało się znaleźć konkretnej bazy danych. W rzeczywistości jednak błąd przy próbie połączenia z serwerem SQL jest czymś innym, ponieważ w momencie, gdy połączenie się nie udaje, nie można jeszcze mówić o istnieniu czy nieistnieniu bazy. Kolejna opcja, 'Pomyślnie dodano rekord do bazy', jest oczywiście błędna, ponieważ w przypadku braku połączenia nie ma możliwości dodania jakiegokolwiek rekordu. Ta odpowiedź myli koncepcję pomyślnego wykonania operacji z brakiem połączenia z bazą danych. Ostatecznie, 'Błąd przetwarzania zapytania SQL' również jest niepoprawny w tym kontekście, ponieważ odnosi się do sytuacji, w której połączenie z bazą danych zostało nawiązane, ale zapytanie SQL nie mogło zostać przetworzone z powodu błędów składniowych, braku uprawnień lub innych problemów. Jednak w przypadku problemu z połączeniem nie dochodzi nawet do etapu przetwarzania zapytania, co czyni tę odpowiedź nieadekwatną.

Pytanie 11

Funkcja agregująca AVG wykorzystana w zapytaniu

SELECT AVG(cena) FROM uslugi;
ma na celu
A. obliczenie liczby dostępnych usług w tabeli
B. zsumowanie wszystkich kosztów usług
C. wyliczenie średniej arytmetycznej cen wszystkich usług
D. znalezienie najwyższej ceny za usługi
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 12

Aby uzyskać dane z tabeli pracownicy wyłącznie dla osób, które osiągnęły 26 lat, należy zastosować zapytanie

A. SELECT * FROM pracownicy WHERE wiek > '25'
B. SELECT * FROM pracownicy AND wiek > '25'
C. SELECT * FROM pracownicy OR wiek > '25'
D. SELECT * FROM wiek WHERE pracownicy > '25'
Poprawne zapytanie to 'SELECT * FROM pracownicy WHERE wiek > '25';'. To zapytanie jest zgodne z zasadami SQL i pozwala na wyświetlenie wszystkich rekordów z tabeli 'pracownicy', które spełniają określony warunek dotyczący wieku. Używając klauzuli WHERE, precyzyjnie filtrujemy wyniki i zwracamy tylko tych pracowników, którzy mają więcej niż 25 lat. Warto pamiętać, że w SQL operator '>' jest wykorzystywany do porównywania wartości, a w tym przypadku pozwala nam na wybranie pracowników, którzy ukończyli 26 lat. Przy projektowaniu zapytań SQL, kluczowe jest stosowanie odpowiednich warunków filtrujących, aby ograniczyć zwracane dane do tych istotnych dla analiz. Przykładowo, analiza wieku pracowników w kontekście przyznawania dodatków lub przeprowadzania szkoleń może opierać się na takich zapytaniach. W praktyce, ważne jest także wykorzystanie indeksów w bazach danych, aby zwiększyć wydajność zapytań, zwłaszcza w dużych zbiorach danych.

Pytanie 13

Tabela gory zawiera dane o polskich szczytach oraz górach, w których się one znajdują. Jakie zapytanie należy wykonać, aby zobaczyć Koronę Gór Polskich, czyli najwyższy szczyt w każdym z pasm górskich?

A. SELECT pasmo, szczyt FROM gory GROUP BY wysokosc;
B. SELECT pasmo, szczyt, wysokosc FROM gory;
C. SELECT pasmo, szczyt, MAX(wysokosc) FROM gory GROUP BY pasmo;
D. SELECT pasmo, szczyt, MAX(wysokosc) FROM gory;
Analizując pozostałe odpowiedzi, można zauważyć kluczowe błędy w podejściu do zadania. W pierwszej opcji, SELECT pasmo, szczyt, wysokosc FROM gory; kwerenda ta zwracałaby wszystkie rekordy z tabeli, co oznacza, że nie zrealizowano by celu znalezienia najwyższego szczytu w każdym pasmie. Brak użycia grupowania i funkcji agregującej prowadzi do nieefektywnego przetwarzania danych. Kolejna odpowiedź, SELECT pasmo, szczyt, MAX(wysokosc) FROM gory; wygląda na bliską poprawności, ale również nie spełnia wymogów, ponieważ nie zawiera klauzuli GROUP BY, co skutkuje błędem w kontekście SQL. Bez grupowania nie można poprawnie zidentyfikować wartości maksymalnych w odniesieniu do poszczególnych pasm. Dodatkowo, kwerenda SELECT pasmo, szczyt FROM gory GROUP BY wysokosc; jest całkowicie wadliwa, ponieważ grupuje dane według wysokości szczytów, co nie ma sensu w kontekście poszukiwania najwyższych szczytów w każdym pasmie. Takie podejście może prowadzić do niejednoznacznych i niepoprawnych wyników, które nie odpowiadają zadaniu. Typowe błędy myślowe, które prowadzą do takich wniosków, obejmują nieprawidłowe zrozumienie zasad grupowania i agregacji w SQL, co jest fundamentalne do skutecznego wykorzystania relacyjnych baz danych.

Pytanie 14

W bazie danych znajduje się tabela pracownicy z kolumnami: id, imie, nazwisko, pensja. W nowym roku postanowiono zwiększyć wynagrodzenie wszystkim pracownikom o 100 zł. Jak powinno wyglądać to w aktualizacji bazy danych?

A. UPDATE pensja SET 100;
B. UPDATE pracownicy SET pensja = pensja + 100;
C. UPDATE pensja SET +100;
D. UPDATE pracownicy SET pensja = 100;
Odpowiedź 'UPDATE pracownicy SET pensja = pensja + 100;' jest prawidłowa, ponieważ wprowadza właściwą składnię SQL, która aktualizuje pole 'pensja' w tabeli 'pracownicy'. To polecenie wykorzystuje operator przypisania '=', aby zaktualizować wartość 'pensja', dodając do niej 100 zł. W praktyce jest to typowy sposób na modyfikację danych w bazach danych relacyjnych, przy użyciu SQL. Kluczowym aspektem jest zrozumienie, że 'pensja' w tym kontekście odnosi się do istniejącej wartości w danym rekordzie, a nie do jakiejś stałej. Operator '+' w tym przypadku informuje system, że chcemy zwiększyć aktualną wartość o 100. Użycie tego typu składni jest zgodne z najlepszymi praktykami w programowaniu baz danych, co sprzyja przejrzystości i zrozumiałości kodu. Tego rodzaju aktualizacje są kluczowe w zarządzaniu danymi pracowników, zwłaszcza w kontekście systemów wynagrodzeń, gdzie regularne zmiany pensji są normą.

Pytanie 15

W tabeli podzespoly należy zaktualizować wartość pola URL na "toshiba.pl" dla wszystkich rekordów, w których pole producent jest równe TOSHIBA. Jak będzie wyglądała ta zmiana w języku SQL?

A. UPDATE podzespoly.producent='TOSHIBA' SET URL = 'toshiba.pl';
B. UPDATE podzespoly SET URL='toshiba.pl' WHERE producent='TOSHIBA';
C. UPDATE producent='TOSHIBA' SET URL = 'toshiba.pl';
D. UPDATE podzespoly SET URL = 'toshiba.pl';
Aby zaktualizować wartość pola URL w tabeli podzespoly na 'toshiba.pl' dla wszystkich rekordów, gdzie pole producent jest równe 'TOSHIBA', należy użyć instrukcji UPDATE w języku SQL. Właściwa składnia tej instrukcji to: UPDATE podzespoly SET URL='toshiba.pl' WHERE producent='TOSHIBA';. W tej instrukcji UPDATE najpierw wskazujemy, której tabeli dotyczy modyfikacja, w tym przypadku 'podzespoly'. Następnie określamy, jakie pole chcemy zaktualizować, czyli 'URL', oraz ustawiamy nową wartość, którą w tym przypadku jest 'toshiba.pl'. Kluczowym elementem tej operacji jest klauzula WHERE, która filtruje rekordy, które mają być zaktualizowane; w tym przypadku tylko te, które mają producenta 'TOSHIBA'. Bez klauzuli WHERE wszystkie rekordy w tabeli zostałyby zmodyfikowane, co mogłoby prowadzić do utraty danych. Przykład ilustruje, jak precyzyjnie można zarządzać danymi w bazie poprzez odpowiednie warunki. Tego typu operacje są zgodne z normami SQL, co zapewnia ich efektywność i bezpieczeństwo w zarządzaniu danymi.

Pytanie 16

Wykonano następującą kwerendę na tabeli Pracownicy:

SELECT imie FROM pracownicy WHERE nazwisko = 'Kowal' OR stanowisko > 2;

Na tabeli Pracownicy, której wiersze zostały pokazane na obrazie, wykonano przedstawioną kwerendę SELECT. Które dane zostaną wybrane?

idimienazwiskostanowisko
1AnnaKowalska1
2MonikaNowak2
3EwelinaNowakowska2
4AnnaPrzybylska3
5MariaKowal3
6EwaNowacka4
A. Tylko Anna.
B. Tylko Maria.
C. Monika, Ewelina, Maria.
D. Anna, Maria, Ewa.
Gratulacje, udzielona odpowiedź jest prawidłowa! Wykonana kwerenda SQL 'SELECT imie FROM pracownicy WHERE nazwisko = 'Kowal' OR stanowisko > 2;' zwraca imiona pracowników, którzy albo mają nazwisko 'Kowal', albo zajmują stanowisko o numerze większym niż 2. W kontekście przedstawionej tabeli pracowników, taka kwerenda zwróci nam poprawną odpowiedź 'Anna, Maria, Ewa'. To dlatego, że Anna pracuje na stanowisku 3, co jest większe niż 2, Maria ma nazwisko 'Kowal', a Ewa pracuje na stanowisku 4, które jest również większe niż 2. SQL jako język zapytań pozwala na efektywne zarządzanie danymi, niezależnie od skomplikowania zapytania. W praktyce, gdy mamy do czynienia z dużym zbiorem danych, takie zapytania pomagają w szybkim filtrowaniu i dostępie do potrzebnych informacji. Dobrym standardem jest wymyślanie i testowanie zapytań SQL w celu zrozumienia, jakie dane zostaną zwrócone, zanim zapytanie zostanie użyte w prawdziwej aplikacji lub systemie.

Pytanie 17

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

A. nadpisania istniejącej tabeli USA
B. stworzenia nowej tabeli USA
C. zmiany tabeli USA
D. usunięcia 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 18

Wskaż komendę, która dokonuje aktualizacji danych w tabeli?

A. SELECT
B. UPDATE
C. CREATE
D. ALTER
Odpowiedź "UPDATE" jest jak najbardziej trafna. To takie podstawowe polecenie SQL, które pozwala na aktualizowanie już istniejących danych w tabeli. Możesz dzięki niemu zmienić jeden albo kilka wierszy w tabeli, w zależności od tego, jakie masz kryteria. Na przykład, jeśli mamy tabelę "pracownicy" i chcemy zwiększyć pensję programistów do 6000 zł, wystarczy użyć polecenia: `UPDATE pracownicy SET pensja = 6000 WHERE stanowisko = 'programista';`. To polecenie działa w taki sposób, że modyfikuje dane, ale przy tym dba o integralność, co jest bardzo ważne w pracy z bazami danych. Warto zawsze dodawać klauzulę WHERE, żeby zmiany dotyczyły tylko wybranych wierszy – to pomoże uniknąć sytuacji, w której przypadkiem zmienisz wszystko. Umiejętność korzystania z UPDATE jest naprawdę istotna, jeżeli chcesz efektywnie zarządzać swoimi danymi.

Pytanie 19

Efektem wykonania kwerendy dla przedstawionej tabeli rezerwacje jest

SELECT sezon, SUM(liczba_dn) FROM rezerwacje
GROUP BY sezon;

id_pokliczba_dnsezon
110lato
24zima
15lato
26zima
15lato
39zima
18zima
A. lato 3, zima 4
B. lato 20, zima 27
C. lato 10, zima 4, lato 5, zima 6, lato 5, zima 9, zima 8
D. lato 10, 5, 5; zima 4, 6, 9, 8
Dobrze, że wybrałeś odpowiedź 'lato 20, zima 27'. Jest to poprawne rozwiązanie, ponieważ zapytanie SQL, które wykonujemy na tabeli rezerwacje, grupuje wyniki według sezonu i sumuje liczbę dni dla każdego sezonu. W praktyce, jeżeli mamy tabelę z danymi o rezerwacjach na różne sezony i chcemy zrozumieć, ile łącznie dni zostało zarezerwowanych dla każdego sezonu, musimy użyć takiego zapytania. W tym przypadku, suma dni dla sezonu 'lato' wynosi 20, a dla sezonu 'zima' - 27. Wiedza ta jest niezwykle przydatna, gdy na przykład chcemy zaplanować ilość dostępnych miejsc w hotelu na kolejne sezony, biorąc pod uwagę historię rezerwacji. Zwróć uwagę, że korzystanie z funkcji agregujących jak SUM w SQL jest kluczowe dla przeprowadzania analiz danych. Właściwe zrozumienie i stosowanie tych funkcji pozwoli Ci na przeprowadzanie skomplikowanych analiz i przewidywań na podstawie zgromadzonych danych.

Pytanie 20

Aby przywrócić bazę danych o nazwie Sklep z pliku towary.sql, należy w miejsce gwiazdek wpisać nazwę użytkownika. Polecenie wygląda następująco:

mysql -u ******* -p Sklep < towary.sql
A. liczbę importowanych obiektów bazy.
B. nazwę użytkownika.
C. nazwę odzyskiwanej tabeli.
D. adres IP bazy danych.
Polecenie mysql ma dość sztywną i dobrze udokumentowaną składnię, więc warto ją sobie poukładać raz a dobrze. W przedstawionym przykładzie mamy: mysql -u ******* -p Sklep < towary.sql. Przełącznik -u w kliencie MySQL zawsze oznacza nazwę użytkownika, czyli konto w systemie bazy danych, którym się logujemy. To nie jest ani adres IP, ani nazwa tabeli, ani żadna liczba obiektów. Klient mysql w ogóle nie przyjmuje w tym miejscu takich danych. Częsty błąd polega na mieszaniu pojęć: adres IP czy hostname serwera bazy podaje się inną opcją, -h (np. -h 192.168.1.10 lub -h db.example.com). Parametr -u nie ma nic wspólnego z lokalizacją serwera, tylko z tożsamością użytkownika w systemie uprawnień MySQL. Podobnie nazwa odzyskiwanej tabeli nie jest nigdzie wpisywana w linii poleceń mysql przy imporcie. Tabele są tworzone i wypełniane wewnątrz pliku SQL – to tam znajdują się instrukcje CREATE TABLE i INSERT, więc nie ma potrzeby ani możliwości podania nazwy jednej konkretnej tabeli w miejscu, gdzie klient oczekuje nazwy użytkownika. Jeśli importujemy tylko jedną tabelę, to i tak cały proces kontroluje zawartość pliku towary.sql, a nie argument -u. Równie mylące jest myślenie o „liczbie importowanych obiektów bazy”. Narzędzie mysql nie ma opcji, w której wpisujemy jakąś liczbę tabel czy rekordów do zaimportowania. Importuje po prostu wszystko, co jest w skrypcie SQL, aż do końca pliku lub do wystąpienia błędu. Właściwy sposób myślenia jest taki: -h mówi „do jakiego serwera się łączę”, -u mówi „kim się loguję”, -p wymusza podanie hasła, dalej podajemy nazwę bazy (Sklep), a znak < przekierowuje zawartość pliku towary.sql na wejście programu. Z mojego doświadczenia wynika, że jak się raz zrozumie to rozdzielenie ról poszczególnych parametrów, to znika większość nieporozumień przy pracy z kopią zapasową i przywracaniem baz danych.

Pytanie 21

W systemie MySQL należy użyć polecenia REVOKE, aby odebrać użytkownikowi anna możliwość wprowadzania zmian tylko w definicji struktury bazy danych. Odpowiednie polecenie do zrealizowania tej operacji ma formę

A. REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'
B. REVOKE ALL ON tabela1 FROM 'anna'@'localhost'
C. REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost'
D. REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'
Wszystkie inne odpowiedzi są nieprawidłowe z kilku powodów. W pierwszej z nich, 'REVOKE ALL ON tabela1 FROM 'anna'@'localhost'', przyznawane są wszystkie uprawnienia, co jest sprzeczne z intencją odebrania tylko określonych praw. Użytkownicy powinni być ograniczani jedynie w tych obszarach, gdzie to konieczne. Z kolei odpowiedź 'REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'' zawiera 'UPDATE', co jest związane z danymi, a nie strukturą bazy, co również czyni ją niewłaściwą. Odmowa praw do aktualizacji danych nie jest odpowiednia w kontekście modyfikacji struktury bazy. Z kolei opcja 'REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'' ponownie nie odnosi się do struktury bazy, ponieważ odnosi się do manipulacji danymi, nie do struktury. Kluczowym błędem w tym kontekście jest mylenie uprawnień związanych z danymi z uprawnieniami związanymi ze strukturą bazy danych. W zarządzaniu uprawnieniami w MySQL istotne jest zrozumienie różnicy pomiędzy tymi kategoriami, aby skutecznie zabezpieczyć bazę danych. W praktyce dobrym podejściem jest wdrożenie zasady minimalnych uprawnień, co zmniejsza ryzyko nieautoryzowanych zmian w strukturze i danych bazy.

Pytanie 22

Tabela filmy zawiera klucz główny id oraz klucz obcy rezyserID. Tabela reżyserzy posiada klucz główny id. Obie tabele są powiązane relacją jeden do wielu, gdzie strona reżyserzy jest po stronie jeden, a filmy po stronie wiele. Aby wykonać kwerendę SELECT łączącą tabele filmy i reżyserzy, należy użyć zapisu

A. ... filmy JOIN rezyserzy ON filmy.rezyserzyID=rezyserzy.id ...
B. ... filmy JOIN rezyserzy ON filmy.id=rezyserzy.filmyID ...
C. ... filmy JOIN rezyserzy ON filmy.rezyserID=rezyserzy.filmyID ...
D. ... filmy JOIN rezyserzy ON filmy.id=rezyserzy.id ...
Wybór niepoprawnej odpowiedzi może wynikać z nieporozumienia co do relacji między tabelami i ich kluczami. W pierwszej opcji, warunek łączenia jest błędny, ponieważ użyto 'filmy.id' zamiast 'filmy.rezyserID'. Klucz główny 'id' w tabeli 'filmy' nie jest powiązany z kluczem głównym w tabeli 'rezyserzy', co prowadzi do nieprawidłowego łączenia. W drugiej opcji, podobnie jak w pierwszej, jest błędne odniesienie, ponieważ 'filmy.filmyID' nie istnieje jako klucz w tabeli 'filmy', co skutkuje niezgodnością, ponieważ 'filmy' nie powinny mieć klucza o takiej nazwie. Rozważając kolejną odpowiedź, zauważamy, że 'filmy.rezyserzyID' również jest niewłaściwe, ponieważ nie jest zgodne z definicją kluczy obcych, które powinny odnosić się do 'rezyserID'. Każda z tych niepoprawnych odpowiedzi nie tylko prowadzi do błędnych wyników, ale także narusza zasady normalizacji bazy danych, co może skutkować problemami z integralnością oraz błędami w analizach danych.

Pytanie 23

Element bazy danych, którego podstawowym celem jest generowanie lub prezentowanie zestawień informacji, to

A. moduł
B. formularz
C. raport
D. makro
Raport to taki dokument w bazie danych, który ma za zadanie pokazać dane w przejrzysty i uporządkowany sposób. To jest mega ważne, zwłaszcza kiedy chcemy analizować różne informacje. Można je wykorzystać do robienia zestawień, statystyk, a nawet wykresów, co naprawdę ułatwia podejmowanie decyzji. Zazwyczaj raporty tworzy się na podstawie danych z różnych miejsc, jak tabele czy zapytania. W programach do zarządzania bazami, jak Microsoft Access, można korzystać z kreatora raportów, który pomaga ustawić wszystko tak, jak się chce – wybieramy źródło danych, układ i format. Oczywiście, do pozyskiwania danych często wykorzystuje się SQL, no i potem już te dane można analizować i przedstawiać w raportach. Jak sobie pomyślisz o przykładzie, to taki miesięczny raport sprzedaży to super narzędzie dla menedżerów, bo mogą ocenić, jak im idzie w sprzedaży i podejmować lepsze decyzje strategiczne.

Pytanie 24

Czym jest relacja w bazach danych?

A. logicznym połączeniem tabel
B. połączeniem dwóch pól w obrębie jednej tabeli
C. algebraicznym połączeniem tabel
D. kluczem głównym w relacji tabel
Relacja w bazach danych to logiczne połączenie tabel, które umożliwia organizację i zarządzanie danymi w sposób umożliwiający ich efektywne przetwarzanie. W kontekście baz danych relacyjnych, relacje tworzone są na podstawie kluczy, które pozwalają na łączenie danych z różnych tabel. Na przykład, w bazie danych e-commerce, tabela 'Klienci' może być połączona z tabelą 'Zamówienia' przez klucz klienta. Dzięki temu, gdy zapytamy o zamówienia konkretnego klienta, silnik bazy danych może wykonać zapytanie łączące te obie tabele, dostarczając spójny zestaw danych. Taki model relacyjny oparty jest na teorii zbiorów i algebrze relacyjnej, co pozwala na skomplikowane operacje, takie jak łączenie, filtrowanie i agregowanie danych. W praktyce, relacje w bazach danych są kluczowe dla zapewnienia integralności danych, eliminacji redundancji oraz zwiększenia wydajności operacji na danych. Standardy takie jak SQL oparte są na tych koncepcjach, co czyni je fundamentalnymi w programowaniu baz danych.

Pytanie 25

W języku SQL do grupy operacji DCL (ang. Data Control Language) należą polecenia:

A. SELECT i INSERT
B. GRANT i REVOKE
C. DELETE i UPDATE
D. CREATE i DROP
W SQL rozróżnienie między DDL, DML i DCL jest kluczowe, bo każdy z tych zestawów poleceń odpowiada za inny obszar pracy z bazą danych. Wiele osób intuicyjnie wrzuca wszystkie komendy „do jednego worka”, a potem trudno jest im zrozumieć, gdzie kończy się manipulacja danymi, a zaczyna zarządzanie uprawnieniami. Data Control Language, czyli DCL, to bardzo wąska, ale ważna grupa poleceń, służąca wyłącznie do kontroli dostępu. W standardowym SQL do DCL zaliczamy praktycznie tylko GRANT i REVOKE. Odpowiedzi typu CREATE i DROP są kuszące, bo też brzmią „administracyjnie”, ale to już inna kategoria – DDL (Data Definition Language). CREATE, ALTER, DROP czy TRUNCATE służą do definiowania i modyfikowania struktury bazy: tworzą tabele, widoki, indeksy, usuwają obiekty. One nie zarządzają prawami użytkowników, tylko tym, jakie obiekty w ogóle istnieją. To, że często wykonuje je administrator, nie znaczy jeszcze, że należą do DCL. Z kolei SELECT, INSERT, UPDATE, DELETE to klasyczne DML (Data Manipulation Language). Te polecenia działają na rekordach: odczytują dane, dodają nowe wiersze, modyfikują istniejące, usuwają je. Typowy błąd myślowy polega na tym, że ktoś myśli: skoro DELETE usuwa dane, to trochę jak „kontrola”, więc może DCL. Niestety nie – DELETE w ogóle nie dotyka uprawnień, ono po prostu kasuje rekordy, o ile użytkownik już ma odpowiednie prawa. Dopiero DCL decyduje, czy użytkownik może wykonać DELETE na danej tabeli. To subtelne, ale bardzo ważne rozróżnienie. Moim zdaniem warto zapamiętać prosty schemat: DDL – struktura, DML – dane, DCL – uprawnienia. Wtedy łatwiej od razu skojarzyć, że tylko GRANT i REVOKE pasują do kategorii Data Control Language, a reszta odpowiedzi dotyczy zupełnie innych warstw pracy z bazą.

Pytanie 26

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

A. relacji
B. klucza obcego
C. klucza podstawowego
D. numeryczne
Klucz podstawowy jest fundamentalnym elementem każdej relacyjnej bazy danych, ponieważ jednoznacznie identyfikuje każdy rekord w tabeli. Jego główną cechą jest unikalność, co oznacza, że żaden z rekordów w tabeli nie może mieć tego samego klucza podstawowego. Klucz podstawowy może składać się z jednego lub więcej atrybutów (kolumn), ale zawsze musi zapewniać jednoznaczność identyfikacji. Przykładem może być tabela 'Użytkownicy', gdzie 'ID_Użytkownika' działa jako klucz podstawowy, pozwalając na łatwe i szybkie wyszukiwanie konkretnych użytkowników. Zgodnie z najlepszymi praktykami projektowania baz danych, klucze podstawowe powinny być stabilne i niezmienne w czasie, aby uniknąć komplikacji związanych z aktualizacją wartości. Klucz podstawowy jest również kluczowy dla relacji między tabelami, ponieważ inne tabele mogą odwoływać się do niego poprzez klucze obce. Dzięki temu, struktura bazy danych staje się bardziej zorganizowana i lepiej znormalizowana, co z kolei prowadzi do zwiększonej wydajności i integralności danych.

Pytanie 27

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 DROP ON szkola.przedmioty TO uczen;
C. GRANT SELECT ON szkola.przedmioty TO uczen;
D. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
Odpowiedź GRANT SELECT ON szkola.przedmioty TO uczen jest poprawna, ponieważ przyznaje użytkownikowi 'uczen' jedynie uprawnienia do odczytu danych w tabeli 'przedmioty' w bazie danych 'szkola'. Uprawnienia SELECT pozwalają na przeglądanie danych, co jest istotne w kontekście nauki czy oceny przedmiotów, ale nie zezwalają na modyfikację danych ani na zmiany w strukturze tabeli. To podejście jest zgodne z zasadą minimalnych uprawnień, co oznacza, że użytkownik powinien mieć tylko te uprawnienia, które są niezbędne do wykonania swoich zadań. W praktyce, przyznawanie tylko uprawnień SELECT jest szczególnie ważne w środowiskach edukacyjnych, gdzie chcemy zapewnić uczniom dostęp do informacji, ale jednocześnie chronić integralność danych. W kontekście dobrych praktyk, ograniczenie dostępu do danych wrażliwych jest kluczowe, a nadawanie zbyt szerokich uprawnień może prowadzić do nieautoryzowanych zmian lub utraty danych.

Pytanie 28

Kwerenda ma za zadanie w tabeli artykuly ALTER TABLE artykuly MODIFY cena float;

A. zmienić nazwę kolumny z cena na float
B. zmienić typ na float dla kolumny cena
C. dodać kolumnę cena o typie float, jeśli nie istnieje
D. usunąć kolumnę cena typu float
Odpowiedź, która zmienia typ kolumny 'cena' na 'float' jest prawidłowa, gdyż użycie kwerendy ALTER TABLE z poleceniem MODIFY pozwala na modyfikację istniejącej kolumny w już utworzonej tabeli. W praktyce, jeśli w tabeli 'artykuły' kolumna 'cena' była wcześniej zdefiniowana jako typ inny niż float, zastosowanie polecenia ALTER TABLE jest właściwą metodą, by dostosować ten typ do wymagań aplikacji, które mogą wymagać precyzyjnych wartości liczbowych, na przykład w kontekście obliczeń finansowych. W SQL, typ float jest używany do przechowywania liczb zmiennoprzecinkowych, co jest szczególnie istotne w przypadku cen, które mogą mieć wartości dziesiętne. Dobre praktyki sugerują, aby zmiana typu danych dokonywana była w sposób przemyślany i po uprzednim sprawdzeniu, czy zmiana nie wpłynie negatywnie na istniejące dane. Warto pamiętać, że przed modyfikacją schematu bazy danych, dobrze jest wykonać kopię zapasową, aby zminimalizować ryzyko utraty danych.

Pytanie 29

Dana jest tabela ksiazki z polami: tytul, autor, cena (typu liczbowego). Aby kwerenda SELECT wybrała tylko tytuły, dla których cena jest mniejsza od 50 zł, należy zapisać

A. SELECT ksiazki FROM tytul WHERE cena < '50 zł';
B. SELECT tytul FROM ksiazki WHERE cena > '50 zł';
C. SELECT tytul FROM ksiazki WHERE cena < 50;
D. SELECT * FROM ksiazki WHERE cena < 50;
Prawidłowa odpowiedź wybiera dokładnie to, o co chodzi w treści zadania: tylko kolumnę tytul z tabeli ksiazki, ale tylko dla tych rekordów, gdzie cena jest mniejsza niż 50. Składnia SELECT tytul FROM ksiazki WHERE cena < 50; jest zgodna ze standardowym SQL i pokazuje dobrą praktykę – pobieramy tylko te dane, które są nam potrzebne, zamiast używać SELECT *. Dzięki temu zapytanie jest lżejsze, szybsze i czytelniejsze, co w większych projektach ma naprawdę duże znaczenie. Moim zdaniem warto zwrócić uwagę na kilka elementów. Po pierwsze, w klauzuli SELECT podajemy konkretne nazwy kolumn (tu: tytul), nie nazwę tabeli. Po drugie, w FROM podajemy dokładnie nazwę tabeli, z której korzystamy (ksiazki). Po trzecie, warunek WHERE cena < 50 poprawnie porównuje wartość liczbową, bo kolumna cena ma typ liczbowy, więc nie używamy tu cudzysłowów ani żadnych „zł” w środku. W praktyce podobny wzorzec stosuje się cały czas, np.: SELECT tytul, autor FROM ksiazki WHERE cena <= 30; żeby dostać tańsze książki, albo SELECT tytul FROM ksiazki WHERE cena BETWEEN 20 AND 40; gdy interesuje nas konkretny przedział. W profesjonalnych aplikacjach webowych taka precyzja w definiowaniu zapytań SQL jest podstawą: ułatwia optymalizację, indeksowanie kolumn (np. indeks na kolumnie cena przyspiesza filtrowanie w WHERE) i minimalizuje przesyłanie niepotrzebnych danych między bazą a aplikacją. Dobra praktyka jest też taka, żeby dostosowywać typy danych: skoro cena jest liczbą, to porównujemy ją z liczbą, bez jednostek, a formatowanie typu „50 zł” robimy później w warstwie prezentacji, np. w PHP, JavaScript albo w szablonach widoków.

Pytanie 30

Polecenie MySQL pokazane poniżej spowoduje, że użytkownikowi tkowal zostaną odebrane określone uprawnienia:

REVOKE DELETE, UPDATE ON pracownicy FROM 'tkowal'@'localhost';
A. odebrane uprawnienia do usuwania i dodawania rekordów w tabeli pracownicy
B. odebrane uprawnienia do usuwania i modyfikacji danych w tabeli pracownicy
C. przydzielone uprawnienia do wszelkich zmian struktury tabeli pracownicy
D. przydzielone uprawnienia do usuwania oraz aktualizacji danych w tabeli pracownicy
W kontekście zarządzania uprawnieniami w MySQL istotne jest zrozumienie różnicy między przydzielaniem a odbieraniem praw dostępu. Polecenie REVOKE nie przydziela uprawnień lecz je odbiera co jest kluczowym aspektem w zarządzaniu bezpieczeństwem bazy danych. Przydzielanie uprawnień odbywa się za pomocą polecenia GRANT które umożliwia nadanie użytkownikowi określonych praw dostępu do tabeli lub innych obiektów bazy danych. Zrozumienie tego rozróżnienia jest fundamentalne ponieważ wpływa ono na sposób w jaki zarządzamy dostępem użytkowników do wrażliwych danych. W niektórych przypadkach można błędnie założyć że REVOKE dotyczy struktury tabeli co jest mylnym podejściem ponieważ takie działania związane są z prawami DDL a nie DML. Dlatego pomyłka w interpretacji tego polecenia może prowadzić do niezamierzonych konsekwencji takich jak niekontrolowane modyfikacje danych. Typowym błędem jest także przypuszczenie że REVOKE może być używane do przydzielania praw co pokazuje brak zrozumienia podstawowych mechanizmów kontroli dostępu w MySQL. Zarządzanie dostępem jest kluczowe w zapewnieniu integralności i poufności danych dlatego ważne jest aby jasno rozróżniać między przydzielaniem i odbieraniem uprawnień.

Pytanie 31

Używając komendy BACKUP LOG w MS SQL Server, można

A. wykonać kopię zapasową dziennika transakcyjnego
B. zalogować się do kopii zapasowej
C. zrealizować pełną kopię zapasową
D. odczytać komunikaty generowane podczas tworzenia kopii
Wybór odpowiedzi dotyczący logowania się do kopii bezpieczeństwa wykazuje nieporozumienie dotyczące funkcji, jakie pełnią operacje backupu w MS SQL Server. Proces tworzenia kopii zapasowej dziennika transakcyjnego nie ma nic wspólnego z logowaniem się do wygenerowanej kopii; jest to osobny proces, który polega głównie na archiwizacji danych transakcyjnych. Kolejne stwierdzenie, że możliwe jest przeczytanie komunikatów wygenerowanych podczas tworzenia kopii, zakłada, że operacja backupu dostarcza interaktywnych danych na temat jej przebiegu, co nie jest zgodne z rzeczywistością. MS SQL Server zwykle loguje wyniki operacji do dziennika zdarzeń lub plików logów, ale nie jest to funkcjonalność, na którą można liczyć w codziennym użytkowaniu. Wreszcie, stwierdzenie, że BACKUP LOG pozwala na wykonanie pełnej kopii bezpieczeństwa, jest także błędne. BACKUP LOG dotyczy tylko dziennika transakcyjnego, podczas gdy pełna kopia bezpieczeństwa wykonana jest przy użyciu polecenia BACKUP DATABASE. W praktyce, wiele osób myli te dwa procesy, co prowadzi do nieefektywnego zarządzania danymi i ryzyka utraty informacji. Zrozumienie technicznych aspektów działania tych poleceń jest kluczowe dla prawidłowego administrowania bazami danych.

Pytanie 32

Podczas projektowania formularza konieczne jest wstawienie kontrolki, która odnosi się do innej kontrolki w odrębnym formularzu. Taka operacja w bazie danych Access jest

A. możliwa dzięki ustawieniu ścieżki do kontrolki w atrybucie "Źródło kontrolki"
B. niemożliwa
C. możliwa tylko wtedy, gdy są to dane numeryczne
D. niemożliwa w każdym trybie poza trybem projektowania
Błędne odpowiedzi wynikają z nieporozumienia dotyczącego możliwości i zasad działania kontrolek w formularzach Access. Ustawienie ścieżki do kontrolki we właściwości 'Źródło kontrolki' nie jest ograniczone do danych liczbowych, co jest błędnym założeniem. W rzeczywistości można odwoływać się do różnych typów danych, w tym tekstowych, datowych oraz liczbowych, co czyni tę funkcjonalność niezwykle uniwersalną. Twierdzenie, że odwołanie jest niemożliwe, jest również nieprawdziwe; Access oferuje rozbudowane możliwości tworzenia interakcji między formularzami, co jest szeroko stosowane w praktycznych zastosowaniach. Warto również zauważyć, że nie ma ograniczeń co do trybów pracy, które mogłyby wpływać na możliwość odwoływania się do kontrolek, co czyni to stwierdzeniem błędnym. W projektowaniu baz danych szczególnie istotne jest zrozumienie, jak różne elementy systemu mogą współdziałać, a umiejętność poprawnego użycia właściwości kontrolek jest kluczowa dla efektywności i użyteczności aplikacji. Ignorowanie tych aspektów prowadzi do nieefektywnego projektowania, w którym trudno jest zarządzać danymi oraz interakcjami użytkowników z aplikacją.

Pytanie 33

Zidentyfikuj poprawnie zbudowany warunek w języku PHP, który sprawdza brak połączenia z bazą MySQL.

A. if (mysqli_connect_errno()){}
B. if {mysqli_connect_error()}{}
C. if {mysql_connect_errno()}{}
D. if (mysql_connect_error())()
No, odpowiedzi, które wybrałeś, mają sporo błędów. Na przykład, 'if (mysql_connect_error())()' jest źle napisane, bo masz tu podwójne nawiasy, a powinny być pojedyncze. 'if {mysql_connect_errno(){}}' i 'if {mysqli_connect_error()}' używają klamr, gdzie powinny być nawiasy okrągłe, bo w PHP warunki muszą być w nawiasach. Te stare funkcje, takie jak 'mysql_connect_error()' czy 'mysql_connect_errno()', to już przeżytek, zostały usunięte w PHP 7.0. Teraz, wybierając 'mysqli', zapewniasz sobie lepsze bezpieczeństwo i działanie aplikacji. To jest kluczowe, żeby zrozumieć, jak poprawnie pisać kod, bo bez tego ciężko osiągniesz sukces w programowaniu w PHP.

Pytanie 34

Według którego parametru oraz dla ilu tabel zostaną zwrócone wiersze na liście w wyniku przedstawionego zapytania?

SELECT * FROM producent, hurtownia, sklep, serwis WHERE
  producent.nr_id = hurtownia.nr_id AND
  producent.wyrob_id = serwis.wyrob_id AND
  hurtownia.nr_id = sklep.nr_id AND
  sklep.nr_id = serwis.nr_id AND
  producent.nr_id = 1;
A. Według parametru wyrób Jd wyłącznie dla trzech tabel.
B. Według parametru nr id dla wszystkich tabel.
C. Według parametru nr id wyłącznie dla trzech tabel.
D. Według parametru wyrób id dla wszystkich tabel.
Brawo! Wybrałeś poprawną odpowiedź, zgodnie z którą parametrem nr id zwraca wiersze dla wszystkich tabel. To zapytanie SQL odnosi się do czterech tabel: producent, hurtownia, sklep i serwis. Zwraca ono wiersze, gdzie wartość kolumny nr_id jest taka sama we wszystkich tych tabelach i równa 1. Dodatkowo, jakość danych jest wspierana przez fakt, że zapytanie sprawdza zgodność wartości kolumny wyrob_id między tabelami producent i serwis. Zrozumienie tego, jak działa to zapytanie i dlaczego to jest ważne, jest kluczowe w praktyce programistycznej. Zapewnia to, że możemy skutecznie i efektywnie manipulować danymi, a także zrozumieć, jak nasze zapytania wpływają na wyniki, które otrzymujemy. Dobra praktyka jest zawsze zrozumienie, jakie dane są zwracane przez nasze zapytanie, zanim zaczniemy z nich korzystać w naszym kodzie. Ostatecznie, zrozumienie, jak korzystać z zapytań SQL do manipulacji i odzyskiwania danych, jest kluczowym elementem dowolnej roli programistycznej.

Pytanie 35

Baza danych MySQL została uszkodzona. Które z poniższych działańnie przyczyni się do jej naprawy?

A. Próba naprawy za pomocą polecenia REPAIR
B. Wykonanie replikacji bazy danych
C. Odtworzenie bazy z kopii zapasowej
D. Utworzenie nowej bazy i przeniesienie do niej tabel
Wykonanie replikacji bazy danych nie pomoże w naprawie uszkodzonej bazy MySQL, ponieważ replikacja polega na tworzeniu kopii danych z jednej bazy do drugiej w czasie rzeczywistym. Jeśli źródłowa baza danych jest uszkodzona, to zainicjowana replikacja jedynie skopiuje wszelkie błędy i uszkodzenia do nowej instancji. Replikacja jest techniką stosowaną głównie dla zwiększenia dostępności bazy danych lub zapewnienia wsparcia w przypadku awarii, a nie jako metoda naprawy uszkodzeń. Dla skutecznej naprawy bazy danych należy najpierw przywrócić jej integralność, a nie tylko jedynie skopiować uszkodzone dane. Dobrym przykładem jest użycie polecenia REPAIR TABLE, które jest dedykowane do naprawy uszkodzonych tabel, lub przywracanie bazy danych z kopii zapasowej, co zapewnia integralność i spójność danych. W sytuacji awarii bazy, kluczowe jest zrozumienie, że naprawa powinna być priorytetowym celem, a nie kopiowanie problemów.

Pytanie 36

W przedstawionym kodzie PHP w miejscu kropek powinno zostać umieszczone polecenie

$zapytanie = mysqli_query($db, "SELECT imie, nazwisko FROM uzytkownik");
$ile = mysqli_num_rows($zapytanie);
for ($i = 0; $i < $ile; $i++)
{
  $wiersz = ……………………………….;
  echo "$wiersz[0] $wiersz[1]";
}
A. mysqli_fetch_row($zapytanie);
B. mysqli_free_result($zapytanie);
C. mysqli_num_fields($zapytanie);
D. mysqli_query($zapytanie);
W analizowanym kodzie PHP, nieprawidłowe opcje wskazują na brak zrozumienia mechanizmu działania zestawów wyników w kontekście interakcji z bazą danych. Użycie mysqli_free_result($zapytanie) nie jest właściwe w tym miejscu, ponieważ ta funkcja służy do zwolnienia pamięci zajmowanej przez zestaw wyników. Powinna być wywoływana po zakończeniu wszystkich operacji na pobranych danych, a nie podczas ich odczytu. Jeśli chodzi o mysqli_num_fields($zapytanie), jest to funkcja, która zwraca liczbę kolumn w zestawie wyników, ale nie dostarcza danych wierszy, co czyni ją nieprzydatną w kontekście iteracji przez wyniki. Z kolei mysqli_query($zapytanie) jest błędne, ponieważ ta funkcja służy do wykonywania zapytań, a nie do pobierania ich wyników. W odpowiedzi na to, kluczowym błędem myślowym jest pomylenie funkcji służących do wykonywania zapytań z tymi, które służą do odczytu danych. Właściwe zrozumienie różnic między tymi funkcjami jest niezbędne do efektywnego zarządzania bazami danych w PHP. Zaleca się, aby programiści dokładnie zapoznali się z dokumentacją funkcji mysqli i ich zastosowaniami, aby unikać podobnych nieporozumień w przyszłości.

Pytanie 37

Jakie polecenie wydane z terminala systemu operacyjnego, które zawiera opcję --repair, pozwala na naprawę bazy danych?

A. mysqldump
B. create
C. mysqlcheck
D. truncate
Zarówno mysqldump, truncate, jak i create stanowią istotne polecenia w zarządzaniu bazami danych, ale nie mają one zdolności do naprawy uszkodzonych tabel. Mysqldump to narzędzie służące do eksportowania danych z bazy do pliku, co jest przydatne w kontekście tworzenia kopii zapasowych, ale nie oferuje funkcji naprawy uszkodzonych tabel. Funkcjonalność mysqldump koncentruje się na zabezpieczaniu danych, a nie na ich naprawie. Truncate, z kolei, to polecenie, które służy do usuwania wszystkich rekordów z tabeli bez rejestrowania pojedynczych operacji usunięcia w dzienniku transakcji, co sprawia, że jest to szybki sposób na opróżnienie tabeli, lecz nie ma zastosowania w kontekście naprawy uszkodzonych danych. Create to polecenie wykorzystywane do tworzenia nowych baz danych lub tabel, co jest podstawową operacją w zarządzaniu bazami danych, ale nie ma związku z naprawą istniejących struktur danych. Dlatego te narzędzia pełnią różne role w ekosystemie MySQL, ale nie są odpowiednie do rozwiązywania problemów z uszkodzonymi tabelami, co czyni mysqlcheck jedynym właściwym rozwiązaniem w tej sytuacji.

Pytanie 38

Polecenie SQL:

GRANT CREATE, ALTER ON sklep.* TO adam;
Zakładając, że użytkownik adam wcześniej nie posiadał żadnych uprawnień, to powyższe polecenie SQL przyzna mu prawa jedynie do:
A. tworzenia oraz modyfikacji struktury wszystkich tabel w bazie sklep
B. dodawania oraz modyfikacji danych w tabeli sklep
C. dodawania oraz modyfikacji danych we wszystkich tabelach bazy sklep
D. tworzenia oraz modyfikacji struktury w tabeli sklep
Wiele błędnych odpowiedzi opiera się na mylnym zrozumieniu zakresu przyznawanych uprawnień. Przede wszystkim, uprawnienia 'CREATE' i 'ALTER' odnoszą się wyłącznie do struktury tabel i innych obiektów, a nie do danych przechowywanych w tabelach. Stąd wstawianie (INSERT) i zmiana danych (UPDATE) nie są umożliwione przez polecenie 'GRANT CREATE, ALTER', co jest kluczowym błędem w niektórych odpowiedziach. Wstawianie danych wymaga przyznania uprawnień 'INSERT', a zmiana danych 'UPDATE', których w tym przypadku nie przyznano. Kolejnym powszechnym nieporozumieniem jest mylenie odniesienia do jednej tabeli z odniesieniem do całej bazy danych. Uprawnienie 'ON sklep.*' wyraźnie sugeruje, że dotyczy wszystkich tabel w bazie danych o nazwie 'sklep', a nie tylko pojedynczej tabeli. To zrozumienie jest fundamentem dla odpowiedniego zarządzania prawami dostępu w praktyce administracyjnej baz danych. Najlepsze praktyki wskazują, że przy przyznawaniu uprawnień należy dokładnie określać, do jakich obiektów użytkownik ma mieć dostęp, co zmniejsza ryzyko nieautoryzowanych zmian i naruszeń bezpieczeństwa.

Pytanie 39

Aby dodać nowy rekord do tabeli Pracownicy, konieczne jest zastosowanie polecenia SQL

A. INSERT INTO Pracownicy VALUES ('Jan',' Kowalski')
B. INSERT (Jan, Kowalski) INTO Pracownicy
C. INSERT VALUES Pracownicy INTO (Jan, Kowalski)
D. INSERT VALUES (Jan, Kowalski) INTO Pracownicy
Aby dodać nowy rekord do tabeli Pracownicy w bazie danych, należy skorzystać z polecenia SQL INSERT INTO, które jest standardowym sposobem na wprowadzenie nowych danych do tabeli. Poprawna składnia polecenia to 'INSERT INTO <nazwa_tabeli> VALUES (<wartości>)'. W przypadku podanego przykładu, używamy 'INSERT INTO Pracownicy VALUES ('Jan', 'Kowalski');', co jest zgodne z wymaganiami SQL. Polecenie to wprowadza dwa nowe atrybuty: imię 'Jan' oraz nazwisko 'Kowalski' do tabeli Pracownicy. Ważne jest, aby wartości były poprawnie otoczone apostrofami w przypadku typów danych tekstowych. Zgodnie z normami SQL, zapis ten pozwala na dodanie rekordu, pod warunkiem, że kolumny tabeli są zgodne z wprowadzanymi danymi, a tabela Pracownicy została wcześniej zdefiniowana w bazie danych. Przykładem może być sytuacja, w której tabela Pracownicy ma kolumny 'Imie' i 'Nazwisko', a wprowadzenie wartości bezpośrednio do tych kolumn jest zgodne z ich definicją.

Pytanie 40

Tabela Pracownicy zawiera informacje na temat pracowników różnych działów, co jest zaznaczone przez pole liczbowe dzial. Z racji tego, że zazwyczaj kwerendy dotyczą tylko działu 2, można uprościć zapytania do tej tabeli, tworząc wirtualną tabelę o nazwie Prac_dzial2 przy użyciu zapytania

A. VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2;
B. CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;
C. CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2;
D. VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;
Wybór odpowiedzi, która nie zawiera pełnej składni SQL, prowadzi do nieporozumień w zrozumieniu, jak działa tworzenie widoków w bazach danych. Odpowiedzi takie jak 'CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;' są błędne, ponieważ użycie słowa kluczowego 'FROM' jest niewłaściwe w kontekście definicji widoku. W standardowym SQL używa się 'AS' do określenia zapytania, które definiuje widok, co jest kluczowe dla poprawnego przetwarzania zapytania przez silnik bazy danych. Z kolei odpowiedzi, które zaczynają się od 'VIEW', takie jak 'VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;' oraz 'VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2;', są całkowicie niepoprawne, ponieważ w SQL nie istnieje polecenie 'VIEW' jako samodzielne polecenie do tworzenia widoków. To może prowadzić do mylnego przekonania, że komendy SQL są bardziej elastyczne w kwestii składni, co nie jest zgodne z rzeczywistością. Użytkownicy powinni zawsze odnosić się do dokumentacji SQL oraz standardów, aby upewnić się, że struktura zapytań jest zgodna z wymaganiami danego systemu bazy danych. Rozumienie poprawnej składni i semantyki SQL jest podstawowym elementem efektywnego zarządzania bazami danych i kluczowym krokiem w procesie nauki oraz implementacji skutecznych rozwiązań bazodanowych.