Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik informatyk
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 23 kwietnia 2026 14:17
Data zakończenia: 23 kwietnia 2026 14:33

Egzamin niezdany

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

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

A. kluczom prywatnym

B. danym whois

C. certyfikatowi SSL

D. informacjom kontaktowym na stronie

Automatyczna weryfikacja właściciela strony udostępnianej przez protokół HTTPS jest możliwa dzięki certyfikatowi SSL, który jest kluczowym elementem infrastruktury bezpieczeństwa w sieci. Certyfikat SSL (Secure Socket Layer) to dokument cyfrowy, który potwierdza tożsamość właściciela witryny oraz umożliwia szyfrowanie danych przesyłanych pomiędzy przeglądarką użytkownika a serwerem. W procesie weryfikacji certyfikatu, przeglądarka internetowa kontaktuje się z odpowiednim urzędem certyfikacji (CA), który wystawił dany certyfikat, w celu potwierdzenia, że certyfikat jest ważny oraz że podany w nim adres URL rzeczywiście należy do określonego właściciela. Przykładowe zastosowanie certyfikatów SSL obejmuje e-commerce, gdzie ochrona danych osobowych i transakcji jest kluczowa. Standardy takie jak X.509 określają format certyfikatów SSL, a ich zastosowanie zapewnia użytkownikom bezpieczniejsze przeglądanie stron internetowych. W kontekście SEO, posiadanie certyfikatu SSL jest również korzystne, gdyż wyszukiwarki, takie jak Google, preferują strony zabezpieczone HTTPS, co wpływa na ich pozycjonowanie.

Pytanie 2

Po wydaniu polecenia użytkownik Jacek będzie mógł

GRANT SELECT, INSERT ON baza1.mojaTabela TO 'Jacek'@'localhost';

A. zmieniać strukturę tabeli i wstawiać nowe dane.

B. usuwać tabelę i tworzyć nową.

C. przeglądać dane w tabeli i wstawiać nowe dane.

D. usuwać dane z tabeli i przeglądać dane.

Twoja odpowiedź jest poprawna. Użytkownik Jacek po wydaniu polecenia SQL 'GRANT SELECT, INSERT ON baza1.mojaTabela TO 'Jacek'@'localhost';' zyskuje możliwość przeglądania (SELECT) oraz wstawiania (INSERT) danych do tabeli 'mojaTabela' znajdującej się w bazie danych 'baza1'. Jest to zgodne ze standardami SQL i dobrymi praktykami zarządzania uprawnieniami w systemach baz danych. Uprawnienie SELECT pozwala na odczyt danych z tabeli, co jest niezbędne do analizy danych, a uprawnienie INSERT umożliwia dodawanie nowych rekordów do tabeli, co jest kluczowe dla utrzymywania aktualności danych. Pamiętaj, że kontrola dostępu do danych jest kluczowym elementem zarządzania bazami danych, zarówno pod względem bezpieczeństwa, jak i zgodności z regulacjami prawnymi.

Pytanie 3

Które z poniższych stwierdzeń dotyczących klucza głównego jest poprawne?

A. Jest unikalny w obrębie tabeli

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

C. Może przyjmować tylko wartości numeryczne

D. W tabeli z danymi osobowymi może to być pole z nazwiskiem

Klucz podstawowy to atrybut lub zestaw atrybutów, który jednoznacznie identyfikuje każdy rekord w tabeli bazy danych. Najważniejszym wymogiem jest, aby klucz podstawowy był unikalny dla każdego wiersza, co oznacza, że nie może być powtórzony w obrębie tej samej tabeli. Przykładem może być numer identyfikacyjny (np. PESEL, NIP) przypisany do konkretnej osoby, który gwarantuje, że każda osoba w tabeli danych osobowych jest jednoznacznie identyfikowalna. Stosowanie kluczy podstawowych jest zgodne z zasadami normalizacji baz danych, co pozwala na minimalizację redundancji danych oraz poprawę integralności danych. Klucz podstawowy może składać się z jednego lub więcej pól, co daje elastyczność w projektowaniu bazy danych, aby pasowała do specyficznych potrzeb aplikacji. Dobre praktyki wskazują, że klucz podstawowy powinien być stabilny, czyli nie zmieniać się w czasie, oraz prosty do zaimplementowania i używania w zapytaniach SQL.

Pytanie 4

Jak nazywa się metoda udostępniania bazy danych w programie Microsoft Access, która dotyczy wszystkich obiektów bazy umieszczonych na dysku sieciowym i wykorzystywanych jednocześnie przez kilku użytkowników?

A. witryny programu SharePoint

B. folderu sieciowego

C. serwera bazy danych

D. dzielonej bazy danych

Odpowiedzi, które wskazują na "serwera bazy danych", "dzielonej bazy danych" lub "witryny programu SharePoint", nie są adekwatne w kontekście udostępniania bazy danych w Microsoft Access. Serwer bazy danych to złożony system, który zarządza dużymi zbiorami danych oraz zapewnia ich integralność i bezpieczeństwo, jednak w przypadku Microsoft Access, który jest narzędziem bazodanowym bardziej skomplikowanym niż prostsze rozwiązania, udostępnianie odbywa się głównie za pośrednictwem folderów sieciowych. Dzielona baza danych oznacza, że baza danych jest podzielona na dwie części: jedną na serwerze (backend) i drugą lokalnie na komputerach użytkowników (frontend). Pomimo że ta konstrukcja może być stosowana do zwiększenia wydajności, nie odnosi się bezpośrednio do koncepcji folderu sieciowego jako metody udostępniania. Witryna programu SharePoint jest platformą do współpracy, która pozwala na zarządzanie dokumentami i danymi w chmurze, ale nie jest bezpośrednio związana z mechanizmem udostępniania bazy danych w Microsoft Access. Zrozumienie różnic między tymi podejściami jest kluczowe, ponieważ często prowadzi to do mylnych wniosków dotyczących rozwiązań technologicznych oraz ich zastosowania w praktyce. W kontekście Access, praktyka umieszczania bazy danych w folderze sieciowym jest standardem branżowym, który zwiększa dostępność i ułatwia współpracę w zespole.

Pytanie 5

Przy użyciu polecenia ALTER TABLE można

A. tworzyć nową tabelę

B. usuwać tabelę

C. zmieniać wartości zapisane w rekordach tabeli

D. zmieniać strukturę tabeli

Polecenie ALTER TABLE jest kluczowym narzędziem w zarządzaniu bazami danych, pozwalającym na modyfikację struktury istniejących tabel. Umożliwia m.in. dodawanie, usuwanie lub modyfikowanie kolumn, a także zmianę ich typów danych. Na przykład, aby dodać nową kolumnę do tabeli, można użyć polecenia: ALTER TABLE nazwa_tabeli ADD nowa_kolumna typ_danych. W praktyce, ALTER TABLE jest niezbędne w przypadku zmiany wymagań aplikacji, które mogą wymagać dostosowania struktury bazy danych. Zmiany strukturalne powinny być przeprowadzane zgodnie z zasadami normalizacji, co zapewnia optymalizację bazy danych oraz zapobiega redundancji danych. Kluczowe jest również testowanie wprowadzonych zmian w środowisku testowym przed ich wdrożeniem w produkcji, co jest zgodne z najlepszymi praktykami w inżynierii oprogramowania. Warto również pamiętać, że podczas modyfikacji struktury tabeli, odpowiednie zrozumienie relacji między tabelami jest istotne dla zachowania integralności danych.

Pytanie 6

Tabele: Studenci, Zapisy, Zajecia są powiązane relacją. Aby wybrać jedynie nazwiska studentów oraz odpowiadające im idZajecia dla studentów z grupy 15, należy wydać kwerendę

