Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

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

Egzamin niezdany

Wynik: 12/40 punktów (30,0%)

Wymagane minimum: 20 punktów (50%)

Nowe

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

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Aby zwiększyć wydajność operacji w bazie danych, należy skupić się na polach, które są często wyszukiwane lub sortowane

A. dodać klucz obcy

B. utworzyć indeks

C. dodać więzy integralności

D. stworzyć oddzielną tabelę przechowującą wyłącznie te pola

Dodawanie kluczy obcych nie jest bezpośrednią metodą na przyspieszenie operacji na bazie danych. Klucze obce są używane do zapewnienia integralności referencyjnej, co oznacza, że ich celem jest zapewnienie spójności danych w relacjach pomiędzy tabelami. Choć klucze obce mogą wpłynąć na wydajność w kontekście zapytań, nie przyspieszają one ani nie optymalizują wyszukiwania w obrębie pojedynczych tabel. Tworzenie osobnych tabel przechowujących tylko te pola również nie jest metodą optymalizacji efektywności wyszukiwania. Tego rodzaju podejście może prowadzić do komplikacji w zarządzaniu danymi oraz zmniejszenia wydajności przy łączeniu tabel w zapytaniach. Dodanie więzów integralności, które zapewniają, że dane w tabelach są poprawne i zgodne z określonymi zasadami, jest również istotne, ale nie wpływa bezpośrednio na szybkość operacji na bazie danych. Takie podejścia mogą prowadzić do błędnych przekonań, że poprawa wydajności bazy danych można osiągnąć poprzez wprowadzenie dodatkowych ograniczeń lub zmian w strukturze danych, co w rzeczywistości może generować dodatkowe koszty obliczeniowe przy wykonywaniu podstawowych operacji. Kluczowe jest stosowanie odpowiednich technik indeksacji, które są powszechnie uznawane za najlepszą praktykę w kontekście optymalizacji zasobów bazy danych.

Pytanie 2

Wskaż właściwą sekwencję kroków w procesie projektowania relacyjnej bazy danych?

A. Selekcja, Określenie relacji, Określenie kluczy głównych tabel, Określenie zbioru danych

B. Określenie zbioru danych, Selekcja, Określenie kluczy głównych tabel, Określenie relacji

C. Określenie kluczy głównych tabel, Określenie zbioru danych, Selekcja, Określenie relacji

D. Określenie relacji, Określenie kluczy głównych tabel, Selekcja, Określenie zbioru danych

Wybranie błędnej odpowiedzi sugeruje, że nie do końca rozumiesz, jak działa proces projektowania relacyjnej bazy danych. Kiedy kolejność kroków jest pomijana, mogą się pojawić problemy. Czasem widziałem, że klucze podstawowe są określane jeszcze przed zdefiniowaniem zbioru danych. To może prowadzić do błędnego przypisania kluczy do tabel. Klucz podstawowy powinien być oparty na wcześniej zdefiniowanych danych, żeby wszystko było unikalne i wartościowe. Jak się nie rozumie, jakie dane mają być w bazie, to ustalanie relacji na wyrost nie ma sensu. W praktyce, jeśli źle podchodzimy do projektowania bazy danych, to później mogą być kłopoty z zarządzaniem danymi, co wpłynie na efektywność naszej aplikacji. Dlatego warto skupić się na dobrze przemyślanym zbiorze danych zanim zaczniemy myśleć o kluczach i relacjach.

Pytanie 3

Co uzyskujemy po wykonaniu zapytania SQL?

A. liczbę uczniów, których średnia ocen wynosi 5

B. suma ocen uczniów, których średnia ocen wynosi 5

C. średnią wszystkich ocen uczniów

D. całkowitą liczbę uczniów

Analizując błędne koncepcje w tym pytaniu warto zwrócić uwagę na mechanizmy działania zapytań SQL które często są mylnie interpretowane. Zapytanie SELECT count(*) nie zwraca liczby wszystkich uczniów lecz tylko tych którzy spełniają określone warunki tutaj średnia ocen wynosi 5. Wybór SELECT count(*) jest kluczowy ponieważ w odróżnieniu od funkcji takich jak AVG() czy SUM() nastawiony jest na zliczanie wierszy a nie na obliczanie wartości średnich czy sum. Mylnym przekonaniem może być że tak skonstruowane zapytanie zwraca średnią ocen wszystkich uczniów; do tego celu służyłaby funkcja AVG(). Podobnie błędne byłoby oczekiwanie że zwróci sumę ocen studentów z daną średnią. Suma wymagałaby użycia funkcji SUM() i odpowiednich modyfikacji zapytania. Często popełnianym błędem jest także niedostrzeżenie że zapytanie z klauzulą WHERE ogranicza wyniki do podzbioru danych co jest kluczowe dla jego poprawnej interpretacji. Zrozumienie tych różnic jest istotne dla efektywnego wykorzystania SQL w praktyce zawodowej i unikania błędów analitycznych.

Pytanie 4

Dostosowanie wyglądu strony dla konkretnego użytkownika i jego identyfikacja w serwisie są możliwe dzięki systemowi

A. formularzy

B. obiektów DOM

C. połączenia z bazą

D. cookie

Obiekty DOM (Document Object Model) to reprezentacja struktury dokumentu HTML lub XML. Dzięki DOM, programiści mogą manipulować elementami na stronie w czasie rzeczywistym, jednak nie umożliwia on identyfikacji użytkowników ani personalizacji ich doświadczeń. DOM pozwala na dynamiczne zmiany w treści strony, ale nie przechowuje informacji o użytkowniku po zamknięciu przeglądarki. Łączenie z bazą danych to proces, który zapewnia dostęp do przechowywanych danych, ale również nie służy do identyfikacji użytkownika na poziomie przeglądarki. Właściwie używane, łączenie z bazą pozwala na pobieranie i zapisywanie danych, jednak wymaga dodatkowych mechanizmów, takich jak sesje, aby poprawnie identyfikować użytkowników. Formularze są narzędziem do zbierania danych od użytkowników, ale same w sobie nie oferują możliwości identyfikacji lub personalizacji. Użytkownik musi wprowadzić dane, które następnie mogą być przetwarzane, ale bez zastosowania cookie lub innych mechanizmów, serwis nie będzie w stanie pamiętać o tych danych przy kolejnych wizytach. W skrócie, obiekty DOM, łączenie z bazą oraz formularze stanowią tylko część ekosystemu webowego, ale nie zapewniają pełnych możliwości identyfikacji i personalizacji użytkownika, jak to robią pliki cookie.

Pytanie 5

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

A. Apache oraz PHP

B. Apache, PHP i MySQL

C. PHP oraz MySQL

D. IIS, Perl oraz MySQL

Aby uruchomić system CMS Joomla!, niezbędne jest środowisko składające się z serwera Apache, języka PHP oraz bazy danych MySQL. Apache jest jednym z najpopularniejszych serwerów WWW, który obsługuje zapytania HTTP i serwuje zawartość stron internetowych. PHP to skryptowy język programowania, który jest powszechnie używany do tworzenia dynamicznych stron internetowych i aplikacji webowych. W kontekście Joomla!, PHP jest odpowiedzialne za przetwarzanie kodu i interakcję z bazą danych. MySQL natomiast to system zarządzania relacyjnymi bazami danych, który przechowuje wszystkie dane potrzebne do działania Joomla!, takie jak informacje o użytkownikach, artykułach i ustawieniach systemowych. Współpraca tych trzech komponentów tworzy stabilne środowisko do działania Joomla!, zapewniając optymalizację wydajności oraz bezpieczeństwo. Warto również zaznaczyć, że Joomla! wymaga minimum wersji PHP 7.2 oraz MySQL 5.5, aby zapewnić pełną funkcjonalność i wsparcie dla nowoczesnych rozwiązań webowych.

Pytanie 6

Jakie są różnice między poleceniami DROP TABLE a TRUNCATE TABLE?

