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: 10 maja 2026 14:19
  • Data zakończenia: 10 maja 2026 14:35

Egzamin niezdany

Wynik: 11/40 punktów (27,5%)

Wymagane minimum: 20 punktów (50%)

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

Sklep online używa tabeli faktury. W trakcie generowania faktury pole dataPlatnosci nie zawsze zostaje uzupełnione. Aby to skorygować, na zakończenie dnia trzeba wpisać bieżącą datę do rekordów, w których to pole nie jest wypełnione. Można to osiągnąć za pomocą kwerendy

A. UPDATE faktury SET dataPlatnosci=CURDATE() WHERE dataPlatnosci IS NULL;
B. UPDATE faktury SET dataPlatnosci=CURTIME() WHERE id = 3;
C. UPDATE faktury SET dataPlatnosci=CURTIME() WHERE dataPlatnosci IS NOT NULL;
D. UPDATE faktury SET dataPlatnosci=CURDATE() WHERE dataplatnosci = '0000-00-00';
Wybór innych opcji jest nieco problematyczny. Kwerenda, która ustawia dataPlatnosci na CURTIME() w wierszach, gdzie id = 3, nie jest zbyt sensowna, bo odnosi się tylko do jednego rekordu. Poza tym, CURTIME() zwraca czas, a nie datę, a w kontekście faktur to nie ma sensu, bo powinny mieć datę płatności, a nie tylko czas. Kolejna sprawa to aktualizacja dat w wierszach, gdzie dataPlatnosci IS NOT NULL, co prowadzi do utraty ważnych informacji. Tego typu podejście jest sprzeczne z zasadami ochrony danych i może narobić bałaganu przy audytach. I ostatnia opcja, która ustawia datę na '0000-00-00', to kompletna katastrofa. Takie coś wprowadza błędne dane, które mogą wywołać problemy później. Użycie '0000-00-00' jako znacznika braku daty jest do bani i może prowadzić do nieporozumień. Lepiej używać NULL, bo to standard w SQL. Wybierając złe opcje, nie tylko ograniczasz funkcjonalność, ale także łamiesz zasady dobrego zarządzania danymi.

Pytanie 2

Przedstawiona jest tabela pracownicy, w której umieszczono rekordy widoczne obok. Jaką wartość zwróci wykonanie umieszczonej w ramce kwerendy SQL?

SELECT MAX(pensja) FROM pracownicy WHERE pensja < 3000;
idimienazwiskopensja
1AnnaKowalska3400
2MonikaNowak1300
3EwelinaNowakowska2600
4AnnaPrzybylska4600
5MariaKowal2200
6EwaNowacka5400
A. 2200
B. 5400
C. 1300
D. 2600
Kwerenda SQL SELECT MAX(pensja) FROM pracownicy WHERE pensja < 3000; służy do znalezienia maksymalnej wartości w kolumnie pensja z rekordów spełniających warunek pensja mniejsza niż 3000. Przeszukując tabelę pracownicy widzimy że wartości spełniające ten warunek to 1300 2600 i 2200. Najwyższą z tych wartości jest 2600 co czyni tę odpowiedź poprawną. Zrozumienie tego typu kwerend SQL jest kluczowe w pracy z bazami danych ponieważ pozwala na wyciąganie konkretnych informacji z dużych zbiorów danych. W praktyce takie zapytania mogą być używane do analizowania danych pracowniczych w firmach gdzie na przykład chcemy zidentyfikować pracowników z wynagrodzeniem poniżej określonego progu. Jest to zgodne z dobrymi praktykami w branży gdzie używa się agregacji danych do celów analitycznych. Zrozumienie jak działa funkcja MAX() w połączeniu z klauzulą WHERE umożliwia efektywne filtrowanie i przetwarzanie danych co jest niezbędne w wielu aplikacjach biznesowych.

Pytanie 3

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

Ilustracja do pytania
A. klucz obcy rezyserzy_id tabeli filmy z kluczem obcym id tabeli rezyserzy
B. klucz obcy rezyserzy_id tabeli filmy z kluczem podstawowym id tabeli rezyserzy
C. klucz podstawowy 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 4

Wskaż prawdziwe stwierdzenie dotyczące polecenia:

CREATE TABLE IF NOT EXISTS adres (ulica VARCHAR(70) CHARACTER SET utf8);
A. IF NOT EXISTS stosuje się opcjonalnie, aby upewnić się, że w bazie danych nie istnieje już taka tabela.
B. Rekordem tabeli nie może być '3 MAJA'.
C. Do tabeli nie można wprowadzać nazw ulic zawierających polskie znaki.
D. Klauzula CHARACTER SET utf8 jest obowiązkowa.
Niepoprawne odpowiedzi pokazują kilka powszechnych błędów myślowych. Na przykład, stwierdzenie, że do tabeli nie można wprowadzać ulic zawierających polskie znaki, jest nieprawdziwe. W rzeczywistości, zastosowanie odpowiedniego kodowania, takiego jak utf8, umożliwia przechowywanie dowolnych znaków specjalnych w tabelach SQL, w tym polskich. To jest bardzo ważne, gdy pracujemy z danymi, które mogą zawierać różne zestawy znaków. Druga nieprawidłowa odpowiedź sugeruje, że klauzula CHARACTER SET utf8 jest obowiązkowa. Jest to również mylące, ponieważ chociaż jest to dobra praktyka, aby umożliwić przechowywanie znaków specjalnych, nie jest to wymagane przez standard SQL. Ostatnia nieprawidłowa odpowiedź sugeruje, że rekordem tabeli nie może być '3 MAJA'. To jest błędne, ponieważ typ danych VARCHAR(70) w SQL pozwala na przechowywanie dowolnych ciągów znaków, w tym dat i nazw. W przypadku wszystkich tych nieprawidłowych odpowiedzi, ważne jest, aby rozumieć podstawy zarządzania danymi i struktur tabeli w SQL.

Pytanie 5

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 ALL ON tabela1 FROM 'anna'@'localhost'
B. REVOKE CREATE INSERT DELETE 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 6

Jakie uprawnienia posiada użytkownik jan po wykonaniu poniższych poleceń na bazie danych? ```GRANT ALL PRIVILEGES ON klienci TO jan;``` ```REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;```

