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: 30 kwietnia 2026 10:52
  • Data zakończenia: 30 kwietnia 2026 11:04

Egzamin niezdany

Wynik: 10/40 punktów (25,0%)

Wymagane minimum: 20 punktów (50%)

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

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

SELECT imie FROM mieszkancy WHERE imie LIKE '_r%';
A. Gerald, Jarosław, Marek, Tamara
B. Arleta, Krzysztof, Krystyna, Tristan
C. Rafał, Rebeka, Renata, Roksana
D. Krzysztof, Krystyna, Romuald
Prawidłowa odpowiedź Arleta Krzysztof Krystyna Tristan jest zgodna z klauzulą LIKE w języku SQL która pozwala na wyszukiwanie wzorców w danych tekstowych W zapytaniu użyto wzorca '_r%' gdzie podkreślenie oznacza dowolny pojedynczy znak a procent dowolną liczbę znaków W tym przypadku imiona muszą mieć 'r' jako drugi znak co jest spełnione dla Arleta Krzysztof Krystyna i Tristan Klauzula LIKE jest często używana w aplikacjach bazodanowych do filtrowania danych tekstowych na przykład w systemach zarządzania klientami gdzie można wyszukiwać nazwiska klientów zaczynające się na określoną literę Dobre praktyki zalecają ostrożne używanie wzorców które mogą prowadzić do pełnych skanów tabel co wpływa na wydajność Indeksowanie kolumn może poprawić szybkość zapytań LIKE jednak należy unikać wzorców zaczynających się od symbolu procenta gdyż pomijają indeksy Warto zrozumieć że LIKE jest potężnym narzędziem w SQL które może znacznie ułatwić pracę z tekstem jednak wymaga ono przemyślanego użycia by nie pogorszyć wydajności bazy danych
Pytanie 2

Na podstawie jakiego parametru oraz z ilu tabel będą zwrócone wiersze w wyniku podanego zapytania?

SELECT * FROM producent, hurtownia, sklep, serwis WHERE
producent.nr_id = hurtownia.nr_id AND
producent.wyrob_id = serwis.wyrob_id AND
hurtownia.nr_id = sklep.nr_id AND
sklep.nr_id = serwis.nr_id AND
producent.nr_id = 1;
A. Na podstawie parametru wyrob_id tylko dla trzech tabel
B. Na podstawie parametru wyrob_id tylko dla trzech tabel
C. Na podstawie parametru nr_id tylko dla trzech tabel
D. Na podstawie parametru nr_id dla wszystkich tabel
Analizując błędne odpowiedzi można zauważyć że kluczowym aspektem w tym pytaniu jest zrozumienie zastosowania parametrów w klauzuli WHERE Odpowiedzi sugerujące selekcję według parametru wyrob_id są nieprawidłowe ponieważ w klauzuli WHERE dominującą rolę odgrywa parametr nr_id choć występuje tam także warunek dotyczący wyrob_id to jednak główną funkcją jest połączenie tabel według nr_id Jest to typowy błąd wynikający z nieuwzględnienia hierarchii oraz sposobu połączenia tabel w relacyjnych bazach danych Ponadto niektóre odpowiedzi ograniczają się wyłącznie do trzech tabel co również jest błędne ponieważ zapytanie obejmuje wszystkie cztery wymienione tabele producent hurtownia sklep i serwis Koncentracja na jednej lub dwóch tabelach często bierze się z pominięcia kluczowych związków logicznych między tabelami jak w przypadku odpowiedzi które ograniczają scope do mniejszej liczby tabel niż rzeczywiście obejmuje zapytanie Kluczową umiejętnością jest zrozumienie jak różne parametry mogą wpływać na wybór danych zwłaszcza w kontekście tworzenia złożonych zapytań SQL gdzie przemyślane zastosowanie klauzul jest niezbędne do efektywnego zarządzania danymi i unikania niepoprawnych interpretacji wyników Właściwe zrozumienie jak parametry takie jak nr_id czy wyrob_id funkcjonują w zapytaniach pozwala na ich poprawne i skuteczne zastosowanie co jest kluczowe w profesjonalnym podejściu do pracy z bazami danych
Pytanie 3

Które tabele będą analizowane w wyniku tego polecenia?

CHECK TABLE pracownicy CHANGED;
A. Tabele, które zostały zmodyfikowane w bieżącej sesji
B. Tabele, które zmieniły się od poprzedniej weryfikacji lub nie zostały poprawnie zamknięte
C. Wyłącznie tabele, które nie zostały poprawnie zamknięte
D. Jedynie tabele odwołujące się do innych
W kontekście podanych odpowiedzi, jedynie opcja pierwsza jest prawidłowa. Niepoprawne jest stwierdzenie, że polecenie CHECK TABLE będzie sprawdzać tylko tabele, które nie zostały poprawnie zamknięte, jak sugeruje druga odpowiedź. Taki scenariusz odnosi się do bardziej ograniczonej funkcji, podczas gdy w realnych zastosowaniach administracyjnych konieczne jest uwzględnienie wszelkich potencjalnych zmian w tabelach, które mogą wpływać na ich integralność. Trzecia odpowiedź wskazuje na tabele referujące do innych, co jest błędnym założeniem, ponieważ polecenie nie ogranicza się do takich relacji, lecz skupia się na detekcji zmian w danych. Ostatecznie, czwarta odpowiedź sugeruje sprawdzanie tabel zmienionych jedynie w bieżącej sesji, co jest nieprawidłowe, ponieważ polecenie z opcją CHANGED poszukuje zmian od ostatniego sprawdzenia bez ograniczenia czasowego do jednej sesji. Typowe błędy myślowe wynikają z niezrozumienia zakresu działania tej funkcji, która ma za zadanie identyfikację zmian wpływających na dane niezależnie od kontekstu czasowego, co jest fundamentalne dla zachowania integralności i poprawności operacji w ramach zarządzania bazą danych, zgodnie z dobrymi praktykami branżowymi w zarządzaniu systemami bazodanowymi.
Pytanie 4

W poniższym zapytaniu SQL, co oznacza symbol gwiazdki w jego wyniku?

SELECT * FROM mieszkancy WHERE imie = 'Anna';
A. zignorowanie warunku dotyczącego imienia
B. pokazanie pola o nazwie '*' (gwiazdka)
C. wyświetlenie wszystkich kolumn z tabeli mieszkancy
D. wyświetlenie wszystkich rekordów z tabeli mieszkancy
W zapytaniu SQL znak gwiazdki (*) nie oznacza wyświetlenia wszystkich rekordów w tabeli, lecz wskazuje, że w wyniku zapytania mamy otrzymać wszystkie kolumny. To ważne rozróżnienie, ponieważ mylenie tych pojęć prowadzi do nieporozumień dotyczących struktury wyników. Każde zapytanie z gwiazdką ograniczone jest jedynie kolumnami nie rekordami. W tym przypadku część WHERE imie = 'Anna' dodatkowo sie mplementuje ograniczenie do konkretnych rekordów co należy do odrębnej części logiki zapytania. Z kolei interpretacja gwiazdki jako pola o nazwie '*' jest błędnym założeniem ponieważ w standardzie SQL nie istnieje możliwość nadania pola o takiej nazwie poprzez użycie gwiazdki. Gdybyśmy chcieli wyświetlić pole o konkretnej nazwie musielibyśmy użyć jego dokładnej nazwy a nie gwiazdki. Interpretacja gwiazdki jako zignorowania warunku WHERE również jest niepoprawna ponieważ WHERE jest integralną częścią zapytania SQL określającą kryteria filtrowania rekordów i działa niezależnie od gwiazdki. Zrozumienie różnic między wyborem kolumn a wyborem rekordów jest kluczowe dla prawidłowego konstruowania zapytań SQL i optymalizacji ich działania w praktycznych zastosowaniach.
Pytanie 5

Jak nazywa się składnik bazy danych, który umożliwia jedynie przeglądanie informacji z bazy, prezentując je w formie tekstowej lub graficznej?