A. Oba polecenia usuwają tylko zawartość tabeli, lecz tylko DROP TABLE może być cofnięte

B. DROP TABLE kasuje tabelę, natomiast TRUNCATE TABLE zmienia dane w niej, które spełniają określony warunek

C. Obydwa polecenia usuwają tabelę wraz z jej zawartością, jednak tylko TRUNCATE TABLE może być cofnięte

D. DROP TABLE kasuje tabelę, a TRUNCATE TABLE usuwa wszystkie dane, pozostawiając tabelę pustą

W odpowiedziach błędnych pojawiają się nieporozumienia dotyczące podstawowych funkcji poleceń DROP TABLE i TRUNCATE TABLE. Istnieje powszechne przekonanie, że oba polecenia działają podobnie, co prowadzi do mylnego wniosku, że można je stosować zamiennie. DROP TABLE rzeczywiście usuwa zarówno strukturę tabeli, jak i jej zawartość, a po jego wykonaniu nie ma możliwości przywrócenia usuniętej tabeli bez wcześniejszego wykonania kopii zapasowej. Z kolei TRUNCATE TABLE usuwa jedynie dane, a sama tabela pozostaje nienauszona. Tego typu pomyłki często są wynikiem braku zrozumienia kontekstu, w jakim używane są te polecenia. Dodatkowo, TRUNCATE TABLE działa na poziomie strony danych, co czyni je szybszym, niż usuwanie danych za pomocą DELETE. Wiele osób błędnie uważa, że oba polecenia są równoważne i że można cofnąć operację DROP TABLE, co jest nieprawdziwe. W praktyce, zrozumienie różnic pomiędzy tymi poleceniami jest kluczowe dla zarządzania danymi w bazach danych, a nieprawidłowe ich użycie może prowadzić do nieodwracalnej utraty danych. Ważne jest, aby przed wykonaniem któregokolwiek z tych poleceń dokładnie przemyśleć skutki, jakie przyniesie ich użycie.

Pytanie 7

Uprawnienia obiektowe przyznawane użytkownikom serwera bazy danych mogą umożliwiać lub ograniczać

A. przechodzić uprawnienia

B. wykonywać polecenia, takie jak tworzenie kopii zapasowej

C. realizować operacje na bazie, takie jak wstawianie lub modyfikowanie danych

D. zmieniać role i konta użytkowników

Uprawnienia obiektowe w kontekście baz danych pozwalają na kontrolowanie dostępu do różnych zasobów, takich jak tabele, widoki czy procedury składowane. Odpowiedź dotycząca wykonywania operacji na bazie, takich jak wstawianie czy modyfikowanie danych, jest prawidłowa, ponieważ uprawnienia te bezpośrednio wpływają na możliwości użytkownika w zakresie manipulacji danymi. Przykładowo, jeśli użytkownik posiada uprawnienie do INSERT, może dodawać nowe rekordy do tabeli, natomiast uprawnienie UPDATE pozwala na zmianę istniejących danych. Takie zarządzanie uprawnieniami jest kluczowe w kontekście bezpieczeństwa danych oraz zapewnienia integralności systemu, ponieważ pozwala na ograniczenie dostępu tylko do tych operacji, które są niezbędne dla danego użytkownika. W praktyce administratorzy baz danych stosują zasady minimalnych uprawnień, przyznając użytkownikom tylko te uprawnienia, które są niezbędne do wykonywania ich pracy, co jest zgodne z najlepszymi praktykami w zakresie zarządzania bezpieczeństwem baz danych.

Pytanie 8

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 DISTINCT miasto FROM mieszkancy;

B. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;

C. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;

D. SELECT COUNT(miasto) FROM mieszkancy;

Wybór odpowiedzi "SELECT COUNT(DISTINCT miasto) FROM mieszkancy;" jest naprawdę trafny. Używasz funkcji COUNT razem z DISTINCT, co pozwala na zliczenie tylko unikalnych miast w tabeli 'mieszkancy'. Funkcja COUNT liczy wszystkie wiersze, a DISTINCT usuwa duplikaty, dzięki czemu dostajemy dokładną liczbę miast. Fajnie jest to wykorzystać, gdy analizujesz dane demograficzne – wtedy wiesz, jakie masz rozkłady w różnych miastach. W bazach danych to standardowy sposób, bo dzięki temu unikasz powielania danych i masz lepsze analizy. Ważne jest też, żeby pamiętać o wydajności zapytań; połączenie DISTINCT z COUNT może być bardziej efektywne niż próba szukania duplikatów później. No i zasady normalizacji bazy danych? One rzeczywiście pomagają w tym, żeby dane były uporządkowane, co ułatwia ich przetwarzanie i analizowanie.

Pytanie 9

W języku PHP, przy pracy z bazą MySQL, aby zakończyć sesję z bazą, należy wywołać

A. mysqli_close()

B. mysqli_exit()

C. mysqli_rollback()

D. mysqli_commit()

Inne odpowiedzi na to pytanie wprowadzają w błąd, ponieważ każda z nich ma inne znaczenie i zastosowanie w kontekście operacji na bazie danych MySQL. Na przykład, mysqli_exit() nie jest standardową funkcją w bibliotece MySQLi i nie istnieje w dokumentacji PHP, co czyni ją nieprawidłową. Funkcje mysqli_commit() i mysqli_rollback() służą do zarządzania transakcjami w bazach danych. mysqli_commit() zapisuje wszystkie zmiany dokonane w bieżącej transakcji, podczas gdy mysqli_rollback() przywraca stan bazy danych do momentu rozpoczęcia transakcji w przypadku, gdy wystąpił błąd lub gdy zdecydujemy się nie akceptować dokonanych zmian. Użycie tych funkcji jest kluczowe w kontekście zapewnienia integralności danych, zwłaszcza w aplikacjach, gdzie wiele operacji zmienia stan bazy danych. Typowy błąd myślowy, który prowadzi do wyboru tych odpowiedzi, to mylenie zamknięcia połączenia z bazą z zarządzaniem transakcjami. Ważne jest, aby zrozumieć, że mimo iż zarówno zamknięcie połączenia, jak i zarządzanie transakcjami są ważnymi aspektami pracy z bazą danych, pełnią one zupełnie różne funkcje. Właściwe zamknięcie połączenia jest kluczowe, aby uniknąć problemów z wydajnością i dostępnością zasobów, które mogą wystąpić, jeśli połączenia nie zostaną prawidłowo zakończone.

Pytanie 10

W podanym kodzie PHP, w miejscu kropek należy umieścić odpowiednią instrukcję

$zapytanie = mysqli_query($db, "SELECT imie, nazwisko FROM uzytkownik");
while ($wiersz = ...................)
    echo "$wiersz[0] $wiersz[1]";

A. mysqli_free_result($zapytanie)

B. mysqli_num_fields($zapytanie)

C. mysqli_query($zapytanie)

D. mysqli_fetch_array($zapytanie)

Funkcja mysqli_fetch_array($zapytanie) jest używana do pobierania wyników zapytania SQL w formie tablicy asocjacyjnej lub indeksowanej. W kontekście podanego kodu, po wykonaniu zapytania SELECT do bazy danych, wyniki są zwracane jako zasób, który musi być przetworzony. Mysqli_fetch_array pozwala na iteracyjne przetwarzanie każdego wiersza z zestawu wyników, co umożliwia dostęp do poszczególnych wartości pól za pomocą indeksów lub kluczy. Jest to przydatne w sytuacjach, gdzie dane muszą być wyświetlane lub przetwarzane w pętli, jak w przykładowym kodzie. Tablica zwracana przez mysqli_fetch_array może zawierać pola zarówno z indeksami numerycznymi, jak i nazwami kolumn, co daje elastyczność w dostępie do danych. Zgodnie z dobrymi praktykami programistycznymi, zawsze należy sprawdzić, czy zapytanie zostało wykonane poprawnie, zanim zacznie się przetwarzać jego wyniki, oraz zwolnić pamięć po zakończeniu przetwarzania wyników. Stosowanie odpowiednich mechanizmów obsługi błędów i zabezpieczeń, takich jak przygotowane zapytania, jest również kluczowe dla bezpieczeństwa aplikacji.

