Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik programista
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 8 czerwca 2026 18:50
Data zakończenia: 8 czerwca 2026 19:17

Egzamin niezdany

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

Wymagane minimum: 20 punktów (50%)

Nowe

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

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Które z poniższych stwierdzeń na temat klucza głównego jest prawdziwe?

A. W przypadku tabeli z danymi osobowymi może to być pole nazwisko

B. Jest unikalny dla danej tabeli

C. Może przyjmować wyłącznie wartości liczbowe

D. Składa się wyłącznie z jednego pola

Klucz podstawowy to atrybut (lub zbiór atrybutów) w tabeli, który jednoznacznie identyfikuje każdy wiersz w tej tabeli. Jego unikalność w obrębie tabeli jest kluczowa, ponieważ pozwala na zapobieganie duplikatom i zapewnia integralność danych. Na przykład, w tabeli przechowującej informacje o klientach, kolumna z identyfikatorem klienta (np. ID klienta) powinna być kluczem podstawowym, ponieważ każdy klient musi mieć unikalny identyfikator. Standardy baz danych, takie jak model relacyjny, podkreślają znaczenie kluczy podstawowych w zapewnieniu stabilności i efektywności w przechowywaniu danych. Użycie klucza podstawowego również wpływa na wydajność operacji wyszukiwania i łączenia tabel, dlatego w projektowaniu baz danych należy starannie dobierać atrybuty, które będą pełnić tę rolę, aby spełniały wymagania unikalności oraz wydajności.

Pytanie 2

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

A. n..1

B. 1..n

C. n..n

D. 1..1

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

Pytanie 3

Aby w tabeli praca, tworzonej w języku SQL, dodać do kolumny stawka warunek, który wymusza, aby przyjmowane były jedynie wartości dodatnie, a jednocześnie mniejsze niż 50, należy zastosować zapis

A. … stawka foat CHECK (stawka>0 AND stawka<50.00)

B. … stawka foat CHECK (stawka IN (0, 50.00))

C. … stawka foat CHECK (stawka>0 OR stawka<50.00)

D. … stawka foat CHECK (stawka BETWEEN 0 AND 50.00)

Wybór odpowiedzi, która nie spełnia założonych warunków, może wynikać z nieprawidłowego zrozumienia logiki operatorów oraz zasadności stosowania warunków CHECK w SQL. Na przykład, zapis '… stawka foat CHECK (stawka BETWEEN 0 AND 50.00)' jest niewłaściwy, ponieważ warunek ten dopuszcza wartość równą zeru, która nie jest wartością dodatnią. Umożliwienie zerowych wartości może prowadzić do sytuacji, w której w tabeli znajdą się dane niezgodne z założeniem, że 'stawka' ma być wartością dodatnią. Podobnie, zapis '… stawka foat CHECK (stawka>0 OR stawka<50.00)' również jest błędny, ponieważ logiczne połączenie za pomocą operatora OR wprowadza możliwość, że 'stawka' może być większa od zera i jednocześnie większa lub równa 50, co jest sprzeczne z naszym celem. Z kolei użycie '… stawka foat CHECK (stawka IN (0, 50.00))' jest nieodpowiednie, ponieważ operator IN sprawdza, czy wartość 'stawka' znajduje się w specyficznej liście wartości, a w tym przypadku znowu dopuszcza zera i wartości graniczne, które nie powinny być zaakceptowane. Tego rodzaju błędy myślowe prowadzą do niepoprawnych założeń w projektowaniu bazy danych, które z kolei mogą skutkować problemami z jakością danych oraz ich późniejszą analizą. Dlatego kluczowe jest zrozumienie, jak właściwie formułować warunki walidacji, aby zapewnić spójność i integralność danych.

Pytanie 4

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

$a = new mysqli('b', 'c', 'd', 'e');

A. nazwa bazy danych

B. hasło dla użytkownika

C. adres serwera bazy danych

D. nazwa użytkownika

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

Pytanie 5

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. CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2;

B. VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2;

C. CREATE VIEW Prac_dzial2 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.

Pytanie 6

Istnieje tabela o nazwie wycieczki z kolumnami: nazwa, cena oraz miejsca (reprezentujące liczbę dostępnych miejsc). Aby wyświetlić tylko nazwy wycieczek, których cena jest mniejsza od 2000 zł oraz mają co najmniej cztery wolne miejsca, należy użyć zapytania

A. SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4

B. SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3

C. SELECT * FROM wycieczki WHERE cena < 2000 OR miejsca > 3

D. SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4

Wszystkie inne odpowiedzi są po prostu błędne i prowadzą do złych wyników w kontekście pytania. Na przykład zapytanie z operatorem OR, czyli 'SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4', pozwala na zwrócenie wycieczek, które spełniają tylko jeden z warunków. To oznacza, że mogą być pokazywane wycieczki droższe, które mają wystarczająco dużo miejsc, co jest niezgodne z wymaganiami. Jeszcze innym błędnym przypadkiem jest użycie operatora AND w 'SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3', gdzie ten drugi warunek jest zbyt ogólny. Powinien precyzować, że miejsc musi być co najmniej cztery, a nie tylko więcej niż trzy. Co więcej, zapytanie 'SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4' zwróci wszystkie kolumny, a nie tylko nazwy wycieczek, co też nie jest tym, czego potrzebujemy. Typowe błędy w myśleniu, które prowadzą do tych błędnych wniosków, to złe łączenie warunków i niewłaściwe zrozumienie, co jest ważne w kontekście wymagań. Aby dobrze pisać zapytania SQL, kluczowe jest zrozumienie struktury danych i logiki, która pozwala na wybranie odpowiednich rekordów.

Pytanie 7

W systemie zarządzania bazami danych MySQL komenda CREATE USER pozwala na

A. pokazanie danych o istniejącym użytkowniku

B. zmianę hasła dla już istniejącego użytkownika

C. utworzenie użytkownika

D. stworznie nowego użytkownika oraz przydzielenie mu uprawnień do bazy

