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: 29 kwietnia 2026 09:16
Data zakończenia: 29 kwietnia 2026 09:17

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

Jakie zadania programistyczne należy wykonać na serwerze?

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

B. Zmiana stylu HTML na stronie spowodowana ruchem kursora

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

D. Zapisanie danych pozyskanych z aplikacji internetowej w bazie danych

Zapisanie danych pobranych z aplikacji internetowej w bazie danych to zadanie, które powinno być wykonywane po stronie serwera ze względów bezpieczeństwa, integralności danych oraz zarządzania zasobami. Serwer jest odpowiedzialny za przechowywanie informacji, które mogą być wykorzystywane przez wielu użytkowników, co wymaga centralizacji ich przetwarzania. W przypadku aplikacji internetowych, dane są często przesyłane z klienta (przeglądarki) do serwera, gdzie są walidowane oraz zapisywane w bazach danych. Na przykład, gdy użytkownik rejestruje się w aplikacji, jego dane osobowe są wysyłane do serwera, który sprawdza poprawność tych informacji i zapisuje je w bazie danych. Właściwe implementacje powinny stosować bezpieczne połączenia (np. HTTPS), a także techniki, takie jak sanitizacja danych, aby unikać ataków typu SQL Injection. Dobrą praktyką jest także stosowanie ORM (Object-Relational Mapping), co umożliwia łatwiejsze zarządzanie danymi i ich relacjami. Przechowywanie danych po stronie serwera pozwala na efektywne zarządzanie zasobami i umożliwia późniejsze przetwarzanie informacji w sposób zorganizowany i bezpieczny.

Pytanie 2

W podanym fragmencie zapytania w języku SQL, komenda SELECT jest używana do zwrócenia SELECT COUNT(wartosc) FROM …

A. średniej w kolumnie wartosc

B. średniej wartości z tabeli

C. ilości wierszy

D. summy w kolumnie wartosc

Tak, masz rację! To zapytanie zwraca liczbę wierszy. Użycie funkcji COUNT w SQL jest jakby liczeniem, ile jest niepustych wartości w danej kolumnie. Kiedy piszemy coś takiego jak SELECT COUNT(wartosc) FROM ..., to ta funkcja sprawdza, ile wierszy ma coś w kolumnie 'wartosc'. Przykładowo, w tabeli z danymi sprzedażowymi, kolumna 'wartosc' może mieć wszystkie wartości transakcji. To zapytanie pokaże nam, ile transakcji się odbyło, co jest super przydatne, gdy analizujemy biznes. Funkcja COUNT jest szalenie popularna, bo daje nam jasny obraz tego, co się dzieje w naszych danych. A jeśli zamiast COUNT(wartosc) zrobimy COUNT(*), to dostaniemy ogólną liczbę wszystkich wierszy, niezależnie od tego, czy coś w nich jest, co może być też przydatne, gdy chcemy ogarnąć całą tabelę.

Pytanie 3

Jakie zadanie wykonuje funkcja COUNT w języku SQL?

A. wyliczenie średniej wartości w danej kolumnie

B. liczenie znaków w polu tekstowym

C. zliczanie rekordów uzyskanych z kwerendy

D. obliczenie wartości bezwzględnej w polu liczbowym

Pierwsza z niepoprawnych odpowiedzi sugeruje, że funkcja COUNT zlicza znaki w polu tekstowym, co jest błędnym podejściem do definicji tej funkcji. W rzeczywistości, COUNT jest funkcją agregującą, która operuje na rekordach, a nie na pojedynczych znakach w danym polu. Aby zliczyć znaki, można użyć funkcji LEN lub CHAR_LENGTH, które są dedykowane do obliczania długości tekstu. Druga niepoprawna odpowiedź odnosi się do obliczania średniej wartości w kolumnie, co również jest nieprawidłowe. Funkcja do obliczania średniej wartości to AVG, która działa na liczbowych danych w wybranej kolumnie, a nie COUNT, który jedynie zlicza rekordy. Trzecia niepoprawna odpowiedź sugeruje obliczenie wartości bezwzględnej, co jest również mylące. Funkcje służące do obliczania wartości bezwzględnej to ABS, a nie COUNT. W kontekście SQL, istotne jest zrozumienie, że każda funkcja ma swoje konkretne przeznaczenie i należy je stosować zgodnie z ich definicjami, aby uzyskać prawidłowe wyniki w analizie danych.

Pytanie 4

Na przedstawionej tabeli samochody wykonano zapytanie SQL SELECT

SELECT model FROM samochody WHERE rocznik = 2016;

id	marka	model	rocznik	kolor	stan
1	Fiat	Punto	2016	czerwony	bardzo dobry
2	Fiat	Punto	2002	czerwony	dobry
3	Fiat	Punto	2007	niebieski	bardzo dobry
4	Opel	Corsa	2016	grafitowy	bardzo dobry
5	Opel	Astra	2003	niebieski	porysowany lakier
6	Toyota	Corolla	2016	czerwony	bardzo dobry
7	Toyota	Corolla	2014	szary	dobry
8	Toyota	Yaris	2004	granatowy	dobry

A. Fiat, Opel, Toyota.

B. Czerwony, grafitowy.

C. Punto, Corsa, Astra, Corolla, Yaris.

D. Punto, Corsa, Corolla.

Niepoprawne odpowiedzi pokazują częste błędy w interpretacji zapytań SQL. Pierwszy z nich to pomylenie kolumny - zapytanie 'SELECT model FROM samochody WHERE rocznik = 2016' odnosi się do kolumny 'model', a nie 'kolor', co wyklucza odpowiedź 'Czerwony, grafitowy'. Drugi błąd to niewłaściwe zrozumienie klauzuli WHERE - jest ona używana do filtrowania rekordów na podstawie konkretnych warunków. W tym przypadku, zapytanie dotyczyło modeli samochodów z rocznika 2016, co wyklucza odpowiedź 'Punto, Corsa, Astra, Corolla, Yaris', ponieważ zawiera modele z innymi rocznikami. Trzeci błąd to pomylenie kolumn - zapytanie odnosiło się do 'model', a nie 'marka', co oznacza, że odpowiedź 'Fiat, Opel, Toyota' jest nieprawidłowa. Ważne jest, aby dokładnie zrozumieć strukturę tabeli i zapytania SQL przed próbą interpretacji wyników.

Pytanie 5

$z = mysqli_query($db, "SELECT ulica, miasto, kod_pocztowy FROM adresy");
$a = mysqli_fetch_row($z);
echo "$a[1], $a[2]";

W języku PHP zapisano fragment kodu działającego na bazie MySQL. Jego zadaniem jest wypisanie

A. ulicy i miasta ze wszystkich zwróconych rekordów

B. miasta i kodu pocztowego z pierwszego zwróconego rekordu

C. ulicy i miasta z pierwszego zwróconego rekordu

D. miasta i kodu pocztowego ze wszystkich zwróconych rekordów