A. SELECT nazwisko, idZajecia FROM Studenci INNER JOIN Zapisy WHERE grupa= 15;

B. SELECT nazwisko, idZajecia FROM Studenci INNER JOIN Zapisy ON Studenci.id = Zapisy.idStudenta;

C. SELECT nazwisko, idZajecia FROM Studenci JOIN Zapisy ON Studenci.id = Zapisy.idStudenta WHERE grupa = 15;

D. SELECT nazwisko, idZajecia FROM Studenci JOIN Zapisy ON Studenci.id = Zapisy.idZajecia WHERE grupa = 15;

Pierwszym istotnym problemem w niepoprawnych zapytaniach jest brak prawidłowego połączenia tabel na właściwych kluczach. W relacyjnych bazach danych, aby sensownie połączyć dane z różnych tabel, należy wykorzystać klucze główne i obce, które jasno definiują powiązania między obiektami. Jeśli zapomni się o warunku JOIN albo połączy się tabele po błędnych kolumnach (na przykład próbując połączyć idStudenta z idZajecia lub pomijając warunek ON), baza zwróci błędne wyniki lub wręcz nie pozwoli wykonać zapytania. To typowy błąd początkujących, którzy nie zawsze rozumieją, jak bardzo ważne jest precyzyjne określenie relacji – w rzeczywistych bazach danych relacji jest wiele, a niewłaściwe powiązanie może prowadzić do powstawania kartuzjańskiego iloczynu, czyli powielania danych bez rzeczywistego sensu. Brak filtru WHERE grupa = 15 skutkuje wyciągnięciem danych dla wszystkich studentów, co może być ogromnym problemem przy dużych bazach i całkowicie rozmija się z celem kwerendy. Moim zdaniem, wiele osób zapomina, że filtrowanie to podstawa – bez tego, szczególnie przy produkcyjnych bazach, można zarówno błędnie interpretować wyniki, jak i mocno przeciążyć system niepotrzebnym ruchem. Takie błędy wynikają często z braku systematycznego podejścia do projektowania zapytań i nieuważnego czytania struktury tabel. Warto od razu przyzwyczajać się do pracy zgodnie z konwencjami, bo to przekłada się na bezpieczeństwo, wydajność i poprawność działania całego systemu. W praktyce – nawet drobny błąd w składni JOIN lub brak filtrowania na kluczowej kolumnie może wywołać lawinę problemów, zwłaszcza gdy kwerenda staje się częścią większej aplikacji biznesowej lub raportu dla zarządu.

Pytanie 7

Fragment tabeli gory prezentuje polskie łańcuchy górskie oraz ich najwyższe szczyty. Przedstaw kwerendę, która oblicza średnią wysokość szczytów dla każdego łańcucha górskiego.

Id	pasmo	nazwa	wysokosc
134	Góry Bystrzyckie	(brak nazwy)	949
137	Góry Bystrzyckie	Anielska Kopa	871
74	Beskid Żywiecki	Babia Góra (Diablak)	1725
41	Beskid Śląski	Barania Góra	1220
145	Góry Karczewskie	Baraniec	723
128	Góry Bardzkie	Bardzka Góra (Kalwaria)	583
297	Tatry	Beskid	2012

A. SELECT pasmo, AVG(wysokosc) FROM gory GROUP BY pasmo

B. SELECT pasmo, AVG(wysokosc) FROM gory LIMIT pasmo

C. SELECT pasmo, SUM(wysokosc) FROM gory GROUP BY pasmo

D. SELECT pasmo, COUNT(wysokosc) FROM gory ORDER BY pasmo

Błędne odpowiedzi wynikają z nieprawidłowego zrozumienia, jak działa grupowanie i agregacja danych w SQL. Odpowiedź SELECT pasmo, AVG(wysokosc) FROM gory LIMIT pasmo nie jest poprawna, ponieważ klauzula LIMIT służy do ograniczenia liczby wyników zwracanych przez zapytanie, a nie do grupowania danych według pasma. Zastosowanie LIMIT pasmo prowadzi do błędu składniowego, gdyż LIMIT oczekuje liczby całkowitej, która określa maksymalną liczbę rekordów do zwrócenia. Odpowiedź SELECT pasmo, SUM(wysokosc) FROM gory GROUP BY pasmo chociaż poprawnie używa klauzuli GROUP BY, liczy sumę wysokości, a nie średnią, co jest niezgodne z treścią pytania. SUM() zlicza całkowitą wysokość szczytów w każdym paśmie, co nie odpowiada na pytanie o średnią wysokość. Odpowiedź SELECT pasmo, COUNT(wysokosc) FROM gory ORDER BY pasmo liczy ilość szczytów w każdym paśmie, co znowu mija się z celem pytania, które dotyczy średniej wysokości. COUNT() używa się do zliczania liczby niepustych rekordów w danej kolumnie, a ORDER BY po prostu sortuje wynik według wartości pasmo. Zrozumienie roli i funkcji każdej z klauzul SQL oraz ich połączenia jest kluczowe w dokładnym przetwarzaniu i interpretacji danych w kontekście analitycznym i raportowym. Tego typu błędy wynikają często z pomylenia funkcji agregujących lub niepełnego zrozumienia mechaniki SQL, co może prowadzić do błędnych wniosków w analizie danych.

Pytanie 8

W hurtowni utworzono tabelę sprzedaż, która zawiera pola: id, kontrahent, grupa_cenowa oraz obrot. Jakie polecenie należy wykorzystać, aby znaleźć tylko kontrahentów z drugiej grupy cenowej, których obrót przekracza 4000 zł?

A. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa=2 OR obrot>4000

B. SELECT sprzedaz FROM kontrahent WHERE obrot>4000

C. SELECT sprzedaz FROM kontrahent WHERE grupa_cenowa=2 AND obrot>4000

D. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa=2 AND obrot>4000

W analizowanych odpowiedziach znajdują się elementy, które nie spełniają wymogów stawianych przez zapytanie o kontrahentów z drugiej grupy cenowej i obrotem powyżej 4000 zł. W pierwszym przypadku, zapytanie używa niewłaściwej konstrukcji, ponieważ polecenie 'SELECT sprzedaz FROM kontrahent WHERE obrot>4000;' odnosi się do błędnych tabel i kolumn, wprowadzając zamieszanie. Użycie 'FROM kontrahent' zamiast 'FROM sprzedaz' wskazuje na nieprawidłowe zrozumienie struktury bazy danych. Kolejny błąd polega na zastosowaniu operatora OR w jednym z zapytań, co prowadzi do zwrócenia wszystkich kontrahentów, którzy mają obrót większy niż 4000 zł, niezależnie od grupy cenowej. W kontekście wymagań pytania, taki zabieg nie jest wystarczający, ponieważ nie segreguje wyników według grupy cenowej, co może skutkować uzyskaniem niepożądanych danych. W ostatniej niepoprawnej odpowiedzi także występuje mylna konstrukcja, ponieważ 'SELECT sprzedaz FROM kontrahent WHERE grupa_cenowa=2 AND obrot>4000;' błędnie wskazuje na tabele i kolumny, co jest niezgodne z zasadami normalizacji baz danych. Zastosowanie niewłaściwych aliasów i odniesień do tabel uniemożliwia skuteczne wykonanie zapytania i analizę danych.

Pytanie 9

Podany fragment kodu PHP ma na celu wstawienie wartości z zmiennych $a, $b, $c do bazy danych, w tabeli dane. Tabela ta składa się z czterech kolumn, z których pierwsza to autoinkrementowany klucz podstawowy. Które z zapytań powinno być przypisane do zmiennej $zapytanie? ``````

A. ```SELECT '$a', '$b', '$c' FROM dane;```

B. ```INSERT INTO dane VALUES (NULL, '$a', '$b', '$c');```

