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: 10 kwietnia 2026 09:52
Data zakończenia: 10 kwietnia 2026 09:53

Egzamin niezdany

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

W języku MySQL należy wykorzystać polecenie REVOKE, aby użytkownikowi anna cofnąć możliwość wprowadzania zmian wyłącznie w definicji struktury bazy danych. Polecenie, które służy do odebrania tych uprawnień, ma następującą formę

A. REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'

B. REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'

C. REVOKE ALL ON tabela1 FROM 'anna'@'localhost'

D. REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost'

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

Pytanie 2

Zapytanie z użyciem klauzuli JOIN jest wykorzystywane w celu

A. pozyskania wyników z dwóch tabel, które są ze sobą powiązane

B. określenia klucza obcego dla tabeli

C. wywołania funkcji agregującej

D. uzyskania wyników tylko z jednej tabeli

Wybór odpowiedzi, który wskazał na funkcje agregujące albo klucze obce, pokazuje, że mogło dojść do pewnego zamieszania z podstawami relacyjnych baz danych. Funkcje agregujące, jak SUM czy COUNT, robią co innego – one działają na zbiorach danych, a nie łączą tabel. Klucz obcy to fajny mechanizm do tworzenia relacji między tabelami, ale sam w sobie nie generuje wyników. Wiem, że klucze obce są ważne, ale nie mają bezpośredniego związku z klauzulą JOIN, która służy do łączenia różnych tabel. Ograniczenie wyników do tylko jednej tabeli nie ma sensu, bo TO nie jest cel klauzuli JOIN. To, że nie zrozumiesz tej zasady, może prowadzić do dużych problemów przy projektowaniu bazy oraz trudności w zbieraniu potrzebnych informacji. Ważne jest, żeby wiedzieć, jak i kiedy używać JOIN, ponieważ bez tego stracisz wiele możliwości. Często ludzie mylą operacje na tabelach z operacjami na pojedynczych wartościach, co jest największym błędem do uniknięcia w SQL.

Pytanie 3

Jakie zadania programistyczne należy wykonać na serwerze?

A. Zmiana stylu HTML na stronie spowodowana ruchem kursora

B. Zapisanie danych pozyskanych z aplikacji internetowej w bazie danych

C. Weryfikacja danych wprowadzonych do pola tekstowego na bieżąco

D. Ukrywanie i wyświetlanie elementów strony w zależności od aktualnej pozycji kursora

Wszystkie pozostałe zadania, takie jak zmiana stylu HTML na stronie wywołana przesunięciem kursora, sprawdzenie danych wpisanych do pola tekstowego w czasie rzeczywistym, czy ukrywanie i pokazywanie elementów strony w zależności od aktualnego stanu kursora, są zadaniami, które powinny być realizowane po stronie klienta. Podejście to wynika z faktu, iż interakcje z użytkownikiem powinny być jak najbardziej responsywne i natychmiastowe, co jest możliwe jedynie przy użyciu JavaScriptu w przeglądarkach. Na przykład, zmiana stylu HTML jest operacją, która nie wymaga komunikacji z serwerem, ponieważ wszystkie potrzebne informacje są już dostępne na kliencie. W przypadku sprawdzania danych w czasie rzeczywistym, przetwarzanie odbywa się lokalnie, co pozwala na natychmiastowe informowanie użytkownika o błędach w formularzach bez opóźnienia wynikającego z oczekiwania na odpowiedź serwera. Ukrywanie i pokazywanie elementów strony również powinno być realizowane po stronie klienta, aby zapewnić płynność interakcji. Użytkownicy oczekują szybkiej reakcji na swoje działania, a operacje po stronie klienta, takie jak animacje czy zmiany widoczności elementów, są znacznie bardziej efektywne, gdy są wykonywane lokalnie, ponieważ nie wymagają dodatkowych zasobów serwera ani czasu przetwarzania. W przeciwnym razie, realizacja tych zadań na serwerze prowadziłaby do zbędnych opóźnień i obciążenia infrastruktury serwerowej, co w konsekwencji ograniczyłoby wydajność i doświadczenie użytkownika.

Pytanie 4

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

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

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

C. zostanie pominięty warunek dotyczący imienia

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

W zapytaniach SQL użycie znaku gwiazdki (*) po klauzuli SELECT jest częstą praktyką, która wskazuje na potrzebę wyświetlenia wszystkich kolumn z tabeli wynikowej. W kontekście zapytania SELECT * FROM mieszkańcy WHERE imie = 'Anna'; oznacza to, że zostaną zwrócone wszystkie kolumny dla rekordów, które spełniają warunek imie='Anna'. Jest to szybki sposób na uzyskanie pełnych danych dla określonych kryteriów bez konieczności wyszczególniania nazw kolumn, co może być szczególnie przydatne w przypadku tabel o dużej liczbie kolumn. Ważnym aspektem jest tutaj optymalizacja zapytań; choć użycie * jest wygodne, w dużych zbiorach danych lepiej jest selekcjonować tylko te kolumny, które są rzeczywiście potrzebne do analizy, co zmniejsza obciążenie bazy danych i poprawia wydajność. W praktykach branżowych zaleca się również zwracanie uwagi na bezpieczeństwo danych i dostępność użytkowników do informacji, szczególnie w kontekście RODO i innych regulacji dotyczących ochrony danych osobowych.

Pytanie 5

SELECT ocena FROM oceny WHERE ocena>2 ORDER BY ocena;

Dana jest tabela oceny o polach id, nazwisko, imie, ocena. Przedstawione zapytanie jest przykładem:

A. sumowania

B. łączenia

C. selekcji

D. projekcji

Wydaje mi się, że wybór odpowiedzi na temat sumy, łączenia czy projekcji może wynikać z niepełnego zrozumienia podstawowych operacji w SQL. Operacja sumy to kwestia agregowania wartości w kolumnie i liczenia ich zbiorczej wartości, co w tym zapytaniu nie ma miejsca. Tutaj nie robimy żadnej agregacji, więc nie ma mowy o sumowaniu. Co do łączenia (JOIN), to działa ono na zasadzie łączenia danych z dwóch lub więcej tabel na podstawie wspólnych kolumn, a w tym zapytaniu mamy do czynienia tylko z jedną tabelą. Jeśli chodzi o projekcję, to jest to wybieranie konkretnych kolumn z tabeli, co może wprowadzać w błąd. W tym zapytaniu kluczowa jest jednak klauzula WHERE. Często zdarza się, że ludzie mylą pojęcia selekcji, które skupia się na ograniczaniu wyników według kryteriów, z projekcją, która dotyczy wyboru kolumn do wyświetlenia. Ważne jest, żeby na każdym etapie pracy z bazami danych zrozumieć te różnice; to pomoże ci skuteczniej wykorzystać SQL i unikać pomyłek w analizach.

Pytanie 6

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

A. SELECT * FROM Mieszkancy, Adresy ON Mieszkancy.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 imie, nazwisko, ulica FROM Mieszkancy JOIN Adresy ON Mieszkancy.Adresy_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 7

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

Tabela samochody zawiera rekordy przedstawione na obrazie. Wydając przedstawione zapytanie SQL zostaną zwrócone dane:

id	klasa_id	marka	model	rocznik
1	1	ford	ka	2017
2	2	seat	toledo	2016
3	3	opel	zafira	2018
4	2	fiat	500X	2018
5	3	opel	insignia	2017

A. zafira; insignia

B. opel zafira; opel insignia

C. zafira

D. opel zafira