Kod PHP wykonuje zapytanie do bazy danych przy użyciu funkcji mysqli_query co powoduje pobranie wszystkich rekordów z kolumn ulica miasto i kod_pocztowy z tabeli adresy jednak funkcja mysqli_fetch_row pobiera tylko pierwszy rekord z wynikowego zbioru danych. Jest to kluczowy aspekt ponieważ mysqli_fetch_row nie iteruje automatycznie przez wszystkie rekordy co jest częstym błędem w interpretacji działania tej funkcji. Często mylnie zakłada się że funkcja echo w połączeniu z pętlą może obsłużyć cały zestaw danych co w kontekście tego kodu nie ma miejsca ponieważ pętla nie została użyta. Zrozumienie działania funkcji takich jak mysqli_fetch_row jest kluczowe dla poprawnego przetwarzania danych z bazy. Indeksowanie w tablicach wynikowych zaczyna się od zera dlatego też $a[1] i $a[2] odnoszą się do drugiego i trzeciego elementu tablicy a nie pierwszego i drugiego co również jest częstym źródłem błędów wśród początkujących programistów. Ponadto brak zrozumienia że echo wypisuje wartości z jednego rekordu a nie wszystkich może prowadzić do błędnych założeń w projektowaniu logiki aplikacji. Aby uzyskać dane ze wszystkich rekordów konieczne byłoby zastosowanie pętli takiej jak while która iterowałaby przez cały zbiór wyników co pokazuje różnicę w podejściu między pobieraniem pojedynczego rekordu a całego zestawu danych. Zrozumienie tych koncepcji jest istotne dla efektywnego i bezpiecznego korzystania z bazy danych w aplikacjach PHP i pozwala na unikanie typowych błędów związanych z przetwarzaniem rekordów z bazy danych. Dokładne zrozumienie struktury tablic wynikowych i sposobu ich przetwarzania jest niezbędne do rozwijania wydajnych i bezpiecznych aplikacji webowych. Warto również pamiętać o zabezpieczeniach takich jak użycie przygotowanych zapytań SQL by uniknąć ataków typu SQL Injection co jest istotnym aspektem tworzenia aplikacji bezpiecznych i odpornych na próby nieautoryzowanego dostępu.

Pytanie 6

Wbudowanym w pakiet XAMPP narzędziem służącym do zarządzania bazą danych jest

A. phpMyAdmin

B. MySQL Workbench

C. SQLite

D. pgAdmin

W tym pytaniu łatwo się pomylić, bo wszystkie podane nazwy są w jakiś sposób związane z bazami danych, ale tylko jedna z nich jest faktycznie wbudowana w XAMPP jako standardowe narzędzie. XAMPP to pakiet, który ma ułatwić uruchomienie lokalnego środowiska serwerowego (Apache, PHP, MySQL/MariaDB itd.) jednym instalatorem. Jego celem jest „postawienie” gotowego stosu webowego na komputerze programisty. Z tego powodu twórcy XAMPP dołączyli phpMyAdmin, bo jest lekkie, webowe i napisane w PHP, więc idealnie pasuje do tego ekosystemu. MySQL Workbench bywa mylony z narzędziami w XAMPP, bo też służy do zarządzania MySQL, ale jest to osobna, natywna aplikacja instalowana oddzielnie, dostarczana przez Oracle. Nie jest częścią XAMPP, nie uruchamia się z panelu XAMPP i nie działa w przeglądarce. To bardziej rozbudowane środowisko do projektowania schematów, administrowania serwerami MySQL, analizowania wydajności. Dla wielu początkujących wygląda „profesjonalniej”, ale w typowej instalacji XAMPP go po prostu nie ma. pgAdmin z kolei jest narzędziem do zarządzania PostgreSQL, a XAMPP domyślnie korzysta z MySQL/MariaDB, nie z PostgreSQL. Stąd pgAdmin nie ma żadnego naturalnego powiązania z XAMPP, występuje raczej w pakietach, które celują w środowisko PostgreSQL (np. instalatory Postgresa). Wybranie tej odpowiedzi zwykle wynika z myślenia: „to jakieś narzędzie do bazy, więc pewnie będzie pasować”, ale tu trzeba zwracać uwagę na konkretny silnik bazy danych. SQLite natomiast nie jest nawet narzędziem administracyjnym, tylko samym silnikiem bazy danych, w dodatku wbudowanym, plikowym. Można z niego korzystać w PHP, ale nie ma tu mowy o tym, że byłby to graficzny panel w XAMPP. Typowy błąd polega na wrzuceniu do jednego worka „wszystko co ma coś wspólnego z bazami” i zakładaniu, że to będzie interfejs do zarządzania. W praktyce warto rozróżniać: silnik bazy (MySQL, MariaDB, PostgreSQL, SQLite) od narzędzia klienckiego/administracyjnego (phpMyAdmin, MySQL Workbench, pgAdmin). W XAMPP, jako narzędzie wbudowane, występuje właśnie phpMyAdmin i to jego nazwę trzeba kojarzyć bezpośrednio z tym pakietem.

Pytanie 7

Poniższe zapytanie SQL ma na celu:

UPDATE Uczen SET id_klasy = id_klasy + 1;

A. zwiększyć o jeden wartość pola Uczen

B. zwiększyć o jeden wartość kolumny id_klasy dla wszystkich wpisów w tabeli Uczen

C. przypisać wartość kolumny id_klasy jako 1 dla wszystkich wpisów w tabeli Uczen

D. ustawić wartość pola Uczen na 1

Wybierając błędne odpowiedzi, można wpaść w pułapki związane z interpretacją polecenia SQL. Na przykład, stwierdzenie, że polecenie zwiększa wartość pola Uczen, jest mylące, ponieważ nie odnosi się do konkretnej kolumny. W SQL każde polecenie musi być precyzyjne, a używanie ogólnych terminów prowadzi do nieporozumień. Mówiąc o "ustawieniu na 1 wartości pola Uczen", mylnie sugeruje się, że wszystkie dane są resetowane do jednej wartości, co jest całkowicie błędne w kontekście podanego polecenia. Kolejną nieprawidłową koncepcją jest pomysł, iż polecenie ustawia wartość kolumny na 1 dla wszystkich rekordów. W rzeczywistości, aktualizuje ono istniejące wartości, zwiększając je o jeden, a nie ustawia ich na stałą wartość. Takie nieprecyzyjne zrozumienie języka SQL może prowadzić do katastrofalnych skutków w praktycznych zastosowaniach baz danych, w tym do utraty danych lub niepoprawnych aktualizacji, co jest sprzeczne z dobrymi praktykami zarządzania danymi. Kluczowe jest zrozumienie, że każdy element w SQL odgrywa istotną rolę, a nieprecyzyjność prowadzi do błędów, które mogą być czasochłonne do naprawienia. Z tego powodu, w pracy z SQL, należy zwracać znaczną uwagę na szczegóły oraz logiczną strukturę zapytań.

Pytanie 8

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

SELECT metraz, cena FROM mieszkania WHERE ile_pokoi > 3;

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

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

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

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

W tym zapytaniu SQL chodzi o to, żeby ściągnąć konkretne dane z tabeli mieszkania. Używamy klauzuli SELECT, dlatego wybieramy tylko te kolumny, które nas interesują, czyli metraż i cena. I to wszystko bierzemy z tabeli mieszkania, co mamy w klauzuli FROM. Jeszcze dodajemy filtr WHERE, który mówi, że bierzemy tylko te mieszkania, które mają więcej niż trzy pokoje. To naprawdę dobra strategia, bo dzięki temu dokładnie widzimy, co nas interesuje. Takie zapytanie przydaje się w analizach rynku nieruchomości, bo można porównywać ceny mieszkań z większą ilością pokoi. Ogólnie mówiąc, SQL jest super narzędziem do pracy z danymi, bo pozwala nam szybko i efektywnie wyciągać to, co jest dla nas ważne. Wiedza na temat takich zapytań to podstawa, zwłaszcza w pracy z dużymi bazami danych i generowaniu różnych raportów.

Pytanie 9