Pytanie 11

W formularzu dokumentu PHP znajduje się pole <input name="im">. Po tym, jak użytkownik wprowadzi ciąg znaków "Janek", aby dodać zawartość tego pola do bazy danych, w tablicy $_POST obecny jest element

A. Janek o indeksie im

B. Janek z następnym numerem indeksu

C. im z następnym numerem indeksu

D. im z indeksem Janek

Poprawna odpowiedź to "Janek o indeksie im", ponieważ w PHP, gdy formularz jest przesyłany, wartości pól formularza są przekazywane do tablicy globalnej $_POST, gdzie kluczami są nazwy pól, a wartościami są dane wprowadzone przez użytkownika. W przypadku pola <input name="im">, po wprowadzeniu przez użytkownika ciągu "Janek", w tablicy $_POST pojawi się element, w którym klucz to "im", a wartość to "Janek". Zgodnie z dobrymi praktykami programistycznymi, nazwy pól powinny być zrozumiałe i znaczące, co ułatwia późniejsze przetwarzanie danych. Przykładem może być sytuacja, w której tworzymy formularz rejestracyjny; odpowiednie nazewnictwo pól, takich jak "im" dla imienia, poprawia czytelność kodu oraz jego konserwowalność. Warto dodać, że dobrym zwyczajem jest również walidacja danych przed ich przetworzeniem, aby zapewnić bezpieczeństwo aplikacji oraz uniknąć potencjalnych ataków, takich jak SQL Injection.

Pytanie 12

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

A. dziedziną.

B. atrybutem.

C. związkiem.

D. krotką.

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 13

W tabeli Recepta pola Imię oraz Nazwisko odnoszą się do pacjenta, dla którego recepta została wystawiona. Jaką kwerendę należy wykorzystać, aby dla wszystkich recept uzyskać datę ich wystawienia oraz imię i nazwisko lekarza, który je wystawił?

A. SELECT Imie, Nazwisko, DataWystawienia FROM Recepta

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

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

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

Patrząc na inne odpowiedzi, widzę, że sporo osób ma problem z rozumieniem relacji między tabelami w bazach danych. W tym przypadku, kluczowe jest korzystanie z JOIN, żeby połączyć dane z Recepty i Lekarza. Kiedy ktoś nie używa tej klauzuli, no to nie ma jak prawidłowo powiązać lekarza z datą wystawienia recepty, co jest wymagane. Jeżeli kwerenda się ogranicza do jednej tabeli, to niestety nie dostaniesz wszystkich potrzebnych informacji. No i musisz pamiętać, że Imie i Nazwisko dotyczą lekarza, a nie pacjenta. Zrozumienie, jak działa klucz obcy (Lekarz_id) w Recepta to kluczowa sprawa. Właściwe skonstruowanie kwerendy polega na połączeniu tych danych przez JOIN – to podstawa, jak chcesz zarządzać bazami danych. Umiejętności w SQL są naprawdę niezbędne w wielu technicznych zawodach, a złe zapytania mogą skutkować błędnymi wynikami, co w pracy może mieć poważne konsekwencje. Myślę, że warto dobrze zrozumieć, jak te relacje działają.

Pytanie 14

Jakie zapytanie SQL będzie odpowiednie do odnalezienia w podanej tabeli tylko imion oraz nazwisk pacjentów, którzy przyszli na świat przed rokiem 2002?

A. SELECT imie, nazwisko FROM Pacjenci WHERE data_ostatniej_wizyty < 2002

B. SELECT * FROM Pacjenci WHERE rok_urodzenia LIKE 2002

C. SELECT * FROM Pacjenci WHERE rok_urodzenia <= 2002

D. SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < 2002

W SQL naprawdę ważne jest, żeby znać różnice między różnymi operatorami i strukturami. Często można się potknąć na operatorach takich jak LIKE, ponieważ ten operator nadaje się bardziej do tekstów, a nie do porównań liczbowych. Tak naprawdę, w przypadku liczb lepiej używać operatorów takich jak < lub <=, które są bardziej celne i efektywne. Jak porównujesz rok urodzenia z 2002, to którzy się urodzili przed tym rokiem, to operator < jest tu niezbędny. Inną sprawą jest użycie selekcji * – to z kolei pobiera wszystkie dane z tabeli. Oczywiście, rozumiem, że nie zawsze jest to potrzebne, bo i tak interesuje nas tylko kilka kolumn. Poza tym, umiejętność pisania sensownych zapytań to kluczowa umiejętność w pracy z bazami danych. Na koniec, warunek data_ostatniej_wizyty < 2002 jest zupełnie nietrafiony, bo dotyczy wizyt, a nie urodzin pacjentów, co totalnie mija się z celem. Musisz bardziej zwracać uwagę na to, jakie kolumny potrzebujesz, żeby dobrze zrozumieć, co właściwie chcesz wyciągnąć z bazy danych.

Pytanie 15

Używając polecenia BACKUP LOG w MS SQL Server, można

A. wykonać kopię zapasową dziennika transakcji

B. wykonać całkowitą kopię zapasową

C. połączyć się z kopią zapasową

D. przeglądać komunikaty wygenerowane w trakcie tworzenia kopii

Pierwsza odpowiedź sugeruje, że polecenie BACKUP LOG może być użyte do wykonania pełnej kopii bezpieczeństwa bazy danych. W rzeczywistości, pełna kopia bezpieczeństwa jest realizowana za pomocą polecenia BACKUP DATABASE, które zgrywa całą bazę danych, w tym wszystkie obiekty i dane. BACKUP LOG dotyczy jedynie dziennika transakcyjnego, co oznacza, że nie jest to odpowiednia odpowiedź. Druga odpowiedź sugeruje, że można zalogować się do kopii bezpieczeństwa, co jest konceptualnie niepoprawne. Kopie zapasowe są plikami, które można przywrócić, ale nie oferują bezpośredniego dostępu do bazy danych. Użytkownik nie może zalogować się do backupu, dopóki nie zostanie przywrócony do instancji SQL Server. Wreszcie, trzecia odpowiedź sugeruje, że BACKUP LOG pozwala na przeczytanie komunikatów wygenerowanych podczas tworzenia kopii. W rzeczywistości, przy tworzeniu kopii zapasowych, komunikaty są rejestrowane w logach serwera, a polecenie BACKUP LOG nie służy do ich przeglądania. Można je jednak monitorować przy pomocy narzędzi do zarządzania SQL Server lub poprzez odpowiednie zapytania do systemowych tabel logów. Dlatego wszystkie te odpowiedzi są błędne w kontekście polecenia BACKUP LOG.

Pytanie 16

Aby zaktualizować maksymalną długość kolumny imie w tabeli klienci do 30 znaków, należy zastosować w języku SQL poniższy kod

A. ALTER TABLE klienci CHANGE imie TEXT;

B. CHANGE TABLE klienci TO COLUMN imie SET CHAR(30);

C. ALTER TABLE klienci MODIFY COLUMN imie VARCHAR(30);

D. CHANGE TABLE klienci MODIFY imie CHAR(30);