Niestety, wybrana przez Ciebie odpowiedź jest nieprawidłowa. W tym przypadku kluczowe jest zrozumienie, jak działa zapytanie SQL w kontekście tabeli, którą analizujemy. Zapytanie 'SELECT model FROM samochody WHERE rocznik > 2017 AND marka = 'opel';' ma na celu wyświetlenie modelu samochodu marki 'opel' z roku produkcji późniejszego niż 2017. W analizowanej tabeli tylko model 'zafira' spełnia oba te kryteria, dlatego jest to poprawna odpowiedź. Wersja 'insignia' nie jest poprawna, ponieważ rocznik tego modelu jest wcześniejszy niż 2017. Podobnie, odpowiedź zawierająca tylko 'opel zafira' jest niepoprawna - mimo, że 'zafira' jest poprawnym modelem, jednak pytanie wymagało podania jedynie modelu, a nie marki i modelu. Wynika to z konstrukcji zapytania SQL, gdzie zaznaczono 'SELECT model', co oznacza, że zapytanie ma zwrócić jedynie model. To pokazuje, jak ważne jest dokładne zrozumienie, jakie informacje są żądane przez zapytanie SQL.

Pytanie 8

W języku PHP nie można zrealizować

A. przetwarzania danych z formularzy

B. zmiany dynamicznej zawartości strony HTML w przeglądarce

C. obróbki danych przechowywanych w bazach danych

D. tworzenia dynamicznej treści strony

PHP, jako skryptowy język programowania po stronie serwera, nie jest w stanie dynamicznie zmieniać zawartości strony HTML w przeglądarce użytkownika po jej załadowaniu. Operacje, które wykonuje PHP, są realizowane na serwerze, a wyniki tych operacji przesyłane są jako statyczny HTML do przeglądarki. Oznacza to, że jakiekolwiek zmiany w treści strony muszą być przeprowadzane przed wysłaniem odpowiedzi do klienta. Dynamiczne zmiany w istniejącej zawartości HTML w przeglądarce są realizowane za pomocą JavaScriptu, który działa po stronie klienta. Na przykład, jeśli mamy formularz, który po wypełnieniu wymaga zmiany niektórej zawartości na stronie bez jej ponownego ładowania, to właśnie JavaScript, a nie PHP, będzie odpowiedzialny za te zmiany. PHP może generować zawartość w odpowiedzi na żądania, ale nie ma możliwości interakcji z już załadowanym DOM w przeglądarce. To ograniczenie wynika z architektury webowej, w której PHP i JavaScript pełnią różne role, co jest zgodne z ogólnymi standardami tworzenia aplikacji webowych, w tym modelu MVC (Model-View-Controller), gdzie PHP obsługuje model i widok, a JavaScript kontroler.

Pytanie 9

Jakie mechanizmy są kluczowe dla Systemu Zarządzania Bazą Danych?

A. Narzędzia do generowania statystyk

B. Moduł do wizualizacji diagramów encji

C. System do zarządzania wersjami bazy danych

D. Wielodostępność do danych

System zarządzania wersjami bazy danych, choć może być użyteczny w kontekście rozwoju aplikacji, nie jest niezbędnym mechanizmem dla systemu zarządzania bazą danych. Służy on przede wszystkim do śledzenia zmian w strukturze bazy oraz w danych, co jest istotne w kontekście kontroli wersji. W praktyce, takie systemy są bardziej związane z procesem deweloperskim niż z podstawowymi funkcjami samego DBMS. Pakiety do tworzenia statystyk również nie są kluczowe dla działania systemu zarządzania bazą. Ich główną rolą jest pomoc w analizie danych oraz optymalizacji zapytań, co jest elementem dodatkowym, a nie wymaganym do prawidłowego funkcjonowania bazy danych. Z kolei przystawka do wizualizacji diagramów encji jest narzędziem wspierającym projektowanie baz danych, ale nie jest niezbędna dla samego systemu zarządzania bazą danych. Wybór odpowiednich narzędzi i mechanizmów w obszarze zarządzania bazami danych powinien być oparty na ich specyficznych zastosowaniach oraz potrzebach użytkowników. Często pojawia się mylne przekonanie, że funkcjonalności dodatkowe są równie istotne jak te podstawowe, co prowadzi do zrozumienia, że kluczowe dla funkcjonowania systemu są te elementy, które zapewniają jego podstawową operacyjność i niezawodność.

Pytanie 10

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

A. FileZilla

B. phpMyAdmin

C. Symfony 3

D. TotalCommander

FileZilla to klient FTP, który służy do przesyłania plików pomiędzy lokalnym komputerem a serwerem. Nie jest on narzędziem przeznaczonym do zarządzania bazami danych, dlatego nie umożliwia importu plików SQL do MySQL. Symfony 3, z kolei, to framework PHP, który służy do tworzenia aplikacji webowych. Mimo że Symfony 3 może współpracować z bazą danych MySQL, nie oferuje funkcji umożliwiających bezpośredni import plików SQL; jego głównym celem jest tworzenie aplikacji, a nie zarządzanie bazami danych. TotalCommander to menedżer plików, który umożliwia przeglądanie i zarządzanie plikami na lokalnym komputerze oraz na serwerach, ale nie ma funkcji związanych z importowaniem danych do baz danych. Chociaż narzędzie to może być użyteczne przy przesyłaniu plików do serwera, nie oferuje możliwości zarządzania bazą danych ani importowania plików SQL. W związku z tym, wybór tych narzędzi jako rozwiązania do importu plików SQL do MySQL jest nieuzasadniony.

Pytanie 11

W formularzu dokumentu PHP znajduje się pole <input name="im">. Gdy użytkownik wprowadzi tekst "Janek", aby dodać wartość tego pola do bazy danych, w tablicy $_POST będzie obecny element

A. im z następującym numerem indeksu

B. Janek z następującym numerem indeksu

C. Janek o indeksie im

D. im o indeksie Janek

Odpowiedzi wskazujące na istnienie dodatkowych numerów indeksów lub powiązań między wartością a nazwą pola są błędne, ponieważ nie odzwierciedlają rzeczywistego działania PHP w kontekście formularzy. W przypadku, gdy użytkownik wpisuje "Janek" w polu o nazwie 'im', PHP nie przypisuje tej wartości do jakiegoś indeksu numerowanego. Tablica $_POST operuje na zasadzie klucz-wartość, gdzie klucz jest nazwą pola w formularzu, a wartość to wprowadzone dane. Zatem klucz 'im' w tablicy $_POST zostałby skojarzony bezpośrednio z wartością 'Janek' jako jego wartość. Każda inna koncepcja, taka jak dodawanie numerów indeksów czy zamiana wartości z kluczem, jest myląca. Typowe błędy myślowe związane z tym zagadnieniem obejmują niezrozumienie, że PHP nie tworzy dynamicznych kluczy w tablicach na podstawie wartości, a jedynie przypisuje wartości do zdefiniowanych kluczy. Z tego powodu, żeby skutecznie operować na danych z formularzy, programiści muszą dokładnie rozumieć, jak działa tablica $_POST oraz jak poprawnie przetwarzać dane wejściowe w PHP, unikając przy tym błędnych interpretacji ich struktury.

Pytanie 12

Instrukcja SQL przedstawiona w formie graficznej

ALTER TABLE 'miasta'
ADD 'kod' text;

A. w tabeli miasta zmienia nazwę kolumny kod na nazwę text

B. zmienia nazwę tabeli miasta na nazwę kod

C. dodaje do tabeli kolumnę o nazwie kod typu text

D. wprowadza do tabeli dwie kolumny o nazwach: kod i text

Zrozumienie polecenia ALTER TABLE w SQL jest ważne, ale czasem ludzie mają problemy z interpretacją. To polecenie służy do zmiany struktury tabeli, a nie do zmiany nazw kolumn czy tabel. W Twoim przykładzie używasz słowa kluczowego ADD, co wskazuje na dodanie nowego elementu, a nie na zmianę nazwy. Jeśli myślisz, że możesz zmienić nazwę kolumny, to wchodzisz na minę, bo to wymaga innego polecenia, jak RENAME lub ALTER COLUMN w niektórych systemach SQL. Wydaje się, że niektórzy myślą, że każde ALTER TABLE wiąże się z nazwami, ale to nie tak. Dlatego ważne jest, żeby znać składnię, bo błędne użycie poleceń może prowadzić do problemów, jak utrata danych. Jeśli testujesz nowe polecenia w kontrolowanym środowisku, to lepiej zrozumiesz, jak to działa i unikniesz typowych pomyłek w SQL.