Jaką klauzulę należy wykorzystać w instrukcji CREATE TABLE w SQL, by dane pole rekordu pozostawało wypełnione?

A. NOT NULL

B. NULL

C. DEFAULT

D. CHECK

Odpowiedź 'NOT NULL' jest poprawna, ponieważ klauzula ta jest używana w SQL do definiowania, że dane pole w tabeli nie może przyjmować wartości NULL, co oznacza, że musi zawierać jakąś wartość. Użycie klauzuli NOT NULL jest kluczowe w zapewnieniu integralności danych, szczególnie w sytuacjach, gdy brak wartości w danym polu może prowadzić do błędów w logice aplikacji lub nieprawidłowych wyników zapytań. Na przykład, w przypadku tworzenia tabeli dla użytkowników w systemie, pole 'email' powinno być oznaczone jako NOT NULL, aby zapobiec sytuacji, w której użytkownik mógłby zostać dodany bez podania adresu e-mail, co uniemożliwiłoby kontaktowanie się z nim. Dobrą praktyką jest również stosowanie klauzuli NOT NULL tam, gdzie dane są wymagane do poprawnego działania aplikacji. Użycie tej klauzuli jest zgodne z zasadami normalizacji baz danych, które z kolei mają na celu redukcję redundancji i poprawę integralności danych.

Pytanie 10

Integralność referencyjna w relacyjnych bazach danych wskazuje, że

A. klucz główny lub klucz obcy nie zawierają żadnych wartości NULL

B. wartość klucza głównego oraz klucza obcego nie może być pusta

C. wartość klucza obcego w konkretnej tabeli musi być równa wartości klucza głównego w powiązanej tabeli lub mieć wartość NULL

D. każdemu kluczowi głównemu przyporządkowany jest dokładnie jeden klucz obcy w danej tabeli lub powiązanych tabelach

Integralność referencyjna to kluczowy koncept w modelu relacyjnych baz danych, który zapewnia spójność oraz integralność danych pomiędzy różnymi tabelami. Oznacza to, że każda wartość klucza obcego w danej tabeli musi być zgodna z wartością klucza głównego w powiązanej tabeli, lub może być wartością NULL, co oznacza brak powiązania. Dzięki temu zyskujemy pewność, że wszelkie relacje między danymi są logiczne i zgodne z założeniami projektowymi bazy danych. Przykładem może być tabela 'Zamówienia', w której klucz obcy 'ID_Klienta' odnosi się do klucza głównego 'ID_Klienta' w tabeli 'Klienci'. Jeśli wartość 'ID_Klienta' w tabeli 'Zamówienia' nie pasuje do żadnej wartości 'ID_Klienta' w tabeli 'Klienci', narusza to integralność referencyjną. Standardy takie jak SQL (Structured Query Language) oraz zasady ACID (Atomicity, Consistency, Isolation, Durability) podkreślają znaczenie integralności danych, co jest kluczowe dla poprawnego funkcjonowania systemów bazodanowych i zapewnienia ich niezawodności oraz efektywności. Utrzymanie integralności referencyjnej jest istotne dla analizy danych, raportowania oraz utrzymywania relacji między różnymi obiektami w bazie.

Pytanie 11

Co zazwyczaj wchodzi w skład Framework'a?

A. wbudowany serwer i obsługa formularzy

B. obsługa błędów i domena

C. zarządzanie komunikacją z bazą danych, mechanizm uruchamiania i przetwarzania akcji

D. certyfikat http oraz mechanizm przetwarzania i uruchamiania akcji

Pierwsza odpowiedź wskazuje na elementy, które są często obecne w aplikacjach webowych, jednak nie są kluczowymi składnikami frameworków. Domeny i obsługa błędów to ważne aspekty ogólnie dotyczące programowania, ale same w sobie nie definiują funkcjonalności frameworka. Obsługa formularzy oraz wbudowany serwer to funkcje, które mogą być dostarczane przez frameworki, jednak nie stanowią one ich podstawowych komponentów. Obsługa formularzy dotyczy głównie interakcji użytkownika z aplikacją, a wbudowany serwer to jedynie narzędzie do lokalnego testowania, które nie jest kluczowe dla samego frameworka. Natomiast certyfikat http jest istotny dla zapewnienia bezpieczeństwa podczas przesyłania danych, lecz nie jest on związany z architekturą czy funkcjonalnością frameworków. Dlatego też, choć wszystkie z wymienionych elementów są ważne w kontekście tworzenia aplikacji webowych, to nie stanowią one rdzenia frameworków, które koncentrują się na ułatwieniu komunikacji z bazą danych oraz zarządzaniu cyklem życia żądań.

Pytanie 12

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

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

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

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

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

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

Pytanie 13

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

A. ustalanie limitów przestrzeni na dysku

B. przypisanie uprawnień

C. wykorzystanie makr

D. określanie zakresu tabel

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

Pytanie 14

Dodanie ograniczenia klucza obcego w taki sposób, aby kolumna Klasy_id z tabeli Uczniowie była powiązana z kolumną id w tabeli Klasy zostanie wykonane przy użyciu polecenia

A. ALTER TABLE Uczniowie ADD FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

B. ALTER TABLE Uczniowie ADD CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

C. ALTER TABLE Uczniowie DROP FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

D. ALTER TABLE Uczniowie DROP CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

W poleceniach dotyczących kluczy obcych bardzo łatwo pomylić operacje `ADD` i `DROP` oraz prawidłową składnię dla poszczególnych dialektów SQL. W przedstawionych błędnych odpowiedziach pojawia się kilka typowych nieporozumień. Część z nich próbuje używać słowa kluczowego `DROP`, które służy do usuwania istniejącego ograniczenia, a nie do jego tworzenia. Jeżeli naszym celem jest dopiero dodanie relacji między tabelą `Uczniowie` a tabelą `Klasy`, to użycie `DROP CONSTRAINT` albo `DROP FOREIGN KEY` jest po prostu logicznie sprzeczne z zadaniem – takie polecenia mogłyby mieć sens tylko wtedy, gdy klucz obcy `FKKlasy` już istnieje i chcemy go zlikwidować. W praktyce takie pomyłki wynikają z mylenia dwóch kroków: projektowania schematu (gdzie klucze dopiero dodajemy) z refaktoryzacją istniejącej bazy (gdzie często coś usuwamy i tworzymy na nowo). Kolejna sprawa to składnia `ADD FOREIGN KEY FKKlasy FOREIGN KEY(...)`. W standardowych systemach zarządzania bazą danych najpierw podaje się `ADD CONSTRAINT nazwa`, a dopiero później słowo `FOREIGN KEY` wraz z listą kolumn. Wpychanie nazwy ograniczenia między `ADD FOREIGN KEY` a definicję kolumn nie jest zgodne z zasadami składni SQL i po prostu nie zadziała. Moim zdaniem to efekt mieszania różnych przykładów z internetu, gdzie w jednych pokazuje się nazwane ograniczenia (`ADD CONSTRAINT ...`), a w innych anonimowe (`ADD FOREIGN KEY (...) REFERENCES ...`), bez nazwy. Dodatkowo, używanie w jednym poleceniu jednocześnie `DROP` i całej definicji `FOREIGN KEY(Klasy_id) REFERENCES Klasy(id)` jest nielogiczne: przy usuwaniu ograniczenia podajemy wyłącznie jego nazwę, bo silnik bazy już zna szczegóły definicji i nie trzeba ich powtarzać. W poprawnym podejściu zawsze zadajemy sobie pytanie: czy ja chcę coś dodać, czy usunąć, i czy składnia, której używam, odpowiada dokumentacji konkretnego systemu (np. SQL Server, MySQL, PostgreSQL). Stosowanie czytelnej, udokumentowanej formy `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES ...` jest zgodne z dobrymi praktykami i oszczędza sporo nerwów przy późniejszej administracji oraz migracjach schematu.