Odpowiedzi sugerujące utworzenie użytkownika i nadanie mu praw do bazy lub wyświetlenie informacji o istniejącym użytkowniku nie są poprawne, ponieważ CREATE USER służy jedynie do definicji konta użytkownika, a nie do przypisywania mu uprawnień. W rzeczywistości, aby przyznać dostęp do bazy danych, należy użyć osobnego polecenia GRANT, które zarządza uprawnieniami dla już istniejących użytkowników. Z tego powodu pomylenie tych dwóch poleceń może prowadzić do nieefektywnego zarządzania użytkownikami w systemie bazy danych. Innym błędnym podejściem jest przypisanie funkcji wyświetlania informacji o użytkownikach do CREATE USER. W MySQL do uzyskania takich informacji wykorzystuje się zapytania do systemowych tabel informacyjnych lub polecenie SHOW GRANTS, które pozwala na przeglądanie przyznanych uprawnień dla konkretnego użytkownika. Z kolei zmiana hasła istniejącego użytkownika z wykorzystaniem CREATE USER jest również pomyłką, gdyż do takiej operacji należy używać polecenia ALTER USER, co pozwala na aktualizację danych logowania bez konieczności usuwania i ponownego tworzenia konta. Błędy te wynikają często z niepełnego zrozumienia funkcji poszczególnych poleceń SQL, co może prowadzić do nieefektywnego zarządzania bazą danych oraz zwiększonego ryzyka bezpieczeństwa.

Pytanie 8

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

SELECT MAX(wiek) - MIN(wiek) FROM uczestnicy;

A. średnią arytmetyczną wieku uczestników.

B. liczbę najstarszych uczestników.

C. minimalny oraz maksymalny wiek uczestników.

D. różnicę wieku pomiędzy najstarszym i najmłodszym uczestnikiem.

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 9

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

SELECT imie FROM mieszkancy WHERE imie LIKE '_r%';

A. Krzysztof, Krystyna, Romuald

B. Gerald, Jarosław, Marek, Tamara

C. Arleta, Krzysztof, Krystyna, Tristan

D. Rafał, Rebeka, Renata, Roksana

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 10

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 * FROM ksiazki WHERE cena < 50;

C. SELECT ksiazki FROM tytul WHERE cena < '50 zł';

D. SELECT tytul FROM ksiazki WHERE cena > '50 zł';

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 11

Jakie polecenie należy wykorzystać, aby przypisać użytkownikowi uprawnienia do tabel w bazie danych?

A. GRANT

B. REVOKE

C. CREATE

D. SELECT

Odpowiedzi SELECT, CREATE i REVOKE mogą wydawać się związane z zarządzaniem dostępem do bazy danych, ale żadna z nich nie jest prawidłowym sposobem na nadanie uprawnień. SELECT to polecenie wykorzystywane do odczytywania danych z tabeli, a nie do nadawania uprawnień. Użytkownik, który nie ma odpowiednich uprawnień, nie będzie w stanie wykonać SELECT, ale to polecenie nie przyznaje tych uprawnień. CREATE z kolei służy do tworzenia nowych obiektów w bazie danych, takich jak tabele czy bazy danych, i również nie ma związku z zarządzaniem uprawnieniami. REVOKE to polecenie, które służy do odbierania wcześniej nadanych uprawnień, co oznacza, że jego funkcjonalność jest odwrotnością GRANT. Niezrozumienie tych podstawowych różnic może prowadzić do błędów w zarządzaniu dostępem do zasobów bazy danych. Kluczowe jest, aby użytkownicy mieli świadomość, jak te polecenia działają i jakie mają zastosowanie, by unikać sytuacji, w których nieodpowiednie uprawnienia są przyznawane lub odbierane, co może wpłynąć na bezpieczeństwo oraz integralność danych.

Pytanie 12

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

A. zostanie pominięty warunek dotyczący imienia

B. zostaną wyświetlone wszystkie kolumny tabeli mieszkańcy

C. zostaną wyświetlone wszystkie wpisy z tabeli mieszkańcy

D. zostanie pokazane pole o nazwie "*" (gwiazdka)

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

Pytanie 13

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

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

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

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

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

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

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

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

Pytanie 14

Zawarte polecenie SQL wykonuje

UPDATE Uczen SET id_klasy = id_klasy + 1;

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

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

C. ustalić wartość pola Uczen na 1

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

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

Pytanie 15

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

A. kwerendą

B. formularzem

C. kopią

D. kolumną

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

Pytanie 16

Kwerenda

ALTER TABLE artykuly MODIFY cena float;

ma na celu dokonanie zmian w tabeli artykuly.

A. usunąć kolumnę o nazwie cena typu float

B. zmienić nazwę kolumny cena na float

C. zmienić typ kolumny cena na float

D. dodać kolumnę o nazwie cena z typem float, jeżeli jeszcze nie istnieje

Twoja odpowiedź na temat usunięcia lub zmiany kolumny nie jest najlepsza w tym kontekście. Jeśli usuniemy kolumnę cena, to stracimy wszystkie dane, które tam były – a to na pewno by zaszkodziło, zwłaszcza gdy mówimy o cenach. Takie operacje robi się tylko wtedy, gdy dany atrybut jest naprawdę niepotrzebny albo był źle wprowadzony. Dodanie kolumny cena, o ile nie istnieje, wydaje się zmieniać strukturę danych, ale jeżeli już jest, to nie ma sensu. Taki ruch mógłby prowadzić do zduplikowania danych, co stoi w sprzeczności z zasadami normalizacji. A zmiana nazwy kolumny z cena na float to już w ogóle nieporozumienie, bo float to typ danych, a nie nazwa, więc wprowadziłoby to zamieszanie. Wszystkie te błędy wynikają z braku zrozumienia, jak działa struktura tabel w bazach danych. Zrozumienie tego jest kluczowe, zanim podejmiesz jakiekolwiek kroki, żeby coś zmieniać.

Pytanie 17

W języku SQL, aby z tabeli Uczniowie wyodrębnić rekordy dotyczące wyłącznie uczennic o imieniu "Aleksandra", które przyszły na świat po roku "1998", należy sformułować zapytanie

A. SELECT * FROM Uczniowie WHERE imie ="Aleksandra" OR rok_urodzenia < "1998"

B. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia < "1998"

C. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia > "1998"

D. SELECT * FROM Uczniowie WHERE imie="Aleksandra" OR rok_urodzenia > "1998"

Wybór odpowiedzi zawierającej operator OR prowadzi do niepoprawnych wyników w kontekście tego zapytania. Operator OR wprowadza możliwość selekcji rekordów, które spełniają przynajmniej jeden z warunków, co nie odpowiada wymaganiu, aby zwracać wyłącznie te uczennice, które mają imię 'Aleksandra' oraz są urodzone po 1998 roku. Na przykład, w przypadku pierwszej odpowiedzi, zwrócone zostaną uczennice o imieniu 'Aleksandra' urodzone przed 1998 rokiem, co jest sprzeczne z wymaganiem, aby uwzględniać tylko uczennice urodzone po 1998 roku. Podobnie, druga odpowiedź również zwróciłaby uczennice o innych imionach, które urodziły się po 1998 roku, co nie jest zgodne z celem zapytania. Odpowiedź zawierająca operator AND jest preferowana w tym przypadku, ponieważ pozwala na dokładne określenie i weryfikację danych, co jest kluczowe w pracy z bazami danych. Prawidłowe zrozumienie różnicy między tymi operatorami jest istotne, aby unikać nieścisłości w wynikach zapytań SQL, szczególnie w kontekście przetwarzania danych w systemach informacyjnych. Operator AND jest używany w celu ograniczenia zbioru wyników, co zwiększa dokładność analizy danych, ułatwia raportowanie i podejmowanie decyzji opartych na danych.

Pytanie 18

SELECT miasto, AVG(pensja) FROM pracownicy GROUP BY miasto;

Podane zapytanie wybierze:

A. nazwy miast z powtórzeniami oraz średnią pensję dla każdego z nich.

B. nazwy miast bez powtórzeń oraz sumę pensji dla każdego z nich.

C. nazwy miast z powtórzeniami oraz sumę pensji dla każdego z nich.

D. nazwy miast bez powtórzeń oraz średnią pensję dla każdego z nich.

Zapytanie z klauzulą GROUP BY i funkcją AVG bywa mylone z sumowaniem danych lub zwykłym wybieraniem rekordów jeden po drugim. W tym konkretnym przypadku bardzo łatwo pomylić średnią z sumą albo nie zauważyć, że grupowanie usuwa powtórzenia wartości w kolumnie grupującej. Warto to uporządkować. Funkcja AVG(pensja) jest klasyczną funkcją agregującą, której zadaniem jest obliczenie średniej arytmetycznej z wartości w danej grupie rekordów. Nie dodaje ona wszystkich pensji „na kupę” tak jak SUM, tylko dzieli ich sumę przez liczbę rekordów w grupie. Jeżeli ktoś spodziewa się sumy, to patrzy bardziej w stronę SUM(pensja), a nie AVG(pensja). To jest typowy błąd: widzimy funkcję agregującą i automatycznie myślimy „to pewnie suma”, bez dokładnego przeczytania nazwy funkcji. Druga kwestia to powtórzenia miast. Klauzula GROUP BY miasto mówi silnikowi bazy danych: pogrupuj wszystkie wiersze według wartości w kolumnie miasto. W efekcie wszystkie rekordy z tym samym miastem są łączone w jedną grupę. Dla każdej takiej grupy zwracany jest dokładnie jeden wiersz wyniku. To oznacza, że w rezultacie zapytania nie ma powtórzonych nazw miast, nawet jeśli w tabeli jest tysiąc pracowników z Warszawy czy Krakowa. Częsty błąd myślowy polega na przenoszeniu intuicji z prostego SELECT bez GROUP BY, gdzie miasto faktycznie się powtarza, na zapytanie z agregacją, gdzie logika jest już inna. W odpowiedziach, które sugerują „z powtórzeniami”, ignorowane jest działanie GROUP BY. Z kolei odpowiedzi mówiące o „sumie pensji” mylą AVG z SUM, co w praktyce może prowadzić do bardzo poważnych błędów analitycznych – wyobraź sobie raport płacowy, w którym zamiast średniej ktoś pokaże sumę wynagrodzeń i na tej podstawie będzie porównywał miasta. Moim zdaniem dobrą praktyką jest zawsze czytanie zapytania fragment po fragmencie: najpierw jakie kolumny są wybierane, potem jakie funkcje agregujące są użyte, a na końcu po czym następuje grupowanie. Taka metoda pozwala uniknąć właśnie takich nieporozumień i lepiej rozumieć, co dokładnie zwróci baza danych, co jest kluczowe przy pracy z realnymi systemami produkcyjnymi.

Pytanie 19

Używając polecenia ALTER TABLE, co można zrobić?

A. zmiana struktury tabeli

B. zmiana wartości w rekordach tabeli

C. usunięcie tabeli

D. stworznie tabeli

W odpowiedziach pojawia się wiele nieprawidłowych koncepcji dotyczących funkcji polecenia ALTER TABLE w SQL. Usuwanie tabeli nie jest zadaniem ALTER TABLE - aby usunąć tabelę, używamy polecenia DROP TABLE. To polecenie całkowicie eliminuje tabelę z bazy danych, co jest zupełnie inną operacją niż modyfikacja już istniejącej struktury. Tworzenie tabeli także nie należy do funkcji ALTER TABLE; do tego celu używamy polecenia CREATE TABLE. To polecenie jest podstawowym narzędziem w procesie projektowania bazy danych, pozwalającym na definiowanie nowych struktur. Kolejną niepoprawną odpowiedzią było sugerowanie, że ALTER TABLE może modyfikować wartości zapisane w rekordach tabeli. Zmiana wartości w rekordach wymaga użycia polecenia UPDATE, które jest zaprojektowane do aktualizacji danych w tabeli, pozostawiając strukturę tabeli nietkniętą. Typowym błędem myślowym jest mylenie operacji strukturalnych z operacjami na danych. W praktyce, zrozumienie różnicy między tymi operacjami jest kluczowe dla efektywnego zarządzania bazami danych. Znalezienie odpowiednich poleceń i technik do realizacji zadań związanych z bazami danych jest fundamentalne dla każdego administratora bazy danych lub programisty, a właściwe korzystanie z ALTER TABLE to jedna z wielu umiejętności, które trzeba opanować.