C. ```SELECT NULL, '$a', '$b', '$c' FROM dane;```

D. ```INSERT INTO dane VALUES ('$a', '$b', '$c');```

Odpowiedzi, które zaczynają się od polecenia SELECT, są błędne, ponieważ nie mają na celu wstawienia nowych danych do tabeli. SELECT jest używane do pobierania danych z bazy danych, a nie do ich dodawania. Polecenie "SELECT '$a', '$b', '$c' FROM dane;" jedynie wyciąga dane, nie wprowadza żadnych zmian w tabeli, co nie spełnia wymagań zadania. Również "SELECT NULL, '$a', '$b', '$c' FROM dane;" działa podobnie, wciąż pozostając w zakresie odczytu danych, a nie ich dodawania. Dwa pierwsze polecenia nie tylko nie są związane z wstawianiem danych, ale również mogą wprowadzać użytkownika w błąd, sugerując, że ich celem jest modyfikacja bazy. Kolejna odpowiedź "INSERT INTO dane VALUES ('$a', '$b', '$c');" jest błędna, ponieważ nie uwzględnia klucza głównego, który powinien być autoinkrementowany. Przekazanie NULL jako pierwszego argumentu jest kluczowe, ponieważ pozwala bazie danych na zarządzanie identyfikatorem. Typowe błędy myślowe obejmują pomylenie operacji wstawiania z operacjami odczytu oraz nieprawidłowe przypuszczenie, że można pominąć kolumny kluczy głównych w zapytaniach wstawiających.

Pytanie 10

Efektem wykonania kwerendy dla przedstawionej tabeli rezerwacje jest

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

id_pok	liczba_dn	sezon
1	10	lato
2	4	zima
1	5	lato
2	6	zima
1	5	lato
3	9	zima
1	8	zima

A. lato 3, zima 4

B. lato 10, 5, 5; zima 4, 6, 9, 8

C. lato 10, zima 4, lato 5, zima 6, lato 5, zima 9, zima 8

D. lato 20, zima 27

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

Pytanie 11

W tabeli podzespoly należy zaktualizować wartość pola URL na 'toshiba.pl' dla wszystkich rekordów, gdzie pole producent to TOSHIBA. W języku SQL ta zmiana będzie wyglądała następująco

A. UPDATE producent='TOSHIBA' SET URL='toshiba.pl';

B. UPDATE podzespoly SET URL='toshiba.pl';

C. UPDATE podzespoly.producent='TOSHIBA' SET URL='toshiba.pl';

D. UPDATE podzespoly SET URL='toshiba.pl' WHERE producent='TOSHIBA';

W analizowanych odpowiedziach występuje szereg błędów w zakresie składni SQL oraz koncepcji użycia klauzuli UPDATE. W pierwszej z niepoprawnych odpowiedzi brak jest warunku WHERE, co skutkuje aktualizacją URL dla wszystkich rekordów w tabeli 'podzespoly', co może prowadzić do niepożądanych zmian w bazie danych. Przy podejmowaniu decyzji o modyfikacji danych, klauzula WHERE jest kluczowa dla ograniczenia zakresu aktualizacji tylko do tych rekordów, które spełniają określone kryteria. Dodatkowo, w kolejnej odpowiedzi zastosowanie składni UPDATE producent='TOSHIBA' SET URL='toshiba.pl'; jest błędne, ponieważ nie reprezentuje ona poprawnej sekwencji SQL. W SQL nie można używać operatora równości bezpośrednio w kontekście instrukcji UPDATE. Ponadto, ostatnia odpowiedź również myli koncepcję, ponieważ sugeruje aktualizację na poziomie producenta, a nie rekordu w tabeli podzespoly. Stosowanie niewłaściwej składni oraz brak zrozumienia kontekstu aktualizacji prowadzi do poważnych błędów w pracy z bazami danych. Kluczowym błędem myślowym jest brak uznania, że każda operacja na bazie danych powinna być przemyślana pod kątem jej wpływu na integralność i spójność danych.

Pytanie 12

W SQL komenda ALTER TABLE ma na celu

A. zmianę kolumn w tabeli

B. usunięcie tabeli z bazy danych

C. dodanie tabeli do bazy danych

D. zmianę danych rekordów w tabeli

Polecenie ALTER TABLE w języku SQL jest kluczowym narzędziem do modyfikacji struktury istniejących tabel w bazie danych. Umożliwia ono dodawanie, usuwanie lub modyfikowanie kolumn oraz zmianę właściwości istniejących kolumn, takich jak typ danych, domyślne wartości czy ograniczenia. Przykładem użycia polecenia ALTER TABLE może być dodawanie nowej kolumny do tabeli: 'ALTER TABLE nazwa_tabeli ADD nowa_kolumna VARCHAR(255);', co dodaje kolumnę o nazwie 'nowa_kolumna' z typem danych VARCHAR i maksymalną długością 255 znaków. Można również usunąć kolumnę, używając składni: 'ALTER TABLE nazwa_tabeli DROP COLUMN kolumna;'. Ważnym aspektem jest to, że zmiany wprowadzone przez ALTER TABLE są natychmiastowe i dotyczą wszystkich przyszłych operacji na tabeli. Standard SQL definiuje to polecenie jako część DDL (Data Definition Language), co oznacza, że zmienia strukturę bazy danych, a nie dane same w sobie. Warto pamiętać o tym, że operacje te mogą powodować blokady tabel i wpływać na wydajność, zwłaszcza w przypadku dużych zbiorów danych.

Pytanie 13

Jakim poleceniem SQL można zlikwidować z tabeli artykuly wiersze, które zawierają słowo "sto" w dowolnej lokalizacji pola tresc?

A. DELETE FROM artykuly WHERE tresc = "%sto%"

B. DELETE FROM artykuly WHERE tresc LIKE "%sto%"

C. DELETE * FROM artykuly WHERE tresc = "%sto%"

D. DELETE * FROM artykuly WHERE tresc LIKE "%sto%"

Wybór odpowiedzi "DELETE * FROM artykuly WHERE tresc = '%sto%';" jest po prostu zły z paru powodów. Po pierwsze, w SQL nie używamy znaku '*' przy DELETE. Jak chcemy usunąć wiersze, to piszemy tylko "DELETE FROM nazwa_tabeli". To '*' sugeruje, że chcesz usunąć jakieś konkretne kolumny, a to w SQL się nie sprawdzi. Druga sprawa to operator '=' zamiast 'LIKE'. '=' używamy do porównania wartości, nie do wyszukiwania wzorców, a tu właśnie szukamy wystąpienia słowa 'sto' w dłuższym tekście. Dlatego operator LIKE z wildcardami jest tu konieczny, by znaleźć i usunąć te wiersze, które mają 'sto' gdziekolwiek. Często ludzie mylą te operatory w SQL, co prowadzi do problemów i nieefektywnego wyszukiwania.

Pytanie 14

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 szkola FROM klasa=klasa+1 WHERE klasa >=1 AND klasa <=5

B. UPDATE nazwisko, imie SET klasa=klasa+1 WHERE klasa>1 OR klasa<5

C. SELECT nazwisko, imie FROM 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 15

Czym jest relacja w bazach danych?

A. kluczem podstawowym w relacji tabel

B. połączeniem dwóch pól jednej tabeli

C. algebraicznym powiązaniem tabel

D. logicznym powiązaniem tabel