Pytanie 15

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

A. raport

B. formularz

C. makropolecenie

D. kwerenda

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

Pytanie 16

Jakim systemem do zarządzania wersjami oprogramowania jest

A. TotalCommander

B. FileZilla

C. Eclipse

D. GIT

TotalCommander, Eclipse i FileZilla to popularne narzędzia, które służą do innych celów w procesie tworzenia oprogramowania, ale nie są systemami kontroli wersji. TotalCommander jest menedżerem plików, który ułatwia nawigację i zarządzanie plikami na komputerze, jednak nie oferuje funkcji śledzenia zmian w kodzie czy współpracy zespołowej. Eclipse to zintegrowane środowisko programistyczne (IDE), które wspiera rozwój aplikacji, ale nie pełni roli systemu kontroli wersji, chociaż może korzystać z różnych systemów kontroli wersji za pomocą odpowiednich wtyczek. FileZilla to klient FTP, który umożliwia przesyłanie plików na serwery, co również nie ma związku z kontrolą wersji. Często mylnie przyjmuje się, że narzędzia związane z zarządzaniem plikami czy programowaniem mogą zastępować systemy kontroli wersji, co jest błędnym podejściem. Systemy kontroli wersji, takie jak GIT, są zaprojektowane z myślą o zarządzaniu zmianami w kodzie źródłowym, co jest kluczowe w nowoczesnym procesie wytwarzania oprogramowania. Ignorowanie tej specyfikacji i nieodróżnianie narzędzi do zarządzania plikami od systemów kontroli wersji może prowadzić do problemów w organizacji pracy zespołu oraz utraty wydajności w projektach.

Pytanie 17

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

SELECT * FROM mieszkancy WHERE imie = 'Anna';

A. pokazanie pola o nazwie '*' (gwiazdka)

B. wyświetlenie wszystkich kolumn z tabeli mieszkancy

C. zignorowanie warunku dotyczącego imienia

D. wyświetlenie wszystkich rekordów z tabeli mieszkancy

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

Pytanie 18

W algebrze relacji działanie selekcji polega na

A. usunięciu krotek z powtórzonymi polami

B. wybór krotek, które spełniają określone warunki

C. wybór krotek, które nie zawierają wartości NULL

D. usunięciu pustych wierszy

Wybieranie krotek niezawierających wartości NULL nie jest operacją selekcji w kontekście algebry relacji, ponieważ selekcja ma na celu filtrację krotek na podstawie określonych warunków, a nie jedynie na podstawie obecności lub braku wartości NULL. W praktyce, aby wykluczyć wartości NULL, można zastosować dodatkowe warunki w operacji selekcji, ale to nie definiuje samej operacji selekcji. Z kolei eliminacja pustych wierszy jest związana z usuwaniem krotek, które nie zawierają żadnych danych, co także nie jest równoznaczne z operacją selekcji. Ta operacja odnosi się bardziej do czyszczenia danych niż do ich wybierania na podstawie określonych kryteriów. Ponadto, eliminacja krotek z powtarzającymi się polami nie jest tożsama z selekcją, ponieważ dotyczy bardziej operacji usuwania duplikatów, które są zazwyczaj realizowane przez operacje takie jak DISTINCT w SQL, a nie przez selekcję, która ma na celu wybór krotek na podstawie warunków logicznych. W algebrze relacji kluczowe jest rozróżnienie między operacjami filtrowania danych a operacjami modyfikacji danych, co jest istotne w kontekście projektowania baz danych oraz w zapewnieniu integralności danych.

Pytanie 19

W tabeli personel znajdują się pola: imie, nazwisko, pensja, staz. Aby otrzymać średnią pensję pracowników, dla których staż wynosi od 10 do 20 lat pracy włącznie, należy wykonać kwerendę:

A. SELECT COUNT(*) FROM personel WHERE staz >= 10 AND staz <= 20

B. SELECT AVG(*) FROM personel WHERE staz >= 10 AND staz <= 20

C. SELECT AVG(pensja) FROM personel WHERE staz >= 10 AND staz <= 20

D. SELECT COUNT(pensja) FROM personel WHERE staz >= 10 AND staz <= 20

Wybór kwerend, które nie wykorzystują funkcji AVG() do uzyskania średniej pensji, może prowadzić do poważnych nieporozumień w analizie danych. Użycie 'SELECT COUNT(pensja) FROM personel WHERE staz >= 10 AND staz <= 20;' jest błędne, ponieważ funkcja COUNT() zlicza liczbę rekordów, a nie oblicza średniej. Przy użyciu COUNT() otrzymamy jedynie liczbę pracowników z wymaganym stażem, co jest informacją, ale nie odpowiada na pytanie o ich średnią pensję. Również kwerenda 'SELECT COUNT(*) FROM personel WHERE staz >= 10 AND staz <= 20;' działa podobnie, bo zlicza wszystkie pasujące rekordy, co nie ma związku z obliczaniem wartości średniej. Ostatecznie, kwerenda 'SELECT AVG(*) FROM personel WHERE staz >= 10 AND staz <= 20;' jest syntaktycznie błędna, ponieważ AVG() wymaga konkretnej kolumny jako argumentu, a nie symbolu wieloznacznego '*'. Tego rodzaju błędne podejścia mogą wynikać z mylnego rozumienia funkcji i ich zastosowania w SQL. Praktyka pokazuje, że kluczowe jest zrozumienie różnicy między funkcjami agregującymi, takimi jak AVG(), a funkcjami zliczającymi, jak COUNT(). Niezrozumienie tych różnic prowadzi do niepoprawnych wyników analizy danych oraz utrudnia podejmowanie decyzji opartych na faktach. Właściwe wykorzystanie SQL jest istotne w każdym środowisku, gdzie analiza danych odgrywa kluczową rolę.

Pytanie 20

W jaki sposób funkcjonuje instrukcja do łączenia wyników zapytań INTERSECT w SQL?

A. Zwraca te wiersze, które wystąpiły w wyniku drugiego zapytania, natomiast nie było ich w wyniku pierwszego zapytania

B. Zwraca część wspólną wyników dwóch zapytań

C. Zwraca zbiór wyników z pierwszego zapytania oraz zbiór wyników z drugiego zapytania, automatycznie eliminując powtarzające się wiersze

D. Zwraca te wiersze, które wystąpiły w wyniku pierwszego zapytania, jednak nie były obecne w wyniku drugiego zapytania

Wszystkie niepoprawne odpowiedzi nie oddają istoty działania instrukcji INTERSECT. Opis dotyczący zwracania listy wyników z obu zapytań oraz usuwania powtarzających się wierszy jest mylący, ponieważ INTERSECT nie łączy wyników, lecz filtruje je, ograniczając się tylko do wspólnych wierszy. Ponadto wskazanie, że instrukcja ta zwraca wiersze z pierwszego zapytania, które nie znajdują się w drugim, jest błędne, ponieważ dotyczy to operatora EXCEPT, który działa na zasadzie różnicy zbiorów. Również stwierdzenie, że INTERSECT zwraca wiersze z drugiego zapytania, które nie występują w pierwszym, również jest mylące i nie ma podstaw w rzeczywistości działania tej instrukcji. W rzeczywistości, INTERSECT nie operuje na zasadzie różnic, lecz na zasadzie przecięcia zbiorów, co oznacza, że korzysta z logiki logicznego AND, a nie OR. Podsumowując, kluczowym elementem użycia INTERSECT jest zrozumienie, że jego zadaniem jest wyodrębnienie wspólnych elementów, co czyni go narzędziem do porównywania i analizy danych, a nie do łączenia ich czy analizy różnic.