Pytanie 20

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

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

B. SELECT tytul FROM ksiazki

C. SELECT * FROM ksiazki

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

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

Pytanie 21

Proces przetwarzania sygnału wejściowego w czasie, wykorzystujący zasadę superpozycji, jest związany z filtrem

A. liniowym

B. niezmiennym w czasie

C. o skończonej odpowiedzi impulsowej

D. przyczynowym

Wybór odpowiedzi związanej z filtrami przyczynowymi, niezmiennymi w czasie i o skończonej odpowiedzi impulsowej może prowadzić do nieporozumień w kontekście filtracji sygnałów. Filtr przyczynowy, chociaż może być liniowy, niekoniecznie musi spełniać wszystkie założenia dotyczące superpozycji, ponieważ jego odpowiedź impulsowa ogranicza się do przeszłych wartości sygnału, co może wprowadzać dodatkowe zniekształcenia w analizie sygnałów. Stosowanie filtrów niezmiennych w czasie w kontekście superpozycji również wymaga ostrożności, ponieważ mogą one wprowadzać zmiany w amplitudzie i fazie sygnałów, co prowadzi do złożonych interakcji. Z kolei filtry o skończonej odpowiedzi impulsowej (FIR) są typem filtru liniowego, ale nie zawsze są przyczynowe; można je zaprojektować jako filtry nieprzyczynowe, co podważa ich użyteczność w kontekście rzeczywistych zastosowań przetwarzania sygnałów. Warto zauważyć, że w praktyce, projektowanie filtrów wymaga zrozumienia i analizy zarówno ich właściwości liniowych, jak i nieliniowych, a także wpływu na jakość przetwarzanych sygnałów. Kluczowe jest również uwzględnienie spektrum sygnału oraz jego cech, co jest zgodne z najlepszymi praktykami inżynieryjnymi, aby uzyskać optymalne wyniki w aplikacjach inżynieryjnych.

Pytanie 22

W języku SQL operator arytmetyczny odpowiadający reszcie z dzielenia to

A. %

B. &

C. ||

D. /

Widzę, że wybrałeś inne operatory arytmetyczne, ale niestety to nie jest to, co tutaj potrzebujemy. Operator '/' służy do dzielenia, a nie do znajdowania reszty – to prosta pomyłka. A ten '||', to jest używane do łączenia tekstów, więc też nie pasuje do obliczeń matematycznych. Operator '&' to w ogóle inna bajka – związany z operacjami bitowymi, a nie z tymi klasycznymi matematykami. Jak się nie rozumie, do czego te operatory służą, może łatwo popełnić błąd w zapytaniach SQL. W sumie, ważne jest, żeby znać operatorów zastosowanie i używać ich w odpowiednich kontekstach. Dobrze jest się zastanowić, na czym polega każda operacja, żeby uniknąć typowych pomyłek w kodzie.

Pytanie 23

W instrukcji CREATE TABLE zastosowanie klauzuli PRIMARY KEY przy definiowaniu pola tabeli spowoduje, że to pole stanie się

A. kluczem podstawowym

B. kluczem obcym

C. indeksem klucza

D. indeksem unikalnym

Wybór klucza obcego jako odpowiedzi jest błędny, ponieważ klucz obcy to inny typ atrybutu, który służy do tworzenia powiązań między tabelami. Klucz obcy odnosi się do klucza podstawowego w innej tabeli, co pozwala na utrzymanie relacyjnych danych. Nie jest to struktura, która jednoznacznie identyfikuje rekord w swojej tabeli, lecz odnosi się do rekordów w innej tabeli. Z kolei indeks klucza to struktura danych, która przyspiesza operacje wyszukiwania na kolumnach tabeli, ale nie pełni funkcji zapewnienia unikalności danych, co jest kluczowe dla klucza podstawowego. Indeks unikalny także różni się od klucza podstawowego; chociaż zapewnia unikalność wartości, może zawierać wartości NULL, podczas gdy klucz podstawowy ich nie dopuszcza. Typowym błędem myślowym jest mylenie tych pojęć, co prowadzi do nieporozumień w projektowaniu baz danych. Kluczowe jest zrozumienie ról, jakie poszczególne elementy struktury bazy danych odgrywają, aby efektywnie zarządzać danymi oraz zapewniać ich integralność. Właściwe zrozumienie tych koncepcji jest niezbędne do tworzenia prawidłowo działających systemów baz danych.

Pytanie 24

Wskaż zapytanie, w którym dane są uporządkowane.

A. SELECT AVG(ocena) FROM uczniowie WHERE klasa = 2;

B. SELECT DISTINCT produkt, cena FROM artykuly;

C. SELECT nazwisko FROM firma WHERE pensja > 2000 LIMIT 10;

D. SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek;

Odpowiedź wskazująca na zapytanie "SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek;" jest prawidłowa, ponieważ zawiera klauzulę ORDER BY, która służy do sortowania rekordów w wynikach zapytania. W tym przypadku dane są sortowane według kolumny 'wiek', co pozwala na uzyskanie uporządkowanej listy mieszkańców, którzy mają więcej niż 18 lat. Sortowanie danych jest kluczowym aspektem w zarządzaniu bazami danych, umożliwiającym łatwiejsze wyszukiwanie oraz analizę informacji. Przykładem zastosowania może być generowanie raportów, gdzie istotne jest uporządkowanie danych, na przykład według wieku, aby zobaczyć, jak rozkłada się wiek mieszkańców w danej grupie. Dodatkowo, stosowanie sortowania zgodnie z przyjętymi standardami SQL zwiększa czytelność oraz efektywność zapytań, a także ułatwia rozwiązywanie problemów związanych z przetwarzaniem danych.

Pytanie 25

Jakie prawa będzie miał 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 mógł usuwać rekordy z tabeli klienci

