Wyniki egzaminu

Informacje o egzaminie:
  • Zawód: Technik programista
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 16 kwietnia 2026 08:58
  • Data zakończenia: 16 kwietnia 2026 09:37

Egzamin niezdany

Wynik: 18/40 punktów (45,0%)

Wymagane minimum: 20 punktów (50%)

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

Określenie powiązań między tabelami w bazie danych MySQL realizuje klauzula

A. ORDER BY
B. REFERENCES
C. PRIMARY KEY
D. INDEX
Podczas analizy pozostałych dostępnych odpowiedzi, należy zauważyć, że nie są one odpowiednie do ustalania relacji pomiędzy tabelami w MySQL. Klauzula INDEX służy do poprawy wydajności zapytań poprzez tworzenie indeksów na kolumnach, co przyspiesza dostęp do danych. Indeksy są używane głównie w kontekście optymalizacji zapytań, a nie do definiowania relacji między tabelami. Z kolei klauzula ORDER BY jest używana do sortowania wyników zapytań według określonych kolumn. Nie ma ona wpływu na strukturalne powiązanie danych w bazie, a jedynie na sposób ich prezentacji w wynikach zapytań. Ostatnia z wymienionych opcji, PRIMARY KEY, jest kluczowym elementem w każdej tabeli, który zapewnia unikalność danych w kolumnie lub zestawie kolumn. Chociaż klucz podstawowy jest niezbędny do identyfikacji rekordów, sam w sobie nie tworzy relacji między tabelami, ale raczej definiuje unikalny identyfikator dla wierszy w danej tabeli. Warto zatem zauważyć, że klauzula REFERENCES jest jedynym poprawnym wyborem do ustalenia relacji między tabelami, podczas gdy pozostałe opcje pełnią inne funkcje w kontekście zarządzania danymi.

Pytanie 2

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 o indeksie Janek
B. Janek o indeksie im
C. im z następującym numerem indeksu
D. Janek z następującym numerem indeksu
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 3

Wskaź na właściwą sekwencję tworzenia aplikacji?

A. Analiza potrzeb klienta, specyfikacja wymagań, tworzenie, wdrażanie, testowanie
B. Analiza potrzeb klienta, specyfikacja wymagań, tworzenie, testowanie, wdrażanie
C. Specyfikacja wymagań, analiza potrzeb klienta, tworzenie, wdrażanie, testowanie
D. Tworzenie, analiza potrzeb klienta, specyfikacja wymagań, wdrażanie, testowanie
Prawidłowa kolejność tworzenia aplikacji zaczyna się od analizy wymagań klienta, co jest kluczowym etapem, pozwalającym zrozumieć oczekiwania oraz potrzeby użytkowników. Następnie, na podstawie zebranych informacji, sporządzana jest specyfikacja wymagań, która dokładnie opisuje, jakie funkcjonalności i cechy powinna posiadać aplikacja. To dokument, który stanowi fundament dla dalszych prac programistycznych. W kolejnej fazie następuje etap tworzenia, w którym programiści przekształcają specyfikację w kod, implementując wszystkie wymagane funkcje. Po zakończeniu kodowania, aplikacja przechodzi testy, które mają na celu wykrycie błędów oraz weryfikację zgodności z wymaganiami. W końcowej fazie, po przeprowadzeniu testów i eliminacji ewentualnych problemów, aplikacja jest wdrażana, co oznacza jej udostępnienie użytkownikom. Cały proces powinien być zgodny z najlepszymi praktykami oraz standardami, takimi jak Agile czy Scrum, które kładą duży nacisk na iteracyjny rozwój oraz stałą komunikację z klientem, co zwiększa szansę na sukces projektu.

Pytanie 4

Jakiego rodzaju relację uzyskuje się, łącząc ze sobą dwie tabele za pomocą kluczy głównych?

A. wiele do wielu
B. jeden do wielu
C. wiele do jednego
D. jeden do jednego
Wybór innych odpowiedzi, takich jak 'wiele do wielu', 'wiele do jednego' czy 'jeden do wielu', wynika zazwyczaj z nieporozumienia dotyczącego definicji i zastosowania relacji w bazach danych. Relacja wiele do wielu występuje, gdy wiele rekordów w jednej tabeli może być powiązanych z wieloma rekordami w innej tabeli, co jest często realizowane przez wprowadzenie tabeli pośredniczącej. Na przykład, w przypadku tabel 'Studenci' i 'Kursy', gdzie jeden student może zapisać się na wiele kursów, a każdy kurs może mieć wielu studentów, stosujemy relację wiele do wielu. Z kolei relacja wiele do jednego oznacza, że wiele rekordów w jednej tabeli odnosi się do jednego rekordu w innej tabeli, co ilustruje na przykład relacja 'Zamówienia' do 'Klientów', gdzie wiele zamówień może być złożonych przez jednego klienta. Natomiast relacja jeden do wielu charakteryzuje się tym, że jeden rekord w jednej tabeli może mieć wiele odpowiadających mu rekordów w innej tabeli. Zrozumienie tych typów relacji jest kluczowe dla projektowania efektywnych baz danych, ponieważ pozwala na optymalne zarządzanie danymi i ich integralnością. Użytkownicy, którzy nie dostrzegają subtelności między tymi relacjami, mogą wprowadzać błędy w projektowaniu baz danych, co prowadzi do problemów z wydajnością i spójnością danych.

Pytanie 5

Baza danych zawiera tabelę uczniowie z kolumnami: imie, nazwisko, klasa. Jakie polecenie SQL powinno być użyte, aby wyświetlić imiona i nazwiska uczniów, których nazwiska zaczynają się na literę M?

A. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko IN "M%"
B. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko IN "M%"
C. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko LIKE "M%"
D. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko = "M%"
Wybór innych opcji jest błędny z kilku powodów związanych z niewłaściwym zastosowaniem operatorów oraz składni SQL. W przypadku polecenia SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko IN "M%", pojawia się mylne rozumienie zastosowania klauzuli ORDER BY. Ta klauzula jest używana do sortowania wyników zapytania, a nie do filtrowania ich na podstawie warunków. Operator IN służy do sprawdzania, czy wartość znajduje się w określonym zbiorze danych, ale nie współdziała poprawnie z wzorcami, takimi jak "M%", które wymagają użycia LIKE. Podobnie, w odpowiedzi SELECT nazwisko, imie FROM uczniowie WHERE nazwisko IN "M%", użycie IN jest niewłaściwe, ponieważ nie można stosować wildcardów w tym kontekście. Ostatecznie, SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko = "M%" również nie jest trafnym podejściem, ponieważ operator = wymaga dokładnego dopasowania, a nie porównania na podstawie wzorca. Powszechnym błędem jest brak zrozumienia zasięgu operatorów w SQL oraz ich właściwej aplikacji w kontekście zapytań, co prowadzi do nieefektywnego uzyskiwania danych. Znalezienie właściwego rozwiązania wymaga zrozumienia, jak zastosować odpowiednie operatory w celu efektywnego przeszukiwania i filtrowania danych w bazach danych.

Pytanie 6

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

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

Pytanie 7

Funkcja agregująca AVG wykorzystana w zapytaniu