A. Będzie miał możliwość wyszukiwania danych w tabeli klienci
B. Będzie miał możliwość usuwania rekordów z tabeli klienci
C. Będzie miał możliwość wstawiania rekordów do tabeli klienci
D. Będzie miał możliwość zmiany struktury tabeli klienci
Odpowiedź jest poprawna, ponieważ po wykonaniu poleceń SQL użytkownik jan ma przyznane wszystkie uprawnienia do tabeli klienci, a następnie odebrano mu konkretne uprawnienia do wykonywania operacji SELECT, INSERT, UPDATE oraz DELETE. Oznacza to, że jedynym uprawnieniem, które pozostaje jemu po tych operacjach, jest możliwość zmiany struktury tabeli, co oznacza operacje takie jak ADD COLUMN czy DROP COLUMN. W praktyce, gdy przyznajemy użytkownikowi rolę, często stosujemy uprawnienia do wykonywania operacji DDL (Data Definition Language), które są niezbędne do modyfikacji schematu bazy danych. Odpowiedzi na pytania dotyczące uprawnień powinny uwzględniać kontekst celów administracyjnych, ponieważ różne role użytkowników mogą mieć różne poziomy dostępu. W związku z tym, zrozumienie systemu uprawnień w kontekście zarządzania bazą danych jest kluczowe, a dobrym standardem jest nadawanie użytkownikom tylko tych uprawnień, które są niezbędne do wykonywania ich zadań.

Pytanie 7

Funkcja agregująca MIN w języku SQL ma na celu obliczenie

A. liczby wierszy, które zwraca kwerenda
B. ilości znaków w rekordach zwróconych przez kwerendę
C. minimalnej wartości kolumny, która jest wynikiem kwerendy
D. średniej wartości różnych pól w rekordu zwróconego przez zapytanie
Wszystkie trzy pozostałe odpowiedzi nie są właściwe w kontekście funkcji agregującej MIN. Funkcja ta nie ma na celu zliczania liczby wierszy zwróconych przez kwerendę; zamiast tego służy do obliczania minimalnej wartości w danej kolumnie. Zliczanie wierszy to zadanie dla funkcji COUNT, która zwraca liczbę rekordów spełniających określone kryteria. Kolejnym błędnym stwierdzeniem jest, że funkcja MIN może obliczać długość znaków w zwróconych rekordach. Długość znaków to kwestia związana z funkcjami takimi jak LEN w SQL, które mierzą długość ciągów znakowych, jednak nie mają one związku z funkcją agregującą MIN. Ostatnia z błędnych odpowiedzi, dotycząca obliczania średniej wartości różnych pól rekordu, również nie jest zgodna z definicją funkcji MIN. Średnia jest obliczana przy użyciu funkcji AVG, która sumuje wartości w danej kolumnie i dzieli je przez liczbę tych wartości. W związku z tym, funkcja MIN jest jedynie odpowiedzialna za wydobycie najniższej wartości z zestawu danych, co jest kluczowe w wielu analizach, ale nie obejmuje ona żadnych z wymienionych w odpowiedziach zadań.

Pytanie 8

Polecenie w języku SQL w formie ALTER TABLE 'miasta' ADD 'kod' text?

A. w tabeli miasta modyfikuje nazwę kolumny kod na text
B. zmienia nazwę tabeli miasta na kod
C. wprowadza do tabeli nową kolumnę o nazwie kod typu text
D. dodaje do tabeli dwie kolumny o nazwach: kod i text
Wszystkie pozostałe odpowiedzi są błędne z kilku powodów. Pierwsza z nich sugeruje, że polecenie zmienia nazwę tabeli 'miasta' na 'kod', co jest nieprawdziwe. W SQL, aby zmienić nazwę tabeli, używa się polecenia RENAME TABLE lub ALTER TABLE z odpowiednimi argumentami, a nie polecenia ADD, które służy wyłącznie do dodawania nowych kolumn. Kolejna fałszywa odpowiedź stwierdza, że dodaje dwie kolumny o nazwach 'kod' i 'text'. W rzeczywistości polecenie ALTER TABLE dodaje tylko jedną kolumnę, co jest wyraźnie widoczne w zapytaniu. W przypadku, gdybyśmy chcieli dodać więcej niż jedną kolumnę, musielibyśmy użyć oddzielnych poleceń ADD dla każdej kolumny lub zdefiniować je razem w pojedynczym poleceniu, co również nie ma miejsca w tym przykładzie. Ostatnia niepoprawna odpowiedź sugeruje, że w tabeli 'miasta' następuje zmiana nazwy kolumny 'kod' na 'text'. Tego rodzaju operacja wymagałaby użycia polecenia RENAME COLUMN, a nie ADD. Polecenie ADD nie zmienia istniejących kolumn, lecz dodaje nowe, co jest fundamentalnym zrozumieniem działania komendy ALTER TABLE. Dlatego wszystkie te odpowiedzi są technicznie błędne i nie oddają rzeczywistego działania zapytania SQL.

Pytanie 9

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 tytul FROM ksiazki WHERE cena < 50;
B. SELECT tytul FROM ksiazki WHERE cena > '50 zł';
C. SELECT ksiazki FROM tytul WHERE cena < '50 zł';
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 10

W przedstawionym kodzie PHP przeprowadzono operację na bazie danych. Jaką funkcję należy wywołać, aby uzyskać liczbę wierszy, które zostały zmienione w tabeli?

$zapytanie="UPDATE kadra SET stanowisko='Programista' WHERE id < 10"; mysqli_query($db, $zapytanie);
A. mysqli_field_count()
B. mysqli_affected_rows()
C. mysqli_use_result()
D. mysqli_num_rows()
Funkcja mysqli_affected_rows() jest używana w kontekście zapytań modyfikujących dane w bazie danych, takich jak INSERT, UPDATE, DELETE. Po wykonaniu zapytania, które zmienia dane, funkcja ta zwraca liczbę wierszy, które zostały zmodyfikowane w wyniku wykonania tego zapytania. W przypadku podanego zapytania, zmieniającego stanowisko w tabeli 'kadra' dla rekordów z identyfikatorem mniejszym niż 10, użycie mysqli_affected_rows() pozwoli na uzyskanie informacji o tym, ile wierszy zostało zaktualizowanych. Jest to niezwykle przydatne w sytuacjach, gdy programista chce mieć kontrolę nad tym, które operacje modyfikujące dane przyniosły zamierzony efekt. Przykładowo, jeśli po wykonaniu zapytania chcemy zaktualizować interfejs użytkownika lub wykonać dodatkowe operacje tylko wtedy, gdy zmiany zostały wprowadzone, użycie tej funkcji jest kluczowe. Dobrą praktyką jest również uwzględnienie obsługi błędów, aby upewnić się, że operacje na bazie danych są poprawnie wykonane, co można osiągnąć za pomocą funkcji mysqli_error() w przypadku błędów zapytań.

Pytanie 11

Przedstawione polecenie SQL nadaje użytkownikowi adam@localhost prawa:

GRANT SELECT, INSERT, UPDATE, DELETE ON klienci TO adam@localhost
A. zarządzania strukturą tabeli klienci.
B. zarządzania strukturą bazy danych klienci.
C. manipulowania danymi w tabeli klienci.
D. manipulowania danymi bazy danych klienci.
Niepoprawne odpowiedzi sugerują, że polecenie SQL nadaje użytkownikowi 'adam' z hosta 'localhost' prawa zarządzania strukturą bazy danych lub tabeli 'klienci', co jest niezgodne z prawdą. Zgodnie z konstrukcją polecenia GRANT, użytkownik otrzymuje prawa do manipulowania danymi, a nie do zarządzania strukturą. Zarządzanie strukturą bazy danych lub tabeli obejmuje operacje takie jak CREATE, ALTER, DROP, które pozwalają na tworzenie, modyfikowanie lub usuwanie bazy danych lub tabeli. Te uprawnienia są zazwyczaj zarezerwowane dla administratorów bazy danych i nie są nadawane zwykłym użytkownikom, co jest zgodne z zasadą minimalnych uprawnień dla bezpieczeństwa systemu. Dodatkowo, polecenie nie odnosi się do całej bazy danych 'klienci', tylko do konkretnej tabeli 'klienci'. Tę pomyłkę można zrozumieć, jako nieprawidłowe zrozumienie hierarchii i struktury bazy danych.

Pytanie 12

Jakie z poniższych stwierdzeń właściwie opisuje tabelę utworzoną przez: CREATE TABLE dane (kolumna INTEGER(3));

A. Tabela zawiera jedną kolumnę, która składa się z trzyelementowych tablic
B. Kolumny w tabeli dane nazywają się: kolumna1, kolumna2, kolumna3
C. Tabela o nazwie dane zawiera trzy kolumny typu liczb całkowitych
D. Tabela o nazwie dane ma jedną kolumnę typu liczb całkowitych
Wszystkie stwierdzenia w pozostałych odpowiedziach są błędne, ponieważ opierają się na niewłaściwym zrozumieniu definicji tabeli w SQL. Twierdzenie, że tabela posiada jedną kolumnę zawierającą trzy elementowe tablice, jest mylące, ponieważ w SQL nie definiuje się kolumn jako tablic. W systemach zarządzania bazami danych, takich jak MySQL, PostgreSQL, czy Oracle, kolumny są jednostkami przechowującymi pojedyncze wartości, a nie struktury złożone jak tablice. Innym błędnym założeniem jest twierdzenie, że kolumny tabeli dane nazywają się kolumna1, kolumna2, kolumna3; w rzeczywistości, tabela posiada jedną kolumnę o nazwie 'kolumna', co jest jasno określone w definicji. Ostatnia nieprawidłowa odpowiedź sugerująca, że tabela ma trzy kolumny jest również nieprawdziwa, ponieważ jest tylko jedna kolumna. Przy definiowaniu tabel w SQL kluczowe jest przestrzeganie zasad dotyczących struktury danych oraz ich odpowiedniej nazwy, co ma fundamentalne znaczenie dla późniejszego korzystania z tych danych. Zrozumienie tych zasad oraz ich praktyczne zastosowanie w pracy z bazami danych pozwala na unikanie typowych błędów i poprawne projektowanie struktur baz danych.

Pytanie 13

Podczas wykonywania zapytania można skorzystać z klauzuli DROP COLUMN

A. ALTER TABLE
B. CREATE TABLE
C. ALTER COLUMN
D. DROP TABLE
Odpowiedź 'ALTER TABLE' jest poprawna, ponieważ klauzula DROP COLUMN jest używana w kontekście zmiany struktury tabeli w bazach danych. Polecenie ALTER TABLE pozwala na modyfikację istniejącej tabeli, w tym dodawanie, usuwanie lub modyfikowanie kolumn. Użycie klauzuli DROP COLUMN umożliwia usunięcie określonej kolumny z tabeli, co jest przydatne, gdy kolumna nie jest już potrzebna, zawiera nieaktualne dane lub w celu optymalizacji struktury bazy danych. Na przykład, jeśli mamy tabelę 'Użytkownicy' z kolumną 'wiek', której chcemy się pozbyć, możemy użyć polecenia: 'ALTER TABLE Użytkownicy DROP COLUMN wiek;'. Ważne jest, aby przed wykonaniem tej operacji upewnić się, że usunięcie kolumny nie wpłynie negatywnie na integralność danych lub logikę aplikacji. Praktyki dotyczące zarządzania bazami danych zalecają również wykonanie kopii zapasowej danych przed takimi operacjami, aby zminimalizować ryzyko utraty danych.

Pytanie 14

Z tabeli mieszkancy trzeba wydobyć unikalne nazwy miast, w tym celu należy użyć wyrażenia SQL zawierającego klauzulę

A. UNIQUE
B. CHECK
C. HAVING
D. DISTINCT
Odpowiedzi takie jak 'UNIQUE', 'CHECK' i 'HAVING' są błędne, ponieważ nie pełnią one funkcji eliminacji duplikatów w kontekście wyboru unikalnych wartości. 'UNIQUE' jest klauzulą, która służy do definiowania ograniczeń w tabelach, gwarantując, że wartości w danej kolumnie są unikalne w kontekście wierszy w tabeli. Jest to przydatne przy projektowaniu schematów baz danych, ale nie jest stosowane w zapytaniach do selekcji danych. 'CHECK' służy do walidacji danych wprowadzanych do tabeli, zapewniając, że spełniają one określone warunki, co jest istotne przy definiowaniu reguł dotyczących wartości, jakie mogą być wprowadzane. Z kolei 'HAVING' jest używane w kontekście grupowania danych, w połączeniu z klauzulą 'GROUP BY', aby filtrować grupy w oparciu o warunki, co jest zupełnie inną operacją niż eliminacja duplikatów. Typowym błędem jest mylenie koncepcji związanych z grupowaniem i selekcją unikalnych wartości. W praktyce, korzystając z 'HAVING', nie uzyskamy unikalnych wartości z kolumny bez wcześniejszego użycia 'GROUP BY', co sprawia, że jest to narzędzie bardziej skomplikowane i mniej efektywne w kontekście prostego wyciągania unikalnych danych. Aby właściwie zrozumieć zasady dotyczące zapytań SQL, ważne jest, aby rozróżniać te różne klauzule oraz ich zastosowania, co pozwoli na bardziej świadome i efektywne korzystanie z języka SQL.

Pytanie 15

Jaką treść komunikatu należy umieścić w kodzie PHP zamiast znaków zapytania?

$a = mysql_connect('localhost', 'adam', 'mojeHaslo');