B. Będzie mógł zmieniać strukturę tabeli klienci

C. Będzie mógł dodawać rekordy do tabeli klienci

D. Będzie mógł przeszukiwać dane w tabeli klienci

Rozważając inne opcje dostępne w pytaniu warto zwrócić uwagę na zakres uprawnień jakie są zazwyczaj przyznawane użytkownikom baz danych. Uprawnienia takie jak INSERT pozwalają na dodawanie nowych rekordów do tabeli co jest istotne w aplikacjach wymagających częstego aktualizowania danych użytkowników. Jednak w przedstawionym scenariuszu uprawnienia te zostały usunięte poleceniem REVOKE co oznacza że jan nie może wstawiać nowych rekordów do tabeli klienci co zdaje się być częstym nieporozumieniem w interpretacji uprawnień. Podobnie DELETE pozwala na usuwanie rekordów co jest kluczowe w zarządzaniu przestrzenią i utrzymywaniu danych aktualnymi. Jednakże po ponownym rozważeniu zaproponowanego scenariusza widzimy że jan nie ma już tych uprawnień. SELECT z kolei służy do przeszukiwania i wyświetlania danych co jest podstawowym działaniem w analizie danych. Brak tego uprawnienia oznacza brak możliwości przeglądania danych co może być ograniczeniem w pracy z bazą danych. Często mylnie zakłada się że użytkownik posiada wszystkie podstawowe uprawnienia co wynika z niewłaściwego zrozumienia poleceń GRANT i REVOKE. W praktyce administratorzy baz danych muszą precyzyjnie zarządzać uprawnieniami aby zapewnić bezpieczeństwo integralność i wydajność danych co oznacza dokładne zrozumienie i stosowanie poleceń DCL (Data Control Language).

Pytanie 26

Pole insert_id zdefiniowane w bibliotece MySQLi języka PHP może być wykorzystane do

A. uzyskania id ostatnio dodanego wiersza

B. pobrania najwyższego indeksu bazy, aby po jego zwiększeniu wstawić pod niego dane

C. otrzymania kodu błędu, gdy wstawienie wiersza się nie powiodło

D. uzyskania pierwszego dostępnego indeksu bazy, tak, aby można było pod nim wstawić nowe dane

Każda z niepoprawnych odpowiedzi zawiera błędne założenia dotyczące funkcji insert_id w kontekście MySQLi. Odpowiedź, która sugeruje, że pole to może być użyte do otrzymania kodu błędu w przypadku niepowodzenia procesu wstawiania wiersza, jest myląca, ponieważ kod błędu jest uzyskiwany za pomocą innych mechanizmów, takich jak mysqli_errno() oraz mysqli_error(). Takie podejście może prowadzić do nieporozumień w zarządzaniu błędami w bazach danych, co jest istotnym aspektem programowania. Ponadto, pomysł, że insert_id może być używany do pobrania najwyższego indeksu bazy, aby po jego inkrementacji wstawić nowe dane jest nieprawidłowy, ponieważ insert_id nie działa w ten sposób; identyfikator jest automatycznie generowany przez bazę danych w momencie dodawania rekordu. Takie podejście może prowadzić do trudności w synchronizacji danych i jest niezgodne z zasadami dobrego projektowania baz danych. Również koncepcja pozyskiwania pierwszego wolnego indeksu jest błędna; w praktyce nie jest zalecane ręczne zarządzanie indeksami, ponieważ może to prowadzić do konfliktów i naruszenia integralności danych. MySQL automatycznie zarządza numerami ID, co jest bardziej efektywne i zmniejsza ryzyko błędów. Wreszcie, stosując te nieprawidłowe koncepcje, programiści mogą napotkać trudności w utrzymaniu kodu i jego rozwoju, co może zwiększyć złożoność aplikacji.

Pytanie 27

W programie MS Access w ustawieniach pola klasa należy określić maskę wprowadzania danych. Jaką maskę należy ustawić, aby dane wprowadzone składały się z trzech znaków w formacie: obowiązkowa cyfra, następnie dwie obowiązkowe litery?

Ogólne
Rozmiar pola	3
Format
Maska wprowadzania
Tytuł
Wartość domyślna
Reguła spr. poprawności
Tekst reguły spr. poprawności
Wymagane	Nie
Zerowa dł. dozwolona	Tak
Indeksowane	Nie
Kompresja Unicode	Tak
Tryb IME	Bez formantu
Tryb zdania edytora IME	Brak
Tagi inteligentne

A. 000

B. 0LL

C. 0CC

D. CLL

W przypadku maski wprowadzania danych w MS Access, należy zrozumieć, jakie znaczenie mają poszczególne symbole używane do stworzenia maski. Symbole te określają, co użytkownik może wprowadzić w każdym miejscu pola. Często spotykanym błędem jest wybór niewłaściwego symbolu, co prowadzi do niepoprawnego formatu danych. W przypadku masek takich jak 0CC, 000 i CLL, każda z nich stosuje niewłaściwe podejście do formatu wymaganego w pytaniu. Maska 0CC zakłada, że po cyfrze mogą znajdować się dowolne znaki, co nie spełnia wymagań dotyczących dwóch obowiązkowych liter. Maska 000 z kolei wymusza wprowadzenie trzech cyfr, co całkowicie mija się z celem, ponieważ wymagany jest format składający się z jednej cyfry i dwóch liter. Maska CLL sugeruje, że pierwszy znak może być dowolnym znakiem (cyfrą lub literą), co również jest niezgodne z wymaganiami, gdzie pierwszą pozycję musi zajmować cyfra. Takie nieporozumienia mogą wynikać z braku zrozumienia znaczenia symboli używanych w maskach wprowadzania danych. Kluczem do poprawnego zastosowania masek w MS Access jest więc dokładne poznanie, jakie symbole są dostępne i jakie mają zastosowanie, aby zwiększyć spójność i integralność danych w systemach bazodanowych. Zrozumienie tych zasad pozwala również uniknąć typowych błędów wynikających z niepoprawnej interpretacji wymagań dotyczących formatowania danych, co jest istotne nie tylko w kontekście egzaminacyjnym, ale także w praktycznej pracy z bazami danych. Poprawne zrozumienie i stosowanie masek wprowadzania danych jest elementem profesjonalnego zarządzania danymi, gdzie każda baza musi spełniać określone standardy jakości i wydajności.