Pytanie 13

Jakie słowo kluczowe w SQL należy zastosować, aby usunąć powtarzające się rekordy?

A. DISTINCT

B. GROUP BY

C. LIKE

D. ORDER BY

Słowo kluczowe DISTINCT jest używane w języku SQL do eliminowania duplikatów z wyników zapytań. Gdy zastosujemy DISTINCT w zapytaniu SELECT, baza danych zwróci tylko unikalne wiersze, co jest niezwykle przydatne, gdy chcemy uzyskać listę bez powtarzających się wartości. Na przykład, jeśli mamy tabelę 'klienci' z kolumną 'miasto', a nasze zapytanie brzmi: 'SELECT DISTINCT miasto FROM klienci;', wówczas wynik będzie zawierał tylko unikalne nazwy miast, eliminując wszelkie duplikaty. To podejście nie tylko upraszcza analizę danych, ale również poprawia wydajność zapytań w wielu przypadkach, zwłaszcza gdy przetwarzamy duże zbiory danych. Użycie DISTINCT jest zgodne z najlepszymi praktykami w zakresie optymalizacji baz danych, ponieważ pozwala zapobiegać przypadkowemu wprowadzaniu niepotrzebnych danych podczas analizy. Warto także zauważyć, że DISTINCT działa na całym zestawie kolumn w zapytaniu. Oznacza to, że jeśli wybierzemy wiele kolumn z DISTINCT, unikalne wiersze będą określane na podstawie kombinacji wartości we wszystkich tych kolumnach, co daje jeszcze większą kontrolę nad wynikami zapytania.

Pytanie 14

Głównym celem systemu CMS jest oddzielenie treści serwisu informacyjnego od jego wizualnej formy. Ten efekt osiągany jest przez generowanie zawartości

A. z plików HTML o stałej zawartości oraz wizualizacji z użyciem ustalonego szablonu

B. z bazy danych oraz wizualizacji poprzez atrybuty HTML

C. z plików HTML o stałej zawartości oraz wizualizacji przy pomocy technologii FLASH

D. z bazy danych oraz wyglądu ze zdefiniowanego szablonu

Poprawna odpowiedź na to pytanie to "z bazy danych oraz wyglądu ze zdefiniowanego szablonu". Systemy CMS (Content Management System) mają na celu oddzielenie treści od prezentacji, co pozwala na łatwiejsze zarządzanie i aktualizowanie zawartości serwisu. Wykorzystanie bazy danych do przechowywania treści jest kluczowe, ponieważ umożliwia dynamiczne generowanie zawartości na stronach internetowych. Dzięki temu, gdy zmienia się treść w bazie danych, zmiany te są automatycznie odzwierciedlane na stronie bez potrzeby modyfikacji statycznych plików HTML. Szablony, które definiują wygląd, są również niezmiernie ważne, ponieważ pozwalają na spójność wizualną serwisu i jego łatwą adaptację w przypadku zmian w designie. Przykładem może być użycie systemu szablonów, takiego jak Twig w Symfony, który umożliwia separację logiki biznesowej od prezentacji, co ułatwia pracę developerom i designerom. Takie podejście jest zgodne z najlepszymi praktykami w branży, zapewniając przy tym elastyczność i skalowalność serwisów internetowych.

Pytanie 15

Pole autor w tabeli ksiazka jest:

CREATE TABLE ksiazka (
 id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
 tytul VARCHAR(200),
 autor SMALLINT UNSIGNED NOT NULL,
 CONSTRAINT `dane` FOREIGN KEY (autor) REFERENCES autorzy(id)
);

A. polem typu tekstowego zawierającym informacje o autorze

B. kluczem obcym związanym z tabelą autorzy

C. kluczem podstawowym tabeli ksiazka

D. polem wykorzystanym w relacji z tabelą dane

Pole autor w tabeli ksiazka jest kluczem obcym, co oznacza, że wskazuje na inne pole w innej tabeli - w tym przypadku na pole id w tabeli autorzy. Klucze obce są podstawowym mechanizmem relacyjnych baz danych, który umożliwia tworzenie związków między różnymi tabelami. Dobre praktyki w projektowaniu baz danych sugerują używanie kluczy obcych do zapewnienia integralności referencyjnej, co oznacza, że każde odniesienie do innej tabeli musi wskazywać na istniejący rekord. Dzięki temu unika się problemów z danymi, takich jak tzw. „osierocone” rekordy, które odwołują się do nieistniejących danych. W praktyce, gdy dodajemy nową książkę do tabeli ksiazka, musimy mieć pewność, że istnieje odpowiedni autor w tabeli autorzy. Takie podejście podnosi jakość danych i pozwala na bardziej złożone zapytania SQL, które mogą łączyć informacje z różnych tabel w sposób spójny i logiki. Klucze obce są także kluczowe w kontekście operacji takich jak aktualizacja czy usuwanie danych, ponieważ mogą automatycznie zaktualizować lub usunąć powiązane rekordy, co zapewnia integralność bazy danych.

Pytanie 16

Atrybut NOT NULL kolumny jest konieczny w przypadku

A. klucza podstawowego

B. określenia wszystkich pól typu numerycznego

C. określenia wszystkich pól tabeli

D. użycia atrybutu DEFAULT

Atrybut NOT NULL jest kluczowym elementem w definicji kolumn w bazach danych, szczególnie w kontekście klucza podstawowego. Klucz podstawowy ma na celu unikalne identyfikowanie każdego rekordu w tabeli, co wymaga, aby wszystkie jego kolumny były wypełnione wartościami. Oznaczenie kolumny jako NOT NULL zapewnia, że nie można wprowadzić rekordu bez podania wartości dla tej kolumny, co jest zgodne z zasadą integralności danych. Przykładem może być tabela użytkowników, gdzie kolumna 'ID' jest kluczem podstawowym. Oznaczenie jej jako NOT NULL zapobiega sytuacji, w której mogłoby istnieć kilka rekordów bez unikalnego identyfikatora. Przy projektowaniu baz danych, zgodnie z zasadami normalizacji, klucze podstawowe powinny zawsze mieć atrybut NOT NULL, aby zachować spójność danych oraz ułatwić operacje związane z łączeniem tabel. Dobre praktyki sugerują również, aby każdy klucz podstawowy był prosty i jednoznaczny, co dodatkowo podkreśla potrzebę tego atrybutu.

Pytanie 17

W tabeli Recepta, kolumny Imie i Nazwisko odnoszą się do pacjenta, na którego wystawiona jest recepta. Jaką kwerendę należy wykorzystać, aby dla każdej recepty uzyskać datę jej wystawienia oraz imię i nazwisko lekarza, który ją wystawił?

A. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta

B. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id

C. SELECT Imie, Nazwisko, DataWystawienia FROM Recepta

D. SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id