Relacje w bazach danych to coś w rodzaju logicznego połączenia tabel. Dzięki nim możemy łączyć dane z różnych miejsc w sposób, który pozwala na bardziej zaawansowane zapytania. Na przykład, w bazie danych do zarządzania zamówieniami, mamy tabelę 'Klienci' i tabelę 'Zamówienia'. I wiesz co? Relacja między nimi często opiera się na identyfikatorze klienta, który działa jak klucz główny w 'Klienci', a jednocześnie jest kluczem obcym w 'Zamówienia'. To ułatwia życie, bo w ten sposób szybko możemy znaleźć wszystkie zamówienia danego klienta. W praktyce, tworzenie relacyjnych baz danych wiąże się też z takimi zasadami jak normalizacja, która pomaga unikać powtarzania danych i dba o ich integralność. Więc tak, zrozumienie relacji w bazach danych to podstawa, jeśli chcemy tworzyć fajne i działające systemy.

Pytanie 16

Jaki jest cel funkcji napisanej w PHP?

$zapytanie = mysql_query("SELECT * FROM napisy");

A. uzyskanie danych z bazy danych

B. nawiązanie połączenia z bazą danych

C. zmianę hasła do bazy danych

D. ochronę bazy danych

Podana funkcja w języku PHP demonstruje zastosowanie polecenia SQL SELECT które jest używane do pobierania danych z bazy danych MySQL. Funkcja mysql_query jest używana do wykonywania zapytań SQL w kontekście bazy danych MySQL. W tym przypadku zapytanie SQL SELECT * FROM napisy pobiera wszystkie rekordy z tabeli o nazwie napisy. W praktyce wybór danych przy użyciu komendy SELECT jest kluczowy w aplikacjach PHP które działają z bazami danych ponieważ pozwala na dynamiczne generowanie zawartości strony internetowej w oparciu o informacje przechowywane w bazie. Ważne jest przestrzeganie najlepszych praktyk takich jak użycie funkcji mysqli_query czy PDO w nowych aplikacjach PHP w celu zapewnienia bezpieczeństwa i wydajności ponieważ mysql_query jest przestarzałe. Dodatkowo należy stosować techniki zabezpieczające przed SQL injection takie jak przygotowane zapytania co zwiększa bezpieczeństwo aplikacji

Pytanie 17

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

A. DROP pracownicy FROM rodzaj_umowy = 0

B. DELETE pracownicy WHERE rodzaj_umowy ='brak'

C. DROP pracownicy WHERE rodzaj_umowy IS NULL

D. DELETE FROM pracownicy WHERE rodzaj_umowy IS NULL

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

Pytanie 18

Wykonanie zapytania SQL spowoduje skasowanie

DELETE FROM mieszkania WHERE status = 1;

A. rekordów, w których wartość pola status jest równa 1, z tabeli mieszkania

B. tabeli mieszkania znajdującej się w bazie danych

C. elementów o nazwie status z tabeli mieszkania

D. tabel, w których wartość pola status wynosi 1, z bazy danych mieszkania

Wskazanie, że kwerenda SQL usunie tabele, pola lub całą tabelę, jest niepoprawne i opiera się na nieporozumieniach dotyczących struktury zapytań SQL. Składnia SQL rozróżnia operacje na poziomie tabel, kolumn i rekordów. W przypadku zapytania DELETE, operacja dotyczy zawsze rekordów, które spełniają określony warunek, a nie struktur tabeli ani kolumn. Usunięcie tabeli wymagałoby użycia zapytania DROP TABLE, natomiast usunięcie kolumny to operacja ALTER TABLE, a następnie DROP COLUMN. Warto zauważyć, że nie można usunąć pola (kolumny) przy pomocy zapytania DELETE, ponieważ to zapytanie nie działa na poziomie strukturalnym bazy danych, a jedynie na danych. W procesie uczenia się SQL, ważne jest, aby zrozumieć, że każdy typ zapytania ma swoje specyficzne zastosowanie i niepoprawne zrozumienie ich funkcji może prowadzić do poważnych pomyłek. Dlatego kluczowe jest, aby przed przystąpieniem do edycji danych w bazie, zapoznać się z dokumentacją oraz najlepszymi praktykami zarządzania danymi, co pozwala uniknąć niepożądanych skutków.

Pytanie 19

W SQL, aby zabezpieczyć kwerendę CREATE USER przed utworzeniem konta, jeżeli ono już istnieje, należy użyć składni

A. CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

B. CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

C. CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

D. CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

Odpowiedzi takie jak 'CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' są nieprawidłowe, ponieważ nie zawierają mechanizmu do weryfikacji istnienia użytkownika przed jego utworzeniem. W przypadku, gdy konto o nazwie 'anna' już istnieje, wykona się próba utworzenia go ponownie, co skutkuje błędem. Tego typu podejście nie tylko narusza praktyki zarządzania bazami danych, ale również wprowadza potencjalne problemy z bezpieczeństwem, gdyż mogą wystąpić niezamierzone konsekwencje w przypadku nadpisania istniejących uprawnień. Odpowiedź 'CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' także jest błędna, gdyż takiej składni nie definiuje standard SQL. 'CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' myli pojęcie zastępowania użytkownika, gdyż nie zawsze jest to pożądane. Użytkownicy mogą mieć różne uprawnienia, a ich usunięcie lub nadpisanie może prowadzić do problemów z dostępem. Takie myślenie często prowadzi do błędnych założeń, że można swobodnie zarządzać użytkownikami bez przemyślanej strategii, co może skutkować poważnymi lukami w bezpieczeństwie oraz problemami z audytem. Zrozumienie, jak ważne jest stosowanie odpowiednich praktyk przy zarządzaniu kontami użytkowników w bazach danych, jest kluczowe dla zapewnienia ich integralności oraz ochrony danych.

Pytanie 20

Aby ustanowić relację jeden do wielu, w tabeli reprezentującej stronę "wiele", konieczne jest zdefiniowanie

A. klucza obcego odnoszącego się do klucza obcego tabeli po stronie "jeden"

B. klucza obcego wskazującego na klucz podstawowy tabeli po stronie "jeden"

C. klucza sztucznego odnoszącego się do kluczy podstawowych obydwu tabel

D. klucza podstawowego wskazującego na klucz podstawowy tabeli po stronie "jeden"

Definiowanie relacji w bazach danych to dosyć skomplikowana sprawa. Jakby nie patrzeć, jak zrobisz coś źle z kluczami obcymi czy podstawowymi, to mogą być duże problemy z danymi. Klucz sztuczny, który odnosi się do kluczy podstawowych w obu tabelach, może wydawać się prosty, ale nie rozwiązuje faktycznego problemu, którym jest jasna relacja między danymi. To wprowadza dodatkowe zamieszanie, a to nie jest dobra praktyka. Jak zdefiniujesz klucz obcy, który wskazuje na inny klucz obcy w tabeli po stronie 'jeden', no to może być tylko mętlik, bo ciężko wtedy utrzymać spójność danych. Klucz podstawowy, który wskazuje na klucz podstawowy z tabeli po stronie 'jeden', to również zły wybór, bo klucz podstawowy ma być unikalny dla każdej tabeli. Kluczowe jest, żeby klucze obce były używane w odpowiedni sposób, bo inaczej struktura danych robi się nieczytelna i trudna do zarządzania, a to na pewno nie idzie w parze z dobrym projektowaniem baz danych.

Pytanie 21

Jakie zapytanie należy użyć, aby wyświetlić tylko imię, nazwisko oraz ulicę wszystkich mieszkańców?

A. SELECT imie, nazwisko, ulica FROM Mieszkancy JOIN Adresy ON Mieszkancy.Adresy_id = Adresy.id

B. SELECT * FROM Mieszkancy JOIN Adresy ON Adresy.id = Mieszkancy.Adresy.id

C. SELECT imie, nazwisko, ulica FROM Mieszkancy, Adresy ON Mieszkancy.Adresy_id = Adresy.id

D. SELECT * FROM Mieszkancy, Adresy ON Mieszkancy.id = Adresy.id