Pytanie 28

Aby utworzyć tabelę w systemie baz danych, należy użyć polecenia SQL

A. NEW TABLE

B. ADD TABLE

C. PLUS TABLE

D. CREATE TABLE

Aby utworzyć tabelę w bazie danych, należy użyć polecenia SQL 'CREATE TABLE', które jest standardową komendą w SQL (Structured Query Language) służącą do definiowania struktury tabeli. Polecenie to pozwala na określenie nazw kolumn, ich typów danych oraz opcji, takich jak klucze główne czy unikalność wartości. Przykładowe użycie tego polecenia wygląda następująco: 'CREATE TABLE pracownicy (id INT PRIMARY KEY, imie VARCHAR(50), nazwisko VARCHAR(50))'. Dzięki temu tworzymy tabelę o nazwie 'pracownicy' z trzema kolumnami: 'id', 'imie' i 'nazwisko'. Używanie polecenia 'CREATE TABLE' jest zgodne z normami SQL, co zapewnia jego przenośność między różnymi systemami zarządzania bazami danych. Dobrą praktyką jest także definiowanie ograniczeń, takich jak 'NOT NULL', aby zapewnić integralność danych. Również istotne jest zrozumienie, że polecenie to jest tylko jednym z wielu w SQL, które umożliwia manipulację danymi w relacyjnych bazach danych.

Pytanie 29

Celem testów wydajnościowych jest ocena

A. zdolności programu do funkcjonowania w sytuacjach, gdy system działa niepoprawnie

B. ciągu zdarzeń, w którym prawdopodobieństwo danego zdarzenia zależy tylko od wyniku zdarzenia wcześniejszego

C. stopnia, w jakim system lub moduł spełnia wymagania dotyczące wydajności

D. zdolności programu do funkcjonowania w sytuacjach, gdy sprzęt działa niepoprawnie

Testy wydajnościowe są kluczowym elementem procesu zapewnienia jakości oprogramowania, mającym na celu ocenę zdolności systemu lub modułu do spełnienia określonych wymagań wydajnościowych. Ich głównym celem jest zmierzenie, jak system radzi sobie w warunkach obciążenia, a także w różnych scenariuszach użytkowania. W ramach testów wydajnościowych analizuje się takie parametry jak czas reakcji, przepustowość oraz zasoby zużywane przez aplikację. Praktycznym przykładem może być testowanie aplikacji internetowej w warunkach, gdy korzysta z niej wielu użytkowników jednocześnie, co pozwala ocenić, jak skaluje się system. W kontekście standardów, organizacje często odnoszą się do metodologii takich jak Performance Testing Framework, a także do narzędzi jak JMeter czy LoadRunner, które umożliwiają automatyzację procesu testowania. Testy te pomagają w identyfikacji wąskich gardeł, które mogą wpływać na wydajność, co przekłada się na lepsze doświadczenia użytkowników oraz minimalizację kosztów związanych z utrzymaniem systemu.

Pytanie 30

W SQL, aby w tabeli Towar dodać kolumnę rozmiar typu znakowego z maksymalną długością 20 znaków, jakie polecenie należy wykonać?

A. ALTER TABLE Towar ALTER COLUMN rozmiar varchar(20)

B. ALTER TABLE Towar CREATE COLUMN rozmiar varchar(20)

C. ALTER TABLE Towar DROP COLUMN rozmiar varchar(20)

D. ALTER TABLE Towar ADD rozmiar varchar(20)

Podane odpowiedzi nie są poprawne z kilku powodów. Odpowiedź sugerująca użycie 'DROP COLUMN' jest myląca, ponieważ to polecenie służy do usuwania istniejącej kolumny z tabeli, a nie dodawania nowej. Usunięcie kolumny bez zrozumienia konsekwencji może prowadzić do utraty danych, co podkreśla znaczenie przemyślenia operacji modyfikujących strukturę bazy danych. Inna odpowiedź, która proponuje 'CREATE COLUMN', jest nieprawidłowa, ponieważ nie jest uznawana za standardową składnię w SQL; nie istnieje polecenie 'CREATE COLUMN'. Zamiast tego, kolumny są dodawane za pomocą 'ADD' w kontekście ALTER TABLE. W przypadku 'ALTER COLUMN' - to polecenie odnosi się do zmiany właściwości już istniejącej kolumny, a nie do dodawania nowej. Dlatego mylenie tych pojęć prowadzi do nieprawidłowych wniosków. Zrozumienie tych różnic jest kluczowe dla poprawnego posługiwania się SQL. Niezrozumienie zasad modyfikacji struktury tabeli może skutkować nieefektywnym zarządzaniem bazą danych oraz błędami w aplikacjach korzystających z danych.

Pytanie 31

Zastosowanie atrybutu NOT NULL dla kolumny jest konieczne w sytuacji, gdy

A. tworzymy definicję wszystkich pól tabeli

B. mamy do czynienia z kluczem podstawowym

C. korzystamy z atrybutu DEFAULT

D. definiujemy wszystkie pola o typie numerycznym

Nieprawidłowe odpowiedzi odzwierciedlają typowe błędne rozumienie działania atrybutu NOT NULL w kontekście tabel baz danych. W przypadku klucza podstawowego, jest to niezbędny warunek, aby zapewnić, że każdy wiersz w tabeli jest jednoznacznie identyfikowalny. Odpowiedzi sugerujące, że atrybut NOT NULL jest wymagany przy użyciu atrybutu DEFAULT, są mylące, ponieważ atrybut DEFAULT służy do ustalania wartości domyślnych dla kolumn, które mogą przyjmować wartość NULL. Użycie atrybutu DEFAULT wcale nie implikuje, że kolumna musi być oznaczona jako NOT NULL. Kolejna niepoprawna koncepcja dotyczy definicji wszystkich pól tabeli. Nie ma wymogu, aby wszystkie kolumny w tabeli były oznaczone jako NOT NULL; zależy to od specyficznych wymagań dotyczących danych w danej aplikacji. Ponadto, definicja wszystkich pól typu numerycznego jako NOT NULL również jest fałszywa, ponieważ pola numeryczne mogą być używane do reprezentacji wartości, które mogą być nieznane lub nieprzydzielone, co prowadziłoby do sytuacji, w której wartość NULL jest jak najbardziej uzasadniona. Zrozumienie tych różnic jest kluczowe dla efektywnego projektowania baz danych oraz zarządzania danymi w aplikacjach, co jest zgodne z najlepszymi praktykami w branży.