A. Raport
B. Zapytanie
C. Formularz
D. Tabela
Raport to taka fajna część bazy danych, która pozwala ludziom spojrzeć na dane w czytelny sposób. Można je tworzyć, żeby analizować wyniki finansowe czy sprawdzać, jak firma sobie radzi. Przygotowywanie raportów na podstawie zapytań do bazy danych jest super, bo wszystko jest potem poukładane i przemyślane. W praktyce, raporty biorą dane z tabel i pokazują je w ładny sposób, wybierając odpowiednie kolumny i wiersze. Są też takie narzędzia jak SQL Server Reporting Services czy Crystal Reports, które oferują mnóstwo opcji do generowania raportów. To wszystko sprawia, że analiza danych jest lepsza i bardziej wizualna. Dobrze jest regularnie aktualizować raporty i dostosowywać je do potrzeb firmy, bo to pomaga w podejmowaniu decyzji na podstawie faktów.
Pytanie 6

W tabeli podzespoly należy zaktualizować wartość pola URL na "toshiba.pl" dla wszystkich wierszy, gdzie producent to TOSHIBA. W SQL zapis tej modyfikacji będzie wyglądać następująco:

A. UPDATE podzespoly.producent = 'TOSHIBA' SET URL = 'toshiba.pl';
B. UPDATE podzespoly SET URL = 'toshiba.pl' WHERE producent = 'TOSHIBA';
C. UPDATE podzespoly SET URL = 'toshiba.pl'
D. UPDATE producent = 'TOSHIBA' SET URL = 'toshiba.pl';
Odpowiedź jest poprawna, ponieważ zawiera właściwą składnię polecenia SQL do aktualizacji wartości w tabeli. W SQL, instrukcja UPDATE jest używana do modyfikacji danych w istniejących rekordach. W tym przypadku, polecenie 'UPDATE podzespoly SET URL = 'toshiba.pl' WHERE producent = 'TOSHIBA';' zmienia wartość pola URL na 'toshiba.pl' tylko dla tych rekordów, gdzie producent jest równy 'TOSHIBA'. To podejście jest zgodne z dobrymi praktykami w zarządzaniu bazami danych, ponieważ pozwala na precyzyjne określenie, które rekordy mają zostać zaktualizowane. W praktyce, przed wykonaniem takiej aktualizacji, zaleca się zawsze wykonać zapytanie SELECT, aby zweryfikować, które rekordy zostaną zmodyfikowane. Zapewnia to dodatkową warstwę kontroli i zabezpiecza przed niezamierzonymi zmianami. Prawidłowe użycie klauzuli WHERE jest kluczowe, aby nie zmienić wszystkich rekordów w tabeli, co mogłoby doprowadzić do utraty danych. Zrozumienie struktury SQL i zasad działania instrukcji jest fundamentem pracy z relacyjnymi bazami danych.
Pytanie 7

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

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

Na przedstawionej tabeli samochodów wykonano zapytanie SQL:

SELECT model FROM samochody
WHERE rocznik=2016;

Jakie wartości zostaną zwrócone w wyniku tego zapytania?
idmarkamodelrocznikkolorstan
1FiatPunto2016czerwonybardzo dobry
2FiatPunto2002czerwonydobry
3FiatPunto2007niebieskibardzo dobry
4OpelCorsa2016grafitowybardzo dobry
5OpelAstra2003niebieskiporysowany lakier
6ToyotaCorolla2016czerwonybardzo dobry
7ToyotaCorolla2014szarydobry
8ToyotaYaris2004granatowydobry
A. Punto, Corsa, Corolla
B. Fiat, Opel, Toyota
C. Punto, Corsa, Astra, Corolla, Yaris
D. Czerwony, grafitowy
W przypadku błędnych odpowiedzi należy zrozumieć dlaczego nie są one poprawne w kontekście zapytania SQL. Zapytanie SELECT model FROM samochody WHERE rocznik=2016; ma na celu zwrócenie tylko tych modeli samochodów które mają rocznik równy 2016. Jakiekolwiek inne odpowiedzi które zawierają wartości nie spełniające tego warunku są niepoprawne. Na przykład odpowiedzi które zawierają kolory samochodów takich jak czerwony czy grafitowy są błędne ponieważ zapytanie nie dotyczy kolumny kolor. W bazach danych struktura zapytania musi precyzyjnie odpowiadać danym które chcemy uzyskać co oznacza że nie można uwzględniać danych z innych kolumn jeśli nie są one częścią zapytania. Kolejnym błędem jest sugerowanie że zapytanie zwraca marki samochodów takie jak Fiat Opel czy Toyota. Ponownie zapytanie specjalnie wybiera kolumnę model a nie marka dlatego takie odpowiedzi nie są zgodne z zapytaniem. Zrozumienie struktury zapytań SQL i precyzyjne określenie jakie dane są potrzebne jest kluczowe w pracy z bazami danych. Typowe błędy przy konstruowaniu zapytań to niepoprawne określenie kolumny lub warunku co prowadzi do nieoczekiwanych wyników. W związku z tym znajomość zasad konstrukcji zapytań oraz umiejętność przewidywania wyników są niezbędne w codziennej pracy z bazami danych aby uniknąć błędów i zapewnić dokładność przetwarzania danych. SQL jako język do zarządzania danymi wymaga precyzyjnego podejścia i znajomości źródła danych co jest kluczowe dla efektywnego zarządzania informacją. Poprawne sformułowanie zapytania zapewnia że wyniki będą zgodne z oczekiwaniami i będą spełniać założenia analizy danych. Warto także stosować narzędzia walidacji zapytań aby upewnić się że są one optymalne i poprawne co jest dobrym standardem w branży.
Pytanie 9

Aby zainstalować system CMS Joomla!, potrzebne jest środowisko

A. Apache, PHP i MySQL
B. IIS, PERL i MySQL
C. Apache oraz PHP
D. PHP oraz MySQL
Użytkownicy mogą mieć wątpliwości co do wyboru odpowiednich technologii dla uruchomienia systemu CMS Joomla!. Odpowiedzi sugerujące jedynie Apache i PHP ignorują istotny element, jakim jest baza danych. Brak MySQL w konfiguracji oznacza, że nie byłoby możliwości przechowywania oraz zarządzania danymi, co jest kluczowe w każdej aplikacji webowej. Z kolei odpowiedź zakładająca użycie IIS, PERL i MySQL wprowadza nieprawidłową konfigurację, gdyż IIS jest serwerem stworzonym przez Microsoft, który może być używany z innymi technologiami, ale nie jest standardowym wyborem dla Joomla!. PERL to język programowania, który nie jest powszechnie używany w ekosystemie Joomla! i nie jest wymagany do jej działania. Inną kwestią jest odpowiedź proponująca tylko PHP i MySQL, która również pomija serwer WWW - fundament działania aplikacji webowych. Prawidłowe uruchomienie Joomla! wymaga zintegrowania wszystkich trzech komponentów: serwera, języka skryptowego i bazy danych. Ignorowanie tych zależności prowadzi do błędnego rozumienia architektury aplikacji internetowych, co może w przyszłości skutkować problemami w implementacji oraz działaniu projektów opartych na Joomla!. Właściwe podejście wymaga zrozumienia, że każdy z tych elementów odgrywa kluczową rolę w zapewnieniu stabilności, bezpieczeństwa oraz wydajności aplikacji.
Pytanie 10

W programie Microsoft Access mechanizmem ochrony danych związanym z tabelą i kwerendą jest