Każda z pozostałych odpowiedzi zawiera błędne podejścia do zmiany długości pola w tabeli. Odpowiedź CHANGE TABLE klienci TO COLUMN imie SET CHAR(30) nie jest poprawna, ponieważ składnia SQL nie przewiduje użycia słowa kluczowego 'CHANGE' w kontekście zmiany kolumny. W SQL zmiany struktury tabeli wykonuje się za pomocą polecenia ALTER TABLE. Dodatkowo, CHAR(30) nie jest zalecane w przypadku, gdy długość przechowywanych danych może się różnić, gdyż zawsze rezerwuje miejsce na 30 znaków, co prowadzi do marnotrawstwa przestrzeni dyskowej. Odpowiedź ALTER TABLE klienci CHANGE imie TEXT jest błędna, ponieważ zmienia typ danych na TEXT, który może przechowywać znacznie większe ilości danych, co nie jest wymagane w przypadku imienia. Przykładowo, użycie TEXT uniemożliwia również wykorzystanie indeksów na tym polu, co może wpłynąć negatywnie na wydajność zapytań. Odpowiedź CHANGE TABLE klienci MODIFY imie CHAR(30) również jest nieprawidłowa z powodu stosowania złej składni oraz wyboru niewłaściwego typu danych. Stosowanie CHAR dla imion może prowadzić do nieefektywności w przechowywaniu, a także nieodpowiedniego zarządzania długością danych, co jest sprzeczne z najlepszymi praktykami projektowania baz danych.

Pytanie 17

Tabela Pracownicy zawiera informacje na temat pracowników różnych działów, co jest zaznaczone przez pole liczbowe dzial. Z racji tego, że zazwyczaj kwerendy dotyczą tylko działu 2, można uprościć zapytania do tej tabeli, tworząc wirtualną tabelę o nazwie Prac_dzial2 przy użyciu zapytania

A. VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;

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

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

D. CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;

Odpowiedź 'CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2;' jest poprawna, ponieważ wykorzystuje standardowe polecenie SQL do tworzenia widoku. Widok jest wirtualną tabelą, która umożliwia użytkownikom wykonywanie zapytań w oparciu o wcześniej zdefiniowane kryteria, co może znacznie uprościć złożoność zapytań w bazach danych. W tym przypadku, widok 'Prac_dzial2' automatycznie filtruje dane, zwracając jedynie pracowników przypisanych do działu 2. Przy pomocy tego widoku, użytkownicy mogą szybko uzyskać dostęp do tego subsetu danych bez konieczności każdorazowego pisania złożonych zapytań. Z perspektywy zarządzania bazą danych, tworzenie widoków jest uznawane za dobrą praktykę, ponieważ pozwala na lepszą organizację i bezpieczeństwo danych, a także stanowi dodatkową warstwę abstrakcji, która może ułatwić stosowanie polityk dostępu. Na przykład, jeśli firma zmieni strukturę działów, wystarczy zaktualizować definicję widoku, co nie wymaga modyfikacji wszystkich zapytań korzystających z tego widoku.

Pytanie 18

W posiadanej tabeli zwanej przedmioty, która zawiera kolumny ocena oraz uczenID, aby wyliczyć średnią ocen dla ucznia z ID równym 7, należy użyć zapytania

A. SELECT AVG(ocena) FROM przedmioty WHERE uczenID = 7

B. COUNT SELECT ocena FROM przedmioty WHERE uczenID = 7

C. SELECT COUNT(ocena) FROM przedmioty WHERE uczenID = 7

D. AVG SELECT ocena FROM przedmioty WHERE uczenID = 7

Wybór innych opcji jest niepoprawny z kilku powodów. Odpowiedź, która zawiera 'AVG SELECT ocena FROM przedmioty WHERE uczenID = 7;' jest błędna, ponieważ nieprawidłowo formułuje składnię SQL. W SQL kolejność słów w zapytaniach jest kluczowa, a funkcje agregujące, takie jak AVG, muszą być używane po słowie SELECT. Z kolei wybór 'COUNT SELECT ocena FROM przedmioty WHERE uczenID = 7;' również jest błędny, ponieważ 'COUNT' jest funkcją, która zlicza ilość wierszy spełniających określone warunki, a nie średnią, co nie odpowiada zadaniu. Warto zauważyć, że mylenie funkcji agregujących, takich jak AVG i COUNT, to powszechny błąd, który wynika z niepełnego zrozumienia ich funkcji. W przypadku zapytania 'SELECT COUNT(ocena) FROM przedmioty WHERE uczenID = 7;' z kolei, chociaż składnia jest poprawna, zapytanie to zlicza liczbę ocen, a nie ich średnią, co nie spełnia wymagań pytania. To podejście nie tylko wprowadza w błąd, ale także może prowadzić do nieprawidłowych analiz danych. Kluczowe jest zrozumienie, że różne funkcje agregujące mają różne zastosowania i nie można ich stosować zamiennie. Użytkownicy pracujący z bazami danych powinni szczególnie zwracać uwagę na typy danych, jakie są przechowywane w ich tabelach oraz na odpowiednią składnię SQL, aby uzyskać zamierzony efekt.

Pytanie 19

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

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

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

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

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

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

Pytanie 20

Polecenie serwera MySQL postaci

REVOKE DELETE, UPDATE ON pracownicy FROM 'tKowal'@'localhost'

sprawi, że użytkownikowi tKowal zostaną

A. odebrane uprawnienia usuwania i modyfikowania danych w tabeli pracownicy

B. przydzielone uprawnienia do wszelkiej zmiany struktury tabeli pracownicy

C. przydzielone uprawnienia do usuwania i aktualizowania danych w tabeli pracownicy

D. odebrane uprawnienia usuwania i dodawania rekordów w tabeli pracownicy

Wszystkie niepoprawne odpowiedzi dotyczą różnych aspektów zarządzania uprawnieniami w MySQL, ale nie odzwierciedlają skutków działania polecenia REVOKE. W pierwszej z nieprawidłowych odpowiedzi stwierdza się, że użytkownik otrzymuje prawa do usuwania i aktualizowania danych w tabeli 'pracownicy'. Jest to nieprawda, ponieważ komenda REVOKE ma na celu odebranie, a nie przydzielenie jakichkolwiek uprawnień. Kolejna odpowiedź sugeruje, że użytkownik traci prawa do usuwania i dodawania rekordów w tabeli. Chociaż uprawnienie do usuwania jest słuszne, dodawanie rekordów (INSERT) nie zostało wymienione w poleceniu REVOKE, więc ta odpowiedź jest myląca. Ostatnia niepoprawna opcja wskazuje, że użytkownik zyskuje prawa do zmiany struktury tabeli 'pracownicy'. W rzeczywistości REVOKE nie ma nic wspólnego z uprawnieniami związanymi ze strukturą tabeli, takimi jak ALTER czy CREATE. Właściwe zrozumienie mechanizmów zarządzania uprawnieniami jest kluczowe dla zapewnienia bezpieczeństwa danych oraz skutecznego zarządzania bazą danych w MySQL.

Pytanie 21

W SQL przeprowadzono zapytanie, jednak jego realizacja nie powiodła się, co skutkowało błędem: #1396 - Operation CREATE USER failed for 'anna'@'localhost'. Możliwą przyczyną takiego zachowania bazy danych może być

CREATE USER 'anna'@'localhost' IDENTIFIED BY '54RTu8';

A. istnienie użytkownika anna w bazie

B. niewystarczające hasło dla konta anna

C. błędna składnia polecenia CREATE USER

D. nieznane polecenie CREATE USER

Odpowiedzi sugerujące zbyt słabe hasło, nieznane polecenie, czy też nieprawidłową składnię polecenia są mylące i wskazują na brak zrozumienia podstawowych zasad działania systemów zarządzania bazą danych MySQL. Po pierwsze, hasło '54RTu8' spełnia standardowe wymagania dotyczące złożoności, które zazwyczaj obejmują minimalną długość oraz kombinację liter i cyfr, co czyni tę odpowiedź nieprawidłową. Ponadto, polecenie CREATE USER jest standardowym poleceniem w SQL, więc stwierdzenie, że jest ono 'nieznane', również nie ma podstaw. Warto zauważyć, że składnia polecenia jest poprawna i nie zawiera żadnych błędów typograficznych. Takie myślenie może prowadzić do fałszywych wniosków, co jest szczególnie problematyczne w kontekście rozwiązywania problemów. W praktyce, użytkownicy powinni nauczyć się korzystać z dokumentacji oraz narzędzi diagnostycznych, takich jak logi błędów, aby lepiej zrozumieć przyczyny problemów. Przykładem dobrej praktyki jest stosowanie komendy SHOW GRANTS, aby sprawdzić, jakich uprawnień już istniejący użytkownik może potrzebować, zanim podejmie się decyzji o jego usunięciu czy modyfikacji.