Wybór odpowiedzi numer 4 jest prawidłowy, ponieważ kwerenda ta skutecznie łączy tabelę Recepta z tabelą Lekarz poprzez klucz obcy Lekarz_id. W ten sposób możliwe jest uzyskanie imienia i nazwiska lekarza wystawiającego receptę oraz daty jej wystawienia. W SQL, operacja JOIN umożliwia łączenie danych z dwóch tabel na podstawie kolumn powiązanych, co jest fundamentalną zasadą w relacyjnych bazach danych. W tym przypadku klucz obcy Lekarz_id w tabeli Recepta odnosi się do klucza głównego id w tabeli Lekarz. Dzięki temu możemy pobrać informacje o lekarzu wystawiającym receptę, co jest powszechną praktyką w aplikacjach medycznych i systemach zarządzania informacją. Stosowanie JOIN jest kluczowe w projektowaniu efektywnych i skalowalnych baz danych, co pozwala na utrzymanie danych w uporządkowanej i znormalizowanej formie zgodnie z zasadami normalizacji baz danych. Taka struktura bazy danych umożliwia łatwe zarządzanie i aktualizowanie informacji oraz minimalizuje redundancję danych, co jest istotne dla zapewnienia spójności i integralności danych w systemie.

Pytanie 18

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

A. DELETE FROM pracownicy WHERE pensja IN (500,1000) AND miejsce_pracy LIKE '*tx*';

B. DELETE FROM pracownicy WHERE pensja BETWEEN 500 AND 1000 OR miejsce_pracy LIKE '%tx%';

C. DELETE FROM pracownicy WHERE pensja > 500 AND pensja < 1000 AND miejsce_pracy LIKE '%tx%';

D. DELETE FROM pracownicy WHERE pensja BETWEEN 500 AND 1000 AND miejsce_pracy LIKE '%tx%';

W tym zadaniu widać kilka typowych pułapek związanych z SQL-em: składnią operatora LIKE, doborem zakresu liczbowego oraz użyciem spójników logicznych AND i OR. Zacznijmy od wzorca tekstowego. W MySQL, zgodnie ze standardową składnią SQL, do dopasowań wzorców używa się znaków % i _. Procent oznacza dowolny ciąg znaków, a podkreślnik pojedynczy znak. Natomiast gwiazdka * nie jest prawidłowym wildcardem w operatorze LIKE, więc zapis typu LIKE '*tx*' po prostu nie zadziała tak, jak większość osób intuicyjnie zakłada. To jest częsty błąd u osób, które mieszają składnię SQL z np. wyrażeniami w stylu systemów plików czy niektórych narzędzi linuksowych. Kolejna sprawa to warunki logiczne. W tym poleceniu chodziło o wybranie rekordów, które spełniają oba kryteria jednocześnie: pensja w określonym przedziale i miejsce pracy zawiera „tx”. Użycie operatora OR całkowicie zmienia znaczenie zapytania, bo wtedy wystarczy, że spełniony jest tylko jeden z warunków. W efekcie można by usunąć osoby, które mają odpowiednią pensję, ale w ogóle nie mają „tx” w miejscu pracy, albo odwrotnie – mają „tx” w miejscu pracy, ale zarabiają dużo mniej lub więcej niż zadany zakres. To klasyczny przykład nieprecyzyjnie dobranego spójnika logicznego, który na produkcyjnej bazie może zakończyć się masowym usunięciem nie tych danych, co trzeba. Trzeci problem dotyczy interpretacji zakresu. Operator IN z wartościami (500,1000) nie wybiera przedziału od 500 do 1000, tylko dokładnie dwie wartości: 500 i 1000. To nie ma nic wspólnego z „między 500 a 1000”, więc zadanie nie byłoby zrealizowane. Z drugiej strony użycie warunku pensja > 500 AND pensja < 1000 wyklucza wartości graniczne, czyli 500 i 1000, co jest sprzeczne z opisem „nie mniej niż 500 i nie więcej niż 1000”. Z mojego doświadczenia najczęściej takie błędy wynikają z pośpiechu i nieprzeczytania dokładnie treści zadania. Dobra praktyka jest taka, żeby zawsze świadomie decydować, czy zakres ma być domknięty (BETWEEN) czy otwarty (>, <) oraz żeby testować zapytanie w wersji SELECT przed wykonaniem operacji DELETE albo UPDATE. To pozwala od razu zauważyć, że warunki logiczne albo wzorzec LIKE nie działają tak, jak zakładaliśmy w głowie.

Pytanie 19

Jakie informacje można uzyskać na temat normalizacji tej tabeli?

A. Tabela znajduje się w trzeciej postaci normalnej

B. Tabela znajduje się w pierwszej postaci normalnej

C. Tabela nie jest znormalizowana

D. Tabela jest w drugiej postaci normalnej

Tabela przedstawiona w pytaniu nie spełnia wymogów żadnej z trzech podstawowych postaci normalnych co oznacza że nie jest znormalizowana. Pierwsza postać normalna wymaga aby wszystkie wartości w tabeli były atomowe co oznacza że kolumna Adres powinna być podzielona na kilka kolumn takich jak ulica miasto i kod pocztowy. Druga postać normalna wymaga że wszystkie atrybuty niekluczowe muszą być deterministycznie zależne od całego klucza głównego co w tym przypadku nie ma zastosowania ponieważ tabela zawiera tylko dwa atrybuty i brak jest klucza złożonego. Trzecia postać normalna eliminuje wszelkie przejściowe zależności funkcyjne pomiędzy atrybutami niekluczowymi co również nie ma zastosowania w tej prostej strukturze. Typowe błędy myślowe prowadzące do niewłaściwych wniosków mogą obejmować niepełne zrozumienie zasad atomowości danych oraz błędne założenie że nieskomplikowana struktura tabeli automatycznie spełnia zasady normalizacji. Dlatego kluczowe jest aby dokładnie rozumieć i identyfikować zależności między danymi oraz jak te zależności wpływają na integralność i efektywność bazy danych co jest szczególnie istotne w dużych systemach gdzie dane są intensywnie modyfikowane i wykorzystywane przez wiele aplikacji jednocześnie. Właściwa normalizacja pozwala na optymalizację czasu dostępu do danych oraz minimalizację redundancji co jest uznawane za dobrą praktykę w branży projektowania baz danych. W kontekście projektowania systemów informatycznych poprawna normalizacja jest nieodłącznym elementem cyklu życia projektu zapewniającym że struktura danych jest odporna na zmiany w wymaganiach użytkowników oraz skalowalna w przypadku wzrostu ilości danych do obsługi przez system. Dlatego zrozumienie i prawidłowe stosowanie zasad normalizacji jest kluczowe dla przyszłych profesjonalistów w dziedzinie IT którzy będą odpowiedzialni za projektowanie i utrzymanie złożonych systemów bazodanowych.

Pytanie 20

Testy aplikacji webowej, mające na celu ocenę wydajności aplikacji oraz bazy danych, a także architektury serwera i konfiguracji, noszą nazwę testów

A. użyteczności

B. funkcjonalnych

C. bezpieczeństwa

D. kompatybilności

Testy użyteczności zajmują się tym, jak łatwo i intuicyjnie użytkownicy mogą korzystać z aplikacji. Obejmują analizę interfejsu użytkownika oraz ogólne wrażenia z korzystania. Choć oczywiście są ważne, to nie mają bezpośredniego związku z testowaniem skalowalności czy tego, jak działa architektura serwera. Z kolei testy funkcjonalne sprawdzają, czy aplikacja działa tak, jak powinna, testując jej funkcje w kontekście poszczególnych zadań, ale też nie obejmują tego, jak aplikacja radzi sobie pod dużym obciążeniem. Testy bezpieczeństwa są o tym, jak znaleźć luki w zabezpieczeniach aplikacji, a nie odnoszą się do skalowalności ani architektury systemu. Często ludzie błędnie mylą cele różnych testów, co prowadzi do wyboru złych odpowiedzi. Ważne jest, żeby zrozumieć, że każdy test ma swoją specyfikę i cele, które pomagają zapewnić, że aplikacja nie tylko działa, ale żeby działała efektywnie w różnych warunkach i na różnych platformach. Dlatego dobrze jest znać kontekst testów kompatybilności, bo to kluczowe do projektowania i wdrażania aplikacji internetowych, które mogą sprostać wymaganiom użytkowników.

Pytanie 21

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

A. REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'

B. REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost'

C. REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'

D. REVOKE ALL ON tabela1 FROM 'anna'@'localhost'

Poprawna odpowiedź to 'REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost''. To polecenie skutecznie odbiera użytkownikowi 'anna' prawo do wykonywania zmian w strukturze bazy danych, w tym do tworzenia nowych tabel, modyfikowania istniejących oraz usuwania tabel. W kontekście MySQL, polecenie REVOKE jest kluczowym narzędziem w zarządzaniu uprawnieniami użytkowników. W praktyce, gdy administrator bazy danych chce ograniczyć możliwości danej osoby, aby nie mogła na przykład zmieniać struktury bazy, musi precyzyjnie określić, które uprawnienia chce cofnąć. Dobrym przykładem byłoby zastosowanie tego polecenia w sytuacji, gdy użytkownik nie przestrzega zasad bezpieczeństwa lub nieautoryzowanie modyfikuje dane. Warto również zauważyć, że użycie 'ALTER' w poleceniu wskazuje na prawo do zmiany definicji tabeli, co jest kluczowe w kontekście bezpieczeństwa danych. Użycie polecenia REVOKE jest zgodne z najlepszymi praktykami w zakresie zarządzania dostępem, które zalecają minimalizację uprawnień przyznawanych użytkownikom, aby zredukować ryzyko przypadkowych lub złośliwych działań.

Pytanie 22

W systemie zarządzania bazą danych MySQL, aby uzyskać listę wszystkich przywilejów przyznanych użytkownikowi anna, można użyć polecenia

A. GRANT * TO anna;

B. REVOKE GRANTS FROM anna;

C. SHOW GRANTS FOR anna;

D. SELECT GRANTS FOR anna;

Odpowiedzi 1, 2 i 3 są nietrafione, bo nie odpowiadają na pytanie o to, jak zobaczyć przydzielone uprawnienia dla użytkownika 'anna'. Pierwsza opcja, 'SELECT GRANTS FOR anna;', jest błędna, bo w MySQL nie ma takiej składni do zdobywania informacji o uprawnieniach. Możliwe, że po prostu pomyliłeś, bo SELECT kojarzy się z pozyskiwaniem danych, ale nie o uprawnieniach. Druga opcja, 'REVOKE GRANTS FROM anna;', też jest niepoprawna, bo REVOKE służy do odbierania uprawnień, a nie ich wyświetlania. Niektórzy mogą myśleć, że odbieranie uprawnień w jakiś sposób pokaże, co wcześniej przyznano, ale to zupełnie coś innego. Trzecia odpowiedź, 'GRANT * TO anna;', sugeruje przyznawanie uprawnień zamiast ich wyświetlania. Użytkownicy mogą myśleć, że znak '*' oznacza wszystkie możliwe uprawnienia, co może prowadzić do niebezpiecznych sytuacji, jeżeli uprawnienia są nadawane bez głębszej analizy. Dlatego zarządzanie uprawnieniami jest mega ważne dla bezpieczeństwa bazy danych, a zrozumienie, jak różne polecenia działają, jest kluczowe.

Pytanie 23

Jaką funkcję SQL można uznać za nieprzyjmującą argumentów?

A. upper

B. len

C. now

D. year

Odpowiedzi, które wskazują na funkcje 'year', 'len' oraz 'upper', opierają się na błędnych założeniach dotyczących sposobu działania tych funkcji. Funkcja 'year' jest wykorzystywana do wyodrębnienia części roku z daty i wymaga podania argumentu, który jest datą. Na przykład, użycie 'year(data)' zwróci numer roku z podanej daty, co stawia tę funkcję w kontekście pobierania argumentów. Z kolei 'len' jest funkcją służącą do określenia długości łańcucha znaków, co również oznacza, że wymaga argumentu w postaci tekstu: 'len('tekst')' zwróci liczbę znaków w podanym łańcuchu. Funkcja 'upper' z kolei przekształca wszystkie znaki w podanym łańcuchu na wielkie litery, także wymaga argumentu: 'upper('tekst')'. Te funkcje są niezwykle użyteczne w codziennej pracy z danymi, ale ich zastosowanie powinno być świadome i oparte na znajomości ich specyfiki. W przypadku takich funkcji, typowym błędem myślowym jest przekonanie, że można je stosować bez znajomości wymaganych argumentów. W praktyce oznacza to, że aby korzystać z możliwości funkcji SQL, niezbędne jest zrozumienie ich struktury i działania, co jest kluczowe dla efektywnego pisania zapytań oraz przetwarzania danych w bazach danych.

Pytanie 24

Jakie tabele będą weryfikowane przez podane polecenie?

CHECK TABLE pracownicy CHANGED;

A. Tabele, które uległy zmianie od ostatniego sprawdzenia lub nie zostały prawidłowo zamknięte.

B. Tabele, które zmieniły się w bieżącej sesji.

C. Jedynie tabele referencyjne.

D. Tylko tabele, które nie zostały prawidłowo zamknięte.

Odpowiedź, że polecenie CHECK TABLE sprawdzi tabele, które zmieniły się od ostatniej kontroli lub nie zostały poprawnie zamknięte, jest poprawna. Polecenie to jest wykorzystywane w systemach zarządzania bazami danych, takich jak MySQL, do diagnozowania i naprawy problemów związanych z integralnością danych. Kiedy tabele są zmieniane lub nie zostały poprawnie zamknięte, mogą wystąpić uszkodzenia, które mogą prowadzić do błędów przy odczycie lub zapisie danych. W praktyce, administratorzy baz danych regularnie wykonują polecenie CHECK TABLE, aby upewnić się, że struktura tabeli jest nienaruszona i że system operacyjny poprawnie zarządza danymi. Użycie CHECK TABLE w kontekście tabel, które zmieniły się od ostatniej kontroli, jest kluczowe, gdyż pozwala na szybką lokalizację problemów. Warto również zauważyć, że w przypadku dużych baz danych wykonanie tego polecenia może być czasochłonne, dlatego dobrze jest zintegrować jego użycie z harmonogramem regularnych kontroli integralności danych, co jest zgodne z najlepszymi praktykami w zarządzaniu bazami danych.

Pytanie 25

Dostępna jest tabela z danymi o mieszkaniach, zawierająca kolumny: adres, metraż, liczba_pokoi, standard, status, cena. Wykonanie poniższej kwerendy SQL SELECT spowoduje wyświetlenie

SELECT metraz, cena FROM mieszkania WHERE ile_pokoi > 3;

A. Wszystkie informacje o tych mieszkaniach, które mają minimum 3 pokoje

B. Metraż oraz koszt tych mieszkań, które mają przynajmniej 3 pokoje

C. Metraż oraz koszt tych mieszkań, które mają więcej niż 3 pokoje

D. Wszystkie informacje poza adresem tych mieszkań, które mają więcej niż 3 pokoje

Czasami odpowiedzi są niepoprawne, bo trudno zrozumieć, jak działają podstawowe elementy SQL. Na przykład, często ludzie mylą operator > z >=, co może prowadzić do złych wyników, bo źle interpretują warunki filtrowania. W zapytaniu SELECT, jeżeli nie wybieramy konkretnych kolumn, to domyślnie będą wybierane wszystkie, co nie jest to, co chcemy. W tej sytuacji interesują nas tylko metraż i cena, a nie wszystkie dane. Zrozumienie, jakie dane się pojawią, wymaga uważności przy pisaniu zapytań SQL. Dobre praktyki to jasne warunki logiczne i dokładne określenie, co chcemy wyciągnąć i kiedy. Często popełnia się błąd, nie uwzględniając operatorów logicznych oraz jak wpływają na końcowy rezultat. Operator > jasno mówi, że chcemy mieszkania z więcej niż trzema pokojami, więc odpowiedzi, które sugerują mieszkania z co najmniej trzema pokojami, są błędne. Te błędy pokazują, jak ważne jest, żeby dokładnie czytać i rozumieć zapytania SQL, bo to naprawdę się przydaje w codziennej pracy z danymi.