A. wykorzystanie makr
B. ustalanie limitów przestrzeni na dysku
C. określanie zakresu tabel
D. przypisanie uprawnień
Odpowiedzi sugerujące określanie przestrzeni tabel, wprowadzenie limitów przestrzeni dyskowej oraz stosowanie makr jako formy zabezpieczeń dostępu do danych w Microsoft Access są mylące i nie oddają istoty zarządzania bezpieczeństwem danych w tym programie. Określanie przestrzeni tabel odnosi się do fizycznej organizacji danych w bazie, ale nie ma bezpośredniego wpływu na to, kto ma prawo do ich przeglądania czy edytowania. Nie służy to ochronie danych, a raczej optymalizacji ich przechowywania. Wprowadzenie limitów przestrzeni dyskowej, chociaż może pomóc w zarządzaniu zasobami systemowymi, nie wpływa na kontrolę dostępu, co czyni tę metodę niewłaściwą w kontekście zabezpieczeń. Istotniejsze jest to, że takie podejście nie reguluje, jak użytkownicy oddziałują z danymi, ani jakie mają do nich uprawnienia. Stosowanie makr natomiast dotyczy automatyzacji procesów i usprawnienia funkcjonalności aplikacji, a nie zarządzania dostępem do danych. Użytkownicy mogą błędnie sądzić, że makra mogą pełnić rolę zabezpieczeń, ale w rzeczywistości są one narzędziem do efektywności pracy. Dlatego ważne jest, aby zrozumieć, że skuteczne zarządzanie dostępem do danych opiera się na przypisaniu odpowiednich uprawnień, co jest fundamentem ochrony informacji w środowisku baz danych.
Pytanie 11

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

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

W tabeli mieszkancy znajdują się dane o osobach z całej Polski. Aby zliczyć, ile różnych miast jest zawartych w tej tabeli, należy wykonać kwerendę

A. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;
B. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;
C. SELECT DISTINCT miasto FROM mieszkancy;
D. SELECT COUNT(miasto) FROM mieszkancy;
Wybór niewłaściwych kwerend może prowadzić do błędnych wyników i nieefektywnego przetwarzania danych. Kwerenda SELECT COUNT(miasto) FROM mieszkancy; zlicza wszystkie rekordy w kolumnie miasto, ale nie eliminuje duplikatów. Zatem, jeśli w tabeli występuje wiele osób z tego samego miasta, wynik będzie zawyżony. Na przykład, przy danych o 100 mieszkańcach z Warszawy, kwerenda ta zwróci liczbę 100, co nie odpowiada liczbie unikalnych miast. Wykorzystywanie SELECT DISTINCT miasto FROM mieszkancy; również nie przyniesie pożądanych rezultatów, ponieważ nie dostarcza ich liczby, a jedynie listę unikalnych miast. To podejście może być przydatne, gdy chcemy zobaczyć wszystkie miasta, ale nie odpowiada na pytanie o ich liczbę. Wybór kwerendy SELECT COUNT(miasto) FROM mieszkancy DISTINCT; jest syntaktycznie niepoprawny, ponieważ DISTINCT nie może być użyty w ten sposób w kontekście COUNT. Typowe błędy myślowe prowadzące do takich wniosków to brak uwzględnienia roli DISTINCT w eliminacji duplikatów oraz nieznajomość właściwej składni SQL. Dlatego kluczowe jest zrozumienie funkcji agregujących oraz ich zastosowania w kontekście analizy danych, co jest niezbędne do skutecznego zarządzania bazami danych i wyciągania właściwych wniosków.
Pytanie 13

Jakie informacje z ośmiu wpisanych rekordów w tabeli zwierzęta zostaną przedstawione w wyniku wykonania wskazanej instrukcji SQL?

Ilustracja do pytania
A. Anna Kowalska, Jan Nowak
B. Dika, Fuks
C. Fafik, Brutus, Dika, Fuks
D. Figaro, Dika, Fuks
Pozostałe odpowiedzi nie uwzględniają poprawnej interpretacji zapytania SQL. Kluczem jest zrozumienie, że zapytanie SELECT imie FROM zwierzeta WHERE rodzaj = 2 AND szczepienie = 2016; poszukuje rekordów, gdzie rodzaj jest 2, a szczepienie równe 2016. Figaro, mimo że ma rodzaj 2, nie spełnia kryterium szczepienia, ponieważ jego wartość to NULL, co oznacza brak danych w tej kolumnie. Dlatego jest wykluczony z wyników. W przypadku Fafika i Brutusa, chociaż mają rok szczepienia 2016, ich rodzaj wynosi 1, co również ich dyskwalifikuje. Zwroty takie jak NULL są istotne przy analizie danych, szczególnie w kontekście brakujących wartości. Zrozumienie, jak działa operator AND oraz filtracja wielokryterialna, jest kluczowe dla efektywnego korzystania z SQL. Praktyczne znaczenie ma również znajomość operatorów logicznych i umiejętność ich zastosowania w prawdziwych projektach, gdzie efektywność i poprawność zapytań mają bezpośredni wpływ na działanie systemów.
Pytanie 14

Proces normalizacji tabel ma na celu

A. wyłącznie stworzenie tabel oraz powiązań w bazie
B. weryfikację i poprawę efektywności bazy danych
C. dodanie danych do bazy
D. wizualizację bazy
Normalizacja tabel jest procesem, który ma na celu organizację struktury bazy danych w taki sposób, aby zminimalizować redundancję danych oraz zapewnić integralność danych. Proces ten polega na podziale dużych tabel na mniejsze i łączeniu ich za pomocą relacji, co pozwala na efektywniejsze zarządzanie danymi. Przykładem normalizacji może być podział tabeli zawierającej informacje o klientach i ich zamówieniach na dwie oddzielne tabele: jedna do przechowywania danych klientów, a druga do danych zamówień, z relacją między nimi. W praktyce normalizacja, zgodna z metodologią Codd'a, obejmuje kilka poziomych form normalnych, takich jak 1NF, 2NF, i 3NF, z których każda wprowadza dodatkowe ograniczenia i zasady. Przy odpowiedniej normalizacji można uniknąć problemów z aktualizacją danych, takich jak anomalie aktualizacji czy usuwania, co jest kluczowe w utrzymywaniu wysokiej jakości danych w systemach bazodanowych.
Pytanie 15

Jakie jest zastosowanie zapytania z klauzulą JOIN?

A. wywołać funkcję agregującą
B. określić klucz obcy dla tabeli
C. uzyskać wynik tylko z jednej tabeli
D. pozyskać dane z dwóch tabel, które są ze sobą powiązane
Zrozumienie błędnych odpowiedzi na to pytanie wymaga analizy kilku koncepcji, które są często mylone w kontekście relacyjnych baz danych. Wywoływanie funkcji agregujących, jak SUM czy AVG, ma na celu przetwarzanie danych w obrębie jednej tabeli, co nie jest bezpośrednio związane z mechanizmem łączenia tabel. Klauzula JOIN nie jest używana do wywoływania funkcji agregujących, lecz do łączenia danych z wielu tabel. Z kolei definiowanie klucza obcego jest procesem strukturalnym, który zapewnia integralność relacji między tabelami, ale nie służy do pozyskiwania danych z tych tabel. W przypadku trzeciej odpowiedzi, uzyskanie wyników jedynie z jednej tabeli jest sprzeczne z ideą klauzuli JOIN, która ma na celu eksplorację relacji między tabelami. Błędy myślenia, które prowadzą do nieprawidłowych wniosków, często polegają na braku zrozumienia podstawowych zasad projektowania baz danych i ich normalizacji. W praktyce, efektywne korzystanie z JOIN pozwala na uzyskiwanie zaawansowanych analiz, jak na przykład raporty sprzedaży, które łączą różne źródła danych. Wiedza na temat właściwego użycia klauzul i relacji w bazach danych jest kluczowa dla każdego, kto dąży do skutecznego zarządzania danymi.
Pytanie 16

Wskaż zapytanie, w którym dane zostały uporządkowane.

A. SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek;
B. SELECT AVG(ocena) FROM uczniowie WHERE klasa = 2;
C. SELECT DISTINCT produkt, cena FROM artykuly;
D. SELECT nazwisko FROM firma WHERE pensja > 2000 LIMIT 10;
Odpowiedź SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek jest poprawna, ponieważ zawiera klauzulę ORDER BY, która jest używana do sortowania wyników zapytania w SQL. W tym przypadku, dane są sortowane według wieku mieszkańców, co pozwala na łatwe zrozumienie rozkładu wiekowego w tej grupie. Klauzula ORDER BY jest standardowym elementem SQL, który może sortować wyniki w porządku rosnącym (ASC) lub malejącym (DESC). Przykładowe zastosowanie to raporty, w których użytkownik chce zobaczyć dane uporządkowane według konkretnego kryterium, np. wiek, cena, data. Dobre praktyki sugerują, aby zawsze jasno definiować, które kolumny mają być używane do sortowania, a także zrozumieć, że sortowanie wpływa na wydajność zapytań, zwłaszcza przy dużych zbiorach danych. W przypadku bardziej złożonych zapytań można także łączyć klauzulę ORDER BY z innymi klauzulami, takimi jak GROUP BY, co zwiększa elastyczność w analizie danych.
Pytanie 17