Pytanie 22

Jaką właściwość pola w tabeli powinno się ustawić, aby akceptowało ono wyłącznie dane liczbowe?

A. Maskę wprowadzania

B. Tagi inteligentne

C. Regułę sprawdzania poprawności

D. Wartość domyślną

Tagi inteligentne są narzędziem umożliwiającym szybki dostęp do dodatkowych funkcji lub opcji związanych z danymi w polu. Nie mają jednak zdolności do ograniczania samej zawartości pola w kontekście dozwolonych znaków. Ich rola jest raczej wspomagająca użytkownika poprzez dodawanie kontekstowych opcji, ale nie dotyczą bezpośrednio walidacji danych. Wartość domyślna to z kolei predefiniowana wartość, jaką pole przyjmuje w momencie tworzenia nowego rekordu, jednak nie wpływa na to, jakie dane użytkownik może wprowadzić. Jest użyteczna do ułatwienia tworzenia danych, ale nie służy do ograniczania formatu wprowadzanych danych. Chociaż reguła sprawdzania poprawności może być stosowana do określania, jakie dane są uznawane za poprawne, jej główną rolą jest weryfikacja już wprowadzonych danych, a nie ich formatowanie w trakcie wprowadzania. Reguły te mogą informować o błędach po wprowadzeniu danych, lecz nie zapobiegają samemu wprowadzaniu błędnych danych. Wiele osób może mylnie sądzić, że reguła sprawdzania poprawności i maska wprowadzania pełnią podobne funkcje, jednak maska działa na poziomie interfejsu wprowadzania, wymuszając określony format w czasie rzeczywistym, podczas gdy reguła działa retrospektywnie. Zrozumienie tych różnic pozwala na odpowiednie zastosowanie tych narzędzi w projektowaniu baz danych, co skutkuje lepszym zarządzaniem jakością danych oraz zwiększeniem intuicyjności interfejsu użytkownika. Stosowanie masek wprowadzania jest szczególnie korzystne w kontekście aplikacji z dużą ilością danych liczbowych, gdzie precyzja jest kluczowa, a reguły poprawności lepiej sprawdzają się w kontekście logicznych zależności pomiędzy polami danych. To rozróżnienie jest kluczowe dla osiągnięcia wysokiej jakości danych i łatwej obsługi w systemach informatycznych.

Pytanie 23

W SQL polecenie INSERT INTO służy do

A. tworzenia nowej tabeli

B. wprowadzania nowych pól do tabeli

C. zmiany rekordów na wskazaną wartość

D. dodawania danych do tabeli

Wprowadzenie do polecenia INSERT INTO często prowadzi do nieporozumień, szczególnie w kontekście funkcji, jakie pełni w SQL. Nieodpowiednie rozumienie tego polecenia może skutkować błędami w projektowaniu baz danych oraz w wykonywaniu operacji na danych. Na przykład, stwierdzenie, że INSERT INTO aktualizuje rekordy, jest nieprecyzyjne. W rzeczywistości, do aktualizacji istniejących danych używa się polecenia UPDATE, które zmienia wartości w określonych rekordach na podstawie podanych kryteriów. Ponadto, w SQL nie można dodawać nowych pól do tabeli za pomocą INSERT INTO; do tego służy polecenie ALTER TABLE. To ostatnie jest niezbędne, gdyż pozwala na modyfikację struktury tabeli, co jest kluczowe w przypadku zmieniających się wymagań aplikacji. Podobnie, stwierdzenie, że INSERT INTO dodaje tabelę, jest również błędne, ponieważ do tego używa się polecenia CREATE TABLE. Ważne jest, aby zrozumieć, że różne polecenia SQL mają swoje specyficzne zastosowania i nie można ich ze sobą mylić. Typowe błędy myślowe w tym zakresie mogą wynikać z nieznajomości języka SQL lub z braku zrozumienia różnicy pomiędzy operacjami na danych a operacjami na strukturze bazy danych. Zrozumienie tych podstawowych różnic jest kluczowe dla efektywnego zarządzania danymi oraz dla poprawnego projektowania baz danych.

Pytanie 24

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

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

B. SELECT tytul FROM ksiazki WHERE cena < 50;

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

D. SELECT * FROM ksiazki WHERE cena < 50;

Odpowiedź "SELECT tytul FROM ksiazki WHERE cena < 50;" jest prawidłowa, ponieważ wykorzystuje składnię SQL, która pozwala na wybranie konkretnych pól z tabeli. W tym przypadku przy pomocy klauzuli SELECT określamy, że interesują nas tylko tytuły książek, a klauzula WHERE filtruje wyniki, zwracając jedynie te rekordy, w których cena jest niższa niż 50 zł. To podejście jest zgodne z najlepszymi praktykami, ponieważ zamiast używać operatora *, który zwraca wszystkie kolumny, wskazujemy dokładnie, jakie dane są nam potrzebne. Dzięki temu kwerenda jest bardziej wydajna i przejrzysta. Przykładowo, w przypadku dużych zbiorów danych, ograniczenie wyników do konkretnego pola może znacząco poprawić czas wykonania zapytania oraz zmniejszyć obciążenie serwera. Ponadto, zapis ceny jako liczby, a nie tekstu (np. '50 zł'), umożliwia prawidłowe porównanie wartości numerycznych, co jest kluczowe w tego typu zapytaniach. W praktyce wykorzystanie tego rodzaju zapytań jest niezbędne, aby efektywnie zarządzać danymi i uzyskiwać precyzyjne wyniki w bazach danych.

Pytanie 25

Kompresja bezstratna pliku graficznego zapewnia

A. wyższą jakość

B. mniejszą ilość warstw

C. oryginalną jakość grafiki

D. rozmiar większy niż w oryginale

Odpowiedzi sugerujące, że kompresja bezstratna przyczynia się do lepszej jakości grafiki oraz mniejszej liczby warstw są mylące. Kompresja bezstratna nie poprawia jakości obrazu, a jedynie utrzymuje ją na poziomie oryginalnym, co oznacza, że nie wprowadza żadnych zmian, które mogłyby podnieść jakość wizualną. W przypadku mniejszej liczby warstw, kompresja bezstratna nie zmienia struktury pliku w sensie liczby warstw, lecz koncentruje się na efektywnym przechowywaniu danych bez ich utraty. Co więcej, odpowiedź wskazująca na rozmiar większy niż grafika oryginalna jest całkowicie nieprawidłowa, ponieważ celem kompresji bezstratnej jest właśnie zmniejszenie rozmiaru pliku, a nie jego zwiększenie. Algorytmy kompresji bezstratnej są zaprojektowane tak, aby zminimalizować ilość zajmowanej przestrzeni dyskowej przy jednoczesnym zachowaniu pełnej jakości grafiki. Dlatego wybór odpowiedzi dotyczących mniejszej liczby warstw, lepszej jakości czy zwiększonego rozmiaru jest błędny i nieodpowiedni w kontekście działania kompresji bezstratnej w plikach graficznych.

Pytanie 26

Polecenie GRANT w języku SQL służy do

A. umieszczania nowych danych w bazie.

B. aktualizacji istniejących danych w bazie.

C. nadawania użytkownikom praw do obiektów.

D. odbierania użytkownikom praw do obiektów.