SELECT AVG(cena) FROM uslugi;
ma na celu
A. znalezienie najwyższej ceny za usługi
B. obliczenie liczby dostępnych usług w tabeli
C. wyliczenie średniej arytmetycznej cen wszystkich usług
D. zsumowanie wszystkich kosztów usług
Funkcja agregująca AVG w języku SQL oblicza średnią arytmetyczną wartości w określonej kolumnie, w tym przypadku w kolumnie 'cena' tabeli 'uslugi'. W kontekście baz danych, obliczanie średniej jest kluczowym narzędziem analitycznym, które pozwala na uzyskanie ogólnego obrazu wartości danej kolumny. W praktyce, analiza średnich cen usług może być użyteczna dla menedżerów chcących dostosować strategię cenową lub dla działów finansowych oceniających wydajność sprzedaży. Przykładowo, jeżeli średnia cena usług wynosi 100 zł, a kolejny miesiąc przynosi spadek do 80 zł, jest to sygnał do analizy powodów obniżenia przychodów. Stosowanie funkcji AVG jest zgodne z najlepszymi praktykami w zakresie analizy danych, gdyż pozwala na podejmowanie decyzji opartych na faktach i liczbach. Warto również zauważyć, że do obliczeń średnich często używa się danych z różnych grup, co może pomóc w zrozumieniu trendów oraz wzorców w zachowaniach klientów na rynku.

Pytanie 8

W aplikacji PHP do bazy danych została wysłana kwerenda SELECT przy pomocy funkcji mysqli_query. Jaką funkcję powinien wykorzystać użytkownik, aby ustalić, ile rekordów zostało zwróconych przez zapytanie?

A. mysqli_query
B. mysqli_num_rows
C. mysqli_connect
D. mysqli_fetch_row
Funkcja mysqli_num_rows jest kluczowym narzędziem w interakcji z bazą danych w PHP, umożliwiającym sprawdzenie liczby rekordów zwróconych przez zapytanie SELECT. Po wywołaniu mysqli_query, które wykonuje zapytanie SQL, można uzyskać wynik, który jest obiektem typu mysqli_result. Używając mysqli_num_rows, możemy szybko i efektywnie dowiedzieć się, ile rekordów zostało zwróconych przez to zapytanie. Przykładowo, po wykonaniu zapytania do bazy danych można użyć poniższego kodu: $result = mysqli_query($conn, 'SELECT * FROM users'); $count = mysqli_num_rows($result); echo 'Liczba rekordów: ' . $count;. Dzięki temu użytkownik ma pełną kontrolę nad danymi, co jest zgodne z najlepszymi praktykami w programowaniu, gdzie liczenie rekordów może być niezbędne do dalszej logiki aplikacji, jak stronicowanie wyników czy walidacja danych. Warto również wiedzieć, że mysqli_num_rows nie tylko zwraca liczbę rekordów, ale także działa wydajnie, co ma znaczenie przy dużych zbiorach danych, gdzie minimalizowanie obciążenia serwera i bazy jest kluczowe.

Pytanie 9

Które z komend przyznaje najniższy poziom uprawnień dla użytkownika uczen w zakresie modyfikacji danych oraz struktury tabeli?

A. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen
B. GRANT INSERT, DROP ON szkola.przedmioty TO uczen
C. GRANT SELECT ON szkola.przedmioty TO uczen
D. DRANT DROP ON szkola.przedmioty TO uczen
Wszystkie pozostałe polecenia przyznają użytkownikowi uczeń szerszy zakres uprawnień, co prowadzi do większego ryzyka nieautoryzowanej modyfikacji danych. Polecenie DRANT DROP ON szkola.przedmioty TO uczen jest nieprawidłowe, ponieważ DRANT nie jest poprawnym poleceniem SQL, co czyni jego interpretację niemożliwą. W kontekście administracji bazami danych, DROP oznacza usunięcie całej tabeli, co w przypadku użytkownika uczeń może prowadzić do katastrofalnych skutków, gdyż może on przypadkowo lub celowo usunąć istotne dane. Kolejne polecenie GRANT INSERT, DROP ON szkola.przedmioty TO uczen przyznaje prawo do wstawiania nowych danych oraz usuwania tabeli. Takie uprawnienia są zdecydowanie nieodpowiednie dla użytkownika uczeń. Umożliwiają one nie tylko dodawanie nieautoryzowanych rekordów, ale także ich usuwanie, co narusza zasady bezpieczeństwa i integralności danych. Podobnie, GRANT ALTER, SELECT ON szkola.przedmioty TO uczen przyznaje prawo do modyfikacji struktury tabeli, co oznacza, że uczeń mógłby zmieniać kolumny, dodawać nowe oraz wprowadzać zmiany, które mogą wpływać na funkcjonowanie całej bazy danych. Prawo do ALTER jest jednym z najszerszych uprawnień w SQL i nie powinno być przyznawane użytkownikom, którzy nie są administratorami, aby zapewnić pełną kontrolę nad bazą danych.

Pytanie 10

Instrukcja ```REVOKE SELECT ON nazwa1 FROM nazwa2``` w SQL pozwala na

A. przyznawanie uprawnień zgodnie z określonym schematem
B. przyznawanie dostępu do tabeli
C. odbieranie przyznanych uprawnień użytkownikowi
D. usunięcie użytkownika z bazy danych
Odpowiedzi sugerujące nadawanie uprawnień są błędne, ponieważ REVOKE jest poleceniem służącym do odbierania, a nie przyznawania praw. Nadawanie uprawnień w SQL realizowane jest za pomocą komendy GRANT, która działa w odwrotny sposób, przyznając określone uprawnienia użytkownikom. W kontekście bezpieczeństwa danych, mylenie tych dwóch operacji może prowadzić do poważnych luk w zabezpieczeniach systemu baz danych. Użytkownicy mogą czasami myśleć, że REVOKE może być używane do usuwania praw, ale dotyczy to tylko odbierania wcześniejszych przyznanych uprawnień, a nie nadawania ich. Dodatkowo, są też odpowiedzi, które nawiązują do usuwania użytkownika z bazy danych; tego nie można osiągnąć za pomocą REVOKE, ponieważ to polecenie nie zajmuje się zarządzaniem samymi kontami użytkowników, a jedynie ich uprawnieniami. Ważne jest, aby znać różnice między tymi operacjami oraz ich zastosowanie w praktyce. Nieprawidłowe zrozumienie tych koncepcji może prowadzić do nieefektywnego zarządzania dostępem, co w konsekwencji naraża system na nieautoryzowany dostęp i potencjalne wycieki danych. Dlatego kluczowe jest, aby każdy administrator baz danych miał solidne podstawy dotyczące zarządzania uprawnieniami i stosował odpowiednie praktyki w codziennej pracy.

Pytanie 11

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

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

if (!$a)
    echo "?????????????";