if (!$a)
    echo "?????????????";
A. Wybrana baza danych nie istnieje
B. Błąd w trakcie przetwarzania zapytania SQL
C. Błąd połączenia z serwerem SQL
D. Rekord został pomyślnie dodany do bazy
Niepoprawne odpowiedzi wynikają z niezrozumienia działania funkcji mysql_connect(). Na przykład twierdzenie, że błąd dotyczy 'Wybrana baza nie istnieje' jest błędne, ponieważ mysql_connect() jedynie łączy z serwerem, a nie wybiera bazy. Do tego służy funkcja mysql_select_db(). Jest to częsty błąd, gdyż początkujący użytkownicy mogą mylić różne etapy interakcji z bazą danych. Kolejnym błędnym podejściem jest zakładanie, że problem dotyczy 'Błędu przetwarzania zapytania SQL'. Funkcja mysql_connect() nie przetwarza zapytań SQL, a jedynie ustanawia połączenie. Odpowiedzialność za przetwarzanie zapytań leży po stronie innych funkcji takich jak mysql_query(). Założenie, że komunikat powinien brzmieć 'Pomyślnie dodano rekord do bazy' również jest nieprawidłowe, ponieważ zawiera informację o sukcesie, gdy w rzeczywistości mamy do czynienia z sytuacją błędną, gdy połączenie nie mogło zostać nawiązane. Zrozumienie tych koncepcji jest kluczowe w budowaniu aplikacji korzystających z baz danych, ponieważ właściwe zarządzanie błędami i komunikacja z użytkownikiem wpływają na stabilność i użyteczność aplikacji.

Pytanie 16

Przykład zapytania SQL przedstawia instrukcję:

UPDATE katalog SET katalog.cena = [cena]*1.1;
A. usuwającej
B. krzyżowej
C. aktualizującej
D. dołączającej
Instrukcja SQL przedstawiona w pytaniu używa słowa kluczowego UPDATE co jest charakterystyczne dla kwerend aktualizujących. Komenda ta modyfikuje istniejące dane w tabeli poprawiając je zgodnie z podanymi kryteriami. W tym przykładzie wszystkie wartości w kolumnie cena tabeli katalog są zwiększane o 10 procent co jest typowym zastosowaniem instrukcji aktualizującej. W praktyce takie zmiany są niezbędne w przypadku modyfikacji cen produktów lub aktualizacji informacji biznesowych. Stosowanie kwerend aktualizujących wymaga zachowania szczególnej ostrożności aby nie naruszyć integralności danych. Dobre praktyki obejmują przygotowanie backupu danych przed wykonaniem operacji oraz przetestowanie kwerendy na mniejszym zbiorze danych w celu uniknięcia błędów. Aktualizacja danych to jedna z najczęstszych operacji w systemach bazodanowych dlatego zrozumienie mechanizmu działania kwerend SQL tego typu jest kluczowe dla efektywnego zarządzania danymi w każdej organizacji. SQL jako język deklaratywny umożliwia łatwe definiowanie co chcemy osiągnąć bez konieczności szczegółowego opisywania jak to zrobić co ułatwia pracę z dużymi i złożonymi zbiorami danych.

Pytanie 17

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

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

Pytanie 18

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

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

Pytanie 19

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

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

Pytanie 20

Jaki System Zarządzania Bazą Danych jest standardowo używany w pakiecie XAMPP?

A. Firebird
B. Oracle
C. PostgreSQL
D. MariaDB
Oracle, Firebird i PostgreSQL to usługi baz danych, które różnią się od MariaDB zarówno pod względem architektury, jak i zastosowania. Oracle to komercyjny system zarządzania bazą danych, który oferuje zaawansowane funkcje, jednak jest on znacznie droższy i mniej dostępny dla indywidualnych programistów lub małych firm. Wykorzystanie Oracle w projektach lokalnych nie jest typowe, ponieważ jest bardziej skierowane na duże przedsiębiorstwa i złożone aplikacje korporacyjne. Firebird to również open-source'owy system, ale nie jest tak szeroko stosowany jak MariaDB w kontekście lokalnego rozwoju aplikacji. Użytkownicy często decydują się na MariaDB ze względu na jej kompatybilność z MySQL oraz szersze wsparcie społeczności. PostgreSQL jest znany z zaawansowanych funkcji i wsparcia dla bardziej skomplikowanych operacji, jednak jego integracja z XAMPP nie jest domyślna, co może wprowadzać użytkowników w błąd, mylnie zakładając, że jest to powszechnie stosowane rozwiązanie. Typowe błędy to nieadekwatne porównanie systemów bez uwzględnienia ich kontekstu użycia, co prowadzi do mylnych wniosków o ich popularności i zastosowalności w projektach lokalnych.

Pytanie 21

Model fizyczny replikacji bazy danych pokazany na ilustracji jest modelem

Ilustracja do pytania
A. równorzędnym
B. centralnego wydawcy
C. rozproszonym
D. centralnego subskrybenta
Model centralnego subskrybenta polega na tym że jeden serwer subskrybuje dane z wielu wydawniczych serwerów co jest odwrotnością modelu centralnego wydawcy. Tego typu rozwiązanie jest mniej popularne ze względu na potrzebę zarządzania synchronizacją z wielu źródeł co komplikuje proces replikacji i zwiększa ryzyko konfliktów danych. Model równorzędny z kolei zakłada że każdy serwer w architekturze działa jako równy uczestnik mający zdolność zarówno publikowania jak i subskrybowania danych. Taka architektura jest bardziej złożona w zarządzaniu zwłaszcza przy dużej liczbie uczestników ponieważ wymaga zaawansowanych mechanizmów rozwiązywania konfliktów i zarządzania współbieżnością. Rozproszony model to rozwiązanie gdzie dane są przechowywane i zarządzane bez centralnego punktu co może być korzystne dla systemów wymagających wysokiej dostępności i elastyczności ale stwarza wyzwania w zakresie spójności danych i wymaga skomplikowanych algorytmów synchronizacji. Wybór modelu nieodpowiedniego dla danej infrastruktury może prowadzić do problemów z wydajnością i spójnością co jest typowym błędem myślowym wynikającym z niewłaściwego zrozumienia wymagań systemowych. Każdy z tych modeli ma swoje specyficzne zastosowania i wyzwania co wymaga odpowiedniej analizy i doświadczenia przy projektowaniu systemów bazodanowych.

Pytanie 22

Które zapytanie MySQL należy użyć, aby usunąć jedynie pracowników, którzy zarabiają nie mniej niż 500 i nie więcej niż 1000 zł oraz ich miejsce pracy zawiera frazę tx