Pytanie 26

Jakie są określenia typowych komend języka SQL, które dotyczą przeprowadzania operacji na danych SQL DML (np.: dodawanie danych do bazy, usuwanie, modyfikowanie danych)?

A. ALTER, CREATE, DROP

B. SELECT, SELECT INTO

C. DENY, GRANT, REVOKE

D. DELETE, INSERT, UPDATE

Pierwsza odpowiedź DENY, GRANT, REVOKE odnosi się do zarządzania uprawnieniami w bazach danych, a nie do operacji na danych. Te polecenia są używane do kontrolowania dostępu do danych, co jest istotne dla bezpieczeństwa, ale nie mają one wpływu na manipulację danymi. W kontekście SQL DML, są one nieodpowiednie, ponieważ nie dotyczą wstawiania, aktualizowania ani usuwania danych. Odpowiedź SELECT, SELECT INTO odnosi się do operacji wyciągania danych z bazy. SELECT służy do pobierania danych, co jest fundamentalne dla analizy i raportowania, ale nie obejmuje modyfikacji danych. SELECT INTO jest używane do kopiowania danych do nowej tabeli, co również nie spełnia wymogu manipulacji danymi w kontekście DML. Odpowiedź ALTER, CREATE, DROP dotyczy struktury bazy danych i definiowania nowych obiektów, takich jak tabele i indeksy. Te polecenia są częścią języka SQL DDL (Data Definition Language) i nie mają zastosowania w kontekście operacji na danych, które są kluczowe dla DML. Zrozumienie różnicy między DML a DDL jest niezbędne, aby skutecznie zarządzać bazą danych i realizować odpowiednie operacje na danych.

Pytanie 27

Który z elementów relacyjnej bazy danych, będący kodem w języku SQL, może być użyty w zapytaniach zmieniających kolumny danych przedstawiane w formie tabeli, niezależnie od tego, czy jest tworzony ręcznie, czy też dynamicznie?

A. Wyzwalacz

B. Reguła

C. Funkcja zdefiniowana

D. Procedura składowa

Funkcja zdefiniowana, znana również jako funkcja skalarna, jest obiektem relacyjnej bazy danych, który może być wywoływany w zapytaniach SQL, w tym w zapytaniach modyfikujących dane. Oferuje ona możliwość przetwarzania i zwracania wartości na podstawie określonego zestawu wejściowych. Funkcje zdefiniowane przez użytkownika są szczególnie przydatne, gdy potrzebujemy skomplikowanej logiki przetwarzania danych, która nie jest dostępna w standardowych funkcjach SQL. Przykładem może być funkcja obliczająca VAT na podstawie podanej kwoty, która może być użyta w zapytaniach INSERT lub UPDATE, aby dynamicznie obliczyć wartość i wprowadzić ją do bazy danych. W standardzie SQL, funkcje zdefiniowane są zgodne z normą SQL-92 i są kluczowym elementem w budowie bardziej zaawansowanych aplikacji bazodanowych. Umożliwiają one encapsulację logiki biznesowej, co pozwala na wielokrotne ich wykorzystanie, a także zwiększa czytelność kodu SQL.

Pytanie 28

Przy użyciu polecenia ALTER TABLE można

A. zmieniać wartości zapisane w rekordach tabeli

B. usuwać tabelę

C. zmieniać strukturę tabeli

D. tworzyć nową tabelę

W kontekście zarządzania bazami danych istnieje wiele podstawowych operacji, które można wykonywać, a polecenie ALTER TABLE jest jednoznacznie związane z modyfikowaniem struktury tabeli, co wyklucza możliwość jego użycia do usuwania lub tworzenia tabel. Odpowiedź sugerująca, że ALTER TABLE może usuwać tabelę, jest merytorycznie błędna. Tego rodzaju operacje realizowane są przez inne polecenia, takie jak DROP TABLE, które służy do usuwania tabeli i jej danych. Podobnie, tworzenie tabeli jest realizowane poleceniem CREATE TABLE. Mylne stwierdzenie, że ALTER TABLE może być używane do modyfikacji wartości w rekordach, również jest niepoprawne, ponieważ zmiana wartości zapisanych w tabeli jest realizowana za pomocą polecenia UPDATE. Niezrozumienie różnicy pomiędzy tymi poleceniami może prowadzić do błędnych operacji na bazie danych, narażających na utratę danych lub nieprawidłowe funkcjonowanie aplikacji. Dlatego tak ważne jest zrozumienie, jakie konkretne operacje można wykonać za pomocą poszczególnych poleceń SQL oraz ich właściwego zastosowania w praktyce, aby zapewnić integralność i bezpieczeństwo danych.

Pytanie 29

Kto z wymienionych zajmuje się stałym przygotowaniem systemu bazy danych do działania w produkcji, zarządzaniem kontami użytkowników oraz instalowaniem nowych wersji systemu bazodanowego?

A. Projektanci i programiści Systemu Zarządzania Bazą Danych

B. Administratorzy systemu bazy danych

C. Twórcy narzędzi programistycznych

D. Administratorzy serwerów oraz sieci komputerowych

Wybór projektantów narzędzi deweloperskich jest błędny, ponieważ ich głównym zadaniem jest tworzenie narzędzi i środowisk, które wspierają proces programowania, a nie zarządzanie bazami danych. Z tego względu nie są odpowiedzialni za utrzymanie i administrację istniejących baz danych. Również administratorzy serwerów i sieci komputerowych, choć mają ważną rolę w zarządzaniu infrastrukturą IT, nie zajmują się bezpośrednio bazami danych. Ich zadania koncentrują się na konfiguracji, zabezpieczeniu oraz monitorowaniu serwerów i sieci, co jest istotne, lecz nie obejmuje bezpośredniego zarządzania systemami bazodanowymi. Także projektanci i programiści Systemu Zarządzania Bazą Danych są bardziej skoncentrowani na tworzeniu i rozwijaniu oprogramowania, a nie na administracji i codziennej obsłudze baz danych. Typowym błędem jest mylenie ról i odpowiedzialności w zespołach IT, co prowadzi do niewłaściwego przypisania zadań. W kontekście nowoczesnych organizacji, zrozumienie specyfiki poszczególnych stanowisk oraz ich funkcji w szerszym ekosystemie IT jest kluczowe dla efektywnego zarządzania i utrzymania systemów informacyjnych.

Pytanie 30

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

A. DEFAULT

B. NULL

C. CHECK

D. NOT NULL

Klauzula NOT NULL w poleceniu CREATE TABLE języka SQL służy do zapewnienia, że dane w danym polu rekordu nie mogą być puste. To oznacza, że podczas wstawiania nowych rekordów do tabeli, każde pole, które zostało zdefiniowane z tą klauzulą, musi zawierać wartość. Na przykład, jeśli mamy tabelę pracowników, w której kolumna 'nazwisko' jest zdefiniowana jako NOT NULL, to każde dodanie nowego pracownika do tej tabeli musi zawierać wartość w kolumnie 'nazwisko'. W praktyce jest to bardzo ważne, ponieważ pozwala na utrzymanie integralności danych i zapobiega sytuacjom, w których kluczowe informacje mogłyby zostać pominięte. Użycie NOT NULL jest zgodne z dobrymi praktykami projektowania baz danych, które podkreślają znaczenie pełnych i kompletnych danych. Zastosowanie tej klauzuli zwiększa jakość danych oraz ułatwia późniejsze operacje na tabeli, takie jak zapytania czy raporty.

Pytanie 31

W relacyjnych bazach danych dane zapisywane są w

A. kolejkach.

B. wektorach.

C. tabelach.

D. listach.