W diagramie ER powiązanie między dwoma zbiorami encji nazywamy

A. związkiem.
B. atrybutem.
C. krotką.
D. dziedziną.
W tym pytaniu łatwo pomylić kilka podstawowych pojęć z teorii baz danych, szczególnie jeśli ktoś kojarzy je tylko z praktyki SQL, a nie z modelu ER. W modelu encja‑związek interesuje nas opis świata rzeczywistego na wyższym poziomie abstrakcji. Zbiory encji to na przykład Pracownicy, Projekty, Produkty, a powiązania między nimi opisujemy właśnie jako związki. Natomiast „krotka” to pojęcie z modelu relacyjnego, czyli z poziomu tabel. Krotka to po prostu pojedynczy wiersz w tabeli, jeden rekord zawierający konkretne wartości atrybutów. Ktoś może intuicyjnie pomyśleć, że skoro wiersz „łączy” wartości atrybutów, to jest jakimś powiązaniem, ale to zupełnie inny poziom opisu: krotka nie jest relacją między zbiorami encji, tylko instancją danych w jednym zbiorze. „Dziedzina” z kolei to zbiór dopuszczalnych wartości dla atrybutu, na przykład dziedzina dla kolumny wiek może być liczbą całkowitą z określonego przedziału, a dla kolumny email – tekstem spełniającym pewien wzorzec. Dziedzina opisuje typ i zakres danych, ale nie opisuje tego, jak tabele czy encje są ze sobą powiązane. Częsty błąd polega na wrzucaniu do jednego worka wszystkich pojęć typu: tabela, rekord, pole, domena, relacja, atrybut, związek – a każde z nich ma dość konkretną definicję. „Atrybut” to po prostu cecha encji, coś w rodzaju kolumny w tabeli: imię, nazwisko, data_urodzenia, cena, ilość. Atrybut opisuje właściwości pojedynczego obiektu, nie tworzy sam z siebie powiązania między zbiorami encji. Oczywiście atrybut może być kluczem obcym, czyli w modelu relacyjnym służyć do realizacji relacji, ale nadal jest to atrybut, a nie sam związek w sensie modelu ER. Z mojego doświadczenia wynika, że największy problem pojawia się, gdy miesza się poziom konceptualny (ER) z poziomem fizycznym (tabele SQL). Na diagramie ER powiązanie między dwoma zbiorami encji nazywamy właśnie związkiem i to ono określa typ relacji (1:1, 1:N, N:M), opcjonalność oraz reguły biznesowe. Dopiero później to powiązanie odwzorowujemy w postaci kluczy obcych, tabel pośredniczących i ograniczeń w konkretnej bazie danych. Dlatego poprawne rozróżnienie tych pojęć jest kluczowe przy profesjonalnym projektowaniu baz danych i zgodne z klasycznymi standardami modelowania danych, które stosuje się w poważnych projektach komercyjnych.
Pytanie 18

Aby utworzyć tabelę w systemie baz danych, trzeba użyć komendy SQL

A. ADD TABLE
B. CREATE TABLE
C. NEW TABLE
D. PLUS TABLE
Żeby stworzyć tabelę w bazie danych, musisz użyć polecenia CREATE TABLE. To jest taki standard w SQL, który jest mega popularny w zarządzaniu bazami danych. Jak używasz tego polecenia, to definiujesz, jak ma wyglądać twoja tabela – nazwę, kolumny i jakie dane będą w tych kolumnach. Na przykład, jeśli chcesz mieć tabelę z informacjami o użytkownikach, będziesz mógł napisać coś takiego: `CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(100), email VARCHAR(100));`. Fajnie jest również ustawić klucz główny (PRIMARY KEY), bo to zabezpiecza unikalność danych w tabeli. To wszystko jest zgodne z zasadami normalizacji danych, co pomaga uniknąć dublowania informacji i poprawia integralność bazy. Tak więc, znajomość CREATE TABLE to podstawa, gdy pracujesz z bazami danych, bo to klucz do dalszego działania z danymi, ich modyfikowania i zarządzania nimi.
Pytanie 19

Zestaw atrybutów relacji, który w minimalny sposób identyfikuje każdy rekord tej relacji, posiadając wartości unikalne oraz niepuste, określamy mianem klucza

A. głównego
B. złożonego
C. kandydującego
D. obcego
Wybór odpowiedzi związanej z kluczem obcym, kandydującym lub złożonym może prowadzić do nieporozumień w zakresie zarządzania danymi w relacyjnych bazach danych. Klucz obcy to atrybut, który tworzy powiązanie między dwiema tabelami, wskazując na klucz główny innej tabeli. Oznacza to, że klucz obcy nie identyfikuje rekordów w swojej tabeli, lecz odnosi się do rekordów w innej tabeli, co jest fundamentalnie różne od roli klucza głównego. Klucz kandydujący to natomiast atrybut, który mógłby pełnić rolę klucza głównego, ale nie jest nim, ponieważ w tabeli może być wiele takich atrybutów, z których jeden ostatecznie zostaje wybrany jako klucz główny. Klucz złożony składa się z dwóch lub więcej atrybutów, które łącznie identyfikują unikalny rekord, co również różni się od prostego klucza głównego. Myląc te pojęcia, można wprowadzić chaos w strukturze bazy danych oraz naruszyć jej integralność, co może prowadzić do błędów w raportowaniu i analizie danych. W praktyce, stosowanie kluczy obcych lub złożonych w sposób niezgodny z ich definicjami prowadzi do trudności w utrzymaniu relacji pomiędzy danymi oraz może generować problemy z wydajnością w operacjach bazodanowych. Zrozumienie różnicy między tymi rodzajami kluczy jest kluczowe dla prawidłowego projektowania bazy danych oraz zapewnienia jej efektywności i przejrzystości.
Pytanie 20

Czym w relacyjnej bazie danych jest odpowiednik encji?

A. kolumna
B. atrybut
C. wiersz
D. tabela
No, odpowiedzi w formie wierszy, kolumn czy atrybutów nie oddają tego, co encja oznacza w relacyjnych bazach danych. Wiersz to niby pojedynczy rekord, ale nie pokazuje encji w pełni. Jakbyśmy uznali wiersz za encję, to moglibyśmy źle zrozumieć, że encja to tylko jeden zestaw danych, a nie cały zbiór rekordów. Kolumna z kolei definiuje atrybuty encji, ale sama nie oddaje encji w całości. Atrybuty są do opisu cech obiektów, ale to nie znaczy, że same w sobie pokazują ich zbiór. Ważne jest, żeby pojąć, że encja jako całość jest reprezentowana przez tabelę, a nie przez pojedyncze składniki jej struktury. W praktyce wiele osób myli te pojęcia, co rzadko prowadzi do efektywnego modelowania danych i może sprawiać problemy z integracją oraz wydajnością zapytań. Dlatego warto uczyć się o strukturze bazy danych, skupiając się na tym, jak różne elementy współdziałają, żeby tworzyć sensowną całość, która dobrze przechowuje i zarządza danymi.
Pytanie 21

Jakie polecenie pozwala na zwiększenie wartości o jeden w kolumnie RokStudiów w tabeli Studenci dla uczniów, którzy są na roku 1÷4?