Polecenie GRANT bywa mylone z typowymi instrukcjami modyfikującymi dane, bo wszystko to jest „SQL” i często używa się tego w jednym skrypcie. Warto jednak wyraźnie oddzielić dwie warstwy: operacje na danych oraz operacje na uprawnieniach. Wstawianie nowych rekordów do tabeli realizuje się za pomocą instrukcji INSERT, a nie GRANT. To INSERT decyduje, jakie wartości trafią do konkretnych kolumn, ewentualnie z dodatkowymi klauzulami, triggerami czy ograniczeniami. GRANT w ogóle nie dotyka zawartości tabeli, tylko informację, kto ma prawo wykonać INSERT, SELECT, UPDATE itd. Podobnie aktualizowanie istniejących danych w tabeli odbywa się przez UPDATE, czasem w połączeniu z WHERE, JOIN, podzapytaniami. GRANT nie zmienia ani jednego pola w rekordach – on jedynie przyznaje lub rozszerza zakres uprawnień użytkownika lub roli. Jeśli użytkownik nie ma prawa UPDATE, to najpierw trzeba użyć GRANT, a dopiero potem można wykonać właściwe polecenie UPDATE. Częstym błędem myślowym jest traktowanie SQL jako jednego wielkiego „zestawu komend do wszystkiego” bez rozróżnienia na DML (Data Manipulation Language) i DCL (Data Control Language). GRANT należy właśnie do DCL, razem z REVOKE, i służy do zarządzania bezpieczeństwem. Jeszcze inny typowy skrót myślowy to przekonanie, że GRANT może „zabierać” prawa, bo kojarzy się ogólnie z uprawnieniami. W rzeczywistości standardowo do odbierania uprawnień służy REVOKE. W wielu systemach relacyjnych właśnie tym poleceniem cofa się wcześniej nadane GRANT-y. Z mojego doświadczenia dobrze jest zapamiętać prostą parę: GRANT – nadaje, REVOKE – odbiera. Dzięki temu łatwiej uniknąć pomyłek przy pisaniu skryptów administracyjnych i przy projektowaniu polityki dostępu do tabel, widoków, procedur i innych obiektów bazy danych.

Pytanie 27

W systemie MySQL trzeba użyć polecenia REVOKE, aby użytkownikowi anna cofnąć możliwość wprowadzania zmian jedynie w definicji struktury bazy danych. Odpowiednia komenda do odebrania tych uprawnień ma postać

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

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

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

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

W analizie odpowiedzi, które są niepoprawne, kluczowe jest zrozumienie, jakie uprawnienia są odbierane i dlaczego to ma znaczenie. Odpowiedzi takie jak 'REVOKE ALL ON tabela1 FROM 'anna'@'localhost'' są niewłaściwe, ponieważ polecenie REVOKE ALL odbiera wszystkie prawa użytkownikowi, co może być zbyt drastycznym krokiem. W kontekście zarządzania uprawnieniami, ważne jest, aby podejść do tego z miarą i precyzją, a nie stosować ogólne odbieranie wszystkich praw. Ponadto, odpowiedzi, które obejmują niewłaściwe kombinacje uprawnień, takie jak 'REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'', są również błędne. Odbieranie prawa UPDATE nie jest zgodne z celem pytania, które dotyczy jedynie strukturalnych zmian, a nie wprowadzania danych. Właściwe podejście do konfiguracji uprawnień powinno koncentrować się na ograniczaniu dostępu użytkowników tylko tam, gdzie jest to absolutnie konieczne, a nie na eliminacji ich zdolności do pracy z danymi w ogóle. Użytkownicy często popełniają błąd myślowy, myśląc, że odebranie zbyt wielu uprawnień jest rozwiązaniem problemu bezpieczeństwa, podczas gdy w rzeczywistości może to prowadzić do zablokowania niezbędnych operacji, co zagraża efektywności pracy organizacji.

Pytanie 28

Dana jest tabela uczniowie, do której wpisano rekordy jak na rysunku. Co będzie wynikiem działania przedstawionego zapytania SQL?

SELECT AVG(ocena) FROM uczniowie;

Nazwisko	Imie	ocena
Kowalski	Sebastian	4
Kaczmarek	Marta	3
Baryła	Zenon	4
Gota	Anna	3

A. Dane 4, 3, 4, 3

B. Wartość 3.5

C. Liczba wierszy równa 4

D. Suma ocen równa 14

Widzę, że popełniłeś parę błędów w odpowiedziach. Stwierdzenie 'Suma ocen równa 14' pokazuje, że mogłeś nie do końca zrozumieć, jak działa AVG, bo ta funkcja nie sumuje wartości, ale liczy średnią. Z kolei odpowiedzi 'Dane 4, 3, 4, 3' i 'Liczba wierszy równa 4' też sugerują, że coś nie tak z interpretacją wyników. Pierwsza sugeruje, że zapytanie wyciąga konkretne liczby, a to nieprawda, bo AVG zwraca tylko jedną wartość – średnią. A druga odpowiedź wprowadza w błąd, mówiąc o liczbie wierszy, podczas gdy AVG operuje na wartościach, a nie ich ilości. Tego typu pomyłki mogą wynikać z nieznajomości funkcji agregujących w SQL. Ważne jest, żeby zrozumieć, co każda funkcja robi i jakie zwraca wyniki.

Pytanie 29

W poniższym kodzie PHP wykonano operację na bazie danych. Której funkcji należy użyć, aby pobrać liczbę zmienionych w tabeli wierszy?

$zapytanie="UPDATE kadra SET stanowisko='Programista' WHERE id < 10";
mysqli_query($db, $zapytanie);

A. mysqli_num_rows()

B. mysqli_field_count()

C. mysqli_use_result()

D. mysqli_affected_rows()

Gratulacje! Wybrałeś poprawną odpowiedź, która jest funkcją mysqli_affected_rows(). Ta funkcja jest specyficzna dla języka PHP i jest używana do zwracania liczby wierszy, które zostały zmienione, dodane lub usunięte przez ostatnie wywołanie funkcji mysqli_query() na serwerze MySQL. W kontekście operacji takich jak INSERT, UPDATE, REPLACE lub DELETE, mysqli_affected_rows() jest nieocenionym narzędziem do śledzenia ilości wykonanych zmian w bazie danych. Dlatego właśnie w przypadku przedstawionego pytania, gdzie w kodzie PHP wykonano operację UPDATE na bazie danych, idealnym rozwiązaniem jest użycie funkcji mysqli_affected_rows() do pobrania liczby zmienionych wierszy. Jest to kluczowe zrozumienie, aby efektywnie manipulować danymi w bazach danych MySQL za pomocą języka PHP.

Pytanie 30

Efektem wykonania kwerendy dla przedstawionej tabeli rezerwacje jest

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

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

A. lato 20, zima 27

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

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

D. lato 3, zima 4

Wybrana przez Ciebie odpowiedź nie jest prawidłowa, ponieważ nie odzwierciedla ona poprawnej interpretacji wyniku zapytania SQL. Możliwe, że nie zrozumiałeś, jak działają funkcje agregujące w SQL, takie jak SUM, które służą do sumowania wartości z określonego pola dla grupy rekordów. W tym przypadku, zapytanie SQL grupuje wyniki według sezonu i sumuje liczbę dni dla każdego sezonu. Błąd może wynikać z niezrozumienia, jak działa grupowanie w SQL. Pamiętaj, że kiedy grupujesz dane, operacje są wykonywane na grupach rekordów, a nie na poszczególnych rekordach. Innym możliwym błędem może być niewłaściwe zrozumienie, jak działa funkcja SUM - nie tworzy ona listy sum z poszczególnych rekordów, ale zwraca jedną sumę dla każdej grupy. Staraj się zwracać uwagę na te szczegóły podczas pracy z SQL. To pozwoli Ci lepiej zrozumieć strukturę danych i przeprowadzać precyzyjne analizy.

Pytanie 31

W języku SQL, w wyniku wykonania poniższego zapytania:

ALTER TABLE osoba DROP COLUMN grupa;

A. zostanie usunięta kolumna grupa

B. zostanie zmieniona nazwa kolumny na grupa