Próbując wybrać tylko konkretne kolumny z powiązanych tabel, ważne jest, żeby poprawnie zastosować składnię SQL. Jak źle podejdziesz do tego, mogą wyjść niepoprawne wyniki albo zapytanie może działać nieefektywnie. Często takie błędy wynikają z tego, że nie do końca rozumiemy relacje między tabelami. Jeśli użyjesz zapytania SELECT * FROM Mieszkancy Adresy ON Mieszkancy.id = Adresy.id, to poległeś, bo nie podałeś poprawnego typu złączenia, a dodatkowo użycie gwiazdki * zwraca wszystkie kolumny, co jest niezgodne z celem tego pytania. Jeszcze gorzej, jeśli napiszesz SELECT * FROM Mieszkancy JOIN Adresy ON Adresy.id = Mieszkancy.Adresy.id – mimo, że JOIN jest ok, używanie gwiazdki sprawia, że nie spełniasz warunków dotyczących selekcji kolumn. W obu przypadkach brakuje selektywności, przez co zapytania są mało efektywne i niezgodne z dobrymi praktykami w projektowaniu baz danych. Zapytanie SELECT imie nazwisko ulica FROM Mieszkancy Adresy ON Mieszkancy.Adresy_id = Adresy.id, chociaż wymienia dobre kolumny, stosuje błędną składnię JOIN, więc jest syntaktycznie złe. SQL wymaga precyzji przy złączaniu, żeby dane były spójne i integralne. Rozumienie, jak poprawnie używać JOIN i jak wybierać kolumny, jest kluczowe do tworzenia skutecznych zapytań, co wpływa na optymalizację pracy z bazami danych.

Pytanie 22

Na przedstawionej grafice widać fragment bazy danych. Jakie kwerendę należy zastosować, aby uzyskać nazwy produktów zakupionych przez klienta o id = 1?

A. SELECT nazwa FROM produkty JOIN transakcje ON nr_produktu = nr_klienta WHERE nr_klienta = 1

B. SELECT nazwa FROM produkty JOIN transakcje_produkty USING(nr_produktu) JOIN transakcje USING(nr_transakcji) WHERE nr_klienta = 1

C. SELECT nazwa FROM produkty JOIN transakcje_produkty USING(nr_produktu) WHERE nr_klienta = 1

D. SELECT nazwa FROM produkty JOIN transakcje_produkty JOIN transakcje WHERE nr_klienta = 1

Niepoprawne odpowiedzi wynikają z błędnego zrozumienia struktury bazy danych oraz sposobu łączenia tabel. Błędem w połączeniach JOIN jest nieprawidłowe określenie warunków łączenia tabel co prowadzi do niekompletnych lub błędnych wyników. W przypadku bazy danych relacyjnej kluczowe jest aby każda tabela była prawidłowo połączona przez klucz obcy co zapewnia integralność danych. Źle skonstruowane zapytania mogą powodować problemy wydajnościowe jak również zwracać niewłaściwe informacje co jest szczególnie problematyczne w środowisku produkcyjnym. Typowe błędy myślowe obejmują nieprawidłowe zrozumienie pojęcia klucza obcego jako mechanizmu łączącego tabele oraz błędne stosowanie klauzuli WHERE bez uwzględnienia pełnej relacji między tabelami. Również użycie niewłaściwych aliasów czy nieprecyzyjnych warunków może prowadzić do nieoptymalnych zapytań. Dlatego też ważne jest zrozumienie działania JOIN oraz jego wpływu na zapytania SQL aby móc skutecznie projektować systemy bazodanowe które są skalowalne i efektywne w działaniu.

Pytanie 23

Podczas tworzenia formularza konieczne jest dodanie kontrolki, która odnosi się do kontrolki w innym formularzu. Jakie działania w bazie danych Access są w tym przypadku możliwe?

A. niemożliwe we wszystkich trybach z wyjątkiem trybu projektowania.

B. możliwe o ile dotyczą danych liczbowych.

C. niemożliwe.

D. możliwe poprzez określenie ścieżki do kontrolki w atrybucie „Źródło kontrolki”.

Wiesz co, nie zgadza się z prawdą to, że nie możesz umieścić kontrolki, która odnosi się do innej w innym formularzu. Microsoft Access naprawdę ma sporo możliwości w tym zakresie. Często ludzie myślą, że mogą odnosić się tylko do danych liczbowych w innych formularzach, co jest błędnym założeniem. Access obsługuje wszelkie rodzaje danych – teksty, daty, logiczne. I nie ma takiej zasady, że odwołania są niemożliwe w trybie innym niż projektowy. W rzeczywistości Access potrafi dynamicznie aktualizować źródła danych, co jest ważne w zarządzaniu informacjami. Właściwość „Źródło kontrolki” jest elastyczna, co pozwala na wyciąganie danych z różnych źródeł, a to jest kluczowe w optymalizacji baz danych. Niektórzy błędnie myślą, że formularze muszą być sztywno zbudowane, a tak naprawdę powinny być elastyczne, żeby móc dostosować się do potrzeb użytkowników.

Pytanie 24

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

mysql -u ******* -p Sklep < towary.sql

A. liczbę importowanych obiektów bazy.

B. adres IP bazy danych.

C. nazwę użytkownika.

D. nazwę odzyskiwanej tabeli.

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 25

W bibliotece mysqli w PHP, aby uzyskać najbardziej aktualny komunikat o błędzie, można użyć funkcji

A. mysqli_error()

B. mysqli_error_list()

C. mysqli_errno()

D. mysqli_use_result()

W kontekście użycia funkcji do uzyskania komunikatów o błędach w bibliotece mysqli, niektóre z odpowiedzi mogą prowadzić do nieporozumień. Na przykład, mysqli_use_result() jest funkcją, która służy do pobierania zestawu wyników z zapytania SELECT w trybie pamięci. Jej głównym zadaniem jest przetwarzanie wyników, a nie błędów, co czyni ją nieodpowiednią w tym kontekście. Użycie tej funkcji nie zapewnia informacji o błędach, czego można się spodziewać w przypadku zapytań, które mogą zakończyć się niepowodzeniem. Z kolei mysqli_errno() zwraca numer błędu związanego z ostatnią operacją, co może być przydatne, ale samo w sobie nie dostarcza opisu błędu, a tym samym nie spełnia wymagań dotyczących uzyskania ostatniego komunikatu o błędzie w formie tekstowej. Mimo że może być użyteczne w niektórych kontekstach, np. w logice warunkowej, nie jest w stanie dostarczyć pełnego opisu, którego można oczekiwać. Funkcja mysqli_error_list() zwraca tablicę wszystkich błędów związanych z ostatnią operacją, co również jest przydatne w określonych sytuacjach, jednak wciąż nie spełnia wymagań dotyczących prostego i bezpośredniego uzyskania ostatniego komunikatu o błędzie. Ostatecznie, przy wyborze metody obsługi błędów, kluczowe jest zrozumienie, że funkcje te mają różne zastosowania i nie każda z nich będzie odpowiednia w kontekście uzyskania pełnego opisu błędu. Podsumowując, wybór odpowiednich funkcji do obsługi błędów jest kluczowy dla efektywnego debugowania i poprawnego działania aplikacji opartych na PHP.

Pytanie 26

Element lub zestaw elementów, który jednoznacznie identyfikuje każdy pojedynczy rekord w tabeli bazy danych, nazywamy kluczem

A. inkrementacyjny

B. obcy

C. przestawny

D. podstawowy