Pytanie 21

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

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

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

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

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

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

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

Pytanie 22

Jakie mechanizmy powinno się wykorzystać do stworzenia ankiety w języku działającym po stronie serwera, tak aby wyniki były zapisane w postaci małego pliku u użytkownika?

A. ciasteczek

B. sesji

C. tablicy globalnej $_FILES

D. bazy danych SQL

Ciasteczka, znane również jako pliki cookie, to małe pliki danych, które są przechowywane na urządzeniu użytkownika przez przeglądarkę internetową. Umożliwiają one przechowywanie informacji między sesjami, co jest kluczowe w przypadku ankiet, gdzie wyniki mogą być zebrane i później analizowane. Zastosowanie ciasteczek w tym kontekście pozwala na przechowywanie wyników ankiety lokalnie, co z kolei zwiększa wydajność i szybkość dostępu do danych. Przykładowo, po wypełnieniu ankiety, wartości odpowiedzi mogą być zapisane w ciasteczku, co umożliwia ich późniejsze odczytanie bez konieczności komunikacji z serwerem. Warto również wspomnieć, że ciasteczka są zgodne z zasadami ochrony prywatności użytkowników, ponieważ można je łatwo zarządzać i usuwać. Dobrą praktyką jest również informowanie użytkowników o używaniu ciasteczek i uzyskiwanie ich zgody na ich przechowywanie, co jest zgodne z regulacjami takimi jak RODO.

Pytanie 23

Zachowanie integralności encji w bazie danych będzie miało miejsce, jeżeli między innymi

A. klucz główny zawsze będzie liczbą całkowitą

B. dla każdej tabeli zostanie ustanowiony klucz główny

C. każdej kolumnie przypisany zostanie typ danych

D. każdy klucz główny będzie miał odpowiadający mu klucz obcy w innej tabeli

Wszystkie zaproponowane odpowiedzi mogą wydawać się związane z tematyką integralności encji, jednak nie każda z nich rzeczywiście przyczynia się do jej zachowania w kontekście baz danych. Użycie klucza głównego jako liczby całkowitej nie jest kryterium zapewniającym integralność; klucz główny może być również tekstowy lub złożony, o ile spełnia warunki unikalności i braku wartości NULL. Przypisanie typu danych dla każdej kolumny jest ważne dla sprawności operacji na danych, ale samo w sobie nie zapewnia integralności encji, ponieważ nie kontroluje unikalności rekordów. Kolejnym błędnym podejściem jest twierdzenie, że każdy klucz główny musi mieć odpowiadający klucz obcy w innej tabeli. Klucz obcy jest używany do ustanowienia relacji między tabelami, ale nie jest wymagany do zapewnienia integralności encji w pojedynczej tabeli. Klucz główny w jednej tabeli działa niezależnie od kluczy obcych w innych tabelach; jego główną rolą jest zapewnienie, że każdy rekord w tabeli jest unikalny. W praktyce, brak zrozumienia tych koncepcji może prowadzić do projektowania baz danych, które są nieefektywne i trudne do zarządzania, co w dłuższej perspektywie wpływa na jakość danych i ich dostępność.

Pytanie 24

Na podstawie tabeli Towar wykonano następujące zapytanie SQL. Jaki będzie wynik tej operacji?

 SELECT nazwa_towaru FROM `Towar` WHERE cena_katalogowa < 65 ORDER BY waga DESC;

ID	nazwa_towaru	cena_katalogowa	waga	kolor
1	Papier ksero A4	11	2.3	biel
2	Zeszyt A5	4.2	0.13	wielokolorowy
3	Zeszyt A5 w linie	3.5	0.12	niebieski
4	Kredki 24 kolory	9	0.3	wielokolorowy
5	Plecak szkolny	65.5	1.3	zielony

A. Zeszyt A5 w linie, Zeszyt A5, Kredki 24 kolory, Papier ksero A4

B. Papier ksero A4, Kredki 24 kolory, Zeszyt A5 w linie, Zeszyt A5

C. Zeszyt A5, Zeszyt A5 w linie, Kredki 24 kolory, Papier ksero A4

D. Papier ksero A4, Kredki 24 kolory, Zeszyt A5, Zeszyt A5 w linie

Twoja odpowiedź jest poprawna. Wykonane zapytanie SQL zwracałoby nazwy towarów, które spełniają warunek ceny katalogowej mniejszej niż 65. Listę tych towarów następnie sortuje od najcięższego do najlżejszego. W przypadku podanej tabeli towary, które spełniają te warunki to: Papier ksero A4 (waga 2.3), Kredki 24 kolory (waga 0.3), Zeszyt A5 (waga 0.13) i Zeszyt A5 w linie (waga 0.12). To jest kluczowy aspekt zrozumienia zapytań SQL, które obejmują selekcję i sortowanie danych. W praktyce, umiejętność filtrowania i organizowania danych jest niezbędna do analizy danych i tworzenia raportów w systemach baz danych. Zrozumienie jak zapytania SQL działa na poziomie podstawowym, umożliwi Ci przewidywanie wyników zapytań, co jest kluczowe dla dobrze zaprojektowanych systemów baz danych.

Pytanie 25

Jaką relację w projekcie bazy danych powinno się ustalić pomiędzy tabelami przedstawionymi na rysunku, przy założeniu, że każdy klient sklepu internetowego złoży co najmniej dwa zamówienia?

A. n:n

B. 1:1

C. 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia

D. 1:n, gdzie 1 znajduje się po stronie Zamówienia, a wiele po stronie Klienta

Analizując różne możliwe relacje między tabelami, warto zrozumieć, dlaczego niektóre podejścia są błędne. Relacja 1:1 zakłada, że jedna jednostka w pierwszej tabeli odpowiada dokładnie jednej jednostce w drugiej tabeli. W kontekście sklepu internetowego sugerowałoby to, że jeden klient może mieć tylko jedno zamówienie, co nie odpowiada rzeczywistości, gdzie klienci zazwyczaj dokonują wielu transakcji. Relacja 1:n, gdzie 1 jest po stronie Zamówienia, a wiele po stronie Klienta, również jest niepoprawna, ponieważ sugeruje, że jedno zamówienie może być przypisane do wielu klientów, co jest sprzeczne z indywidualnym charakterem zakupów. Relacja n:n, choć teoretycznie pozwalałaby na przypisanie wielu klientów do wielu zamówień, w rzeczywistości wymagałaby dodatkowej tabeli pośredniej do przechowywania tych powiązań, co wprowadzałoby niepotrzebną złożoność i mogłoby prowadzić do błędów w przetwarzaniu danych. Typowym problemem przy projektowaniu baz danych jest błędne zrozumienie relacji między danymi, co może prowadzić do nieefektywnych struktur, utrudniających zarówno utrzymanie jak i rozwój systemu. Dlatego tak ważne jest dokładne zrozumienie specyfiki relacji między danymi i stosowanie odpowiednich modeli, które zapewnią zarówno integralność jak i wydajność systemu informatycznego na dłuższą metę.