A. Błąd połączenia z serwerem SQL
B. Błąd w trakcie przetwarzania zapytania SQL
C. Rekord został pomyślnie dodany do bazy
D. Wybrana baza danych nie istnieje
Poprawna odpowiedź 'Błąd połączenia z serwerem SQL' jest właściwa, ponieważ funkcja mysql_connect() służy do nawiązywania połączenia z serwerem bazy danych MySQL. Jeśli połączenie nie powiedzie się, zwraca false. W takiej sytuacji należy poinformować użytkownika o nieudanym połączeniu. Jest to kluczowe w debugowaniu i zapewnianiu użytkownikowi zrozumiałych komunikatów błędów. W praktyce, połączenie z bazą danych jest podstawowym krokiem w wielu aplikacjach internetowych, a jego poprawna obsługa to standardowa praktyka branżowa. Współczesne podejście wymaga także użycia rozszerzenia mysqli lub PDO zamiast przestarzałej funkcji mysql_connect(). Jest to zalecane ze względu na lepsze wsparcie bezpieczeństwa i wydajności. Użycie funkcji mysqli_connect() pozwala na obsługę zarówno błędów połączenia, jak i zapytań SQL w sposób bardziej elastyczny i bezpieczny.

Pytanie 12

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. Formularz
B. Raport
C. Tabela
D. Zapytanie
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 13

W MS SQL Server komenda RESTORE DATABASE jest używana do

A. zaktualizowania bazy danych z weryfikacją więzów integralności
B. przywrócenia bazy danych z kopii zapasowej
C. rekonstrukcji bazy danych na podstawie danych buforowanych
D. usunięcia bazy danych z serwera centralnego subskrybenta
Odpowiedzi, które wskazują na inne funkcje polecenia RESTORE DATABASE, nie uwzględniają kluczowej roli, jaką odgrywa ono w odtwarzaniu bazy danych z kopii zapasowej. Przykładowo, odświeżenie bazy danych z kontrolą więzów integralności sugeruje, że polecenie to zajmuje się aktywnym zarządzaniem danymi i ich integralnością, co jest mylnym zrozumieniem jego funkcji. Kontrola integralności danych jest istotna, ale nie jest bezpośrednio związana z procesem przywracania bazy. Inna niepoprawna koncepcja odnosi się do przebudowywania bazy danych w oparciu o buforowane dane, co sugeruje, że można modyfikować strukturę bazy w oparciu o dane przechowywane w pamięci operacyjnej. Takie podejście jest błędne, ponieważ przywracanie bazy danych z kopii zapasowej ma na celu przywrócenie jej dokładnego stanu, a nie zmianę. Wreszcie, usunięcie bazy danych z serwera subskrybenta nie ma żadnego związku z poleceniem RESTORE DATABASE, które jest używane do odtwarzania, a nie usuwania. Te mylne interpretacje mogą prowadzić do poważnych błędów w zarządzaniu bazami danych, dlatego kluczowe jest, aby zrozumieć konkretne funkcje i zastosowania polecenia w kontekście administracji baz danych.

Pytanie 14

Jakie źródło danych może posłużyć do stworzenia raportu?

A. etykieta
B. zapytanie ALTER
C. projekt raportu
D. zapytanie SELECT
Etykieta jako źródło danych dla raportu nie jest najlepszym pomysłem, bo sama etykieta nie ma danych, które można by analizować. To jakby mieć tylko opakowanie bez zawartości. Projekt raportu także nie nadaje się jako źródło, bo mówi głównie o tym, jak coś powinno wyglądać, a nie jakie info powinno być w środku. Ważne jest, żeby źródłem danych były konkretne tabele czy zapytania, które dostarczają faktyczną wiedzę. Co do zapytania ALTER, to też jest pewne nieporozumienie, bo ono służy do zmiany struktury bazy, a nie do pobierania danych. Może zmieniać kolumny czy tabelę, ale nie da nam informacji do raportu. Zdarza się, że mylimy różne funkcje w SQL, co prowadzi do użycia niewłaściwych narzędzi do analizy. Dlatego warto wiedzieć, do czego dokładnie służą zapytania SQL, żeby dobrze zarządzać danymi i robić sensowne raporty.

Pytanie 15

Jakie rozwiązanie powinno być wdrożone w organizacji danych, aby przyspieszyć wykonanie zapytań w bazie danych?

A. Reguły
B. Klucze podstawowe
C. Wartości domyślne
D. Indeksy
Klucze podstawowe pełnią inną rolę w bazach danych niż indeksy. Służą one do jednoznacznej identyfikacji każdego wiersza w tabeli i zapewniają, że nie ma duplikatów danych. Choć klucze podstawowe mogą być automatycznie indeksowane przez system bazy danych, ich głównym celem jest zapewnienie integralności danych, a nie przyspieszanie wyszukiwania. Reguły, z drugiej strony, dotyczą logiki aplikacji i kontroli danych, ale nie wpływają na szybkość dostępu do danych. Mogą one być używane do walidacji danych przed ich zapisaniem w bazie, co jest ważne, lecz nie przyspiesza samego procesu wyszukiwania. Wartości domyślne definiują, jakie dane mają być wstawiane, gdy nie podano żadnej wartości, ale również nie mają wpływu na wydajność zapytań. Wszystkie te elementy mają swoje istotne miejsce w projektowaniu baz danych, jednak nie są bezpośrednio związane z optymalizacją szybkości zapytań jak to jest w przypadku indeksów. Często mylnie zakłada się, że klucze podstawowe i inne mechanizmy są wystarczające do poprawy wydajności, co może prowadzić do nieefektywnego projektowania i nieodpowiednich optymalizacji w systemie bazodanowym.

Pytanie 16

Zastosowanie poniższej kwerendy SQL spowoduje usunięcie

DELETE FROM mieszkania WHERE status=1;
A. pola o nazwie status w tabeli mieszkania
B. tabeli mieszkania z systemu baz danych
C. tabel, w których pole status ma wartość 1, z bazy danych mieszkania
D. rekordów, dla których pole status ma wartość 1, z tabeli mieszkania
Odpowiedź, którą zaznaczyłeś, jest jak najbardziej trafna i dotyczy działania kwerendy SQL, szczególnie polecenia DELETE. W tym przypadku, to DELETE FROM mieszkania WHERE status=1 oznacza, że zamierzamy usunąć wszystkie rekordy z tabeli mieszkania, gdzie status jest równy 1. To jest ważne, bo w zarządzaniu bazami danych kluczowe jest precyzyjne ustalenie, które dane chcemy usunąć. Z mojej perspektywy, przed wykonaniem takiej operacji warto najpierw wykonać zapytanie SELECT z tymi samymi warunkami, żeby zobaczyć, co dokładnie usuniemy. Przykład? Możesz chcieć usunąć mieszkania, które są zarezerwowane lub niedostępne, co może być oznaczone statusem 1. To naprawdę dobra praktyka, bo pozwala na lepsze zarządzanie danymi i na utrzymanie porządku w bazie. A wiesz, co jeszcze? Zawsze warto zrobić kopię zapasową danych przed masowym usuwaniem, żeby nie stracić czegoś ważnego.

Pytanie 17

Przed przystąpieniem do tworzenia kopii zapasowej bazy danych, aby była ona poprawna i zdatna do późniejszego przywrócenia, konieczne jest sprawdzenie