A. DELETE FROM pracownicy WHERE pensja BETWEEN 500 AND 1000 OR miejsce_pracy LIKE '%tx%';
B. DELETE FROM pracownicy WHERE pensja > 500 AND pensja < 1000 AND miejsce_pracy LIKE '%tx%';
C. DELETE FROM pracownicy WHERE pensja BETWEEN 500 AND 1000 AND miejsce_pracy LIKE '%tx%';
D. DELETE FROM pracownicy WHERE pensja IN (500,1000) AND miejsce_pracy LIKE '*tx*';
Poprawne jest zapytanie: DELETE FROM pracownicy WHERE pensja BETWEEN 500 AND 1000 AND miejsce_pracy LIKE '%tx%';. Słowo kluczowe BETWEEN w SQL oznacza przedział domknięty, czyli w tym przypadku usuwani będą pracownicy, którzy zarabiają co najmniej 500 i jednocześnie nie więcej niż 1000 zł. To dokładnie odpowiada treści zadania, bez żadnych niedomówień na granicach zakresu. Gdybyśmy użyli > i <, to wartości 500 i 1000 zostałyby wykluczone, co w tym zadaniu byłoby niezgodne z wymaganiem. Drugi warunek korzysta z operatora LIKE wraz z maską '%tx%'. Wzorzec z procentami z obu stron oznacza: znajdź wszystkie wiersze, gdzie ciąg znaków „tx” występuje gdziekolwiek w tekście kolumny miejsce_pracy – na początku, w środku albo na końcu. W MySQL znak % jest standardowym symbolem wieloznacznym (wildcard) dla dowolnego ciągu znaków, a nie gwiazdka *, dlatego zapis z % jest poprawny i zgodny z dokumentacją. Spójnik AND jest tu kluczowy, bo warunek mówi wyraźnie: usuwamy tylko tych pracowników, którzy spełniają jednocześnie oba kryteria – zarówno zakres pensji, jak i fragment tekstu w miejscu pracy. W praktyce takie zapytanie stosuje się np. przy porządkowaniu danych testowych: można szybko usunąć sztuczne rekordy z określonego przedziału płac i z wybranych lokalizacji. Moim zdaniem warto wyrabiać sobie nawyk bardzo precyzyjnego formułowania warunków logicznych (AND/OR) i zawsze sprawdzać, czy zakres jest domknięty czy otwarty. Dobrą praktyką jest też najpierw wykonać SELECT z tym samym WHERE, zobaczyć jakie rekordy zostaną naruszone, a dopiero potem odpalać DELETE – szczególnie na produkcyjnej bazie, bo tam pomyłki bywają bolesne.

Pytanie 23

W języku MySQL należy wykorzystać polecenie REVOKE, aby użytkownikowi anna cofnąć możliwość wprowadzania zmian wyłącznie w definicji struktury bazy danych. Polecenie, które służy do odebrania tych uprawnień, ma następującą 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'
Wybór innego podejścia do odbierania uprawnień użytkownikowi 'anna' jest niewłaściwy z kilku powodów. Po pierwsze, REVOKE ALL ON tabela1 FROM 'anna'@'localhost' jest zbyt ogólnie sformułowane, jako że odbiera wszystkie przydzielone uprawnienia, w tym te, które mogą być konieczne do wykonywania podstawowych operacji na danych. Taki ruch mógłby całkowicie zablokować użytkownika w interakcji z tabelą, co nie odzwierciedla zamierzonego celu, jakim jest jedynie ograniczenie możliwości modyfikacji struktury. Drugą nieodpowiednią propozycją jest REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'. Ta komenda również jest błędna, ponieważ wprowadza uprawnienie UPDATE, które nie jest związane z zarządzaniem strukturą bazy danych. Odbieranie tego uprawnienia sprawiłoby, że użytkownik nie mógłby wprowadzać danych do tabeli, co jest sprzeczne z intencją ograniczenia jedynie modyfikacji struktury. Kolejną niewłaściwą odpowiedzią jest REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost', która również nie spełnia wymogów, ponieważ odbiera uprawnienia związane z wstawianiem i usuwaniem danych, co jest istotne dla pracy z danymi w tabeli. W kontekście zarządzania bazami danych, istotne jest, aby precyzyjnie określać, jakie uprawnienia są odbierane, a także dokładnie rozumieć ich zastosowanie oraz potencjalne konsekwencje ich odebrania.

Pytanie 24

Jakie są przykłady standardowych poleceń w języku zapytań SQL, odnoszących się do operacji na danych SQL DML, takich jak wstawianie, usuwanie oraz modyfikacja danych?

A. SELECT, SELECT INTO
B. ALTER, CREATE, DROP
C. DELETE, INSERT, UPDATE
D. DENY, GRANT, REVOKE
Wybór innych odpowiedzi nie jest poprawny, ponieważ skupiają się na różnych aspektach zarządzania bazami danych. Polecenia typu ALTER, CREATE i DROP są związane z definicją danych (DDL, Data Definition Language). ALTER umożliwia modyfikację struktury tabeli, na przykład dodawanie nowych kolumn, natomiast CREATE jest używane do tworzenia nowych obiektów w bazie danych, takich jak tabele czy widoki. DROP z kolei służy do usuwania tych obiektów. Te polecenia są fundamentalne dla zarządzania strukturą bazy, ale nie dotyczą bezpośrednio operacji na danych. Inna grupa poleceń, takich jak DENY, GRANT i REVOKE, odnosi się do zarządzania uprawnieniami użytkowników w systemie baz danych, co jest istotne dla bezpieczeństwa, ale nie wpływa na manipulację danymi. Te polecenia kontrolują, kto ma dostęp do jakich danych, co jest kluczowe w kontekście bezpieczeństwa, ale nie są one używane do wprowadzania, usuwania czy aktualizacji danych w tabelach. Dlatego te zestawy poleceń, mimo że są istotne w kontekście zarządzania bazami danych, nie odpowiadają na pytanie dotyczące operacji na danych w kontekście DML.

Pytanie 25

W MySQL nadanie roli DBManager użytkownikowi pozwala na uzyskanie praw umożliwiających