Pytanie 32

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

A. CONSTRAINT fk_osoba_uczen FOREIGN KEY ON(nazwisko, imie) REFERENCES osoby (nazwisko, imie)

B. CONSTRAINT (nazwisko, imie) FOREIGN KEY REFERENCES osoby (nazwisko, imie)

C. CONSTRAINT (nazwisko, imie) FOREIGN REFERENCES KEY osoby (nazwisko, imie)

D. CONSTRAINT fk_osoba_uczen FOREIGN KEY(nazwisko, imie) REFERENCES osoby (nazwisko, imie)

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

Pytanie 33

Pojęcie krotka odpowiada

A. kolumnie

B. wierszowi

C. tabeli

D. relacji

Krotka to struktura danych, która reprezentuje pojedynczy wiersz w tabeli relacyjnej. W kontekście baz danych krotka składa się z zestawu wartości, z których każda odpowiada kolumnie w tej tabeli. Przykładowo, w przypadku tabeli 'Użytkownicy', krotka może zawierać informacje o jednym użytkowniku, takie jak imię, nazwisko, adres e-mail i data rejestracji. Używanie krotek w bazach danych jest zgodne z koncepcją relacyjnych baz danych, gdzie dane organizowane są w tabelach, a każda krotka jest unikalnym wpisem. W praktyce programiści często korzystają z krotek w językach programowania, takich jak Python, gdzie krotki są używane do grupowania danych, które nie powinny być modyfikowane. Dzięki zastosowaniu krotek zwiększa się czytelność kodu i ułatwia jego zarządzanie. W kontekście standardów, krotki odzwierciedlają zasady normalizacji danych, co jest kluczowe dla utrzymania integralności oraz spójności danych w bazach.

Pytanie 34

Czy automatyczna weryfikacja właściciela witryny dostępnej przez protokół HTTPS jest możliwa dzięki

A. informacjom kontaktowym na stronie

B. danym whois

C. kluczom prywatnym

D. certyfikatowi SSL

Wybór niepoprawnych odpowiedzi można wytłumaczyć poprzez zrozumienie, jak działa weryfikacja właściciela strony internetowej. Dane kontaktowe na stronie mogą być przydatne dla użytkowników, ale nie mają one żadnego wpływu na automatyczną weryfikację tożsamości właściciela domeny przez protokół HTTPS. Oferowanie takich danych może zwiększyć zaufanie użytkowników, jednak nie jest to standardowy sposób potwierdzania tożsamości. Klucze prywatne są elementem kryptografii używanym w procesie szyfrowania danych, ale same w sobie nie służą do weryfikacji właściciela strony. Klucz prywatny jest używany do podpisywania cyfrowego certyfikatu, a jego posiadanie przez właściciela witryny jest jednym z warunków uzyskania certyfikatu SSL, ale nie zastępuje automatycznej weryfikacji. Dane whois, chociaż mogą zawierać informacje o właścicielu domeny, są publicznie dostępne i nie są używane w procesie weryfikacji HTTPS. Właściciele stron mogą zarejestrować swoje domeny z fikcyjnymi danymi kontaktowymi, co czyni je mało wiarygodnym źródłem informacji o rzeczywistym właścicielu. Dlatego wszystkie te odpowiedzi nie są związane z procesem automatycznej weryfikacji, który opiera się na certyfikatach SSL.

Pytanie 35

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

A. SQLite

B. MySQL Workbench

C. pgAdmin

D. phpMyAdmin

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

Pytanie 36

W przypadku uszkodzenia serwera bazy danych, aby jak najszybciej przywrócić pełną funkcjonalność bazy danych, należy skorzystać z

A. opisów struktur danych w tabelach.

B. kompletnej listy użytkowników serwera.

C. najnowszej wersji instalacyjnej serwera.

D. aktualnej wersji kopii zapasowej.

Wybór najnowszej wersji instalacyjnej serwera jako odpowiedzi na problem z uszkodzeniem bazy danych może prowadzić do poważnych nieporozumień. Instalacja nowej wersji oprogramowania nie rozwiązuje problemu utraty danych ani nie przywraca ich integralności. Nawet jeśli instalacja najnowszej wersji może wprowadzić nowe funkcjonalności oraz poprawki błędów, to w kontekście odzyskiwania danych jest to podejście niewłaściwe. Z kolei pełna lista użytkowników serwera, choć może być pomocna w zarządzaniu dostępem, nie ma nic wspólnego z procesem przywracania danych po awarii. Kluczowym elementem odzyskiwania danych jest sama zawartość bazy, a nie jej struktura użytkowników. Natomiast opis struktur danych w tabelach również jest nieprzydatny w sytuacji, gdy celem jest przywrócenie aktualnych danych do bazy. Takie myślenie może prowadzić do błędnych założeń, że znajomość struktury bazy danych wystarczy do jej odtworzenia, co jest dalekie od rzeczywistości. W praktyce, aby skutecznie przywrócić bazę danych, kluczowe jest posiadanie aktualnych kopii zapasowych, które można szybko wykorzystać. Ignorując ten element, ryzykujemy nie tylko utratę danych, ale również wydłużenie czasu przestoju oraz większe koszty związane z naprawą systemu.

Pytanie 37

W której notacji diagramów ER został zapisany model związków encji przedstawiony na ilustracji?

A. Min-Max.

B. Chena.

C. Bachmana.

D. Martina.