A. spójności bazy danych
B. opcji udostępnienia bazy danych
C. poprawności składni zapytań
D. uprawnień dostępu do serwera bazy danych
Prawa dostępu do serwera bazy danych, możliwość udostępnienia bazy danych oraz poprawność składni zapytań to aspekty, które są istotne w kontekście zarządzania bazami danych, jednak nie mają one bezpośredniego wpływu na możliwość wykonania poprawnej kopii bezpieczeństwa. Sprawdzanie praw dostępu jest kluczowe z punktu widzenia bezpieczeństwa, ale nawet przy odpowiednich uprawnieniach, kopia zapasowa będzie bezwartościowa, jeśli dane są niezgodne lub uszkodzone. Możliwość udostępnienia bazy danych odnosi się do tego, czy inni użytkownicy mogą z niej korzystać, co również nie ma wpływu na integralność danych, które kopiujemy. Z kolei poprawność składni zapytań dotyczy aspektu komunikacji z bazą danych, a nie stanu samych danych. Właściwie skonstruowane zapytania mogą z powodzeniem zwrócić wynik, ale nie gwarantują, że dane, które chcemy zarchiwizować, są zgodne i spójne. Często w praktyce pomija się te elementy, koncentrując się na bezpośrednich aspektach zarządzania danymi, co może prowadzić do poważnych problemów po przywróceniu bazy z kopii zapasowej. Najważniejsze jest, aby przed wykonaniem kopiowania danych, zapewnić ich spójność, co jest fundamentem operacji backupu.

Pytanie 18

Co uzyskujemy po wykonaniu zapytania SQL?

Ilustracja do pytania
A. średnią wszystkich ocen uczniów
B. suma ocen uczniów, których średnia ocen wynosi 5
C. liczbę uczniów, których średnia ocen wynosi 5
D. całkowitą liczbę uczniów
Zapytanie SQL SELECT count(*) FROM Uczniowie WHERE srednia = 5; wykorzystuje funkcję agregującą count(*), która służy do zliczania liczby wierszy spełniających określone warunki. W tym przypadku warunkiem jest srednia = 5 co oznacza że zapytanie zlicza wszystkich uczniów których średnia ocen wynosi dokładnie 5. Jest to powszechna praktyka w analizie danych gdzie często potrzebujemy określić liczebność pewnych grup danych na przykład aby przeanalizować ich rozkład lub porównać je z innymi grupami. W profesjonalnej bazie danych zliczanie wierszy na podstawie kryteriów jest standardem co umożliwia generowanie raportów i podejmowanie decyzji na podstawie danych. Użycie count(*) bez dodatkowych parametrów jest zgodne z dobrymi praktykami ponieważ jest wydajne i łatwe w interpretacji. W praktyce stosowanie tego typu zapytań jest nieodzowne w działach analizy danych zarządzania relacjami z klientami czy w edukacji gdzie analizujemy wyniki uczniów.

Pytanie 19

W bazie danych znajduje się tabela pracownicy z kolumnami: id, imie, nazwisko, pensja. W nowym roku zdecydowano o podwyżce pensji dla wszystkich pracowników o 100 zł. Ta aktualizacja w bazie danych powinna mieć formę

A. UPDATE pracownicy SET pensja = 100
B. UPDATE pensja SET +100
C. UPDATE pracownicy SET pensja = pensja + 100
D. UPDATE pensja SET 100
Odpowiedź 'UPDATE pracownicy SET pensja = pensja + 100;' jest właściwa, ponieważ używa standardowej składni SQL do aktualizacji danych w tabeli. W tym przypadku, instruktacja 'SET pensja = pensja + 100' oznacza, że dla każdego rekordu w tabeli 'pracownicy', wartość kolumny 'pensja' zostanie zwiększona o 100 zł. To podejście jest zgodne z zasadami dobrych praktyk w programowaniu SQL, ponieważ aktualizuje wartość na podstawie jej bieżącej wartości, co pozwala na zachowanie pełnej kontroli nad danymi. Tego rodzaju aktualizacja jest często stosowana w bazach danych, gdy konieczne jest modyfikowanie istniejących danych na podstawie ich aktualnych wartości. Na przykład, jeśli w tabeli mamy pracowników z różnymi wynagrodzeniami, każdemu z nich dodamy stałą kwotę, co sprawia, że struktura danych pozostaje spójna. Dodatkowo, takie podejście ma zastosowanie w praktycznych scenariuszach, takich jak coroczne podwyżki wynagrodzeń, co jest powszechną praktyką w wielu organizacjach, a poprawność tej operacji można zweryfikować poprzez zapytania SELECT po aktualizacji.

Pytanie 20

Instrukcja REVOKE SELECT ON nazwa1 FROM nazwa2 w języku SQL pozwala na

A. odebranie uprawnień danemu użytkownikowi
B. przyznawanie uprawnień z użyciem ustalonego schematu
C. przyznawanie praw do tabeli
D. usunięcie użytkownika z bazy danych
Pierwsza z niepoprawnych odpowiedzi dotyczy nadawania uprawnień z użyciem zdefiniowanego schematu. W rzeczywistości polecenie REVOKE nie ma nic wspólnego z nadawaniem uprawnień, lecz dotyczy jedynie ich odbierania. Schematy w SQL służą do grupowania obiektów bazy danych, a nadawanie uprawnień odbywa się za pomocą polecenia GRANT. Kolejna odpowiedź sugeruje usuwanie użytkownika z bazy, co jest całkowicie nieprawidłowe. REVOKE nie ma na celu usuwania kont użytkowników ani ich danych, a jedynie zarządzanie ich dostępem do konkretnych zasobów. Ostatnia niepoprawna odpowiedź wskazuje na nadawanie praw do tabeli, co również jest błędne, ponieważ REVOKE służy do ich odbierania, a nie nadawania. Nadawanie uprawnień do tabeli wykonywane jest poprzez polecenie GRANT, które przyznaje użytkownikowi odpowiednie prawa. Te błędne odpowiedzi mogą wprowadzać w błąd osoby, które dopiero zaczynają przygodę z SQL, dlatego istotne jest, aby dokładnie zrozumieć różnicę między nadawaniem a odbieraniem uprawnień oraz znać odpowiednie komendy do zarządzania dostępem w bazach danych.

Pytanie 21

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

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

Pytanie 22