C. zostanie dodana kolumna grupa

D. zostanie zmieniona nazwa tabeli na grupa

Pierwsza odpowiedź sugeruje, że kolumna 'grupa' zostanie dodana do tabeli, co jest błędne, ponieważ użycie słowa 'DROP' sugeruje usunięcie, a nie dodanie. W SQL do dodawania kolumn używa się komendy 'ADD', a nie 'DROP'. Druga odpowiedź, która stwierdza, że kolumna zostanie usunięta, jest poprawna, ale nie są podane inne aspekty jej działania. Trzecia odpowiedź dotyczy zmiany nazwy tabeli na 'grupa', co również jest niepoprawne, ponieważ komenda 'ALTER TABLE' z 'DROP COLUMN' nie ma na celu zmiany nazwy tabeli, lecz jedynie modyfikację jej struktury poprzez usunięcie kolumny. Zmiana nazwy tabeli wymagałaby użycia komendy 'RENAME'. Ostatnia odpowiedź, która mówi, że zmienia nazwę kolumny na 'grupa', jest również fałszywa, ponieważ do zmiany nazwy kolumny w SQL używa się komendy 'ALTER COLUMN' z 'RENAME', a nie 'DROP'. Tak więc, wszystkie te odpowiedzi zawierają błędne interpretacje dotyczące funkcji komendy 'ALTER TABLE DROP COLUMN', a zrozumienie tej komendy jest kluczowe dla prawidłowego zarządzania strukturą bazy danych.

Pytanie 32

Aby zmienić strukturę już istniejącej tabeli przy użyciu zapytania SQL, należy użyć kwerendy

A. ALTER TABLE

B. INSERT INTO

C. CREATE TABLE

D. UPDATE

Wybór odpowiedzi 'UPDATE' jest niepoprawny, ponieważ polecenie UPDATE służy jedynie do modyfikacji danych znajdujących się w już istniejących rekordach tabeli, a nie do zmiany samej struktury tabeli. Użycie tego polecenia w kontekście pytania prowadzi do mylnego wniosku, że można za jego pomocą dodawać kolumny lub zmieniać ich typy. Podobnie jak UPDATE, odpowiedź 'INSERT INTO' jest również niewłaściwa. To polecenie jest używane do dodawania nowych rekordów do tabeli, a nie do modyfikacji jej struktury. W praktyce, błędne użycie INSERT INTO w kontekście zmiany struktury tabeli może prowadzić do nieporozumień i komplikacji w zarządzaniu danymi. Ponadto odpowiedź 'CREATE TABLE' jest także nieadekwatna, ponieważ to polecenie tworzy nową tabelę w bazie danych, a nie modyfikuje istniejącą. Typowym błędem w rozumieniu poleceń SQL jest mylenie między operacjami na danych a operacjami na strukturze bazy danych. Kluczowe jest zrozumienie różnicy między tymi typami operacji, ponieważ każda komenda SQL ma swoje specyficzne zastosowanie i nie można ich stosować zamiennie. W kontekście administracji bazami danych, umiejętność rozróżnienia tych komend jest niezbędna, aby efektywnie zarządzać strukturą i danymi w bazach danych.

Pytanie 33

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

A. generowania raportów z danych

B. tworzenia powiązań w relacyjnych bazach danych

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

D. łatwiejszego wprowadzania, edytowania oraz usuwania danych

Formularze do obsługi baz danych są kluczowym narzędziem, które umożliwia użytkownikom łatwe wprowadzanie, edytowanie i usuwanie danych w sposób zorganizowany i efektywny. Głównym celem formularzy jest zapewnienie przyjaznego interfejsu, który upraszcza interakcję z bazą danych, eliminując potrzebę bezpośredniego wprowadzania poleceń SQL czy pracy z tabelami w surowej formie. Dzięki formularzom użytkownicy mogą szybko wprowadzać dane do bazy, a także modyfikować istniejące rekordy, co jest szczególnie istotne w codziennym zarządzaniu danymi. Przykładem zastosowania formularzy jest system CRM, gdzie zespół sprzedażowy może w prosty sposób dodawać nowe informacje o klientach czy aktualizować dane kontaktowe. Dobre praktyki w projektowaniu formularzy obejmują zapewnienie walidacji danych, co pozwala na uniknięcie błędów podczas wprowadzania, oraz stosowanie odpowiednich typów pól, takich jak daty, numery czy listy rozwijane, które zwiększają użyteczność formularza. W skrócie, formularze są nieodłącznym elementem efektywnego zarządzania danymi i poprawiają wydajność pracy z bazami danych.

Pytanie 34

Wskaż system do zarządzania treściami.

A. MariaDB

B. phpMyAdmin

C. Apache

D. Joomla!

Joomla! to system zarządzania treścią (CMS), który umożliwia użytkownikom tworzenie i edytowanie stron internetowych bez potrzeby zaawansowanej wiedzy programistycznej. Jest to jeden z najpopularniejszych CMS na świecie, używany przez miliony witryn, od prostych blogów po skomplikowane portale e-commerce. Jego zalety obejmują elastyczność, możliwość łatwego dostosowywania za pomocą rozbudowanych wtyczek i szablonów oraz aktywną społeczność, która wspiera rozwój i aktualizacje. Joomla! umożliwia zarządzanie użytkownikami, co pozwala na tworzenie złożonych struktur dostępu do treści, co jest istotne w kontekście dużych organizacji. Dobre praktyki przy korzystaniu z Joomla! obejmują regularne aktualizacje, aby zapobiegać lukom bezpieczeństwa, oraz optymalizację treści pod kątem SEO, co zwiększa widoczność witryn w wynikach wyszukiwania. System ten jest zgodny z wieloma standardami webowymi, co czyni go solidnym wyborem dla profesjonalnych projektów webowych.

Pytanie 35

Aby stworzyć poprawną kopię zapasową bazy danych, która będzie mogła zostać później przywrócona, należy najpierw sprawdzić

A. spójność bazy

B. uprawnienia dostępu do serwera bazy danych

C. poprawność składni zapytań

D. możliwość udostępnienia bazy danych

Sprawdzanie możliwości udostępniania bazy danych jest ważne, ale nie ma bezpośredniego wpływu na jakość i integralność samej kopii bezpieczeństwa. Może to dotyczyć kwestii użytkowników i ról, jednak nawet przy poprawnym udostępnieniu, jeżeli dane są niespójne, kopia może być bezużyteczna. Prawa dostępu do serwera bazy danych, choć istotne z punktu widzenia bezpieczeństwa, również nie wpływają na jakość danych. Użytkownik mógłby mieć pełne prawa dostępu, ale to nie gwarantuje, że baza danych jest poprawna i gotowa do stworzenia kopii zapasowej. Poprawność składni zapytań to kolejny aspekt ważny dla efektywnego działania bazy danych, jednak w kontekście wykonywania kopii zapasowej, nie odnosi się bezpośrednio do spójności danych. Nawet poprawnie sformułowane zapytania mogą prowadzić do błędnych wyników, jeśli dane w bazie są w złym stanie. Dlatego też, żadne z wymienionych zagadnień nie zastąpi konieczności sprawdzenia spójności bazy jako kluczowego elementu przed wykonaniem kopii bezpieczeństwa.

Pytanie 36

Kto z wymienionych zajmuje się nieprzerwanym przygotowaniem systemu bazy danych do pracy produkcyjnej, zarządzaniem kontami użytkowników oraz instalowaniem aktualizacji systemu bazodanowego?

A. Twórcy narzędzi dla deweloperów

B. Administratorzy serwerów oraz sieci komputerowych

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

D. Administratorzy systemu bazy danych