W modelu relacyjnych baz danych kluczowe jest zrozumienie, że podstawową strukturą przechowywania danych jest tabela, a nie ogólne pojęcia typu lista, kolejka czy wektor. Te inne struktury występują częściej w programowaniu, w kodzie aplikacji, a nie jako główny element fizycznej organizacji danych w systemach takich jak MySQL czy PostgreSQL. Lista kojarzy się z prostym zbiorem elementów zapisanych jeden po drugim, bez sztywnych kolumn i typów danych. W kodzie możemy mieć listę obiektów użytkowników, ale kiedy te dane trafiają do relacyjnej bazy, lądują w tabeli z jasno zdefiniowanymi kolumnami. Baza danych musi zapewnić integralność, indeksy, klucze, możliwość złożonych zapytań SQL – zwykła lista tego nie ogarnia. Kolejka z kolei to struktura typu FIFO, używana np. w systemach kolejkowania zadań, komunikatach między serwisami, przetwarzaniu asynchronicznym. W bazach danych można co najwyżej zaimplementować logikę działania kolejki na tabeli (np. kolumna status, czas dodania, pobieranie najstarszego zadania), ale fizycznie to dalej jest tabela, a nie specjalny typ „kolejka” w sensie modelu relacyjnego. Wektor natomiast to pojęcie bardziej z matematyki i programowania niskopoziomowego, czasem używane jako tablica dynamiczna. W silnikach baz danych oczywiście istnieją wewnętrzne struktury w pamięci, jakieś tablice, strony danych, indeksy, ale użytkownik pracuje z tabelami, relacjami, widokami. Typowym błędem myślowym jest przenoszenie pojęć z programowania obiektowego czy struktur danych 1:1 do świata relacyjnych baz. W praktyce, niezależnie od tego, czy obsługujesz system CRM, sklep internetowy czy prosty blog, zawsze kończysz z tabelami: użytkownicy, posty, komentarze, produkty itd. Reszta struktur, takich jak listy czy kolejki, to bardziej narzędzia w warstwie aplikacji, nie fundament modelu relacyjnego. Dlatego przy pytaniach o relacyjne bazy danych warto automatycznie myśleć o tabelach, kolumnach, wierszach i kluczach, bo to jest absolutna podstawa pracy z SQL.

Pytanie 32

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

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

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

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

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

Zapytania, które nie były prawidłowe, operują na istotnych nieporozumieniach związanych z użyciem operatorów logicznych oraz z określeniem liczby wolnych miejsc. Przykłady te często wykorzystują operator OR, co prowadzi do sytuacji, w której jeden z warunków może być spełniony, a drugi nie. W szczególności, użycie operatora OR w kontekście zadań, które wymagają spełnienia obu warunków, prowadzi do nieprawidłowych wyników. Na przykład, zapytanie z OR zwróci wszystkie wycieczki, które mają cenę poniżej 2000 zł, niezależnie od tego, ile mają wolnych miejsc, co może skutkować wyświetleniem wycieczek, które w ogóle nie spełniają kryteriów dostępności. Dodatkowo, w jednym z zapytań zastosowano niewłaściwą wartość dla ilości wolnych miejsc - 'miejsca > 3' zamiast 'miejsca > 4', co również prowadzi do nieścisłości. Zmiana wartości progowej nie uwzględnia wymogu, by wycieczki miały przynajmniej cztery wolne miejsca, tym samym zmieniając sens zapytania. Kluczowym błędem jest zatem zrozumienie, że w kontekście filtrowania danych w bazie, zarówno operator AND, jak i precyzyjne określenie wartości granicznych są niezbędne dla uzyskania poprawnych i użytecznych wyników.

Pytanie 33

W tabeli zwierzeta znajdują się kolumny nazwa, gatunek, gromada, cechy, dlugosc_zycia. Aby uzyskać listę nazw zwierząt, które dożywają przynajmniej 20 lat oraz są ssakami, jakie zapytanie należy wykonać?

A. SELECT nazwa FROM zwierzeta WHERE gromada = 'ssak';

B. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >= 20 AND gromada = 'ssak';

C. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >= 20 OR gromada = 'ssak';

D. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >= 20;

Zrozumienie, dlaczego pozostałe odpowiedzi są niepoprawne, wymaga analizy koncepcji związanych z używaniem operatorów w zapytaniach SQL. Pierwsza opcja, która wskazuje jedynie na gromadę ssaków, nie spełnia wymagania dotyczącego długości życia. W rezultacie, takie zapytanie może zwrócić wszystkie ssaki, niezależnie od ich długości życia, co nie odpowiada na postawione pytanie. Druga odpowiedź koncentruje się wyłącznie na długości życia zwierząt, a więc zignoruje ich przynależność do gromady, co również prowadzi do niekompletnych wyników. Z punktu widzenia standardów projektowania baz danych, takie podejście jest niewłaściwe, ponieważ nie uwzględnia wymagań wielokryterialnych. Ostatnia opcja używa operatora 'OR', co oznacza, że wystarczy, aby jedno z kryteriów było spełnione, co skutkuje zwróceniem większej liczby zwierząt, w tym tych, które są krócej żyjące i nie są ssakami. Taki sposób myślenia prowadzi do sytuacji, w której wyniki są rozmyte i nieprecyzyjne, co w praktyce może wpłynąć na jakość analiz i decyzji opartych na tych danych. Właściwe formułowanie zapytań jest kluczowe dla zapewnienia, że otrzymujemy tylko te dane, które są istotne dla naszych potrzeb i celów analitycznych.

Pytanie 34

Jak nazywa się platforma wspierająca rozwój oprogramowania w technologii .NET?

A. framework

B. db2

C. eclipse

D. middleware

Framework to kluczowy element w ekosystemie programowania w technologii .NET, który dostarcza zestaw narzędzi, bibliotek i standardów do tworzenia aplikacji. .NET Framework, opracowany przez firmę Microsoft, umożliwia deweloperom tworzenie różnorodnych aplikacji, od aplikacji webowych po aplikacje desktopowe i mobilne. Framework ten wspiera szeroki zakres języków programowania, w tym C#, Visual Basic i F#. Działa na zasadzie dostarczania środowiska uruchomieniowego oraz zestawu klas, które ułatwiają proces programowania, przyspieszając rozwój dzięki gotowym komponentom i wspólnym funkcjonalnościom. Przykładowo, ASP.NET, część .NET Framework, jest używany do budowy aplikacji webowych, co pozwala na łatwe implementowanie funkcji takich jak autoryzacja użytkowników, zarządzanie sesjami i integracja z bazami danych. Dzięki swojej architekturze, .NET Framework przestrzega standardów, takich jak Common Language Specification (CLS), co zapewnia interoperacyjność między różnymi językami programowania. Jest to fundament, na którym opiera się wiele nowoczesnych rozwiązań w świecie IT, co czyni go niezastąpionym narzędziem dla każdego programisty w technologii .NET.

Pytanie 35

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

A. SELECT nazwisko, imie FROM mieszkańcy AS 'Poznań' OR 'Kraków';

B. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto HAVING 'Poznań' OR 'Kraków';

C. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto BETWEEN 'Poznań' OR 'Kraków';

D. SELECT nazwisko, imie FROM mieszkańcy WHERE miasto='Poznań' OR miasto='Kraków';