idnazwiskoimiedata_urubezpieczony
✏️ Edytuj📋 Kopiuj⛔ Usuń1KowalskiJan2005-12-181
✏️ Edytuj📋 Kopiuj⛔ Usuń2NowakAdam2005-10-101
✏️ Edytuj📋 Kopiuj⛔ Usuń3WisniewskiAntoni2005-06-140
✏️ Edytuj📋 Kopiuj⛔ Usuń4LipskaAnna2006-04-121
✏️ Edytuj📋 Kopiuj⛔ Usuń5TomaszewskiPawel2006-07-110
✏️ Edytuj📋 Kopiuj⛔ Usuń6KostarzJulia2006-03-201
✏️ Edytuj📋 Kopiuj⛔ Usuń7BorewiczPatryk2007-06-211
✏️ Edytuj📋 Kopiuj⛔ Usuń8KoperskiBartlomiej2001-09-100
Które zapytanie w języku MySQL usunie z tabeli uczniowie uczniów urodzonych w czerwcu?
A. DROP FROM `uczniowie` WHERE data_ur == #-06-#
B. DELETE FROM `uczniowie` WHERE data_ur LIKE "%-06-%"
C. DROP FROM `uczniowie` WHERE data_ur LIKE "06"
D. DELETE FROM `uczniowie` WHERE data_ur LIKE "?-06-?"
Poprawnie wskazane zapytanie korzysta z instrukcji DELETE oraz operatora LIKE z odpowiednim wzorcem: "%-06-%". W kolumnie data_ur mamy daty zapisane w standardowym formacie ISO: RRRR-MM-DD, np. 2005-06-14. W takim formacie miesiąc zawsze znajduje się na pozycjach 6–7 i jest zapisany jako dwucyfrowa liczba z wiodącym zerem. Wzorzec "%-06-%" oznacza: dowolny ciąg znaków przed, dokładnie „-06-” w środku, oraz dowolny ciąg znaków po. Dzięki temu trafiamy w wszystkie daty, gdzie miesiąc to 06, czyli czerwiec, niezależnie od roku i dnia. To jest bardzo praktyczne podejście, gdy przechowujemy datę w typie DATE i chcemy filtrować po miesiącu bez dodatkowych funkcji. W MySQL operator LIKE działa na wartościach tekstowych, ale typ DATE jest w takim kontekście automatycznie konwertowany do postaci tekstowej w formacie 'YYYY-MM-DD', więc wzorzec z myślnikami jest jak najbardziej poprawny. W realnych projektach częściej stosuje się funkcje DATE_FORMAT albo MONTH(data_ur) = 6, bo to jest czytelniejsze i mniej podatne na pomyłki w zapisie wzorca. Jednak w tym zadaniu celem jest zrozumienie, jak działa LIKE, wildcard „%” oraz jak wygląda rzeczywisty format przechowywania daty. Dobrą praktyką jest też zawsze używanie pojedynczych cudzysłowów w SQL (np. '%-06-%'), choć MySQL akceptuje też podwójne w pewnych konfiguracjach. Moim zdaniem warto zapamiętać ten sposób myślenia: patrzysz na rzeczywisty zapis danych w kolumnie i dopasowujesz wzorzec tak, żeby trafić dokładnie ten fragment, który Cię interesuje (tu: '-06-').

Pytanie 23

Jakie polecenie wykonane w systemowej konsoli umożliwi przywrócenie bazy danych?

A. mysql -u root -p baza < kopia.sql
B. mysql -u root -p baza > kopia.sql
C. mysqldump -u root -p baza > kopia.sql
D. mysqldump -u root -p baza < kopia.sql
Wszystkie inne odpowiedzi są niepoprawne, ponieważ z użyciem niewłaściwych poleceń z systemu MySQL. Pierwsze z tych poleceń, zamiast przywracać bazę danych, tworzy jej kopię zapasową, co nie odpowiada na zadane pytanie. Użycie 'mysqldump' z parametrami '-u root -p baza > kopia.sql' jest sposobem na eksport danych z bazy do pliku SQL, a nie na ich import. Kolejne polecenie sugeruje zastosowanie 'mysqldump' w kontekście przywracania, co jest również błędne, ponieważ 'mysqldump' jest narzędziem służącym do zrzutów, a nie importu. Z kolei ostatnie polecenie 'mysql -u root -p baza > kopia.sql' ponownie nie wykonuje przywracania, lecz zapisuje dane z bazy danych do pliku, co jest odwrotnością oczekiwanej operacji. W praktyce, błędne zastosowanie tych poleceń może prowadzić do poważnych konsekwencji, takich jak utrata danych czy niewłaściwe zarządzanie bazą danych. Dlatego kluczowe jest zrozumienie roli każdego z narzędzi dostępnych w MySQL oraz ich poprawne zastosowanie w różnych scenariuszach administracyjnych.

Pytanie 24

Powszechnie stosowanym narzędziem SZBD do tworzenia zestawień danych, które można wydrukować, jest

A. raport
B. kwerenda UPDATE
C. formularz
D. makro
Kwerenda UPDATE jest używana do modyfikacji istniejących danych w bazie danych. Głównym celem kwerendy jest aktualizacja wartości pól w określonych rekordach, co jest zupełnie innym zadaniem niż generowanie zestawień danych. Użytkownicy, którzy mylnie uważają, że kwerenda UPDATE może służyć do tworzenia raportów, mogą nie rozumieć podstawowego podziału funkcji w systemach bazodanowych. Z kolei formularz jest interfejsem użytkownika, który umożliwia wprowadzanie danych do bazy, ale nie jest narzędziem do generowania zestawień, co sprawia, że jego zastosowanie jest także niewłaściwe w kontekście tego pytania. Makro, z drugiej strony, to zestaw instrukcji automatyzujących różne operacje w bazie danych, ale także nie jest dedykowane do tworzenia raportów. Kluczowym błędem myślowym jest utożsamianie narzędzi do modyfikacji lub wprowadzania danych z narzędziami do ich analizy i raportowania. Warto zrozumieć, że każdy z tych elementów ma swoje specyficzne zastosowanie w systemach zarządzania bazami danych, a ich pomylenie może prowadzić do nieskutecznego wykorzystania zasobów oraz obniżenia jakości analizy danych.

Pytanie 25

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

A. 1 .. n
B. n .. n
C. n .. 1
D. 1 .. 1
Relacje 1 .. n, n .. 1 oraz n .. n wskazują na bardziej złożone powiązania między tabelami w relacyjnych bazach danych, które nie są adekwatne w kontekście kluczy głównych. W przypadku relacji 1 .. n, jeden rekord w tabeli A może mieć wiele odpowiadających mu rekordów w tabeli B, co prowadzi do sytuacji, w której dane są powielane w tabeli B. Typowym błędem jest mylenie sytuacji, w której każdy rekord w tabeli A jest powiązany z wieloma rekordami w tabeli B, co prowadzi do wniosku o relacji 1 .. n. Z kolei relacja n .. 1 oznacza, że wiele rekordów w tabeli A odpowiada jednemu rekordowi w tabeli B, co również nie jest zgodne z definicją relacji 1 .. 1. Co więcej, relacja n .. n sugeruje, że wiele rekordów w tabeli A może być powiązanych z wieloma rekordami w tabeli B, co prowadzi do dużej złożoności i trudności w utrzymaniu integralności danych w bazie. Zrozumienie tych konceptów jest kluczowe dla modelowania danych, dlatego ważne jest, aby unikać nadmiernego uproszczenia lub generalizacji relacji, co często prowadzi do błędnych wniosków w projektowaniu bazy danych.

Pytanie 26

Która wartość tekstowa nie pasuje do podanego w ramce wzorca wyrażenia regularnego?