W kontekście baz danych, istnieje kilka terminów, które mogą być mylące, zwłaszcza w odniesieniu do kluczy. Klucz inkrementacyjny, mimo że jest użyteczny w wielu systemach baz danych do generowania unikalnych identyfikatorów, nie jest terminem opisującym typ klucza, ale raczej metodą tworzenia wartości dla klucza podstawowego. Klucz przestawny (ang. pivot key) to termin bardziej związany z analizą danych niż z identyfikacją wierszy w tabelach; odnosi się do technik agregacji danych i transformacji w zbiorach danych, głównie w kontekście tabel przestawnych, które są używane do wizualizacji i analizy danych, a nie do bezpośredniej identyfikacji rekordów. Klucz obcy (ang. foreign key) to kolejny termin, który jest często mylony z kluczem podstawowym. Klucz obcy jest polem w jednej tabeli, które wskazuje na klucz podstawowy w innej tabeli, co służy do ustanawiania relacji między dwiema tabelami. Klucz obcy nie identyfikuje wierszy w swojej tabeli, lecz tworzy powiązania z innymi danymi. Rozumienie tych terminów oraz ich zastosowań jest kluczowe dla efektywnego projektowania baz danych oraz unikania powszechnych błędów, które mogą prowadzić do problemów z integralnością danych i wydajnością systemu.

Pytanie 27

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

A. SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3

B. SELECT nazwisko FROM klienci LIMIT 3

C. SELECT nazwisko FROM klienci ORDER BY punkty DESC LIMIT 3

D. SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC

Wybór kwerendy SELECT nazwisko FROM klienci ORDER BY punkty DESC LIMIT 3 jest poprawny, ponieważ wykorzystuje klauzulę ORDER BY w celu posortowania wyników na podstawie kolumny 'punkty' w porządku malejącym. Dzięki temu, najpierw wyświetlone zostaną rekordy z najwyższą liczbą punktów. Zastosowanie LIMIT 3 oznacza, że z całej posortowanej listy, wybierane są jedynie trzy rekordy, co idealnie odpowiada wymaganiu znalezienia trzech najlepszych klientów. Takie podejście jest zgodne z dobrymi praktykami w programowaniu SQL, ponieważ pozwala na precyzyjne wydobycie danych z bazy, a także na efektywne zarządzanie wynikami zapytań. Przykład zastosowania to sytuacja, gdy firma chce nagrodzić swoich najlepszych klientów na podstawie ich aktywności, co może przyczynić się do zwiększenia ich lojalności. W kontekście analizy danych, zrozumienie, jak korzystać z klauzul ORDER BY i LIMIT, jest kluczowe dla optymalizacji zapytań oraz interpretacji wyników.

Pytanie 28

Jakie zadanie ma funkcja PHP o nazwie mysql_select_db()?

A. nawiązać połączenie między bazą danych a serwerem SQL

B. uzyskać dane z bazy danych na podstawie zapytania

C. wyznaczyć bazę, z której będą pozyskiwane dane

D. wyznaczyć tabelę, z której będą pozyskiwane dane

Funkcja mysql_select_db() w PHP jest naprawdę ważna, bo pozwala nam wybrać konkretną bazę danych, z której chcemy czerpać informacje. Gdy już nawiążemy połączenie z serwerem MySQL przez mysql_connect(), to pierwsze co powinniśmy zrobić, to wybrać bazę danych, na której będziemy działać. To ważny krok, bo w każdej bazie może być sporo tabel, a nasze zapytania muszą iść do odpowiedniej. Na przykład, jeśli mamy bazę danych 'sklep' i potrzebujemy tabeli 'produkty', to musimy wywołać mysql_select_db('sklep'). Dzięki temu MySQL wie, gdzie szukać naszych tabel i informacji. Z mojego doświadczenia, dobrze jest upewnić się, że wybraliśmy odpowiednią bazę danych przed wykonaniem jakichkolwiek zapytań, bo wtedy unikamy różnych problemów z kontekstem danych.

Pytanie 29

Według którego pola tabeli zostały pogrupowane dane w przedstawionym raporcie?

A. wynik

B. id_uczestnika

C. rok

D. nazwa

Poprawnie wskazano, że dane w raporcie zostały pogrupowane według pola „rok”. Widać to po tym, że poszczególne rekordy są zebrane w bloki oznaczone nagłówkami 2009, 2010, 2011, 2012, 2020, a dopiero pod każdym z tych lat pojawiają się konkretne konkursy, id_uczestnika i wynik. To jest właśnie klasyczny przykład grupowania danych w raporcie po jednym z pól tabeli – w tym przypadku po kolumnie roku. W praktyce, czy to w SQL, czy w kreatorach raportów (np. w MS Access, LibreOffice Base, Crystal Reports, narzędziach BI), gdy projektujemy raport, często definiujemy tzw. sekcję grupującą (group header) opartą na wybranym polu. Tutaj takim polem jest rok, więc każda zmiana wartości roku powoduje rozpoczęcie nowej grupy i wyświetlenie nagłówka z tą wartością. To poprawia czytelność i pozwala łatwo analizować dane w podziale na lata. Moim zdaniem warto zapamiętać, że grupowanie po dacie lub roku to jedna z najczęściej stosowanych praktyk raportowych: używa się tego do raportów sprzedaży w latach, statystyk odwiedzin strony WWW, wyników egzaminów itd. W SQL można by to od strony danych poprzedzić np. zapytaniem sortującym: SELECT * FROM konkursy ORDER BY rok, nazwa; a samo faktyczne grupowanie wizualne realizuje już mechanizm raportów. Dobrą praktyką jest też, żeby pole, po którym grupujemy, było najpierw użyte do sortowania – inaczej grupy mogą się „rozsypać” i raport stanie się nieczytelny.

Pytanie 30

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

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

A. ilość najstarszych uczestników

B. różnicę wieku pomiędzy najstarszym a najmłodszym uczestnikiem

C. średnią wartość wieku uczestników

D. najmłodszy i najstarszy wiek uczestników

Wybór odpowiedzi, która sugeruje, że zapytanie zwraca minimalny oraz maksymalny wiek uczestników, jest błędny, ponieważ zapytanie wykorzystuje operację odejmowania wyników funkcji MAX i MIN. Użyte tutaj funkcje agregujące nie zwracają osobno wartości minimalnej i maksymalnej, a jedynie ich różnicę. Zrozumienie operacji MAX i MIN jest kluczowe; funkcje te są stosowane do obliczeń w celu uzyskania jednej wartości z grupy. Odpowiedź dotycząca średniej arytmetycznej wieku uczestników również jest myląca, ponieważ do obliczenia średniej potrzeba użyć funkcji AVG, a nie różnicy, która jest przedstawiona w zapytaniu. Ostatecznie, wybór opcji dotyczącej liczby najstarszych uczestników nie ma żadnego związku z zapytaniem, ponieważ nie ma w nim mowy o zliczaniu, a jedynie o różnicy wieku. Takie nieporozumienia mogą wynikać z braku jasności co do podstawowych funkcji SQL oraz ich zastosowania w analizie danych. Dlatego kluczowe jest, aby na etapie nauki SQL zwracać szczególną uwagę na kontekst użycia różnych funkcji i ich właściwe zrozumienie, aby uniknąć błędnych interpretacji wyników zapytań.

Pytanie 31

Poziom izolacji transakcji Repeatable Read (tryb powtarzalnego odczytu) używany przez MS SQL jest związany z problemem

A. brudnych odczytów

B. niepowtarzalnych odczytów

C. utraty aktualizacji

D. odczytów widm