Na diagramie przedstawiono model w notacji Martina, a nie w żadnej z pozostałych wymienionych. Warto zrozumieć, czym ta notacja różni się od innych, bo w praktyce projektowania baz danych bardzo łatwo je ze sobą pomylić. Notacja Chena to bardziej „akademickie” podejście do ERD. Encje są zwykle rysowane jako prostokąty, ale atrybuty pojawiają się w osobnych elipsach, połączonych liniami z encją. Klucz główny bywa podkreślony, a związki są reprezentowane przez romby z nazwą relacji. Na naszym diagramie nic takiego nie ma – atrybuty są w środku prostokąta, w formie listy, a nie jako osobne kształty, więc to już mocny sygnał, że to nie jest Chen. Z kolei notacja Bachmana historycznie kojarzy się z modelami sieciowymi i specyficznym sposobem prezentowania struktur danych, często z łamanymi liniami i strzałkami, raczej nie przypomina tabel z nagłówkiem i listą pól. W typowych podręcznikach do systemów baz danych Bachman jest pokazywany jako dość stary styl, dziś mało używany przy klasycznym relacyjnym ERD, więc mało prawdopodobne, by tak wyglądał nowoczesny diagram klient–zakup–towar. Odpowiedź Min-Max jest też myląca, bo Min-Max nie jest nazwiskiem autora notacji, tylko sposobem zapisu krotności relacji, np. (0,1), (1,n). Można taki zapis wykorzystać zarówno z notacją Chena, jak i z innymi, ale sam diagram z obrazka nie używa jawnego oznaczenia min/max przy relacjach – widzimy crow’s foot, czyli styl typowy dla Martina. Typowy błąd w tego typu pytaniach polega na tym, że ktoś kojarzy jeden detal, np. gdzieś widział oznaczenia min-max, i automatycznie zakłada, że każda notacja z relacjami i krotnościami to „Min-Max”. Tutaj jednak kluczowe są kształty encji i sposób zapisu atrybutów: prostokąt z nagłówkiem i lista pól jak w tabeli, bez elips i rombów, bez dodatkowych znaczników kluczy – to bardzo klasyczny, praktyczny styl używany przy projektowaniu relacyjnych baz danych, właśnie w notacji Martina. Dobrze jest więc patrzeć na diagram całościowo, a nie tylko na pojedynczy symbol, bo wtedy łatwiej uniknąć takich pomyłek.

Pytanie 38

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. nazwę odzyskiwanej tabeli.

B. liczbę importowanych obiektów bazy.

C. adres IP bazy danych.

D. nazwę użytkownika.

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 39

Użytkownik Jan będzie miał możliwość realizacji

GRANT ALL PRIVILEGES ON dane.* TO 'Jan'@'localhost';

A. wszystkie operacje na tabelach bazy dane oraz przekazywać prawa innym użytkownikom

B. wyłącznie operacje CREATE, ALTER, DROP na tabelach w bazie dane

C. tylko operacje manipulacji danymi oraz zmienić jedynie swoje uprawnienia

D. wszystkie operacje na tabelach w bazie dane

Niepoprawne odpowiedzi wynikają z nieporozumień dotyczących zakresu uprawnień, jakie mogą być przyznane użytkownikom w systemie baz danych. Ograniczanie możliwości Jan do jedynie operacji CREATE, ALTER, DROP na tabelach bazy danych jest błędne, ponieważ przyznanie ALL PRIVILEGES pozwala na znacznie szerszy zakres operacji, w tym manipulację danymi poprzez SELECT i INSERT. Warto zauważyć, że w kontekście baz danych, operacje związane z manipulowaniem danymi są kluczowe dla prawidłowego funkcjonowania aplikacji i utrzymania integralności danych. Twierdzenie, że Jan miałby jedynie możliwość zmiany własnych praw, jest również mylne, ponieważ uprawnienia ALL PRIVILEGES dają użytkownikowi kontrolę nad wszystkimi tabelami oraz możliwość nadawania uprawnień innym użytkownikom. Koncepcja ograniczenia uprawnień do jedynie manipulacji danymi nie uwzględnia pełnego potencjału, jaki niesie ze sobą przyznanie ALL PRIVILEGES, co prowadzi do nieefektywnego zarządzania bazą danych. Zrozumienie, jak działają uprawnienia w systemach baz danych, jest kluczowe dla bezpieczeństwa i prawidłowego zarządzania danymi, dlatego konieczne jest, aby administratorzy baz danych dokładnie analizowali zasady, według których przyznają uprawnienia użytkownikom.

Pytanie 40

Formularze do zarządzania bazami danych są tworzone w celu

A. łatwiejszego wprowadzania, edytowania oraz usuwania danych

B. tworzenia powiązań w relacyjnych bazach danych

C. generowania raportów z danych

D. wyszukiwania rekordów spełniających określone kryteria

Wiele osób może pomylić rolę formularzy w codziennej pracy z bazami danych, koncentrując się na ich potencjalnych zastosowaniach do wyszukiwania danych, raportowania czy wprowadzania powiązań relacyjnych. Wyszukiwanie wierszy spełniających dane kryteria jest procesem, który zazwyczaj wiąże się z używaniem kwerend SQL, a nie bezpośrednio z formularzami. Formularze nie mają na celu zastępowania tego procesu, lecz oferują przyjazny interfejs do interakcji z danymi, co może być mylnie interpretowane jako ich główna funkcja. Podobnie, raportowanie danych odbywa się zazwyczaj na poziomie analizy danych, a nie za pomocą formularzy, które są narzędziem do manipulacji danymi. Wprowadzenie powiązań w relacyjnych bazach danych dotyczy strukturalnego projektowania bazy, co jest odrębnym zagadnieniem od funkcji formularzy. Te błędne zrozumienia mogą prowadzić do nieefektywnego korzystania z systemów baz danych oraz frustracji użytkowników, którzy nie potrafią w pełni wykorzystać możliwości, jakie oferują formularze. Kluczowe jest zrozumienie, że formularze są narzędziem wspierającym zarządzanie danymi, a nie ich analizę czy strukturalne projektowanie, co powinno być podstawą każdej pracy z bazami danych.

Rozpocznij nowy egzamin

Powrót do strony głównej