(([A-ZŁŻ][a-ząęóżźćńłś]{2,})(-[A-ZŁŻ][a-ząęóżźćńłś]{2,})?)
A. Nowakowska-Kowalska
B. Kowalski
C. Jelenia Góra
D. Kasprowicza
Wyrażenie regularne, które zostało podane w pytaniu, to [A-ZŁŻ][a-ząęóżźćńłś]{2,}-[A-ZŁŻ][a-ząęóżźćńłś]{2,}. Wyrażenie to jest używane do walidacji polskich nazwisk, gdzie pierwsza litera musi być dużą literą z zakresu A-Z oraz polskimi znakami diakrytycznymi, następnie muszą występować co najmniej dwa znaki małe, również z zestawu polskich liter. Po pierwszej części, która odpowiada za pierwsze nazwisko, mamy opcjonalny fragment, który zaczyna się od znaku '-', co oznacza, że można podać drugie nazwisko, które także musi spełniać te same warunki. Przykład poprawnych wartości to Kowalski oraz Nowakowska-Kowalska. Wartość 'Jelenia Góra' nie pasuje do tego wzorca, ponieważ zawiera spację, która nie jest dozwolona w tym kontekście. Dodatkowo, spację można interpretować jako rozdzielenie dwóch słów, co wykracza poza przyjęty format. W związku z tym, prawidłowa odpowiedź to 'Jelenia Góra'.

Pytanie 27

Tworząc tabelę produkty, należy dodać pole cena, które będzie odzwierciedlać koszt produktu. Jaki typ powinno mieć to pole?

A. TINYTEXT
B. ENUM
C. INTEGER(11)
D. DECIMAL(10, 2)
Typ DECIMAL(10, 2) jest odpowiedni dla pola ceny w tabeli produktów, ponieważ umożliwia dokładne przechowywanie wartości liczbowych z określoną precyzją i skalą. W tym przypadku liczba 10 oznacza maksymalną liczbę cyfr, które mogą być przechowywane, a 2 oznacza liczbę cyfr po przecinku. Dzięki temu można przechowywać wartości cenowe, które mają do dwóch miejsc po przecinku, co jest standardem w większości aplikacji związanych z handlem. Przykładem może być cena produktu wynosząca 19,99 PLN. Użycie typu DECIMAL jest zgodne z dobrymi praktykami w projektowaniu baz danych, ponieważ zapobiega problemom związanym z zaokrąglaniem, które mogą występować przy użyciu typów zmiennoprzecinkowych. Stosowanie DECIMAL jest szczególnie istotne w aplikacjach finansowych, gdzie precyzja wartości jest kluczowa. Warto dodać, że zgodnie z normami SQL, stosowanie tego typu danych pozwala na wykonywanie dokładnych zapytań i obliczeń, co jest niezbędne do prawidłowego funkcjonowania systemów zarządzania danymi.

Pytanie 28

Na ilustracji przedstawiono związek jeden do wielu. Łączy on

Ilustracja do pytania
A. klucz podstawowy id w tabeli z kluczem obcym rezyserzy_id w tabeli rezyserzy
B. klucz obcy rezyserzy_id w tabeli filmy z kluczem obcym id w tabeli rezyserzy
C. klucz podstawowy id w tabeli filmy z kluczem podstawowym id w tabeli rezyserzy
D. klucz obcy rezyserzy_id w tabeli filmy z kluczem podstawowym id w tabeli rezyserzy
Relacja jeden do wielu jest kluczowym elementem projektowania baz danych i występuje, gdy pojedynczy rekord w jednej tabeli może być powiązany z wieloma rekordami w innej tabeli. W tym przypadku mamy do czynienia z relacją między tabelą 'rezyserzy' i 'filmy'. Klucz podstawowy 'id' w tabeli 'rezyserzy' jest związany z kluczem obcym 'rezyserzy_id' w tabeli 'filmy'. Oznacza to, że jeden reżyser może być autorem wielu filmów. Klucz obcy w tabeli 'filmy' wskazuje na odpowiedni rekord w tabeli 'rezyserzy', co zapewnia integralność danych i umożliwia wykonywanie operacji takich jak JOIN w języku SQL, co jest przydatne przy pobieraniu danych z obu tabel jednocześnie. W praktyce stosowanie kluczy obcych jest standardową praktyką w projektowaniu relacyjnych baz danych, ponieważ ułatwia organizację i normalizację danych. Zrozumienie tych relacji jest niezbędne dla każdego, kto pracuje z bazami danych, gdyż pozwala na efektywne zarządzanie i analizowanie danych w skomplikowanych systemach informatycznych.

Pytanie 29

Klucz obcy w tabeli jest ustanawiany w celu

A. określić relację 1..n powiązującą go z kluczem głównym innej tabeli
B. zapewnić jednoznaczną identyfikację rekordu w tabeli
C. opracować formularz do wprowadzania danych do tabeli
D. wiązać go z innymi kluczami obcymi w tabeli
Klucz obcy (foreign key) w bazach danych jest fundamentalnym elementem w modelowaniu relacji pomiędzy tabelami. Jego podstawowym celem jest zdefiniowanie relacji 1..n pomiędzy tabelą, w której się znajduje, a kluczem głównym innej tabeli. Oznacza to, że jeden rekord w tabeli, która zawiera klucz główny, może być powiązany z wieloma rekordami w tabeli z kluczem obcym. Na przykład, w systemie zarządzania zamówieniami, tabela 'Klienci' może mieć klucz główny 'ID_klienta', a tabela 'Zamówienia' może zawierać klucz obcy 'ID_klienta', co pozwala na powiązanie wielu zamówień z jednym klientem. To nie tylko ułatwia strukturalne organizowanie danych, ale również wspiera integralność referencyjną; czyli zapewnia, że każdy wpis w tabeli 'Zamówienia' odnosi się do istniejącego klienta. W praktyce, dobre praktyki projektowania baz danych zalecają używanie kluczy obcych do zachowania spójności danych i ułatwienia ich analizy, co odzwierciedla większą efektywność w strumieniu pracy oraz w raportowaniu.

Pytanie 30

Jaki typ komunikatu jest zawsze przesyłany wyłącznie w kierunku w dół, to jest od kierownika do pracownika?

A. Poszukiwanie rozwiązań.
B. Zgłaszanie.
C. Uwagi dotyczące polityki organizacji.
D. Powierzenie zadania.
Powierzenie zadania jest komunikatem, który jest zawsze przekazywany w sposób pionowy w dół, co oznacza, że jest przekazywany od przełożonego do podwładnego. Tego typu komunikacja jest kluczowa dla efektywnego zarządzania, ponieważ pozwala przełożonym na delegowanie odpowiedzialności i ustalanie oczekiwań wobec pracowników. Przykładem może być sytuacja, w której kierownik działu przydziela zadanie konkretnej osobie, określając cele, terminy oraz zasoby potrzebne do jego realizacji. W praktyce, powierzenie zadań jest zgodne z zasadami efektywnego zarządzania projektami, gdzie klarowność i zrozumienie oczekiwań są niezbędne do osiągnięcia sukcesu. Warto również zwrócić uwagę na standardy, takie jak PMBOK, które podkreślają znaczenie komunikacji w procesie zarządzania projektami, w tym precyzyjnego delegowania zadań. Dzięki temu powierzenie zadań nie tylko zapewnia jasność, ale także zwiększa zaangażowanie pracowników i ich odpowiedzialność za realizowane projekty.

Pytanie 31

Jakie zapytanie SQL dotyczące tabeli pracownicy, której struktura to: id, imie, nazwisko, plec, zarobek, pozwoli na osobne obliczenie średniego wynagrodzenia kobiet oraz średniego wynagrodzenia mężczyzn?