Odpowiedź 'odczytów widm' jest właściwa, ponieważ poziom izolacji transakcji Repeatable Read zapobiega brudnym odczytom i niepowtarzalnym odczytom, ale nie rozwiązuje problemu odczytów widm. Odczyty widmowe występują, gdy w czasie trwania transakcji inne transakcje mogą dodać nowe wiersze, które spełniają kryteria zapytania tej transakcji, co prowadzi do sytuacji, w której transakcja widzi różne dane w kolejnych odczytach. W praktyce, implementując poziom izolacji Repeatable Read, aplikacje muszą być świadome tego, że mogą wystąpić takie sytuacje, co może prowadzić do nieprzewidywalnych wyników. Przykładowo, jeśli jedna transakcja odczytuje zestaw danych, a inna transakcja w międzyczasie dodaje nowe rekordy, to podczas kolejnego odczytu pierwsza transakcja może zobaczyć te nowe rekordy, co jest problemem. Z tego powodu standardy i dobre praktyki w projektowaniu aplikacji bazodanowych zalecają używanie bardziej ścisłych poziomów izolacji, takich jak Serializable, kiedy to konieczne, aby uniknąć takich problemów. Warto zwrócić uwagę, że stosowanie odpowiednich poziomów izolacji jest kluczowe dla zapewnienia spójności i integralności danych, co jest niezbędne w większości nowoczesnych aplikacji bazodanowych.

Pytanie 32

W języku SQL zrealizowano polecenia GRANT przedstawione w ramce. Kto uzyska prawo do przeglądania oraz modyfikowania danych?

GRANT ALL ON frmy TO 'adam'@'localhost';
 GRANT ALTER, CREATE, DROP ON frmy TO 'anna'@'localhost';
 GRANT SELECT, INSERT, UPDATE ON frmy TO 'tomasz'@'localhost';

A. Adam oraz Anna

B. Tomasz i Adam

C. Tomasz oraz Anna

D. Jedynie Tomasz

Odpowiedź, że prawo do przeglądania i zmiany danych mają Tomasz i Adam, jest prawidłowa, ponieważ wynikają one z poleceń GRANT wykonanych w SQL. Adam otrzymuje pełne prawa do bazy danych 'frmy' dzięki komendzie 'GRANT ALL', co oznacza, że może zarówno przeglądać, jak i modyfikować wszelkie dane w tej bazie. Z kolei Tomasz, dzięki przyznanym mu uprawnieniom SELECT, INSERT i UPDATE, również ma możliwość przeglądania danych oraz ich zmiany. Ta sytuacja odzwierciedla kluczowe aspekty zarządzania uprawnieniami w systemach baz danych, gdzie precyzyjne przydzielanie ról i dostępów jest fundamentalne dla zapewnienia bezpieczeństwa i integralności danych. Praktyczne zastosowania takich operacji obejmują sytuacje, w których administratorzy baz danych muszą zróżnicować dostęp do danych w zależności od ról użytkowników, co jest zgodne z zasadami minimalnych uprawnień, które są standardem w branży IT.

Pytanie 33

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

A. A RIGHT JOIN B

B. A LEFT JOIN B

C. A FULL OUTER JOIN B

D. A INNER JOIN B

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

Pytanie 34

Który typ relacji wymaga stworzenia tabeli pośredniczącej łączącej klucze główne obu tabel?

A. 1..1

B. 1..n

C. n..1

D. n..n

Wybór relacji 1..1 sugeruje, że jeden rekord w pierwszej tabeli jest powiązany z dokładnie jednym rekordem w drugiej tabeli, co nie wymaga tabeli pośredniej. Przykładem może być relacja między tabelą 'Pracownicy' a tabelą 'Działy', gdzie każdy pracownik jest przypisany do jednego działu, a każdy dział ma jednego pracownika. Relacje 1..n oraz n..1 również nie wymagają tabel pośrednich, ponieważ pozwalają na przypisania jednego rekordu do wielu rekordów, ale nie wymagają wzajemnych powiązań, co jest charakterystyczne dla relacji n..n. Relacja 1..n oznacza, że jeden rekord z tabeli A może być powiązany z wieloma rekordami z tabeli B, ale nie odwrotnie, natomiast w relacji n..1 wiele rekordów z tabeli A jest przypisanych do jednego rekordu w tabeli B. Te błędne podejścia wynikają z niepełnego zrozumienia struktury relacji danych oraz roli tabel pośrednich w zarządzaniu skomplikowanymi powiązaniami. Aby uniknąć mylnych interpretacji, ważne jest zrozumienie, że relacje 1..1, 1..n i n..1 nie wymagają tabel pośrednich, ponieważ nie łączą wielu rekordów z obu tabel, co jest kluczowym wymogiem dla relacji n..n.

Pytanie 35

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

A. tworzenia powiązań w relacyjnych bazach danych

B. wyszukiwania rekordów, które spełniają określone kryteria

C. generowania raportów z danych

D. ułatwienia wprowadzania, edytowania i usuwania danych

Wiele osób może pomylić funkcję formularzy w bazach danych z ich rolą w raportowaniu danych. Chociaż formularze mogą być używane do generowania raportów, ich głównym celem nie jest prezentacja danych, ale ułatwienie ich wprowadzania oraz zarządzania. Raporty zazwyczaj są generowane na podstawie danych już istniejących w bazie i wymagają analizy, co wykracza poza funkcję formularzy. Z kolei wyszukiwanie wierszy spełniających określone kryteria, choć istotne, również nie jest głównym zadaniem formularzy. Wyszukiwanie to proces związany z kwerendami SQL, który pozwala na wydobycie danych na podstawie różnych warunków, co także nie jest bezpośrednio związane z funkcjonalnością formularzy, które skupiają się na interakcji użytkownika z danymi. Ponadto, wprowadzanie powiązań w relacyjnych bazach danych to bardziej zaawansowany proces projektowania bazy, który wymaga zrozumienia struktury danych i zastosowania kluczy głównych oraz obcych. Powiązania są definiowane na etapie projektowania bazy danych, a nie podczas korzystania z formularzy. Dlatego, chociaż wszystkie wymienione funkcje są istotne w kontekście zarządzania danymi, formularze skupiają się głównie na uproszczeniu interakcji użytkownika z procesem wprowadzania i modyfikacji danych.

Pytanie 36

Jaką klauzulę należy użyć w instrukcji CREATE TABLE w SQL, żeby pole rekordu nie mogło być puste?

A. CHECK

B. NULL

C. NOT NULL

D. DEFAULT

Wybór odpowiedzi NULL wskazuje na nieprawidłowe zrozumienie roli tej klauzuli w kontekście tworzenia tabel w SQL. Klauzula NULL jest domyślnym ustawieniem dla kolumn, które nie zostały oznaczone jako NOT NULL. Oznacza to, że kolumna może zawierać wartości puste (NULL), co w wielu przypadkach może prowadzić do problemów z integralnością danych. Z drugiej strony, klauzula CHECK jest używana do określenia warunków, które muszą być spełnione przez dane w kolumnie, ale nie gwarantuje, że pole nie będzie puste. Może być użyta do walidacji wartości, ale nie służy do blokowania pustych wpisów. Klauzula DEFAULT pozwala na ustawienie wartości domyślnej dla kolumny, jeżeli nie zostanie podana żadna inna wartość, lecz nie chroni przed wprowadzeniem danych pustych. Typowe błędy myślowe, które prowadzą do takich niepoprawnych wniosków, to mylenie celów różnych klauzul oraz nieodróżnianie między zasadą integralności a ustawieniami domyślnymi dla kolumn. W kontekście projektowania baz danych, kluczowe jest zrozumienie, że NOT NULL ma na celu zapewnienie, że ważne dane są zawsze obecne, co jest niezbędne dla właściwego funkcjonowania aplikacji oraz analizy danych.

Pytanie 37

Podana jest tabela książki z kolumnami: tytuł, autor (w formie tekstowej), cena (w formie liczbowej). Jaką kwerendę SELECT należy wykorzystać, aby otrzymać tylko tytuły, których cena jest niższa niż 50 zł?

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ł';