Pytanie 26

Jakie dane zostaną wyświetlone po wykonaniu podanych poleceń?

bool gotowe = true;
cout << gotowe;

A. nie

B. 0

C. tak

D. 1

Analizując zadanie, należy zrozumieć, jak język C++ interpretuje zmienne typu bool podczas ich wypisywania. W podanym kodzie zmienna boolowska gotowe ma przypisaną wartość true. Gdy taka zmienna jest wypisywana przy użyciu cout, jej wartość jest domyślnie przekształcana na liczby całkowite 1 dla true i 0 dla false. To zachowanie wynika z domyślnej konfiguracji strumienia cout, który obsługuje wartości logiczne w sposób liczbowy. Niektórzy mogą się spodziewać, że cout wypisze słowo true lub true w formie tekstowej, jednak to wymaga użycia flagi boolalpha, która nie jest tu zastosowana. Dlatego też odpowiedzi takie jak tak lub nie są niepoprawne, ponieważ oznaczają oczekiwanie wyjścia tekstowego, które nie pasuje do domyślnego formatu C++. Innym błędem mogłoby być oczekiwanie, że wynik będzie zerem, jednak to byłoby możliwe tylko w przypadku, gdyby zmiennej przypisano wartość false. Takie nieporozumienia często wynikają z braku zrozumienia, jak strumienie w C++ konwertują wartości logiczne na tekst. Zrozumienie i prawidłowe zastosowanie tych reguł jest kluczowe dla programistów pracujących w tym języku, szczególnie gdy zależy im na efektywności i zgodności z konwencjami programistycznymi. Aby uniknąć takich nieporozumień, warto dokładnie studiować dokumentację dotyczącą zachowania strumieni w C++ i eksperymentować z różnymi ustawieniami, aby w pełni zrozumieć ich działanie w praktyce.

Pytanie 27

Jakie polecenie należy zastosować, aby wysłać dane przy pomocy funkcji mysqli_query() w skrypcie PHP, który dodaje informacje z formularza umieszczonego na stronie internetowej do bazy danych?

A. SELECT

B. ALTER

C. INSERT INTO

D. UPDATE

Odpowiedź 'INSERT INTO' jest poprawna, ponieważ jest to standardowa kwerenda SQL używana do wstawiania nowych rekordów do tabel w bazie danych. W kontekście PHP i funkcji mysqli_query(), wstawianie danych z formularza zazwyczaj obejmuje przygotowanie kwerendy, która zawiera instrukcję INSERT INTO wraz z nazwą tabeli oraz danymi, które mają zostać dodane. Na przykład, jeśli mamy formularz z polami 'imie' i 'nazwisko', kwerenda mogłaby wyglądać następująco: 'INSERT INTO uzytkownicy (imie, nazwisko) VALUES (?, ?)'. Użycie znaków zapytania (?) jest zgodne z najlepszymi praktykami, ponieważ pozwala na bezpieczne wprowadzenie danych, chroniąc aplikację przed atakami SQL Injection. Dobrą praktyką jest również używanie PDO lub MySQLi z przygotowanymi zapytaniami, co zwiększa bezpieczeństwo oraz efektywność kodu. W ten sposób można skutecznie wstawiać dane do bazy danych, zachowując przy tym standardy programistyczne.

Pytanie 28

Funkcja mysqli_num_rows() w PHP może być używana po wcześniejszym wykonaniu zapytania

A. UPDATE

B. DELETE

C. INSERT

D. SELECT

Funkcja mysqli_num_rows() służy do zwracania liczby wierszy w rezultacie zapytania SQL, jednak może być wywołana wyłącznie po zastosowaniu kwerendy SELECT. Kwerenda ta jest używana do pobierania danych z bazy danych, co oznacza, że jej wykonanie generuje zbiór wyników. Kiedy wykonujemy zapytanie SELECT, mysqli_num_rows() umożliwia nam sprawdzenie, ile rekordów zwróciło zapytanie. Na przykład, po wykonaniu zapytania SELECT * FROM users, możemy użyć mysqli_num_rows($result), aby uzyskać liczbę użytkowników w tabeli. To podejście jest zgodne z dobrymi praktykami programistycznymi, ponieważ pozwala na efektywne zarządzanie i analizowanie danych. Warto także zauważyć, że funkcja ta nie jest stosowana w przypadku kwerend modyfikujących dane, takich jak INSERT, DELETE czy UPDATE, ponieważ te operacje nie zwracają zbioru wyników, a jedynie potwierdzają wykonanie akcji. Zrozumienie, kiedy używać mysqli_num_rows(), jest kluczowe w pracy z bazami danych w PHP i pozwala na skuteczne optymalizowanie zapytań oraz zarządzanie danymi.

Pytanie 29

W środowisku PHP pobrano z bazy danych rezultat działania zapytania przy użyciu komendy mysql_query. W celu uzyskania z otrzymanej kwerendy jednego wiersza danych, konieczne jest użycie polecenia

A. mysql_fetch_lengths

B. mysql_fetch_row

C. mysql_field_len

D. mysql_list_fields

Odpowiedzi, takie jak 'mysql_list_fields', 'mysql_fetch_lengths' i 'mysql_field_len', nie są odpowiednie w kontekście pobierania wiersza danych. 'mysql_list_fields' służy do pobierania informacji o polach w tabeli i nie zwraca wyników kwerendy, tylko metadane tabeli, co oznacza, że nie nadaje się do uzyskania dostępu do danych. 'mysql_fetch_lengths' dostarcza długości wszystkich pól w ostatnio pobranym wierszu, ale nie pozwala na bezpośrednie pobranie danych. Z kolei 'mysql_field_len' zwraca długość określonego pola w tabeli, a nie wiersza wyników kwerendy. Te funkcje mogą być użyteczne w określonych kontekstach, jednak nie realizują głównego celu, którym jest dostarczenie danych. Typowym błędem, który popełniają programiści, jest mylenie tych funkcji z właściwym sposobem na pobieranie danych. Kluczowe jest zrozumienie, że do pracy z danymi zawsze należy używać funkcji, które bezpośrednio zwracają wyniki zapytania. W tej sytuacji wybór odpowiedniej funkcji jest nie tylko kwestią techniczną, ale również najlepszych praktyk w programowaniu, które obejmują optymalizację kodu oraz unikanie nieefektywnych metod dostępu do danych.

Pytanie 30

Tabela samochody zawiera dane przedstawione poniżej:

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

Wydając zamieszczone zapytanie SQL, jakie dane zostaną zwrócone:

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

A. zafira

B. zafira; insignia

C. opel zafira; opel insignia

D. opel zafira

Wszystkie niepoprawne odpowiedzi zawierają błędy związane z interpretacją wyników zapytania SQL. Odpowiedź 'opel zafira' jest niepoprawna, ponieważ zapytanie nie zwraca modelu w formie złożonej, a jedynie oczekuje nazwy modelu. Podobnie, odpowiedzi 'zafira; insignia' oraz 'opel zafira; opel insignia' sugerują, że obie te nazwy są zwracane przez zapytanie, co jest błędne. W rzeczywistości, zapytanie filtruje dane tak, że tylko jeden model – 'zafira' – jest odpowiedzią na podane warunki. Przykłady takich błędnych założeń często wynikają z niepełnego zrozumienia działania operatorów w zapytaniach SQL oraz ich wpływu na wyniki. Analizując odpowiedzi, należy zwracać uwagę na precyzyjność zapytań oraz na zastosowanie odpowiednich warunków filtrujących, aby uniknąć błędnych wniosków. W praktyce, dobre zrozumienie działania SQL i umiejętność właściwego formułowania zapytań to kluczowe umiejętności w każdej pracy związanej z danymi, co podkreśla znaczenie dokładności i staranności w tym obszarze. Każdy analityk danych powinien dążyć do mistrzostwa w tej dziedzinie, aby skutecznie wspierać podejmowanie decyzji na podstawie danych.