A. UPDATE Studenci, RokStudiow+1 WHERE RokStudiow < 5
B. UPDATE RokStudiow SET RokStudiow++ WHERE RokStudiow < 5
C. UPDATE Studenci SET RokStudiow WHERE RokStudiow < 5
D. UPDATE Studenci SET RokStudiow = RokStudiow+1 WHERE RokStudiow < 5
Odpowiedzi, które nie są zgodne z właściwą składnią i logiką SQL, prowadzą do nieprawidłowych aktualizacji w bazie danych. Pierwsze podejście, 'UPDATE Studenci, RokStudiow+1 WHERE RokStudiow < 5;', jest błędne, ponieważ nie wykorzystuje poprawnej struktury polecenia UPDATE. W SQL należy określić kolumnę, która ma być zaktualizowana, a nie używać dodatkowego wyrażenia w sekcji FROM. Drugie podejście, 'UPDATE Studenci SET RokStudiow WHERE RokStudiow < 5;', jest również niekompletne, ponieważ brakuje w nim informacji o nowej wartości, którą należy przypisać. W tym przypadku, SET wymaga zarówno kolumny, jak i nowej wartości. Z kolei trzecia odpowiedź, 'UPDATE RokStudiow SET RokStudiow++ WHERE RokStudiow < 5;', nie jest zgodna z składnią SQL, jako że operator '++' nie jest uznawany w standardzie SQL. Błędy te często wynikają z niewłaściwego zrozumienia, jak działa aktualizacja danych w SQL, co może prowadzić do niepoprawnych lub nieefektywnych zapytań. Kluczowym elementem jest znajomość standardów SQL i praktyczne umiejętności ich stosowania w codziennych operacjach zarządzania danymi.
Pytanie 22

W SQL klauzula DISTINCT w poleceniu SELECT spowoduje, że otrzymane dane

A. zostaną uporządkowane
B. będą spełniały dany warunek
C. będą zgrupowane według wskazanego pola
D. nie będą zawierały powtórzeń
Użycie klauzuli DISTINCT w instrukcji SELECT w języku SQL ma na celu eliminację powtórzeń w zwracanych wynikach. Dzięki temu, gdy wykonujemy zapytanie, w którym chcemy uzyskać unikalne wartości z określonej kolumny, możemy uniknąć sytuacji, w której te same dane pojawiają się wielokrotnie. Na przykład, jeśli mamy tabelę z informacjami o klientach, a chcemy otrzymać listę unikalnych miast, w których mieszkają, możemy użyć zapytania SELECT DISTINCT city FROM customers. Ta funkcjonalność jest szczególnie przydatna w raportowaniu i analizie danych, gdzie unikalność wartości ma kluczowe znaczenie. Warto również zauważyć, że klauzula DISTINCT wpływa na wydajność zapytań, dlatego ważne jest, aby używać jej tylko wtedy, gdy jest to rzeczywiście konieczne. Przy stosowaniu DISTINCT warto również znać inne techniki, takie jak grupowanie danych przy użyciu GROUP BY, które może być bardziej odpowiednie w niektórych scenariuszach, szczególnie gdy chcemy wykonywać agregacje.
Pytanie 23

Określ rodzaj relacji między tabelami: Tabela1 oraz Tabela3?

Ilustracja do pytania
A. Jeden do jednego
B. Jeden do wielu
C. Wiele do jednego
D. Wiele do wielu
Rozważając różne typy relacji pomiędzy tabelami w relacyjnych bazach danych, istotne jest zrozumienie konceptu kluczy i połączeń. Relacja jeden do jednego implikuje, że każdemu rekordowi w jednej tabeli odpowiada dokładnie jeden rekord w drugiej. Stosuje się ją tam, gdzie dane można logicznie podzielić na dwie części, jak np. dane osobowe i szczegółowe informacje kontaktowe danej osoby. Relacja jeden do wielu oznacza, że jeden rekord z pierwszej tabeli łączy się z wieloma rekordami w drugiej. Przykładowo, jeden autor może napisać wiele książek. Taka struktura jest typowa przy modelowaniu hierarchii danych i przy relacjach typu rodzic-dziecko. W przypadku relacji wiele do wielu, potrzebna jest trzecia tabela, która pośredniczy między dwoma głównymi tabelami, przechowując ich klucze obce. Umożliwia to powiązanie wielu rekordów z obu stron. Typowe błędy polegają na niepoprawnym wyborze typu relacji, co prowadzi do redundancji danych i problemów z integralnością. Zrozumienie i prawidłowe zastosowanie tych koncepcji jest kluczowe dla projektowania efektywnych i skalowalnych baz danych, wspierając jednocześnie złożone operacje i analizy. Wybór niewłaściwego typu relacji może prowadzić do trudności w zarządzaniu danymi i skomplikowanych zapytań, co jest znanym wyzwaniem w zarządzaniu bazami danych.
Pytanie 24

W języku PHP uzyskano wyniki kwerend z bazy danych przy użyciu polecenia mysql_query. Aby wydobyć z otrzymanej kwerendy pojedynczy wiersz danych, konieczne jest użycie polecenia

A. mysql_fetch_lengths
B. mysql_fetch_row
C. mysql_field_len
D. mysql_list_fields
Wszystkie inne odpowiedzi są nieprawidłowe z różnych powodów, które warto dokładnie zrozumieć. mysql_field_len to funkcja używana do uzyskania długości pola w danej tabeli, a więc nie ma zastosowania w kontekście pobierania wierszy danych. To podejście jest typowym błędem myślowym, w którym zamiast skupić się na operacji, która dotyczy danych wynikowych, użytkownik myli funkcje związane z metadanymi i długościami pól. mysql_list_fields, z kolei, służy do uzyskiwania listy pól w danej tabeli, co również nie odpowiada na potrzebę pobrania danych z kwerendy. Znowu, może to wynikać z nieporozumienia dotyczącego różnicy między metadanymi a rzeczywistymi danymi. Ostatnia funkcja, mysql_fetch_lengths, zwraca długości wszystkich pól w ostatnio pobranym wierszu, co jest przydatne, ale również nie sprosta zadaniu pobrania wiersza danych. Zrozumienie, że różne funkcje mają różne zastosowania, jest kluczowe w programowaniu, szczególnie w pracy z bazami danych, gdzie precyzyjność i znajomość funkcjonalności API są niezbędne do efektywnego działania aplikacji. Warto również dodać, że w kontekście nowoczesnych aplikacji zamiast przestarzałych funkcji mysql, lepiej jest używać mysqli lub PDO, które są bardziej bezpieczne i oferują lepsze wsparcie dla nowoczesnych praktyk programistycznych.
Pytanie 25

Narzędzie używane do organizowania i przedstawiania danych z wielu wpisów w celu ich wydruku lub dystrybucji to

A. makropolecenie
B. formularz
C. kwerenda
D. raport
Kwerenda, formularz i makropolecenie to narzędzia, które mają zupełnie inne zadania niż raportowanie. Kwerenda to tak jakby pytanie do bazy danych, które pozwala wyciągać konkretne informacje z całkiem dużej ilości danych. Jej głównym celem jest raczej filtracja niż grupowanie danych, więc niekoniecznie nadaje się do tworzenia raportów. Formularz to interfejs, za pomocą którego możemy wprowadzać lub edytować dane, ale nie pomoże nam w grupowaniu czy ładnej prezentacji w formie raportu. Makropolecenie to natomiast zestaw instrukcji w Excelu, które mogą automatyzować powtarzalne zadania, co jest spoko, ale nie ma tu mowy o tworzeniu raportów. Widać więc, że każde z tych narzędzi ma swoje przeznaczenie i nie może zastąpić efektywnego raportu, który jest kluczowy w analizie danych.
Pytanie 26

W SQL, aby uniemożliwić stworzenie konta przy wykonywaniu kwerendy CREATE USER, gdy konto już istnieje, można zastosować następującą składnię

A. CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
B. CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
C. CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
D. CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
Odpowiedzi, które nie zawierają klauzuli 'IF NOT EXISTS', nie są optymalne, ponieważ mogą prowadzić do błędów, gdy próbuje się utworzyć konto, które już istnieje. W przypadku polecenia 'CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';', jeśli konto 'anna' jest już w systemie, użytkownik otrzyma błąd, co skutkuje niepowodzeniem całego skryptu. W kontekście administracji baz danych, jest to szczególnie problematyczne, gdy skrypty są uruchamiane automatycznie, ponieważ mogą one przerywać dalsze operacje. Natomiast składnia 'CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' jest nieprawidłowa, ponieważ nie istnieje w standardzie SQL. Użytkownicy mogą mylić 'DROP' z opcją usunięcia konta, co w praktyce nie powinno być podejmowane bez wyraźnej intencji. Ostatecznie, 'CREATE OR REPLACE USER...' działa odmiennie, ponieważ nie jest standardową operacją w SQL dla użytkowników; bardziej odpowiednie byłoby jej zastosowanie w kontekście obiektów, takich jak procedury czy widoki. Kluczowe jest zrozumienie, że błędne podejście do tworzenia użytkowników może prowadzić do chaosu w zarządzaniu bazą danych i stwarzać potencjalne zagrożenia dla bezpieczeństwa. Dlatego tak istotne jest stosowanie klauzuli 'IF NOT EXISTS', co jest zgodne z najlepszymi praktykami w branży zarządzania systemami baz danych.
Pytanie 27

W języku SQL polecenie INSERT INTO

A. dodaje tabelę.
B. dodaje pola do tabeli.
C. wprowadza dane do tabeli.
D. aktualizuje rekordy określoną wartością.
W SQL bardzo łatwo pomylić polecenia, bo wszystkie wyglądają dość podobnie, ale każde ma swoje wyraźne zadanie. INSERT INTO jest komendą typowo do pracy na danych, nie na strukturze bazy. Jeżeli ktoś myśli, że tym poleceniem „dodaje tabelę”, to miesza dwa różne obszary: definicję struktury i operacje na rekordach. Tworzenie nowej tabeli wykonuje się za pomocą CREATE TABLE, gdzie określamy nazwy kolumn, typy danych, klucze główne itd. INSERT zakłada, że tabela już istnieje i jest gotowa na przyjmowanie rekordów. Podobnie błędne jest kojarzenie INSERT z dodawaniem pól (kolumn) do tabeli. Modyfikacja struktury tabeli, czyli dokładanie nowych kolumn, zmiana typów, usuwanie kolumn, to domena polecenia ALTER TABLE. To jest tzw. DDL (Data Definition Language). Natomiast INSERT należy do DML (Data Manipulation Language), czyli tej części SQL, która operuje na danych: INSERT, UPDATE, DELETE, SELECT. Jeśli próbujemy INSERT-em „dodać pole”, to tak jakby śrubokrętem próbować wbijać gwóźdź – czasem coś się tam stanie, ale to w ogóle nie to narzędzie. Częstym nieporozumieniem jest też mylenie INSERT i UPDATE. UPDATE służy do aktualizacji istniejących rekordów, czyli zmiany wartości w wierszach, które już są w tabeli. Wykorzystuje się przy tym klauzulę WHERE, żeby wskazać, które rekordy mają zostać zmodyfikowane. INSERT natomiast zawsze tworzy nowy wiersz. Jeśli ktoś uważa, że INSERT „aktualizuje rekordy określoną wartością”, to tak naprawdę opisuje działanie UPDATE. W praktyce prowadzi to do błędów typu duplikowanie danych zamiast ich poprawiania. Moim zdaniem największy błąd myślowy polega na wrzucaniu wszystkiego, co „coś zmienia w bazie”, do jednego worka. Tymczasem w dobrze zaprojektowanym systemie bazodanowym wyraźnie rozdziela się operacje na schemacie (CREATE, ALTER, DROP) od operacji na danych (INSERT, UPDATE, DELETE). Zrozumienie tej różnicy jest kluczowe, żeby pisać poprawne i bezpieczne zapytania SQL. INSERT INTO zawsze oznacza: dodaj nowy rekord do istniejącej tabeli, z wartościami zgodnymi z jej strukturą i ograniczeniami.
Pytanie 28

Została stworzona baza danych z tabelą podzespoły, która zawiera pola: model, producent, typ, cena. Aby uzyskać listę wszystkich modeli pamięci RAM od firmy Kingston uporządkowanych od najniższej do najwyższej ceny, należałoby użyć kwerendy:

A. SELECT model FROM podzespoły WHERE typ='RAM' AND producent='Kingston' ORDER BY cena ASC
B. SELECT model FROM producent WHERE typ='RAM' OR producent='Kingston' ORDER BY podzespoły ASC
C. SELECT model FROM podzespoły WHERE typ='RAM' AND producent='Kingston' ORDER BY cena DESC
D. SELECT model FROM podzespoły WHERE typ='RAM' OR producent='Kingston' ORDER BY cena DESC
Analizując niepoprawne odpowiedzi, można zauważyć kilka istotnych błędów koncepcyjnych, które prowadzą do błędnych wyników. W przypadku pierwszej z błędnych kwerend, użycie klauzuli ORDER BY cena DESC sprawia, że wyniki są sortowane od najdroższej do najtańszej, co jest sprzeczne z wymaganiem przedstawienia modeli w porządku rosnącym. Problem ten często wynika z błędnego zrozumienia celu sortowania, co może prowadzić do frustracji użytkowników poszukujących najkorzystniejszych cen. W innej z błędnych odpowiedzi, klauzula WHERE wykorzystuje operator OR zamiast AND, co skutkuje zwróceniem modeli RAM od różnych producentów, co jest niewłaściwe w kontekście zadania, które wymaga danych tylko od producenta Kingston. Ponadto, ostatnia odpowiedź zawiera również błąd w odniesieniu do źródła danych, wskazując na tabelę 'producent' zamiast 'podzespoły'. W SQL kluczowe jest zrozumienie struktury danych oraz logiczne formułowanie zapytań, aby uniknąć nieścisłości. Błędy te mogą wynikać z mylnego założenia, że każda zmiana w zapytaniu nie wpływa na jego integralność i wynik, co jest niebezpiecznym podejściem w praktyce programistycznej.
Pytanie 29

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

A. niepowtarzalnych odczytów
B. odczytów widm
C. brudnych odczytów
D. utraty aktualizacji
Wybór odpowiedzi 'niepowtarzalnych odczytów', 'brudnych odczytów' lub 'utraty aktualizacji' wskazuje na brak zrozumienia, jak działają różne poziomy izolacji transakcji w kontekście baz danych. Odczyty niepowtarzalne polegają na tym, że transakcja może odczytać różne wartości w kolejnych odczytach tego samego wiersza, co jest problemem rozwiązywanym przez poziom Repeatable Read. Oznacza to, że dane odczytane w jednym kroku transakcji pozostają spójne do końca tej transakcji, a zatem nie są one narażone na zmiany poprzez inne transakcje w tym samym czasie. Brudne odczyty występują, gdy jedna transakcja odczytuje dane zapisane przez inną, jeszcze niezakończoną transakcję, co jest problemem z kolei eliminowanym przez poziomy izolacji takie jak Read Committed. Utrata aktualizacji to inny problem, który polega na tym, że dwie transakcje odczytują tę samą wartość i zapisują zmodyfikowane wartości, przy czym ostatnia zapisuje nadpisując wcześniejszą, co także nie jest bezpośrednim problemem w kontekście Repeatable Read. W praktyce, zrozumienie różnicy między tymi problemami jest kluczowe dla zapewnienia spójności transakcji. Warto zatem studiować dokumentację i standardy, aby właściwie dobierać poziomy izolacji w zależności od wymagań konkretnej aplikacji.
Pytanie 30

Wskaż poprawne zdanie dotyczące poniższego polecenia. ```CREATE TABLE IF NOT EXISTS ADRES (ulica VARCHAR(70)) CHARACTER SET utf8); ```