A. tworzenie kont użytkowników na serwerze oraz przypisywanie im haseł
B. nadzorowanie serwera
C. wszystkie działania na bazach danych oraz użytkownikach serwera
D. wszelkie operacje na bazach danych serwera
Wybór odpowiedzi, która sugeruje, że rola DBManager przyznaje wszystkie operacje na bazach danych i użytkownikach serwera, jest błędny. Chociaż rola ta rzeczywiście daje szerokie uprawnienia do operacji na bazach danych, nie obejmuje ona zarządzania użytkownikami serwera, co jest kluczowe w kontekście bezpieczeństwa i kontroli dostępu. W rzeczywistości w MySQL, operacje związane z tworzeniem użytkowników i nadawaniem im odpowiednich uprawnień są zarezerwowane dla ról administracyjnych, jak np. root. Zrozumienie tego jest fundamentalne dla właściwego zarządzania bezpieczeństwem w systemach bazodanowych, ponieważ umożliwia to precyzyjne określenie, kto ma dostęp do jakich danych oraz jakie operacje może wykonać. Typowym błędem jest mylenie ról i uprawnień. Użytkownicy muszą zrozumieć, że różne role mają różne poziomy dostępu i odpowiedzialności, co można osiągnąć poprzez odpowiednie przypisywanie uprawnień w oparciu o zasady najmniejszych uprawnień. Również, monitorowanie serwera, które zostało wspomniane jako jedna z odpowiedzi, nie jest związane z rolą DBManager, a zamiast tego wymaga osobnych narzędzi i uprawnień, które pozwalają na analizę wydajności i działania systemu.

Pytanie 26

W języku PHP wykonano poniższą operację. Aby uzyskać wszystkie rezultaty tego zapytania, należy:

$tab = mysqli_query($db, "SELECT imie FROM Osoby WHERE wiek < 18");
A. użyć polecenia mysql_fetch
B. wyświetlić zmienną $db
C. zaindeksować zmienną tab, tab[0] to pierwsze imię
D. zastosować pętlę z poleceniem mysqli_fetch_row
Odpowiedź, która zakłada zastosowanie pętli z poleceniem mysqli_fetch_row, jest poprawna, ponieważ po wykonaniu zapytania do bazy danych za pomocą mysqli_query, otrzymujemy wynik w postaci zestawu rekordów, który musimy przetworzyć. Funkcja mysqli_fetch_row pozwala na iteracyjne pobieranie wierszy z tego zestawu, co jest niezbędne do wyświetlenia wszystkich imion osób, które spełniają warunek wieku poniżej 18 lat. Przykładowy kod do iteracji może wyglądać tak: while($wiersz = mysqli_fetch_row($tab)) { echo $wiersz[0]; } W ten sposób każda iteracja w pętli wyświetli pierwszą kolumnę (imie) z każdego wiersza rezultatu. Tego typu podejście jest zgodne z dobrymi praktykami, ponieważ pozwala na efektywne zarządzanie pamięcią i ogranicza ryzyko przeciążenia systemu, szczególnie w przypadku dużych zbiorów danych. Ważne jest, aby pamiętać, że połączenie z bazą danych i zapytania powinny być zawsze odpowiednio zamykane i zabezpieczane przed atakami, co jest istotne w kontekście bezpieczeństwa aplikacji.

Pytanie 27

Funkcja napisana w PHP ma na celu

Ilustracja do pytania
A. ustawienie hasła do bazy danych
B. pobranie informacji z bazy danych
C. nawiązanie połączenia z bazą danych
D. zabezpieczenie bazy danych
Ustawienie hasła do bazy danych nie jest realizowane przez zapytanie SQL w PHP lecz przez konfigurację połączenia z bazą danych zwykle przy użyciu funkcji mysql_connect lub mysqli_connect gdzie hasło jest jednym z parametrów. Zabezpieczenie bazy danych nie polega na prostym zapytaniu lecz wymaga szerszego podejścia obejmującego kontrolę dostępu zarządzanie uprawnieniami szyfrowanie danych i ochronę przed atakami SQL Injection. Połączenie z bazą danych w PHP realizowane jest poprzez funkcje umożliwiające nawiązanie sesji z serwerem bazodanowym jak mysql_connect lub nowocześniejsze mysqli_connect oraz obiekty PDO które oferują bardziej zaawansowane mechanizmy zarządzania połączeniami. Często występującym błędem jest mylenie funkcji odpowiedzialnych za zarządzanie połączeniem z funkcjami wykonującymi operacje na danych. Mylenie tych dwóch aspektów pracy z bazą danych prowadzi do błędów w aplikacjach jak niewłaściwe zarządzanie zasobami lub podatność na ataki. Nowoczesne podejścia takie jak stosowanie ORM-ów jak Doctrine w PHP abstrahują wiele tych mechanizmów co upraszcza zarządzanie tymi aspektami w kodzie. Ważnym aspektem jest także stosowanie praktyk bezpieczeństwa takich jak walidacja i sanitizacja danych oraz używanie przygotowanych wyrażeń co jest kluczowe w ochronie danych i zapewnieniu prawidłowego działania aplikacji. Zrozumienie tych podstawowych elementów jest kluczowe w tworzeniu bezpiecznych i wydajnych aplikacji bazodanowych.

Pytanie 28

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

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

Pytanie 29

Baza danych 6-letniej szkoły podstawowej zawiera tabelę szkola z polami: imie, nazwisko oraz klasa. Uczniowie z klas 1-5 przeszli do wyższej klasy. Jakie polecenie należy użyć, aby zwiększyć wartość w polu klasa o 1?

A. SELECT nazwisko, imie FROM klasa=klasa+1 WHERE klasa>1 OR klasa <5
B. SELECT szkola FROM klasa=klasa+1 WHERE klasa >=1 AND klasa <=5
C. UPDATE nazwisko, imie SET klasa=klasa+1 WHERE klasa>1 OR klasa<5
D. UPDATE szkola SET klasa=klasa+1 WHERE klasa>=1 AND klasa <=5
W analizie błędnych odpowiedzi należy zwrócić uwagę na nieprawidłowości w składni i logice zapytań. Pierwsza odpowiedź sugeruje użycie 'UPDATE nazwisko, imie SET klasa=klasa+1 WHERE klasa>1 OR klasa<5;', co jest niepoprawne, ponieważ 'UPDATE' powinno odnosić się do całej tabeli, a nie do pojedynczych pól. Ponadto warunki w klauzuli 'WHERE' są zbyt ogólne, co skutkowałoby aktualizacją uczniów, którzy nie zdali do kolejnej klasy. Druga odpowiedź zawiera poprawną strukturę, ale użycie 'SELECT szkola FROM klasa=klasa+1 WHERE klasa >=1 AND klasa <=5;' jest błędne, gdyż 'SELECT' nie jest odpowiednie do aktualizacji danych - powinno być użyte 'UPDATE'. Ostatnia propozycja również myli pojęcia, stosując 'SELECT' zamiast 'UPDATE', co skutkuje próbą odczytania danych, zamiast ich aktualizacji. Typowym błędem myślowym jest mylenie tych dwóch komend w SQL, co prowadzi do nieporozumień w zakresie manipulacji danymi. Kluczowe jest zrozumienie, że 'UPDATE' jest używane do zmiany istniejących rekordów, podczas gdy 'SELECT' służy do pobierania danych. Aby uniknąć takich błędów, ważne jest, aby zrozumieć funkcje i zastosowania różnych poleceń SQL oraz praktykować ich wykorzystanie w rzeczywistych scenariuszach.