Pytanie 31

Aby za pomocą instrukcji SELECT uzyskać listę nazwisk osób mieszkających na osiedlu, przy czym nazwiska te nie mogą się powtarzać, należy sformułować zapytanie w następujący sposób

A. SELECT DISTINCT nazwisko FROM mieszkancy

B. SELECT AVG(nazwisko) FROM mieszkancy

C. SELECT TOP 10 nazwisko FROM mieszkancy

D. SELECT nazwisko FROM mieszkancy ORDER BY nazwisko

Odpowiedzi, które nie wykorzystują klauzuli DISTINCT, nie są w stanie spełnić wymogu eliminacji duplikatów w wynikach zapytania. Na przykład, użycie "SELECT nazwisko FROM mieszkancy ORDER BY nazwisko;" tylko sortuje wyniki według nazwisk, ale nie eliminuje powtarzających się rekordów. To jest typowy błąd w myśleniu, gdzie użytkownicy mogą myśleć, że sortowanie wystarczy, aby uzyskać unikalne wyniki. Jeżeli w tabeli znajduje się wiele osób o tym samym nazwisku, zapytanie to nadal zwróci wszystkie wystąpienia, co prowadzi do niepożądanych rezultatów. Z kolei "SELECT TOP 10 nazwisko FROM mieszkancy;" ogranicza wyniki do tylko 10 pierwszych rekordów, ale nie zapewnia ich unikalności. W zależności od kolejności, w jakiej dane są prezentowane, wynik może zawierać duplikaty, co nie spełnia wymagań zadania. Dodatkowo, "SELECT AVG(nazwisko) FROM mieszkancy;" ma na celu obliczenie średniej, co jest nonsensowne w kontekście kolumny tekstowej jak 'nazwisko', ponieważ średnia nie jest miarodajną miarą dla danych tekstowych. Takie podejście demonstruje niewłaściwe zrozumienie typów danych i ich zastosowań w SQL. W każdej sytuacji, umiejętność poprawnego formułowania zapytań SQL jest kluczowa dla efektywnej pracy z bazami danych i unikania błędów analitycznych.

Pytanie 32

W bazie danych MySQL utworzono tabelę. Aby jednoznacznie zdefiniować, że pole ID jest kluczem głównym, należy dopisać

 CREATE TABLE Osoby ( ID int NOT NULL, nazwisko varchar(255) NOT NULL, wiek int);

A. FOREIGN KEY w linii, w której jest zdefiniowane pole ID.

B. PRIMARY KEY (ID) przed zamknięciem nawiasu.

C. PK (ID) przed zamknięciem nawiasu.

D. PK w linii, w której jest zdefiniowane pole ID.

Niektóre odpowiedzi na to pytanie mogły zawierać błędne koncepcje, które warto omówić. W języku SQL, skrót 'PK' nie jest rozpoznawany jako oznaczenie klucza głównego. Poprawnym oznaczeniem jest klauzula 'PRIMARY KEY'. Innym błędnym podejściem jest próba oznaczenia pola ID jako klucz obcy za pomocą klauzuli 'FOREIGN KEY'. Klucze obce są używane do tworzenia powiązań między tabelami w relacyjnych bazach danych, a nie do definiowania unikalności rekordu. Dlatego takie podejście jest niezgodne ze standardami SQL i dobrymi praktykami w projektowaniu baz danych. Zrozumienie różnicy między kluczami głównymi a obcymi jest kluczowe dla efektywnego tworzenia i zarządzania relacyjnymi bazami danych. Za pomocą klucza głównego określamy unikalność rekordu, natomiast klucz obcy pozwala na tworzenie relacji między różnymi tabelami.

Pytanie 33

W tabeli mieszkancy znajdują się różne dane. Aby przefiltrować jedynie mieszkańców, którzy mają przypisaną dzielnicę = 1, stworzono dla uproszczenia działania wirtualną tabelę (widok) poprzez zastosowanie kwerendy

A. CREATE VIEW mieszkancy FROM mieszkancy WHERE dzielnica = 1

B. CREATE VIEW mieszkancy WHERE dzielnica = 1

C. CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy WHERE dzielnica = 1

D. CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy

Odpowiedzi, które nie pasują do definicji widoków w SQL, mają kilka kluczowych błędów. W pierwszej z nich, 'CREATE VIEW mieszkancy WHERE dzielnica = 1;', brakuje ważnych elementów do zdefiniowania widoku. Przede wszystkim, nie ma słowa 'AS', które powinno być tam, żeby określić kwerendę, z której widok się tworzy. SQL wymaga, żeby definicja widoku miała zapytanie, czego tutaj brakuje. W drugiej odpowiedzi, 'CREATE VIEW mieszkancy FROM mieszkancy WHERE dzielnica = 1;', również jest niepoprawna, bo nie ma 'AS' i jest zła składnia, bo 'FROM' nie może być używane w tworzeniu widoku bez odpowiedniej struktury. Ostatnia odpowiedź, 'CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy;', choć składnia jest okej, nie filtruje danych do mieszkańców z dzielnicy nr 1. To błędne myślenie, bo często zapominamy o używaniu filtrów, co prowadzi do tego, że mamy za dużo danych do analizy. Tworząc widoki, warto zawsze mieć na uwadze, po co je robimy i zadbać o to, żeby zawierały tylko te dane, które są nam naprawdę potrzebne.

Pytanie 34

Jaką rolę odgrywa kwerenda krzyżowa w systemie baz danych MS Access?

A. Eliminuje rekordy z tabel zgodnie z określonymi kryteriami

B. Prezentuje zliczone wartości z określonego pola, organizując je w wiersze oraz kolumny

C. Dodaje do wskazanej tabeli dane z innej tabeli

D. Zmienia już istniejące dane w tabeli

Kwerenda krzyżowa w MS Access jest niezwykle przydatnym narzędziem, które umożliwia prezentację zliczonych wartości w formie tabeli przestawnej. Dzięki tej funkcji użytkownicy mogą analizować dane w sposób bardziej zrozumiały i przejrzysty, przyporządkowując wartości do odpowiednich wierszy i kolumn. Na przykład, w przypadku bazy danych sprzedaży, kwerenda krzyżowa może przedstawiać zliczenie sprzedaży według miesięcy w układzie tabelarycznym, gdzie wiersze reprezentują poszczególne miesiące, a kolumny różne kategorie produktów. To znacznie ułatwia porównania i analizę trendów. Kwerendy krzyżowe są zgodne z najlepszymi praktykami analizy danych, ponieważ pozwalają na efektywne podsumowywanie informacji i umożliwiają łatwe generowanie raportów, co jest kluczowe w procesach decyzyjnych w organizacjach. W kontekście analizy danych, warto również zwrócić uwagę na możliwość stosowania dodatkowych funkcji agregujących, takich jak SUMA, ŚREDNIA czy MAX, co zwiększa elastyczność i dokładność wyników.

Pytanie 35

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

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

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

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

C. najmłodszy i najstarszy wiek uczestników

D. ilość najstarszych uczestników