A. SELECT AVG(zarobek) FROM pracownicy AS sredni_zarobek
B. SELECT AVG(zarobek) FROM pracownicy GROUP BY plec HAVING plec='k' AND plec='m'
C. SELECT AVG(zarobek) FROM pracownicy WHERE plec='k' AND plec='m'
D. SELECT AVG(zarobek) FROM pracownicy GROUP BY plec
Pierwsza opcja nie jest poprawna, ponieważ nie oblicza średnich zarobków osobno dla każdej płci, lecz zwraca jedną średnią, jeśli w tabeli są pracownicy różnych płci. Kolejne zapytanie, które wykorzystuje alias, jest błędne, ponieważ użycie 'AS sredni_zarobek' nie wprowadza żadnej funkcjonalności do obliczania średni dla płci. Nie definiuje ono kontekstu grupowania danych, przez co zwróci jedną wartość, a nie różne średnie dla każdej płci. Następnie, zapytanie z warunkiem WHERE plec='k' AND plec='m' jest całkowicie niepoprawne, ponieważ nie można, aby jedna wartość plec jednocześnie była równa 'k' i 'm'. Takie zapytanie nic nie zwróci, ponieważ nie znajdzie żadnych wierszy spełniających ten warunek. Ostatnia odpowiedź z GROUP BY plec HAVING plec='k' AND plec='m' również zawiera błędne założenia. Klauzula HAVING służy do filtrowania grup, ale podobnie jak w poprzednich przypadkach warunek 'plec='k' AND plec='m'' nie ma sensu, ponieważ nie można grupować wyników w ten sposób. Dlatego wszystkie te zapytania nie osiągną celu związanego z obliczeniem średnich zarobków osobno dla kobiet i mężczyzn.

Pytanie 32

Baza danych, która fizycznie znajduje się na wielu komputerach, lecz logicznie postrzegana jako całość, opiera się na architekturze

A. rozproszoną
B. lokalną
C. abstrakcyjną
D. relacyjną
Wybór architektury relacyjnej, abstrakcyjnej czy lokalnej do opisu systemu, w którym baza danych jest rozproszona, wskazuje na pewne nieporozumienia w zakresie terminologii i koncepcji baz danych. Architektura relacyjna odnosi się do struktury baz danych, w której dane są przechowywane w tabelach oraz powiązaniach między nimi, a nie do fizycznego rozmieszczenia danych. Systemy relacyjne mogą być wdrażane zarówno w architekturze lokalnej, jak i rozproszonej. Abstrakcyjna architektura danych dotyczy natomiast sposobów modelowania, które są niezależne od konkretnej technologii i nie odnoszą się bezpośrednio do fizycznego rozproszenia danych. Z kolei architektura lokalna odnosi się do sytuacji, w której wszystkie komponenty systemu są umieszczone w jednym miejscu, co zdecydowanie wyklucza możliwość rozproszenia danych. W praktyce, nieprawidłowy wybór architektury może prowadzić do problemów z wydajnością, dostępnością i skalowalnością systemu. Często mylone są pojęcia związane z architekturą baz danych i ich implementacją, co może skutkować błędnymi decyzjami projektowymi i trudnościami w zarządzaniu danymi. Dobrze jest zrozumieć, że architektura rozproszona nie tylko zwiększa wydajność, ale również poprawia bezpieczeństwo i dostępność danych, co czyni ją odpowiednim wyborem dla nowoczesnych systemów przetwarzania danych.

Pytanie 33

Jakie są nazwy standardowych instrukcji w języku SQL, które dotyczą wykonywania operacji na danych w SQL DML (np.: dodawanie danych do bazy, usuwanie, wprowadzanie zmian w danych)?

A. DENY, GRANT, REVOKE
B. SELECT, SELECT INTO
C. ALTER, CREATE, DROP
D. DELETE, INSERT, UPDATE
Odpowiedź DELETE, INSERT, UPDATE jest całkiem trafna, bo te polecenia są częścią DML, czyli Data Manipulation Language, w SQL-u. DML to zestaw komend do zarządzania danymi w bazach danych. Moim zdaniem, DELETE jest kluczowe, bo pozwala na usuwanie zbędnych rekordów, co pomaga utrzymać bazę w dobrym stanie. Z kolei INSERT to coś, co używamy do dodawania nowych wpisów do tabeli, co jest mega ważne, jeśli chodzi o zbieranie danych potrzebnych aplikacji. A UPDATE? No to już absolutnie istotna sprawa, bo z jego pomocą zmieniamy dane, które już są w bazie, co przydaje się na przykład przy aktualizacji informacji o użytkownikach czy produktach. Przykłady? Można użyć INSERT, żeby dodać nowego użytkownika do tabeli 'Users', DELETE, żeby pozbyć się nieaktywnych kont, a UPDATE, żeby zmienić e-mail jakiegoś użytkownika. Dobrym pomysłem jest też korzystanie z transakcji, bo zapewnia to lepszą integralność danych podczas operacji DML.

Pytanie 34

Które z poniższych poleceń przyznaje użytkownikowi uczen najniższy poziom uprawnień w zakresie zmiany danych i struktury tabel?

A. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
B. GRANT DROP ON szkola.przedmioty TO uczen;
C. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;
D. GRANT SELECT ON szkola.przedmioty TO uczen;
Rozpatrując inne polecenia, które zostały zaproponowane, należy zauważyć, że każde z nich przyznaje użytkownikowi 'uczen' szerszy zakres uprawnień, co nie jest zgodne z założeniem nadawania minimalnych uprawnień. Przyznanie uprawnień DROP, jak w przypadku polecenia GRANT DROP ON szkola.przedmioty TO uczen, pozwoliłoby użytkownikowi usunąć tabelę 'przedmioty', co jest nieakceptowalne w kontekście użytkownika edukacyjnego. Takie działanie nie tylko zagrażałoby integralności bazy danych, ale również mogłoby prowadzić do utraty ważnych informacji. Podobnie, przyznanie uprawnień INSERT, jak w poleceniu GRANT INSERT, DROP ON szkola.przedmioty TO uczen, umożliwia użytkownikowi dodawanie nowych rekordów do tabeli, co w przypadku ucznia nie jest pożądane, ponieważ jego rola powinna być ograniczona do przeglądania danych. Co więcej, polecenie GRANT ALTER, SELECT ON szkola.przedmioty TO uczen zawiera uprawnienie ALTER, które pozwala na modyfikację struktury tabeli, co również nie powinno mieć miejsca w kontekście użytkownika, który jest tylko uczniem. Wszelkie te niepoprawne podejścia prowadzą do niebezpieczeństwa związane z nieautoryzowanymi zmianami w bazie danych, co jest sprzeczne z najlepszymi praktykami w zakresie zarządzania uprawnieniami i bezpieczeństwa danych. Warto pamiętać, że właściwe zarządzanie uprawnieniami nie tylko zabezpiecza dane, ale również usprawnia procesy edukacyjne, zapewniając odpowiedni dostęp do informacji w sposób kontrolowany.

Pytanie 35

W aplikacji PHP, która zarządza bazą danych, aby uzyskać numer błędu oraz jego opis po dokonaniu jakiejkolwiek operacji, jakie funkcje powinny być wykorzystane?