A. Nie można dodawać do tabeli ulic, które zawierają polskie znaki w nazwie
B. IF NOT EXISTS używa się opcjonalnie, żeby potwierdzić, że taka tabela nie istnieje w bazie danych
C. Rekord tabeli nie może mieć wartości 3 MAJA
D. Klauzula CHARACTER SET utf8 jest wymagana
Klauzula IF NOT EXISTS w poleceniu CREATE TABLE jest używana do zapobiegania błędom, które mogą wystąpić, gdy próbujesz stworzyć tabelę, która już istnieje w danej bazie danych. Dzięki temu operatorowi, jeśli tabela o podanej nazwie już istnieje, polecenie nie zostanie wykonane, co pozwala na uniknięcie konfliktów oraz zbędnych błędów w aplikacji. Jest to szczególnie przydatne w sytuacjach, gdy skrypty są uruchamiane wielokrotnie, na przykład podczas aktualizacji lub migracji bazy danych. Użycie IF NOT EXISTS jest opcjonalne, ale zalecane dla poprawności i stabilności kodu SQL. Przykład praktyczny: można stworzyć tabelę 'klienci' z poleceniem 'CREATE TABLE IF NOT EXISTS klienci (id INT PRIMARY KEY, imie VARCHAR(100));', co zapobiega próbie utworzenia tabeli, która już istnieje. Zgodnie z standardami SQL, operator ten jest powszechnie akceptowany w większości systemów zarządzania bazami danych, takich jak MySQL, PostgreSQL czy SQLite, co czyni go uniwersalnym rozwiązaniem w projektach opartych na bazach danych.
Pytanie 31

Jak można utworzyć kopię zapasową bazy danych MySQL?

A. modyfikowaniem danych
B. importowaniem bazy
C. agregowaniem danych
D. eksportowaniem bazy
Import bazy danych nie jest procesem, który może służyć jako kopia zapasowa, ponieważ polega on na wprowadzaniu danych do bazy z plików zewnętrznych. Wykorzystuje się go głównie do przywracania danych z wcześniej stworzonych kopii zapasowych lub do migracji danych pomiędzy bazami. Zatem, import nie generuje kopii zapasowej, a jedynie odtwarza stan bazy z już istniejących danych. Agregacja danych, z kolei, to proces, który polega na zbieraniu i przetwarzaniu danych z różnych źródeł w celu uzyskania bardziej złożonych informacji, co nie ma nic wspólnego z tworzeniem kopii zapasowych. Chociaż agregacja może być przydatna do analizy danych, nie ma zastosowania w kontekście ochrony danych bazy. Modyfikacja danych odnosi się do zmiany istniejących rekordów w bazie danych, co również nie jest związane z procesem tworzenia kopii zapasowych. Modyfikacja może prowadzić do utraty ważnych informacji, dlatego też kluczowe jest najpierw zabezpieczenie danych poprzez eksport przed jakimikolwiek zmianami. W związku z tym, żadna z wymienionych odpowiedzi nie jest właściwa w kontekście wykonywania kopii zapasowej bazy MySQL.
Pytanie 32

W tabeli mieszkancy znajdują się dane o osobach z całego kraju. Aby ustalić, ile unikalnych miast występuje w tej tabeli, trzeba zapisać kwerendę

A. SELECT COUNT(miasto) FROM mieszkancy;
B. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;
C. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;
D. SELECT DISTINCT miasto FROM mieszkancy;
Wybór odpowiedzi, która polega na użyciu tylko funkcji COUNT, jak w "SELECT COUNT(miasto) FROM mieszkancy;" nie jest najlepszy. To zapytanie zlicza wszystkie wystąpienia miast, w tym duplikaty, więc dostajesz łączną liczbę wierszy w kolumnie 'miasto', a to nie pokazuje, ile tak naprawdę jest unikalnych miejscowości. Moim zdaniem, ta pomyłka może prowadzić do złych wniosków, bo nie uwzględniasz różnorodności danych. Użycie DISTINCT, na przykład w "SELECT DISTINCT miasto FROM mieszkancy;", też nie daje ci liczby unikalnych miast, tylko listę ich. Niektórzy mogą myśleć, że wystarczy wylistować unikalne wartości, żeby wiedzieć, ile ich jest, ale to błędne podejście do zliczania. A ta odpowiedź "SELECT COUNT(miasto) FROM mieszkancy DISTINCT;" jest też niepoprawna, bo nie możesz używać DISTINCT w takim kontekście. Z doświadczenia wiem, że zrozumienie zasad dotyczących funkcji agregujących i filtrujących w SQL jest naprawdę kluczowe, jeśli chcesz dobrze zarządzać danymi i prowadzić sensowne analizy. Dlatego warto zastanowić się nad tym, jak używasz tych funkcji, żeby uniknąć typowych błędów przy interpretacji wyników zapytań w bazach danych.
Pytanie 33

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

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

Podana jest tabela psy z polami: imie, rasa, telefon_wlasciciela, rok_szczepienia. Jakie polecenie SQL należy zastosować, aby znaleźć numery telefonów właścicieli, których psy były szczepione przed rokiem 2015?

A. SELECT imie, rasa FROM psy WHERE rok_szczepienia > 2015
B. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015
C. SELECT psy FROM rok_szczepienia < 2015
D. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia > 2015
Wybór odpowiedzi 'SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015;' jest poprawny z kilku powodów. Przede wszystkim, zapytanie to spełnia wymogi dotyczące selekcji danych z tabeli 'psy', koncentrując się na właścicielach psów, które zostały zaszczepione przed rokiem 2015. W SQL klauzula WHERE jest kluczowym elementem, który pozwala na filtrowanie wyników według określonych kryteriów. W tym przypadku, filtrujemy psy na podstawie roku ich szczepienia, co jest zgodne z naszym celem. Ponadto, selekcjonowanie tylko kolumny 'telefon_wlasciciela' jest właściwe, ponieważ chcemy uzyskać konkretne dane, a nie całą tabelę. Użycie operatora '<' jest odpowiednie, ponieważ skupia się na roku mniejszym niż 2015. Praktycznym zastosowaniem tego zapytania może być uzyskanie kontaktów do właścicieli, aby przypomnieć im o konieczności ponownego zaszczepienia ich psów, co wpisuje się w działania profilaktyczne i zdrowotne w dbaniu o dobrostan zwierząt. Warto również pamiętać, że dobre praktyki w projektowaniu baz danych zalecają użycie poprawnych typów danych oraz właściwe indeksowanie kolumn, co może przyspieszyć wykonanie zapytań tego typu.
Pytanie 35

Na ilustracji przedstawiono wybór formatu pliku do importu bazy danych. Który format powinien być wykorzystany, jeśli dane zostały wyeksportowane z programu Excel i zapisane jako tekst z użyciem przecinka do oddzielania wartości pól?

Ilustracja do pytania
A. XML
B. SQL
C. ESRI
D. CSV
Format SQL jest używany do pracy z relacyjnymi bazami danych, ale nie jest odpowiedni do importu danych z Excela, jeśli są one zapisane w postaci tekstowej z przecinkami. SQL to język zapytań, który służy do zarządzania i modyfikacji danych w bazach danych, ale nie jest formatem przechowywania danych. W przypadku ESRI, mamy do czynienia z formatem plików kształtu, który jest specyficzny dla danych geoprzestrzennych i nie jest dostosowany do ogólnych danych tabelarycznych, takich jak te z Excela. Format ESRI jest używany głównie w GIS do przechowywania danych przestrzennych. Natomiast XML jest formatem znaczników, który umożliwia przechowywanie danych w strukturze drzewa i jest bardziej złożony niż CSV. XML jest używany wtedy, gdy potrzebujemy skomplikowanej struktury danych z definicjami hierarchii, co czyni go mniej efektywnym dla prostego importu tabelarycznego. Wybór niewłaściwego formatu wynika często z niezrozumienia specyfiki i przeznaczenia każdego z nich. Często błędnym założeniem jest przekonanie, że bardziej skomplikowane formaty, takie jak XML czy SQL, są zawsze lepszym wyborem, co nie jest prawdą, gdy celem jest prostota i kompatybilność z szeroką gamą programów i systemów. CSV pozostaje najefektywniejszym rozwiązaniem dla tego typu danych dzięki swojej prostocie i łatwości użycia w wielu kontekstach technologicznych.
Pytanie 36

W tabeli mieszkancy, która zawiera pola id, imie, nazwisko, ulica, numer oraz czynsz (kwota całkowita), należy uzyskać informacje o osobach zamieszkujących ulicę Mickiewicza pod numerami 71, 72, 80, których czynsz nie przekracza 1000 zł. Klauzula WHERE w zapytaniu powinna wyglądać następująco

A. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) OR czynsz < 1000
B. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) AND czynsz < 1000
C. WHERE ulica = 'Mickiewicza' AND numer > 70 AND numer < 81 OR czynsz < 1000
D. WHERE ulica = 'Mickiewicza' OR numer IN (71, 72, 80) OR czynsz < 1000
Jak patrzę na twoje odpowiedzi, to widzę, że główny problem leży w tym, jak używasz operatorów logicznych i jak stawiasz warunki. W pierwszej próbie, zastosowanie OR, czyli 'ulica = 'Mickiewicza' OR numer IN (71, 72, 80) OR czynsz < 1000', prowadzi do tego, że dostaniesz dane wszystkich mieszkańców, nawet tych z innych ulic, co zupełnie nie jest tym, czego szukamy. W drugiej opcji, klauzula 'numer > 70 AND numer < 81' znowu nie daje ci dokładnych numerów mieszkań, bo może zwrócić wyniki spoza naszego zakresu. Trzecia wersja też nie wychodzi najlepiej, bo łączy operator OR i przez to dostajesz dane o czynszu poniżej 1000 zł, niezależnie od lokalizacji. Kluczowy błąd w zrozumieniu SQL polega na tym, że AND i OR różnią się w swoich zastosowaniach i wpływają na końcowy wynik. Ogólnie, lepiej starannie przemyśleć zapytania SQL i testować je na małych zbiorach danych, żeby nie wpaść w pułapki.
Pytanie 37

W systemie MySQL przyznanie roli o nazwie DBManager umożliwia użytkownikowi wykonywanie

A. zakładanie użytkowników serwera oraz definiowanie ich haseł
B. wszystkie operacje na bazach danych serwera
C. nadzór nad serwerem
D. wszystkie operacje związane z bazami danych oraz użytkownikami serwera
Wybór odpowiedzi, która sugeruje, że rola DBManager przyznaje prawa do monitorowania serwera, tworzenia użytkowników serwera oraz wykonywania wszystkich operacji na bazach danych i użytkownikach, może prowadzić do mylnych wniosków na temat rzeczywistych możliwości tej roli. Monitorowanie serwera jako funkcja nie jest bezpośrednio związane z rolą DBManager. Chociaż monitorowanie jest istotnym aspektem zarządzania bazami danych, odpowiednie uprawnienia związane z tą funkcjonalnością są przyznawane innym rolom lub użytkownikom posiadającym konkretne przywileje, takie jak rola DBMonitor. Tworzenie użytkowników serwera i ustawianie im haseł również wykracza poza standardowe uprawnienia roli DBManager. Zwykle te czynności są przypisane administratorom systemu, którzy mają kontrolę nad bezpieczeństwem całego środowiska bazodanowego. Odpowiedzi sugerujące możliwość wykonywania wszelkich operacji na bazach danych i użytkownikach mogą sugerować, że rola DBManager obejmuje pełne uprawnienia administracyjne, co nie jest zgodne z praktykami bezpieczeństwa, które zalecają ograniczanie uprawnień w oparciu o zasadę najmniejszych uprawnień. Takie zrozumienie jest kluczowe, ponieważ przyznawanie zbyt szerokich uprawnień może prowadzić do luk w zabezpieczeniach i nadużyć, co narusza standardy zarządzania danymi i bezpieczeństwa w organizacjach. Dlatego ważne jest, aby dokładnie rozumieć zakres dostępnych ról i ich odpowiedzialności, aby zapewnić właściwe zarządzanie dostępem i bezpieczeństwem danych.
Pytanie 38

W systemie baz danych sklepu znajdują się dwie tabele połączone relacją: produkty oraz oceny. Tabela oceny zawiera dowolną liczbę ocen wystawionych przez klientów dla konkretnego produktu, opisaną poprzez pola: id, ocena (pole numeryczne), produktID (klucz obcy). Aby uzyskać maksymalną ocenę dla produktu o ID wynoszącym 10, należy wykorzystać zapytanie

A. MAX SELECT ocena FROM oceny WHERE produktID = 10;
B. SELECT MAX(ocena) FROM oceny WHERE produktID = 10;
C. SELECT MAX COUNT(ocena) FROM oceny WHERE produktID = 10;
D. COUNT MAX SELECT ocena FROM oceny WHERE produktID = 10;
Analizując pozostałe odpowiedzi, można zauważyć, że każda z nich zawiera błędy w składni i logice SQL, które prowadzą do niewłaściwych wniosków. W przypadku pierwszej niepoprawnej odpowiedzi, sformułowanie 'COUNT MAX SELECT' jest niepoprawne, ponieważ łączy niezgodne ze sobą komendy. Nie ma takiej funkcji jak 'COUNT MAX'; COUNT służy do zliczania wierszy, a nie do obliczania maksymalnej wartości. W kolejnej odpowiedzi 'MAX SELECT' z kolei jest niepoprawnym użyciem słów kluczowych SQL. MAX powinien występować jako część złożonego zapytania SELECT, a nie jako osobna funkcja. Takie podejście może być wynikiem braku zrozumienia struktury komend SQL. Ostatnia odpowiedź, 'SELECT MAX COUNT(ocena)', również jest błędna, ponieważ nie możemy jednocześnie używać MAX i COUNT w taki sposób. MAX zwraca jedną wartość, podczas gdy COUNT zlicza, co wprowadza zamieszanie. Zastosowanie niepoprawnych konstrukcji SQL może prowadzić do błędów w wykonaniu zapytań oraz do zwracania nieoczekiwanych wyników, co jest szczególnie niebezpieczne w kontekście aplikacji produkcyjnych oraz baz danych, w których precyzyjne dane są kluczowe dla podejmowania właściwych decyzji. Dlatego ważne jest, aby dokładnie zrozumieć sposób działania funkcji agregujących oraz ich prawidłowe zastosowanie w zapytaniach.
Pytanie 39

Po zrealizowaniu polecenia SQL użytkownik Ela zyska możliwość wykorzystania poniższych uprawnień:

GRANT SELECT, INSERT, UPDATE, DELETE ON baza1.tab1 TO 'Ela'@'localhost';
A. realizować wszystkie działania na strukturze danych
B. tylko dodawać oraz zmieniać dane
C. tylko tworzyć i zmieniać strukturę tabeli
D. przeprowadzać wszystkie operacje na danych
Wybór odpowiedzi, która sugeruje, że użytkownik może jedynie dodawać i modyfikować dane, jest mylny, ponieważ nie uwzględnia uprawnienia SELECT, które jest również częścią przyznanych uprawnień. Ograniczając interpretację do dodawania i modyfikowania danych, można zignorować kluczowy aspekt bazy danych – możliwość ich przeglądania. Ponadto, twierdzenie, że użytkownik może jedynie tworzyć i modyfikować strukturę tabel, jest nieadekwatne, ponieważ polecenie GRANT nie dotyczy uprawnień do zmiany struktury bazy danych, takich jak dodawanie nowych tabel czy kolumn. Takie operacje są regulowane przez inne uprawnienia, które muszą być również przyznane. W sytuacji, gdy mówimy o operacjach na strukturze danych, należy uwzględnić, że uprawnienia GRANT dotyczą jedynie pracy z danymi przechowywanymi w tabelach, a nie z ich strukturalnymi aspektami. Pojęcie 'wszystkie operacje na strukturze danych' może wprowadzać w błąd, ponieważ nie odnosi się do przyznanych uprawnień, które nie obejmują na przykład tworzenia nowych tabel lub zmiany ich definicji. Dlatego ważne jest, aby dokładnie zrozumieć różnicę między uprawnieniami do operacji na danych a uprawnieniami do zarządzania strukturą bazy danych. Kluczowym błędem jest zatem niedostrzeganie znaczenia uprawnienia SELECT oraz niewłaściwe rozumienie zakresu przyznawanych uprawnień w kontekście SQL.
Pytanie 40

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

A. DROP pracownicy WHERE rodzaj_umowy IS NULL
B. DROP pracownicy FROM rodzaj_umowy = 0
C. DELETE FROM pracownicy WHERE rodzaj_umowy IS NULL
D. DELETE pracownicy WHERE rodzaj_umowy ='brak'
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.
Rozpocznij nowy egzamin
Powrót do strony głównej