Prawidłowa odpowiedź to różnica wieku pomiędzy najstarszym i najmłodszym uczestnikiem, ponieważ zapytanie SQL wykorzystuje funkcje agregujące MAX oraz MIN na kolumnie wieku. Funkcja MAX(wiek) zwraca najwyższą wartość wieku w zbiorze danych, co odpowiada wiekowi najstarszego uczestnika, podczas gdy MIN(wiek) zwraca najniższą wartość, czyli wiek najmłodszego uczestnika. Różnica tych dwóch wartości daje nam dokładny wynik, przedstawiający zakres wieku w grupie uczestników. Tego typu analizy są niezwykle przydatne w kontekście organizacji zawodów, gdzie zrozumienie różnorodności wiekowej może wpłynąć na planowanie sekcji rywalizacyjnych czy strategii marketingowych. Rekomenduje się, aby w praktyce wykorzystać podobne zapytania do analizy demografii uczestników, co może pomóc w lepszym dostosowaniu wydarzeń do potrzeb grupy docelowej oraz w analizie trendów w uczestnictwie w różnych kategoriach wiekowych.

Pytanie 36

W systemie PHP złożono zapytanie SELECT do bazy przy pomocy funkcji mysqli_query. Jaką funkcję powinien wykorzystać użytkownik, aby ustalić liczbę rekordów, które zwróciło to zapytanie?

A. mysqli_fetch_row

B. mysqli_query

C. mysqli_num_rows

D. mysqli_connect

Wybór innych funkcji jako odpowiedzi na pytanie jest niezgodny z ich rzeczywistym przeznaczeniem w kontekście analizy wyników zapytań w PHP. Funkcje takie jak mysqli_fetch_row służą do pobierania pojedynczego wiersza z zestawu wyników i nie dostarczają informacji o łącznej liczbie rekordów. Użycie tej funkcji może prowadzić do błędnych wniosków, gdyż zamiast podać liczbę wyników, zwraca jedynie dane jednego wiersza. Innym przykładem jest mysqli_query, która jest odpowiedzialna za wykonanie zapytania, ale nie oferuje metody na określenie ilości zwróconych rekordów. Podobnie, mysqli_connect jest funkcją do nawiązywania połączenia z bazą danych, co jest zupełnie nieadekwatne w kontekście analizy wyników zapytań. Użytkownicy często mylą te funkcje, ponieważ wszystkie są częścią pakietu MySQLi, jednak każda z nich ma swoje specyficzne zastosowanie. Właściwe zrozumienie roli poszczególnych funkcji jest kluczowe dla efektywnej pracy z bazami danych w PHP. Ignorowanie tego może prowadzić do nieefektywnego kodu oraz problemów z wydajnością aplikacji. Dlatego ważne jest, aby przed przystąpieniem do pisania zapytań zrozumieć, jakie funkcje będą potrzebne i jakie dane chcemy uzyskać.

Pytanie 37

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

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

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

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

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

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

Pytanie 38

W języku SQL, jaki będzie efekt wykonania poniższego zapytania?

ALTER TABLE osoba DROP COLUMN grupa;

A. Zmieniona zostanie nazwa tabeli na grupa.

B. Dodana zostanie kolumna grupa.

C. Zmieniona zostanie nazwa kolumny na grupa.

D. Usunięta zostanie kolumna grupa.

Wybrana odpowiedź jest niepoprawna, ale nie martw się, to jest okazja do nauki. Zapytanie SQL w pytaniu nie dotyczyło zmiany nazwy tabeli ani kolumny, a także nie dotyczyło dodawania nowej kolumny. W języku SQL do zmiany nazwy tabeli używamy zapytania 'RENAME', natomiast do zmiany nazwy kolumny używamy 'ALTER TABLE' z dodatkiem 'RENAME COLUMN'. Dodawanie nowej kolumny wymaga natomiast użycia 'ALTER TABLE' z dodatkiem 'ADD COLUMN'. Wszystkie te operacje są ważne i niezbędne w różnych scenariuszach pracy z bazą danych. Jednak w tym przypadku mieliśmy do czynienia z instrukcją 'ALTER TABLE' z dodatkiem 'DROP COLUMN', które służy do usunięcia kolumny. Pamiętaj, że każde z tych zapytań ma inne skutki i odpowiednie zastosowania, więc ważne jest dokładne zrozumienie różnic między nimi.

Pytanie 39

Proces normalizacji tabel ma na celu

A. weryfikację i poprawę efektywności bazy danych

B. wizualizację bazy

C. dodanie danych do bazy

D. wyłącznie stworzenie tabel oraz powiązań w bazie

Niektóre pomysły na niepoprawne odpowiedzi wskazują na powszechne nieporozumienia dotyczące normalizacji w kontekście baz danych. Stwierdzenie, że normalizacja polega jedynie na utworzeniu tabel i relacji, jest mylne. Normalizacja to znacznie bardziej skomplikowany proces, który zakłada również przemyślane podejście do organizacji danych oraz ich struktury. Utworzenie tabel i relacji to zaledwie etap, który nie zapewnia, że baza danych będzie wolna od błędów czy nadmiarowości. Inna nieprawidłowa odpowiedź dotycząca dodawania rekordów do bazy nie uwzględnia faktu, że normalizacja skupia się na strukturze i organizacji danych, a nie na ich wprowadzaniu. Ponadto, przedstawienie graficzne bazy danych, choć może być przydatne w wizualizacji, nie ma nic wspólnego z procesem normalizacji, który jest techniką analizy i poprawy struktury danych. Zrozumienie, że normalizacja nie ogranicza się do jednego aspektu zarządzania danymi, ale jest całościowym podejściem do ich organizacji, jest kluczowe dla efektywnego projektowania baz danych. W praktyce, nieprawidłowe zrozumienie celu normalizacji może prowadzić do poważnych problemów z wydajnością i integralnością danych w systemach bazodanowych.

Pytanie 40

W systemie baz danych MySQL komenda CREATE USER pozwala na

A. stworzenie użytkownika oraz przypisanie mu uprawnień do bazy

B. stworzenie nowego użytkownika

C. zmianę hasła dla już istniejącego użytkownika

D. zobaczenie danych o aktualnym użytkowniku

Polecenie CREATE USER w bazie danych MySQL jest kluczowym narzędziem do zarządzania użytkownikami w systemie zarządzania bazami danych. Jego podstawowym celem jest utworzenie nowego konta użytkownika, które pozwala na autoryzowany dostęp do różnych zasobów bazy danych. Użycie tego polecenia wiąże się z określeniem nazwy użytkownika oraz hasła, a także opcjonalnymi parametrami, takimi jak host, który określa, z jakiego adresu IP użytkownik może uzyskać dostęp do serwera. Przykładowe polecenie CREATE USER wygląda następująco: CREATE USER 'nazwa_użytkownika'@'host' IDENTIFIED BY 'hasło'; Po utworzeniu użytkownika można przypisać mu odpowiednie uprawnienia za pomocą polecenia GRANT, co pozwala na kontrolowanie, jakie operacje użytkownik może wykonywać na bazie danych. Dobrą praktyką jest regularne przeglądanie i aktualizacja uprawnień użytkowników, aby zapewnić bezpieczeństwo danych. Zgodnie z najlepszymi standardami bezpieczeństwa należy unikać nadawania zbyt szerokich uprawnień, co jest zgodne z zasadą najmniejszych uprawnień (principle of least privilege).

Rozpocznij nowy egzamin

Powrót do strony głównej