Odpowiedzi, które zostały podane jako niepoprawne, zawierają różne błędy w składni oraz logiczne nieścisłości. W pierwszym przypadku, zapytanie "SELECT * FROM ksiazki WHERE cena < 50;" zwraca wszystkie kolumny z tabeli, co nie jest zgodne z wymaganiami pytania, które prosi o zwrócenie jedynie tytułów książek. Użycie operatora * zamiast konkretnego pola jest nieefektywne, co prowadzi do większego obciążenia, szczególnie przy dużych zbiorach danych. Innym zapytaniem, które jest niepoprawne, jest "SELECT tytul FROM ksiazki WHERE cena > '50 zł';". To zapytanie zawiera błąd w operatorze porównania, ponieważ zamiast poszukiwać książek tańszych niż 50 zł, filtruje te droższe. Dodatkowo, zawarcie ceny jako tekstu ('50 zł') wprowadza nieprawidłowe zachowanie porównania, ponieważ SQL nie przetwarza wartości tekstowych jako liczb. Wreszcie, zapytanie "SELECT ksiazki FROM tytul WHERE cena < '50 zł';" jest całkowicie błędne, ponieważ sugeruje, że wybieramy kolumnę z tabeli 'ksiazki' na podstawie warunków dotyczących innej kolumny. Tego typu błędne zrozumienie struktury i składni SQL często prowadzi do frustracji w pracy z bazami danych. Kluczowe w nauce SQL jest zrozumienie, że każdy element zapytania ma swoje miejsce i rolę, co pozwala na tworzenie poprawnych i efektywnych kwerend.

Pytanie 38

Jakie uprawnienia są konieczne do wykonania oraz przywrócenia kopii zapasowej bazy danych Microsoft SQL Server 2005 Express?

A. Users

B. Security users

C. Administrator systemu

D. Użytkownik lokalny

W kontekście zarządzania bazą danych Microsoft SQL Server, posiadanie niewłaściwych uprawnień może prowadzić do poważnych problemów z dostępnością i bezpieczeństwem danych. Odpowiedzi takie jak 'Users', 'Security users' oraz 'Użytkownik lokalny' wskazują na nieporozumienie dotyczące ról i uprawnień w systemie zarządzania bazami danych. Użytkownicy z uprawnieniami 'Users' mają ograniczone zdolności, które zazwyczaj obejmują jedynie wykonywanie zapytań i manipulację danymi w ramach istniejących struktur, ale nie pozwalają na zarządzanie operacjami administracyjnymi, takimi jak tworzenie kopii zapasowych. Rola 'Security users' jest subtelnym elementem zabezpieczeń i również nie przekłada się na możliwości administracyjne. Co więcej, 'Użytkownik lokalny' odnosi się do kont użytkowników w systemie operacyjnym i nie ma bezpośredniego związku z uprawnieniami w SQL Server. Typowym błędem myślowym jest utożsamianie ról systemowych z poziomem dostępu do operacji na poziomie bazy danych, co może prowadzić do nieefektywnego zarządzania kopiami zapasowymi. Ważne jest, aby zrozumieć, że tylko odpowiednio uprawniony administrator systemu jest w stanie zapewnić kompleksowe zarządzanie danymi, w tym ich bezpieczeństwem i integralnością.

Pytanie 39

W MS SQL Server rola predefiniowana o nazwie dbcreator umożliwia użytkownikowi

A. zarządzanie bezpieczeństwem systemu

B. wykonywanie wszelkich operacji na serwerze i posiadanie praw do każdej bazy

C. zarządzanie plikami na dysku

D. tworzenie, modyfikowanie, usuwanie oraz przywracanie bazy danych

Wybór niewłaściwej odpowiedzi jest powszechnym błędem związanym z myleniem ról i uprawnień w MS SQL Server. Na przykład, stwierdzenie, że rola dbcreator pozwala na zarządzanie bezpieczeństwem systemu, jest nieprawidłowe, ponieważ bezpieczeństwo bazy danych i systemu zarządzania bazami danych w SQL Server podlega głównie roli sysadmin oraz uprawnieniom przyznanym przez administratorów. Rola dbcreator koncentruje się na operacjach dotyczących baz danych, a nie na bezpieczeństwie. Podobnie, stwierdzenie, że ta rola umożliwia zarządzanie plikami na dysku, jest błędne; te operacje są związane z rolą, która zarządza systemowymi operacjami plików, a nie bezpośrednio z rolą dbcreator. Natomiast twierdzenie, że rola ta pozwala na wykonywanie każdej operacji na serwerze i posiadanie prawa własności każdej bazy, jest całkowicie mylące, ponieważ taka szeroka moc jest zarezerwowana dla roli sysadmin, która nie ma ograniczeń w działaniach na serwerze SQL. Zrozumienie tych różnic jest niezbędne dla prawidłowego zarządzania uprawnieniami w systemach bazodanowych i może pomóc w uniknięciu kompromitacji danych czy nieautoryzowanego dostępu do krytycznych informacji. W przypadku nadawania uprawnień zawsze należy kierować się zasadą minimalnych uprawnień, aby zredukować ryzyko związane z nieautoryzowanym dostępem i zmianami. Zachowanie spójności w przydzielaniu ról i uprawnień jest kluczowe dla bezpieczeństwa i prawidłowego funkcjonowania systemów bazodanowych.

Pytanie 40

W przedstawionej na rysunku relacji pole AutorID znajdujące się w tabeli ksiazki jest kluczem

A. podstawowym.

B. kandydującym.

C. sztucznym.

D. obcym.

Na tym przykładzie bardzo dobrze widać, jak łatwo pomylić różne rodzaje kluczy w relacyjnej bazie danych. W tabeli ksiazki pole AutorID wygląda jak zwykła kolumna z liczbą, ale jego sens wynika dopiero z relacji z tabelą autorzy. To pole nie identyfikuje jednoznacznie rekordu książki, więc nie może być kluczem podstawowym. Kluczem podstawowym jest tu IDKsiazki, bo to ono służy do unikalnego oznaczania każdego wiersza z książką. Typowy błąd myślowy polega na tym, że skoro AutorID też jest liczbą i też wygląda jak identyfikator, to ktoś uznaje go za klucz podstawowy lub kandydujący. Tymczasem klucz kandydujący to taki, który mógłby być kluczem podstawowym, czyli musi gwarantować unikalność. AutorID tej cechy nie ma – jeden autor może mieć wiele książek, więc ta wartość powtarza się w wielu wierszach. Dlatego nie spełnia warunku unikalności i odpada jako kandydat. Czasem pojawia się też skojarzenie z kluczem sztucznym, bo pola typu ID są często tworzone sztucznie, np. jako auto_increment. Klucz sztuczny to jednak pojęcie opisujące sposób tworzenia identyfikatora w tabeli, a nie jego rolę w relacji między tabelami. Sztuczny (surrogate) może być np. IDKsiazki czy IDAutor – liczba bez znaczenia biznesowego, używana tylko jako identyfikator. AutorID w tabeli ksiazki nie jest nowym sztucznym kluczem, tylko przechowywaniem wartości z innej tabeli. Jego podstawowa funkcja to łączenie tabel, czyli właśnie rola klucza obcego. Z mojego doświadczenia warto zawsze zadać sobie pytanie: „czy to pole jednoznacznie identyfikuje wiersz w tej tabeli, czy tylko wskazuje na wiersz w innej tabeli?”. Jeśli to drugie, to mówimy o kluczu obcym, a nie o kluczu podstawowym, kandydującym czy sztucznym. Taka prosta mentalna checklista bardzo pomaga przy projektowaniu schematów i unikaniu nieporozumień w nazewnictwie i projektowaniu relacji.

Rozpocznij nowy egzamin

Powrót do strony głównej