A. funkcje mysqli_error i mysqli_error_number
B. funkcje mysqli_error i mysqli_errno
C. tylko funkcję mysqli_error
D. funkcje mysqli_error i mysqli_connect_errno
Wybór funkcji mysqli_error i mysqli_connect_errno nie jest właściwy, ponieważ mysqli_connect_errno jest funkcją przeznaczoną do uzyskiwania numeru błędu połączenia z bazą danych, a nie błędu SQL. Użycie tej funkcji w kontekście operacji na bazie danych prowadzi do mylnego wniosku, że jej zastosowanie jest uniwersalne dla wszystkich błędów. W rzeczywistości, mysqli_connect_errno powinno być stosowane głównie podczas nawiązywania połączenia, natomiast dla błędów związanych z zapytaniami SQL właściwe są inne funkcje. Z kolei wskazanie tylko na funkcję mysqli_error nie jest wystarczające, ponieważ sama dostarcza jedynie opisu błędu, a nie jego numeru, co ogranicza możliwości analizy i diagnostyki. Użytkownicy często popełniają błąd myślowy, zakładając, że pojedyncza funkcja może spełnić wszystkie potrzeby związane z obsługą błędów. W prawidłowym procesie zarządzania błędami w programowaniu, kluczowe jest użycie zestawu funkcji, które dostarczają zarówno opisy, jak i kody błędów, co pozwala na bardziej wszechstronną reakcję na różne sytuacje awaryjne. Ignorowanie tej zasady może prowadzić do nieefektywnego debugowania i długotrwałych problemów w działaniu aplikacji.

Pytanie 36

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

A. len
B. now
C. year
D. upper
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 37

Które zapytanie języka SQL zlicza wszystkie rekordy w tabeli Zamowienia?

A. SELECT ALL(*) FROM Zamowienia;
B. SELECT SUM() FROM Zamowienia;
C. SELECT COUNT(*) FROM Zamowienia;
D. COUNT(Zamowienia);
Prawidłowe zapytanie to: SELECT COUNT(*) FROM Zamowienia;. Funkcja agregująca COUNT() w SQL służy właśnie do zliczania rekordów, a gwiazdka * oznacza „wszystkie kolumny”, czyli w praktyce każdy wiersz w tabeli. Silnik bazy danych nie patrzy wtedy na konkretne pola, tylko sprawdza ile wierszy spełnia warunek w klauzuli FROM/WHERE. To jest standardowy zapis opisany w dokumentacji większości systemów bazodanowych, takich jak MySQL, PostgreSQL, SQL Server czy Oracle. Moim zdaniem warto od razu zapamiętać ten wzorzec, bo jest używany dosłownie wszędzie: do paginacji wyników w aplikacjach webowych (np. policzenie ile jest wszystkich zamówień, żeby wyświetlić numer strony), do raportów (ile zamówień w danym miesiącu), do monitoringu (ile rekordów ma tabela po imporcie danych) itd. Bardzo często łączy się COUNT(*) z klauzulą WHERE, np.: SELECT COUNT(*) FROM Zamowienia WHERE status = 'zrealizowane'; – wtedy zliczasz tylko wybrane zamówienia, spełniające warunek. Dobra praktyka jest też taka, że jeśli chcesz policzyć wszystkie wiersze, to używasz właśnie COUNT(*), a nie COUNT(nazwa_kolumny), bo COUNT(kolumny) pomija wartości NULL. To czasem jest pożądane, ale domyślnie, przy zwykłym „ile jest rekordów w tabeli”, stosuje się COUNT(*). W wielu optymalizacjach baz danych silnik ma specjalne mechanizmy, które potrafią bardzo szybko policzyć COUNT(*) bez czytania całej tabeli, co jest kolejnym powodem, żeby korzystać z tej formy, zgodnie z dobrą praktyką branżową.

Pytanie 38

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

Pytanie 39

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

A. SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC
B. SELECT nazwisko FROM klienci LIMIT 3
C. SELECT nazwisko FROM klienci ORDER BY punkty DESC LIMIT 3
D. SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3
Analiza niepoprawnych odpowiedzi ujawnia szereg kluczowych błędów w interpretacji zapytania SQL. W pierwszym przypadku, 'SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC;' następuje nieprawidłowa składnia, ponieważ klauzula LIMIT powinna być umieszczona po klauzuli ORDER BY. Taki błąd sprawia, że zapytanie nie zostanie zrealizowane przez system baz danych. Kolejna odpowiedź, 'SELECT nazwisko FROM klienci LIMIT 3;', pomija istotny element sortowania, dlatego zwróci po prostu pierwsze trzy nazwiska z tabeli, bez względu na ilość punktów. Takie podejście jest mało efektywne, ponieważ nie identyfikuje najlepszych klientów na podstawie ich punktów, co jest kluczowe dla analizy jakości klientów. Ostatnia odpowiedź, 'SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3;', znów koncentruje się na sortowaniu alfabetycznym nazwisk zamiast na punktach, co nie spełnia kryteriów określonych w pytaniu. Takie błędy ukazują typowe nieporozumienia w zakresie funkcji SQL, gdzie kluczowe jest rozróżnienie pomiędzy różnymi metodami sortowania i ograniczania wyników. Istotne jest, aby w analizach danych zawsze zwracać uwagę na odpowiednie kryteria oraz zasady, które mają realny wpływ na proces podejmowania decyzji.

Pytanie 40

Na tabeli 'dania', której wiersze zostały pokazane, wykonano przedstawioną kwerendę:

SELECT * FROM dania WHERE typ < 3 AND cena < 30 LIMIT 5;
Ile wierszy wybierze kwerenda?
idtypnazwacena
11Gazpacho20
21Krem z warzyw25
31Gulaszowa ostra30
42Kaczka i owoc30
52Kurczak pieczony40
62wieprzowy przysmak35
72Mintaj w panierce30
82Alle kotlet30
93Owoce morza20
103Grzybki, warzywka, sos15
113Orzechy i chipsy10
123Tatar i jajo15
133Bukiet warzyw10
A. 8
B. 5
C. 2
D. 13
Kwerenda SQL zawarta w pytaniu to `SELECT * FROM dania WHERE typ < 3 AND cena < 30 LIMIT 5;`. Analizując tę kwerendę, możemy zauważyć, że wybiera ona wiersze z tabeli `dania`, gdzie wartość kolumny `typ` jest mniejsza niż 3 oraz wartość kolumny `cena` jest mniejsza niż 30. Sprawdźmy dane w tabeli: dla `typ` 1 mamy trzy dania: Gazpacho (cena 20), Krem z warzyw (cena 25) oraz Gulaszowa ostra (cena 30), z których dwa pierwsze spełniają warunek dotyczący ceny. Dla `typ` 2 mamy Kaczkę i owoc (cena 30), Kurczaka pieczonego (cena 40) oraz Wieprzowy przysmak (cena 35), które nie spełniają wymogu ceny. W rezultacie, wiersze, które spełniają oba warunki to: Gazpacho oraz Krem z warzyw. Zatem kwerenda wybierze 2 wiersze. W kontekście praktycznym, umiejętność tworzenia filtrów w kwerendach SQL jest kluczowa w analizie danych oraz w tworzeniu raportów, co jest bardzo istotne w pracy z bazami danych.