Pytanie 30

Kwerenda umożliwiająca modyfikację wielu rekordów lub przeniesienie ich przy pomocy jednego działania, określana jest jako kwerenda

A. parametrycznej
B. funkcjonalnej
C. krzyżowej
D. wybierająca
Odpowiedzi takie jak kwerenda wybierająca, parametryczna czy krzyżowa nie są właściwe w tym kontekście pytania, bo nie są do wprowadzania zmian w wielu rekordach. Kwerenda wybierająca filtruje i zwraca dane z bazy, ale nie zmienia ich. Często ludzie mylą to z masowym przetwarzaniem, co prowadzi do błędnych wniosków. Kwerenda parametryczna za to pozwala na dynamiczne dodawanie zmiennych podczas wykonywania zapytania, ale również nie działa na masowej aktualizacji. Jest bardziej o elastycznym pobieraniu danych według jakichś kryteriów. Kwerenda krzyżowa z kolei służy do analizy danych w formie tabeli przestawnej, co jest zupełnie inną bajką, bo tu chodzi bardziej o zestawianie niż o modyfikacje. Często myli się różne typy kwerend i ich funkcje w bazach danych, co może prowadzić do zamieszania i błędów. Ważne jest, żeby zrozumieć, że te różne kwerendy mają swoje konkretne zastosowania i są projektowane do różnych zadań w ramach baz danych.

Pytanie 31

Aby zliczyć wszystkie wiersze w tabeli Koty, należy wykorzystać zapytanie

A. SELECT COUNT(Koty) AS ROWNUM
B. SELECT ROWNUM() FROM Koty
C. SELECT COUNT(*) FROM Koty
D. SELECT COUNT(ROWNUM) FROM Koty
W przypadku pierwszej niepoprawnej odpowiedzi, SELECT ROWNUM() FROM Koty, należy zaznaczyć, że ROWNUM jest funkcją specyficzną dla baz danych Oracle, która zwraca numer wiersza dla każdego wiersza wynikowego zapytania. Funkcja ta nie może być używana do zliczania wierszy, ponieważ nie zwraca liczby wierszy, a jedynie ich numerację. W rezultacie, zapytanie to nie spełnia wymagań dotyczących zliczania wszystkich wierszy w tabeli. Kolejna odpowiedź, czyli SELECT COUNT(Koty) AS ROWNUM, również jest błędna, ponieważ COUNT(Koty) zlicza nie NULL-owe wartości w kolumnie o nazwie Koty, a nie całkowitą liczbę wierszy w tabeli. Jeśli tabela Koty zawiera kolumny z wartościami NULL, to wynik tego zapytania będzie mniejszy niż oczekiwana całkowita liczba wierszy. Ostatnia niepoprawna odpowiedź, SELECT COUNT(ROWNUM) FROM Koty, jest myląca, ponieważ ROWNUM nie jest kolumną ani funkcją, którą można zliczać. Odwołuje się ponownie do numeracji wierszy, a COUNT(ROWNUM) nie ma sensu w kontekście zliczania rekordów w tabeli, co prowadzi do błędnych obliczeń. Każda z tych odpowiedzi nie tylko nie realizuje założonego celu zliczania wierszy, ale może także wprowadzać w błąd osoby pracujące z SQL, sugerując zastosowanie niewłaściwych metod.

Pytanie 32

Integralność encji w systemie baz danych będzie zapewniona, jeśli między innymi

A. każda kolumna otrzyma zdefiniowany typ danych
B. każdy klucz główny będzie miał odpowiadający mu klucz obcy w innej tabeli
C. dla każdej tabeli zostanie ustanowiony klucz główny
D. klucz główny zawsze będzie liczbą całkowitą
Inne odpowiedzi na to pytanie wskazują na powszechnie występujące błędne przekonania dotyczące integralności encji. Twierdzenie, że klucz główny musi być zawsze liczbą całkowitą, jest błędne, ponieważ klucz główny może przyjmować różne typy danych, takie jak ciągi znaków, co może być użyteczne w przypadku identyfikatorów alfanumerycznych. Przypisanie typu danych dla każdej kolumny jest ważne, ale samo w sobie nie gwarantuje integralności encji, ponieważ nie eliminuje problemu duplikacji wartości, co jest kluczowe dla kluczy głównych. Ponadto, sugerowanie, że każdy klucz główny powinien mieć odpowiadający klucz obcy w innej tabeli, prowadzi do nieporozumienia, ponieważ klucz główny nie musi być powiązany z kluczem obcym, jeśli tabela nie jest częścią relacji. Klucze obce są używane do tworzenia relacji między tabelami, ale nie są wymogiem dla każdej tabeli. W praktyce, klucz główny jest podstawowym wymogiem dla spójności danych w tabelach, natomiast inne aspekty, takie jak typ danych czy relacje między tabelami, są uzupełniające i nie mogą być traktowane jako równorzędne do roli klucza głównego w zapewnieniu integralności encji.

Pytanie 33

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

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

Pytanie 34

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. najmłodszy i najstarszy wiek uczestników
D. średnią wartość wieku 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 35

Jakie wartości powinny mieć zmienne w funkcji z biblioteki mysqli, by ustanowić połączenie z serwerem i bazą danych?

mysqli_connect($a, $b, $c, $d) or die('Brak połączenia z serwerem MySQL.');
A. adres serwera - $a, nazwa bazy danych - $d, login - $b, hasło - $c
B. adres serwera - $c, nazwa bazy danych - $d, login - $a, hasło - $b
C. adres serwera - $c, nazwa bazy danych - $d, login - $b, hasło - $a
D. adres serwera - $a, nazwa bazy danych - $b, login - $c, hasło - $d
Wybór złych odpowiedzi pewnie wynika z tego, że nie do końca zrozumiałeś, jak ważna jest prawidłowa kolejność argumentów w funkcji mysqli_connect. Często zdarza się pomylić kolejność argumentów przy połączeniu z bazą danych. Rozumienie tej logiki jest naprawdę istotne: pierwszy argument to adres serwera, np. localhost, a drugi to nazwa użytkownika. Trzeci to hasło do bazy, a czwarty to nazwa bazy, z którą chcesz się połączyć. Jak zmienisz kolejność tych zmiennych, to nie uda się nawiązać połączenia, bo serwer nie będzie wiedział, jak uwierzytelnić użytkownika ani znaleźć bazy. Użytkownikom, którzy nie czują się pewnie w tym temacie, może to być frustrujące. Z mojego doświadczenia, kluczem jest dobrze poznać specyfikację funkcji oraz myśleć logicznie, żeby przypisać zmienne do odpowiednich argumentów. Jak to ogarniesz, to unikniesz wielu błędów i lepiej sobie poradzisz z bazami danych w przyszłości.