Wybór błędnych odpowiedzi wynika z nieprawidłowego zrozumienia podstawowych zasad użycia operatorów w SQL oraz sposobu, w jaki warunki filtracji danych powinny być konstruowane. Zapytanie, które wykorzystuje BETWEEN, jest stosowane do porównywania wartości w określonym zakresie, ale w tym przypadku nie jest możliwe wskazanie dwóch różnych wartości, jak w przypadku miast. Operator OR w kontekście BETWEEN nie ma zastosowania, co sprawia, że ta koncepcja jest fundamentalnie błędna. Z drugiej strony, użycie HAVING jest niewłaściwe, ponieważ służy do filtrowania wyników po agregacji danych, a nie do bezpośredniej filtracji na podstawie wartości. Dodatkowo, konstrukcja SELECT z aliasem 'Poznań' OR 'Kraków' jest syntaktycznie niepoprawna, ponieważ operator OR nie może być użyty w tym kontekście. Typowym błędem w myśleniu jest mylenie operatorów logicznych i ich zastosowania w różnych kontekstach zapytań SQL. Zrozumienie, kiedy używać WHERE, HAVING oraz jak działa składnia zapytań, jest kluczowe dla poprawnego pisania i optymalizacji zapytań baz danych.

Pytanie 36

Model fizyczny replikacji bazy danych pokazany na ilustracji to model

A. rozproszony

B. centralnego wydawcy

C. centralnego subskrybenta

D. równorzędny

Równorzędny model replikacji zakłada że wszystkie serwery w sieci mają taką samą rolę i mogą zarówno publikować jak i subskrybować dane co prowadzi do bardziej skomplikowanego zarządzania danymi ze względu na konieczność rozwiązywania konfliktów i synchronizacji zmian w różnych lokalizacjach W przeciwieństwie do modelu centralnego wydawcy ten model nie oferuje centralnego punktu kontroli co może prowadzić do problemów z jednolitością danych W modelu rozproszonym natomiast dane są dzielone między różnymi serwerami co może być przydatne w systemach o dużej skali ale wymaga bardziej złożonej architektury sieci oraz zaawansowanych mechanizmów synchronizacji i redundancji danych Model centralnego subskrybenta z kolei działa odwrotnie do centralnego wydawcy gdzie wiele serwerów publikuje dane do jednego subskrybenta co nie jest praktyczne w większości scenariuszy biznesowych ponieważ ogranicza przepływ informacji i może prowadzić do wąskich gardeł Decyzja o wyborze odpowiedniego modelu replikacji powinna opierać się na potrzebach organizacji oraz specyfice infrastruktury technicznej zastosowanej w firmie błędne zrozumienie tej koncepcji może prowadzić do nieefektywnego działania systemu oraz problemów z dostępnością i bezpieczeństwem danych

Pytanie 37

Baza danych zawiera tabelę artykuły z kolumnami: nazwa, typ, producent, cena. Aby wypisać wszystkie nazwy artykułów jedynie typu pralka, których cena mieści się w zakresie od 1000 PLN do 1500 PLN, należy użyć zapytania

A. SELECT nazwa FROM artykuly WHERE typ="pralka" OR cena BETWEEN 1000 AND 1500

B. SELECT nazwa FROM artykuly WHERE typ="pralka" AND cena FROM 1000 TO 1500

C. SELECT nazwa FROM artykuly WHERE typ="pralka" OR cena BETWEEN 1000 OR 1500

D. SELECT nazwa FROM artykuly WHERE typ="pralka" AND cena BETWEEN 1000 AND 1500

Błędne odpowiedzi opierają się na nieporozumieniach dotyczących składni SQL oraz logicznych błędach w użyciu operatorów. W pierwszym przypadku, użycie 'cena FROM 1000 TO 1500' jest niepoprawne, ponieważ składnia SQL nie wspiera takiego zapisu. Poprawne podejście wymagałoby użycia operatora 'BETWEEN'. Drugie podejście używa operatora 'OR', co skutkuje zwróceniem artykułów, które są typu 'pralka' lub mają cenę w podanym przedziale, a to jest niezgodne z wymaganiem, które wymaga obu warunków jednocześnie. Trzecia opcja z 'BETWEEN' jest bliska poprawnej, ale przez użycie operatora 'OR' dla ceny również nie spełnia wymagań. Ostatnia odpowiedź, która stosuje 'OR' w kontekście ceny, jest błędna, ponieważ nie można używać 'OR' w ten sposób przy definiowaniu zakresu. Typowe błędy myślowe, które mogą prowadzić do takich nieporozumień, obejmują mylenie operatorów logicznych oraz niewłaściwe rozumienie składni SQL. W rezultacie, kluczowe jest zrozumienie, że do filtrowania danych używamy 'AND' dla warunków, które muszą być spełnione jednocześnie oraz 'BETWEEN' do określenia zakresu wartości.

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ę użytkownika.

B. nazwę odzyskiwanej tabeli.

C. adres IP bazy danych.

D. liczbę importowanych obiektów bazy.

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

Zdefiniowana jest tabela o nazwie wycieczki z atrybutami nazwa, cena oraz miejsca (jako liczba dostępnych miejsc). Aby wyświetlić jedynie nazwy tych wycieczek, dla których cena jest mniejsza niż 2000 złotych i które mają co najmniej cztery wolne miejsca, należy użyć zapytania

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

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

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

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

Przyglądając się pozostałym odpowiedziom, można zauważyć, że nie spełniają one wymagań stawianych przez pytanie, co czyni je błędnymi. Pierwsza z nich zawiera operator OR, co oznacza, że przynajmniej jeden z warunków musi być spełniony. W związku z tym, możliwe jest uzyskanie wyników, w których cena jest niższa niż 2000 zł, ale liczba wolnych miejsc wynosi tylko 4 lub mniej, co nie odpowiada wymogowi przynajmniej czterech wolnych miejsc. Dodatkowo, operator AND przed warunkiem miejsc >4 jest niewłaściwy, ponieważ nie zapewnia, że liczba wolnych miejsc będzie co najmniej cztery. Trzecia odpowiedź z kolei wykorzystuje operator * w klauzuli SELECT, co powoduje, że zwrócone zostaną wszystkie kolumny tabeli wycieczki zamiast tylko nazw. Ostatecznie, ostatnia odpowiedź również błędnie używa operatora OR zamiast AND, co prowadzi do sytuacji, w której system może zwrócić wycieczki z ceną powyżej 2000 zł, jeśli chociaż jedno z kryteriów jest spełnione, co nie jest zgodne z zamiarem użytkownika. Te błędy ilustrują istotę precyzyjnego formułowania zapytań SQL, aby uzyskać dokładne i zgodne z wymaganiami wyniki.

Pytanie 40

Aby wykonać usunięcie tabeli, należy użyć kwerendy

A. DELETE

B. DROP TABLE

C. TRUNCATE TABLE

D. UNIQUE

Wybór DELETE jest często mylnie interpretowany jako metoda usuwania tabeli. Komenda DELETE jest używana do usuwania wierszy z tabeli, a nie do usuwania samej tabeli. Na przykład, polecenie DELETE FROM Użytkownicy WHERE id = 1 usunie tylko wiersz odpowiadający konkretnemu identyfikatorowi, pozostawiając tabelę oraz inne dane nietknięte. Inną błędną odpowiedzią jest UNIQUE, która nie jest komendą do usuwania czegokolwiek. To słowo kluczowe jest stosowane do definiowania ograniczeń unikalności dla kolumn w tabeli, aby zapewnić, że wartości w danej kolumnie są niepowtarzalne. Truncating tabeli, przez użycie komendy TRUNCATE TABLE, może być mylone z usunięciem tabeli, ale ta komenda tylko opróżnia tabelę z danych, pozostawiając jej strukturę nienaruszoną. Główne różnice między TRUNCATE a DELETE polegają na tym, że TRUNCATE jest szybsze i nie zapisuje poszczególnych usunięć w dzienniku transakcji. Często w praktyce powstają nieporozumienia związane z zastosowaniem tych poleceń. Dlatego istotne jest zrozumienie, że DROP TABLE jest jedyną komendą, która całkowicie usuwa tabelę, a pozostałe komendy mają inne, odrębne funkcje związane z zarządzaniem danymi w bazie.

Rozpocznij nowy egzamin

Powrót do strony głównej