Wybór projektantów narzędzi deweloperskich jako odpowiedzialnych za przygotowanie systemu bazy danych do pracy produkcyjnej jest błędny, ponieważ ich głównym zadaniem jest projektowanie i rozwijanie narzędzi oraz aplikacji, które ułatwiają proces tworzenia oprogramowania. Nie zajmują się oni bezpośrednio zarządzaniem bazami danych, lecz tworzą rozwiązania, które mogą być wykorzystywane przez administratorów baz danych. Z kolei administratorzy serwerów i sieci komputerowych koncentrują się na zarządzaniu infrastrukturą sieciową i serwerową, co obejmuje utrzymanie sprzętu oraz zapewnienie jego dostępności i wydajności. Ich praca jest istotna dla ogólnego funkcjonowania systemów, ale nie zajmują się oni bezpośrednio bazami danych ani nie zarządzają nimi. Ostatnia grupa, czyli projektanci i programiści Systemu Zarządzania Bazą Danych, koncentruje się na tworzeniu oprogramowania do zarządzania bazą danych oraz na jego rozwoju. Choć ich praca jest niezbędna w kontekście tworzenia funkcjonalności bazy danych, to nie odpowiadają oni za codzienne zarządzanie i utrzymanie działającego systemu. Dlatego też tylko administratorzy systemu bazy danych są odpowiedzialni za ciągłe przygotowanie systemu do pracy produkcyjnej oraz zarządzanie użytkownikami.

Pytanie 37

Polecenie DROP w języku SQL ma na celu

A. zaktualizować dane obiektu

B. wprowadzić nowy obiekt

C. usunąć istniejący obiekt

D. zmodyfikować parametry obiektu

Instrukcja DROP w języku SQL jest używana do usuwania istniejących obiektów z bazy danych, takich jak tabele, widoki, procedury składowane czy indeksy. Użycie tej komendy powoduje, że wszystkie dane przechowywane w danym obiekcie zostają trwale usunięte, co oznacza, że nie można ich odzyskać, chyba że wcześniej wykonano kopię zapasową. Przykładowa składnia polecenia DROP TABLE nazwa_tabeli usuwa całkowicie tabelę wraz z jej strukturą oraz danymi. W SQL standardowym oraz w jego implementacjach, takich jak MySQL, PostgreSQL czy SQL Server, instrukcja ta jest kluczowym narzędziem dla administratorów baz danych, pozwalającym na efektywne zarządzanie obiektami w bazach. Należy jednak stosować ją ostrożnie, ponieważ skutki wykonania tego polecenia są nieodwracalne. Rekomenduje się również, przed usunięciem obiektu, sprawdzenie, czy nie ma on powiązań z innymi obiektami, aby uniknąć błędów w aplikacjach korzystających z tych danych.

Pytanie 38

Jakie są etapy w odpowiedniej kolejności przy tworzeniu aplikacji?

A. Analiza oczekiwań klienta, określenie wymagań, programowanie, testowanie, wdrożenie

B. Analiza oczekiwań klienta, określenie wymagań, programowanie, wdrożenie, testowanie

C. Programowanie, analiza oczekiwań klienta, określenie wymagań, wdrożenie, testowanie

D. Określenie wymagań, analiza oczekiwań klienta, programowanie, wdrożenie, testowanie

Odpowiedź wskazująca na kolejność: analiza wymagań klienta, specyfikacja wymagań, tworzenie, testy, wdrażanie jest poprawna i odzwierciedla standardowy model cyklu życia oprogramowania (SDLC). Zaczynamy od analizy wymagań, co oznacza zrozumienie potrzeb klienta i zebranie informacji, które będą fundamentem dalszych prac. Następnie przechodzimy do specyfikacji wymagań, gdzie dokumentujemy te potrzeby w formie, która będzie zrozumiała dla zespołu developerskiego. Tworzenie aplikacji następuje po szczegółowym omówieniu i zaakceptowaniu wymagań, co minimalizuje ryzyko błędów. Testy są kluczowym etapem, który pozwala na weryfikację, czy stworzone rozwiązanie spełnia wymagania oraz działa zgodnie z założeniami. Ostateczne wdrożenie aplikacji do użytkowania powinno nastąpić po przeprowadzeniu wszystkich testów i uzyskaniu pozytywnych wyników. Przykład zastosowania tej metodologii można zaobserwować w projektach realizowanych w metodologii Agile, gdzie iteracje pozwalają na ciągłe dostosowywanie aplikacji do zmieniających się potrzeb klienta. Takie podejście zwiększa satysfakcję użytkowników i minimalizuje koszty związane z poprawkami.

Pytanie 39

W przedstawionym kodzie PHP, co powinno się wyświetlić zamiast znaków zapytania?

$x = mysql_query('SELECT * FROM mieszkancy');
 if(!$x)
 echo "???????????????????????";

A. Zapytanie zostało zrealizowane pomyślnie

B. Nieprawidłowe hasło do bazy danych

C. Niepoprawna nazwa bazy danych

D. Błąd w trakcie przetwarzania zapytania

W przypadku odpowiedzi Nieprawidłowe hasło do bazy danych taki komunikat pojawiłby się raczej na wcześniejszym etapie procesu nawiązywania połączenia z bazą danych a nie podczas przetwarzania samego zapytania SQL Błąd związany z hasłem jest związany z funkcją mysql_connect a nie z mysql_query co wskazuje na niepoprawne zrozumienie sekwencji działań w PHP Podobnie odpowiedź Nieprawidłowa nazwa bazy danych sugeruje problem na etapie nawiązywania połączenia z bazą danych zanim jakiekolwiek zapytanie zostanie wykonane Takie błędy zwykle wynikają z podania niepoprawnych parametrów w funkcji łączącej z bazą danych a nie podczas wykonywania zapytania Dodatkowo wybór tej odpowiedzi wskazuje na brak zrozumienia jak działa mechanizm wyboru bazy danych w PHP Odpowiedź Zapytanie przetworzono pomyślnie jest logicznie błędna w kontekście użycia bloku if(!x) który wyraźnie wskazuje na reakcję na niepowodzenie zadania więc nie może być wybrana jako prawidłowa w sytuacji gdy oczekiwane jest wystąpienie błędu Takie błędy myślowe często wynikają z niezrozumienia struktury warunkowej w PHP oraz sposobu obsługi błędów Praktyczną wskazówką jest zawsze testowanie i logowanie komunikatów zwracanych przez funkcje PHP co jest zgodne z dobrymi praktykami programistycznymi i pozwala unikać takich pomyłek

Pytanie 40

Zdefiniowano bazę danych z tabelą sklepy, zawierającą pola: nazwa, ulica, miasto, branża. Aby odnaleźć wszystkie nazwy sklepów spożywczych znajdujących się wyłącznie we Wrocławiu, należy użyć kwerendy:

A. SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND miasto='Wrocław';

B. SELECT sklepy FROM nazwa WHERE branza='spożywczy' BETWEEN miasto='Wrocław';

C. SELECT nazwa FROM sklepy WHERE branza='spożywczy' OR miasto='Wrocław';

D. SELECT sklepy FROM branza='spożywczy' WHERE miasto='Wrocław';

Pierwsza odpowiedź nie jest właściwa, bo użycie BETWEEN w SQL po prostu nie ma sensu w tym kontekście. BETWEEN jest do określania zakresów wartości, na przykład dat, a nie do porównania różnych kolumn. No i zapytanie jest źle skonstruowane, bo nie mówi, z jakiej tabeli chcemy pobrać te dane. Druga odpowiedź też myli się w składni, bo zamienia kolejność operatorów i nie dodaje odpowiednich klauzul, co prowadzi do błędnych wyników. Na przykład, użycie branza='spożywczy' tam gdzie powinno być FROM, to wyraźny błąd. Trzecia odpowiedź korzysta z operatora OR, co jest technicznie błędne dla tego zapytania, ponieważ chcemy, żeby oba warunki były spełnione jednocześnie. W rezultacie, wszystkie te odpowiedzi są po prostu błędne i nie spełniają standardów pisania zapytań SQL.

Rozpocznij nowy egzamin

Powrót do strony głównej