Pytanie 36

Wskaż polecenie SQL, które dodaje kolumnę miesiacSiewu do już istniejącej tabeli rośliny

A. CREATE TABLE rosliny {miesiacSiewu int}
B. UPDATE rosliny ADD miesiacSiewu int
C. ALTER TABLE rosliny ADD miesiacSiewu int
D. INSERT INTO rosliny Values (miesiacSiewu int)
Pierwsza niepoprawna odpowiedź wykorzystuje polecenie 'UPDATE rosliny ADD miesiacSiewu int;', ale to zupełnie nie to, bo UPDATE jest do zmieniania już istniejących rekordów, a nie do dodawania kolumn. Kolejna odpowiedź, w której jest 'CREATE TABLE rosliny {miesiacSiewu int};', to też zły pomysł. CREATE TABLE jest do tworzenia nowych tabel, co w tym przypadku nie ma sensu, bo tabela 'rosliny' już przecież jest. Stworzenie nowej tabeli zamiast zmieniania tej istniejącej tylko by skomplikowało sprawę. Ostatnia odpowiedź z 'INSERT INTO rosliny Values (miesiacSiewu int);' też nie pasuje, bo INSERT INTO jest do dodawania nowych rekordów, a nie do kolumn. Do tego to 'miesiacSiewu int' nie powinno się tam znaleźć, bo w poleceniu INSERT powinny być rzeczywiste dane, a nie definicje typów. Te niepoprawne odpowiedzi pokazują różne rzeczy w SQL, ale żadna z nich nie osiąga celu dodania kolumny do istniejącej tabeli.

Pytanie 37

Które z poleceń przyznaje użytkownikowi uczen najniższe uprawnienia w kontekście modyfikacji danych oraz struktury tabeli?

A. GRANT SELECT ON szkola.przedmioty TO uczen;
B. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;
C. GRANT DROP ON szkola.przedmioty TO uczen;
D. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
Patrząc na błędne odpowiedzi, można zauważyć, że większość z nich przyznaje użytkownikowi 'uczen' zbyt wiele uprawnień, które mogą prowadzić do niebezpiecznych sytuacji. Na przykład, opcja GRANT DROP ON szkola.przedmioty TO uczen pozwala na usunięcie całej tabeli 'przedmioty', co, moim zdaniem, jest zdecydowanie przesadą dla ucznia. Podobnie, jeśli dajemy GRANT ALTER, SELECT ON szkola.przedmioty TO uczen, to on może zmieniać strukturę tabeli, co dla kogoś, kto dopiero się uczy, nie jest dobrym pomysłem, bo mogą się pojawić błędy i problemy z danymi. Uprawnienia GRANT INSERT, DROP ON szkola.przedmioty TO uczen także są kiepskim pomysłem, bo taki użytkownik mógłby dodawać nowe wiersze czy usuwać istniejące, co znowu zagraża integralności danych. Często myślimy, że im więcej uprawnień damy, tym lepiej, ale w praktyce taka szeroka swoboda może przynieść więcej szkody niż pożytku. Dlatego ważne jest, żeby stosować zasadę minimalnych uprawnień i dokładnie przemyśleć, co naprawdę potrzebne, żeby uczeń mógł spokojnie uczyć się przedmiotów.

Pytanie 38

Jakie narzędzie pozwala na zaimportowanie pliku z danymi SQL do bazy danych MySQL?

A. TotalCommander
B. FileZilla
C. Symfony 3
D. phpMyAdmin
phpMyAdmin to popularne narzędzie webowe, które umożliwia zarządzanie bazami danych MySQL i MariaDB. Dzięki phpMyAdmin można łatwo importować pliki z danymi SQL do bazy danych. Proces importu jest prosty: wystarczy zalogować się do phpMyAdmin, wybrać odpowiednią bazę danych, a następnie skorzystać z opcji 'Import'. Użytkownik może wskazać plik SQL, który chce zaimportować, a phpMyAdmin zadba o resztę. To narzędzie obsługuje różne formaty plików, w tym .sql, co czyni je wszechstronnym rozwiązaniem. Dodatkowo, phpMyAdmin oferuje funkcje umożliwiające zarządzanie strukturą tabel, przeglądanie danych, a także eksportowanie danych do różnych formatów. Narzędzie to jest zgodne z międzynarodowymi standardami bezpieczeństwa i dostępności, co czyni je popularnym wyborem wśród programistów i administratorów baz danych. Przykładem użycia może być migracja danych z lokalnego środowiska deweloperskiego do produkcyjnego, gdzie import danych SQL jest kluczowym krokiem w procesie wdrożenia.

Pytanie 39

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

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

Pytanie 40

Jaki typ powinien być zastosowany, aby pole w bazie danych mogło przechowywać liczby zmiennoprzecinkowe?

A. FLOAT
B. VARCHAR
C. CHAR
D. INT
Wybranie typu INT jako odpowiedzi wskazuje na nieporozumienie dotyczące sposobu przechowywania danych liczbowych w bazach danych. Typ INT jest przystosowany jedynie do przechowywania wartości całkowitych, co oznacza, że nie może obsługiwać liczb rzeczywistych ani wartości z ułamkami. W praktycznych zastosowaniach, gdy użytkownik potrzebuje manipulować wartościami, które nie są całkowite (np. ceny produktów, które mogą mieć część dziesiętną), użycie INT prowadziłoby do błędnych obliczeń i zakłóceń w logice aplikacji. W przypadku CHAR oraz VARCHAR, te typy są przeznaczone do przechowywania tekstu. CHAR jest stałej długości, co może prowadzić do marnowania miejsca w bazie, podczas gdy VARCHAR jest zmiennej długości, co czyni go bardziej elastycznym, ale ani jeden, ani drugi typ nie są przeznaczone do przechowywania danych numerycznych. Typowe błędy myślowe, które prowadzą do takich wyborów, polegają na nieprzemyślanej interpretacji potrzeb aplikacji i rodzaju danych, które powinny być przechowywane. Użytkownicy baz danych powinni zawsze dążyć do dokładnego określenia wymaganych typów danych na podstawie ich zastosowania, aby uniknąć problemów z integralnością danych oraz ich wydajnością w przyszłych operacjach.