Wyniki egzaminu

Nowy egzamin
Informacje o egzaminie:
  • Zawód: Technik programista
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 10 kwietnia 2026 09:51
  • Data zakończenia: 10 kwietnia 2026 09:52

Egzamin niezdany

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

Wymagane minimum: 20 punktów (50%)

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

Proces przetwarzania sygnału wejściowego w czasie, wykorzystujący zasadę superpozycji, jest związany z filtrem

A. liniowym
B. o skończonej odpowiedzi impulsowej
C. przyczynowym
D. niezmiennym w czasie
Wybór odpowiedzi związanej z filtrami przyczynowymi, niezmiennymi w czasie i o skończonej odpowiedzi impulsowej może prowadzić do nieporozumień w kontekście filtracji sygnałów. Filtr przyczynowy, chociaż może być liniowy, niekoniecznie musi spełniać wszystkie założenia dotyczące superpozycji, ponieważ jego odpowiedź impulsowa ogranicza się do przeszłych wartości sygnału, co może wprowadzać dodatkowe zniekształcenia w analizie sygnałów. Stosowanie filtrów niezmiennych w czasie w kontekście superpozycji również wymaga ostrożności, ponieważ mogą one wprowadzać zmiany w amplitudzie i fazie sygnałów, co prowadzi do złożonych interakcji. Z kolei filtry o skończonej odpowiedzi impulsowej (FIR) są typem filtru liniowego, ale nie zawsze są przyczynowe; można je zaprojektować jako filtry nieprzyczynowe, co podważa ich użyteczność w kontekście rzeczywistych zastosowań przetwarzania sygnałów. Warto zauważyć, że w praktyce, projektowanie filtrów wymaga zrozumienia i analizy zarówno ich właściwości liniowych, jak i nieliniowych, a także wpływu na jakość przetwarzanych sygnałów. Kluczowe jest również uwzględnienie spektrum sygnału oraz jego cech, co jest zgodne z najlepszymi praktykami inżynieryjnymi, aby uzyskać optymalne wyniki w aplikacjach inżynieryjnych.
Pytanie 2

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_row
B. mysql_field_len
C. mysql_list_fields
D. mysql_fetch_lengths
Odpowiedź 'mysql_fetch_row' jest prawidłowa, ponieważ to funkcja w PHP, która pobiera jeden wiersz danych jako tablicę numeryczną z wyników zapytania SQL. Jest to kluczowy element do pracy z danymi zwróconymi przez bazę danych, gdyż umożliwia nam iterację przez wyniki zapytania. Przykładowo, po wykonaniu kwerendy za pomocą 'mysql_query', używamy 'mysql_fetch_row', aby uzyskać pierwszy wiersz wyników: $row = mysql_fetch_row($result);. W praktyce, korzystając z tej funkcji, możemy odnosić się do poszczególnych kolumn, używając indeksów, co jest efektywne, zwłaszcza przy pracy z dużymi zbiorami danych. Warto pamiętać, że 'mysql_fetch_row' jest jedną z podstawowych funkcji w pracy z bazami danych w PHP, jednak w najnowszych projektach zaleca się korzystanie z rozszerzenia PDO lub MySQLi, które oferują lepsze zabezpieczenia oraz wsparcie dla obiektowego podejścia programowania. To także zgodne z najlepszymi praktykami w zakresie bezpieczeństwa i wydajności aplikacji webowych.
Pytanie 3

Instrukcja REVOKE SELECT ON nazwa1 FROM nazwa2 w SQL pozwala na

A. przyznawanie uprawnień za pomocą ustalonego schematu
B. usuwanie konta użytkownika z bazy danych
C. przyznawanie praw dostępu do tabeli
D. pozbawianie użytkownika uprawnień
Pierwsza z błędnych odpowiedzi dotyczy nadawania uprawnień przy użyciu schematu, co jest trochę mylące. REVOKE nie nadaje, a odbiera uprawnienia. Wiele osób to myli, co prowadzi do zamieszania w zarządzaniu uprawnieniami. Kolejna nieprawidłowa odpowiedź mówi o usuwaniu użytkownika z bazy, co też jest błędne, bo REVOKE nie usuwa kont, a tylko zmienia uprawnienia. Kluczowe jest, żeby rozumieć różnicę między zarządzaniem uprawnieniami a użytkownikami. Ostatnia z błędnych odpowiedzi sugeruje, że to polecenie nadaje prawa do tabeli, a to totalnie mija się z prawdą, bo jego zadaniem jest właśnie odbieranie takich uprawnień. Z mojego doświadczenia, przydatne jest stosowanie GRANT do nadawania uprawnień, żeby uniknąć zamieszania. W zarządzaniu bazami danych ważne jest, żeby wiedzieć, jakie operacje dotyczą bezpieczeństwa danych i jak je właściwie stosować, żeby wszystko działało jak należy.
Pytanie 4

Polecenie TRUNCATE TABLE w systemie MySQL stosuje się do usuwania

A. wierszy tabeli.
B. kolumn.
C. tabel.
D. baz danych.
W poleceniu TRUNCATE TABLE kluczowe jest zrozumienie, że operujemy na zawartości tabeli, a nie na jej definicji czy całej bazie danych. W praktyce wiele osób myli to polecenie z innymi instrukcjami SQL, co później prowadzi do niebezpiecznych sytuacji w środowisku produkcyjnym. Usuwanie tabel jako obiektów bazy danych realizuje się poleceniem DROP TABLE. DROP kasuje całą strukturę: kolumny, indeksy, klucze, uprawnienia powiązane z tą tabelą. Po DROP nie ma już gdzie wstawić danych, trzeba tabelę zdefiniować na nowo. TRUNCATE takich rzeczy nie robi, pozostawia strukturę nienaruszoną. Mylenie TRUNCATE z usuwaniem kolumn też bywa częste. Za dodawanie i usuwanie kolumn odpowiada ALTER TABLE, np. ALTER TABLE nazwa_tabeli DROP COLUMN nazwa_kolumny. To są operacje na schemacie (strukturze) danych, a TRUNCATE działa na poziomie rekordów, czyli zawartości. Ktoś, kto kojarzy słowo „truncate” z „ucięciem” struktury, może intuicyjnie pomyśleć, że zniknie kolumna, ale w SQL tak to nie działa. Podobnie w przypadku baz danych: do kasowania całych baz służy DROP DATABASE, ewentualnie w narzędziach typu phpMyAdmin odpowiednie opcje w interfejsie. TRUNCATE TABLE nie ma prawa dotykać całej bazy, bo jest przypisane do konkretnej tabeli. Typowy błąd myślowy polega na wrzuceniu do jednego worka wszystkich poleceń, które „coś usuwają”, bez rozróżniania, czy modyfikujemy strukturę (DDL), czy dane (DML), oraz na jakim poziomie: pojedynczy rekord, wszystkie rekordy, tabela czy cała baza. W MySQL TRUNCATE to specyficzna hybryda – formalnie DDL, ale semantycznie kasuje wyłącznie wiersze. Dlatego dobra praktyka jest taka: DROP używamy, gdy chcemy pozbyć się obiektu (tabeli, bazy), ALTER – gdy zmieniamy strukturę (kolumny, indeksy), a TRUNCATE lub DELETE – gdy czyścimy zawartość, przy czym TRUNCATE zawsze usuwa wszystkie wiersze, bez możliwości filtrowania i bez prostego cofnięcia transakcji. Rozdzielenie tych pojęć bardzo ułatwia bezpieczną pracę z SQL-em.
Pytanie 5

Z tabeli mieszkancy trzeba wydobyć unikalne nazwy miast, w tym celu należy użyć wyrażenia SQL zawierającego klauzulę

A. CHECK
B. UNIQUE
C. DISTINCT
D. HAVING
Odpowiedzi takie jak 'UNIQUE', 'CHECK' i 'HAVING' są błędne, ponieważ nie pełnią one funkcji eliminacji duplikatów w kontekście wyboru unikalnych wartości. 'UNIQUE' jest klauzulą, która służy do definiowania ograniczeń w tabelach, gwarantując, że wartości w danej kolumnie są unikalne w kontekście wierszy w tabeli. Jest to przydatne przy projektowaniu schematów baz danych, ale nie jest stosowane w zapytaniach do selekcji danych. 'CHECK' służy do walidacji danych wprowadzanych do tabeli, zapewniając, że spełniają one określone warunki, co jest istotne przy definiowaniu reguł dotyczących wartości, jakie mogą być wprowadzane. Z kolei 'HAVING' jest używane w kontekście grupowania danych, w połączeniu z klauzulą 'GROUP BY', aby filtrować grupy w oparciu o warunki, co jest zupełnie inną operacją niż eliminacja duplikatów. Typowym błędem jest mylenie koncepcji związanych z grupowaniem i selekcją unikalnych wartości. W praktyce, korzystając z 'HAVING', nie uzyskamy unikalnych wartości z kolumny bez wcześniejszego użycia 'GROUP BY', co sprawia, że jest to narzędzie bardziej skomplikowane i mniej efektywne w kontekście prostego wyciągania unikalnych danych. Aby właściwie zrozumieć zasady dotyczące zapytań SQL, ważne jest, aby rozróżniać te różne klauzule oraz ich zastosowania, co pozwoli na bardziej świadome i efektywne korzystanie z języka SQL.
Pytanie 6

Klucz obcy w bazie danych jest tworzony w celu

A. określenia relacji 1..n łączącej go z kluczem głównym innej tabeli
B. umożliwienia jednoznacznej identyfikacji rekordu w bazie danych
C. stworzenia formularza do wprowadzania danych do tabeli
D. łączenia go z innymi kluczami obcymi w tabeli
Zrozumienie roli klucza obcego w tabeli wymaga głębszego spojrzenia na struktury relacyjnych baz danych. Klucz obcy definiuje relacje pomiędzy tabelami, co jest niezwiązane z jednoznaczną identyfikacją rekordu w tabeli. Ta koncepcja jest często mylona, ponieważ klucz główny, a nie klucz obcy, jest odpowiedzialny za zapewnienie unikalności każdego rekordu. Klucz obcy jest używany do wskazywania na klucz główny w innej tabeli, co tworzy powiązania, ale nie ma on na celu identyfikacji rekordu w swojej tabeli. Dodatkowo, klucz obcy nie ma związku z tworzeniem formularzy do wprowadzania danych. Formularze są narzędziem interfejsu użytkownika, które mogą wykorzystywać dane z tabel bazodanowych, ale nie są bezpośrednio związane z pojęciami klucza obcego i klucza głównego. Tworzenie formularzy nie zmienia struktury danych czy relacji między nimi. W kontekście łączenia kluczy obcych z innymi kluczami obcymi, również jest to niepoprawne, gdyż klucz obcy nie jest używany do tworzenia połączeń z innymi kluczami obcymi w tej samej tabeli. Klucz obcy ma na celu jedynie odniesienie do klucza głównego z innej tabeli, co ilustruje podstawowe zasady projektowania baz danych, w tym zapewnienie integralności referencyjnej i unikanie cyklicznych odniesień, które mogą prowadzić do błędów i niepoprawnych danych. Zrozumienie tych różnic jest kluczowe dla skutecznego projektowania relacyjnych baz danych.
Pytanie 7

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

A. Zwraca zbiór wyników z pierwszego zapytania oraz zbiór wyników z drugiego zapytania, automatycznie eliminując powtarzające się wiersze
B. Zwraca te wiersze, które wystąpiły w wyniku drugiego zapytania, natomiast nie było ich w wyniku pierwszego zapytania
C. Zwraca część wspólną wyników dwóch zapytań
D. Zwraca te wiersze, które wystąpiły w wyniku pierwszego zapytania, jednak nie były obecne w wyniku drugiego zapytania
Instrukcja INTERSECT w języku SQL jest używana do zwracania wspólnych wyników dwóch lub więcej zapytań SELECT. W praktyce INTERSECT identyfikuje i zwraca jedynie te wiersze, które występują zarówno w pierwszym, jak i w drugim zbiorze wyników. Warto zauważyć, że podczas używania tej instrukcji, domyślnie usuwane są duplikaty, co oznacza, że każde unikalne wystąpienie wspólnych wierszy zostanie zwrócone tylko raz. Na przykład, jeżeli mamy dwa zapytania: pierwsze zwracające klientów z miasta A, a drugie klientów z miasta B, zastosowanie INTERSECT pozwoli nam uzyskać listę klientów, którzy znajdują się w obu zbiorach, co może być istotne w kontekście analizy danych lub segmentacji rynku. W kontekście standardów SQL, INTERSECT jest jednym z operatorów zbiorowych, obok UNION i EXCEPT, co czyni go fundamentalnym narzędziem w pracy z relacyjnymi bazami danych. Użycie INTERSECT może być korzystne w sytuacjach, gdy chcemy uzyskać analizę porównawczą lub zidentyfikować wspólne elementy pomiędzy różnymi zestawami danych, co jest kluczowe w wielu zastosowaniach analitycznych i raportowych.
Pytanie 8

W celu modyfikacji danych w bazie danych można wykorzystać

A. filtrowaniem
B. formularzem
C. raportem
D. kwerendą SELECT
Formularz jest kluczowym narzędziem do edytowania danych w bazach danych, ponieważ umożliwia użytkownikom interakcję z danymi w sposób przyjazny i zrozumiały. Stosując formularze, można łatwo wprowadzać, modyfikować i usuwać informacje w bazie, co jest szczególnie ważne w aplikacjach typu CRUD (Create, Read, Update, Delete). W kontekście baz danych, formularze są często zintegrowane z systemami zarządzania bazami danych (DBMS), co pozwala na walidację danych wprowadzanych przez użytkowników i zabezpieczenie przed błędami. Przykładem zastosowania formularzy może być system zarządzania klientami, gdzie pracownik wprowadza dane klientów za pomocą formularza, co automatycznie aktualizuje odpowiednie tabele w bazie danych. Właściwe projektowanie formularzy uwzględnia zasady UX/UI, co zwiększa efektywność użytkowników i zmniejsza ryzyko pomyłek. Ponadto, formularze mogą być wspierane przez zaawansowane technologie, takie jak AJAX, które umożliwiają dynamiczne aktualizacje danych bez konieczności przeładowania strony.
Pytanie 9

Aby stworzyć relację jeden do wielu, w tabeli po stronie wiele, co należy zdefiniować?

A. klucz sztuczny odnoszący się do kluczy podstawowych obu tabel
B. klucz obcy wskazujący na klucz podstawowy tabeli po stronie jeden
C. klucz obcy wskazujący na klucz obcy tabeli po stronie jeden
D. klucz podstawowy wskazujący na klucz podstawowy tabeli po stronie jeden
W kontekście relacji jeden do wielu w bazach danych, każda z podanych niepoprawnych opcji wprowadza w błąd odnośnie do zasady funkcjonowania kluczy obcych i ich roli w modelowaniu danych. Klucz obcy wskazujący na klucz obcy tabeli po stronie jeden jest konceptualnie błędny, ponieważ klucz obcy zawsze odnosi się do klucza podstawowego innej tabeli, a nie do innego klucza obcego. Taki układ narusza zasady referencyjności i integralności danych, co może prowadzić do trudności w utrzymaniu spójności w bazie. Kolejną niepoprawną opcją jest klucz sztuczny odnoszący się do kluczy podstawowych obu tabel. Klucze sztuczne, choć mogą być użyteczne w pewnych kontekstach, nie powinny być używane jako sposób tworzenia relacji, ponieważ nie odzwierciedlają naturalnych powiązań między danymi. Klucz podstawowy wskazujący na klucz podstawowy tabeli po stronie jeden również jest mylny, ponieważ w relacji jeden do wielu klucz podstawowy tabeli 'jeden' musi być referencjonowany przez klucz obcy w tabeli 'wiele', a nie odwrotnie. Te nieporozumienia mogą prowadzić do błędów projektowych w bazach danych, co w efekcie utrudnia ich rozwój i zarządzanie, szczególnie w dużych systemach, gdzie spójność danych jest kluczowa dla funkcjonowania aplikacji.
Pytanie 10

W zaprezentowanym fragmencie zapytania SQL, instrukcja SELECT ma za zadanie zwrócić

SELECT COUNT(wartosc) FROM ...
A. średniej w kolumnie wartosc
B. suma w kolumnie wartosc
C. liczby rekordów
D. średniej wartości tabeli
W przypadku języka SQL, funkcja SELECT służy do wybierania danych z bazy i często jest mylona ze sposobem podsumowywania danych. Odpowiedzi wskazujące na obliczanie średniej w tabeli lub w kolumnie są błędne, ponieważ średnia (AVG) jest obliczana zupełnie inną funkcją. Select średniej w kolumnie wymaga użycia AVG zamiast COUNT. To powszechny błąd, wynikający z niepełnego zrozumienia różnicy między różnymi funkcjami agregującymi. Z kolei zrozumienie dlaczego odpowiedź dotycząca sumy w kolumnie jest błędna wiąże się z innym typowym nieporozumieniem w SQL. SUM służy do dodawania wartości liczbowych w kolumnie, jednak COUNT skupia się na liczbie wierszy, co oznacza, że jego celem nie jest sumowanie wartości, lecz ich zliczanie. W tej sytuacji pytanie dotyczyło liczby niepustych wartości w kolumnie wartosc, a nie sumy tych wartości. Takie błędy często wynikają z mylnego postrzegania funkcji jako wzajemnie zamiennych, podczas gdy każda z nich ma specyficzne zastosowanie i wynika z niej inna logika działania. Warto zatem skupić się na zrozumieniu przeznaczenia i użycia każdej z funkcji agregujących osobno, co pozwoli uniknąć takich nieporozumień w przyszłości. Ważne jest, aby pamiętać o tych różnicach i stosować odpowiednie funkcje zgodnie z potrzebami analizy danych. Poprawne użycie funkcji COUNT pozwala na efektywne zliczanie wartości i jest fundamentalne dla prawidłowego przetwarzania danych w SQL.
Pytanie 11

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

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

Podczas zapisywania hasła użytkownika w serwisie WWW, na przykład w bankowości internetowej, aby zabezpieczyć je przed odczytaniem, zazwyczaj stosuje się funkcję

A. cyklometrycznych
B. mieszających
C. klucza
D. abstrakcyjnych
Zastosowanie cyklometrycznych, abstrakcyjnych czy mieszających funkcji do zabezpieczania haseł użytkowników jest nieadekwatne, gdyż każda z tych koncepcji ma swoje własne specyfikacje i zastosowanie, które nie są bezpośrednio związane z właściwym zabezpieczaniem haseł. Funkcje cyklometryczne, na przykład, są używane w programowaniu do analizy złożoności kodu, a nie do ochrony danych. Z kolei abstrakcyjne funkcje są bardziej związane z programowaniem obiektowym i nie mają zastosowania w kontekście szyfrowania haseł. Funkcje mieszające, mimo że mogą być stosowane w niektórych scenariuszach związanych z kryptografią, nie są wystarczające do zabezpieczania haseł samodzielnie. Bez dodatkowego mechanismu, takiego jak klucz szyfrujący, funkcje te mogą być niewystarczające do ochrony danych przed nieautoryzowanym dostępem. Często błędne przekonania na temat użycia różnych funkcji wynikają z niepełnego zrozumienia ich przeznaczenia oraz pomylenia ich z technikami szyfrowania lub hashowania, co prowadzi do niewłaściwych strategii zabezpieczania informacji. Właściwe podejście powinno zawsze uwzględniać standardy branżowe oraz najlepsze praktyki, takie jak stosowanie silnych algorytmów szyfrujących oraz odpowiednie zarządzanie kluczami.
Pytanie 13

Która z funkcji SQL nie przyjmuje żadnych argumentów?

A. now
B. upper
C. len
D. year
Wybór funkcji 'upper', 'len' lub 'year' jako odpowiedzi wskazuje na nieporozumienie dotyczące funkcji w SQL. Funkcja 'upper' służy do konwertowania tekstu na wielkie litery, co oznacza, że wymaga argumentu - ciągu znaków, który ma zostać przekształcony. Przykładowe użycie tej funkcji to 'SELECT upper(nazwa) FROM tabela;', gdzie 'nazwa' jest kolumną z danymi tekstowymi. Podobnie, funkcja 'len' wylicza długość ciągu znaków i również wymaga argumentu; na przykład, 'SELECT len(nazwa) FROM tabela;' zwróci liczbę znaków w kolumnie 'nazwa'. Funkcja 'year' wyciąga rok z daty, co czyni ją również funkcją wymagającą argumentu, jak 'SELECT year(data) FROM tabela;', gdzie 'data' jest kolumną z wartościami dat. Typowe błędy myślowe prowadzące do wyboru tych funkcji jako odpowiedzi wynikają z mylenia ich z funkcjami, które mogą działać bez argumentów, jak 'now'. Warto znać różnice między tymi funkcjami, aby skutecznie korzystać z SQL w praktyce, a także unikać niepoprawnych zapytań, które mogą prowadzić do błędów wykonania lub nieprawidłowych wyników.
Pytanie 14

Podczas definiowania tabeli produkty należy stworzyć pole cena, które będzie reprezentować wartość produktu. Odpowiedni typ danych dla tego pola to

A. ENUM
B. TINYTEXT
C. DECIMAL(10, 2)
D. INTEGER(11)
Wybór typów danych dla pola przechowującego cenę produktu ma kluczowe znaczenie dla poprawności funkcjonowania bazy danych. INTEGER(11) jest typem, który przechowuje liczby całkowite, co oznacza, że nie może być zastosowany do reprezentacji wartości z miejscami dziesiętnymi, co jest niezbędne w przypadku cen. Użycie INTEGER może prowadzić do poważnych problemów, jak zaokrąglanie cen, co w branży handlowej może skutkować błędnymi transakcjami. TINYTEXT to typ danych przeznaczony do przechowywania tekstu, co czyni go całkowicie nieodpowiednim do reprezentacji wartości liczbowych, a tym bardziej cen. W przypadku zastosowania TINYTEXT w tym kontekście, nie tylko utracimy możliwość przeprowadzania obliczeń na cenach, ale również stworzymy dodatkowe problemy z wydajnością bazy danych, ponieważ operacje na tekstach są znacznie wolniejsze niż na liczbach. Z kolei ENUM, który jest używany do określenia zestawu dozwolonych wartości, nie ma zastosowania w kontekście cen, które mogą się zmieniać i nie są ograniczone do stałego zestawu opcji. Użycie ENUM do reprezentacji cen prowadziłoby do nieefektywności, ponieważ każda zmiana ceny wymagałaby modyfikacji definicji pola. Typowe błędy myślowe prowadzące do takich niepoprawnych wniosków to brak zrozumienia znaczenia precyzyjnego przechowywania danych finansowych oraz nieznajomość dostępnych typów danych i ich zastosowań w kontekście konkretnej aplikacji.
Pytanie 15

W SQL polecenie ALTER TABLE służy do

A. dodawania tabeli do bazy danych
B. zmiany kolumn w tabeli
C. usuwania tabeli z bazy danych
D. zmiany danych w rekordach tabeli
Zrozumienie działania polecenia ALTER TABLE jest kluczowe w kontekście zarządzania bazami danych, ponieważ jego zastosowanie jest znacznie szersze niż sugerują to błędne odpowiedzi. Modyfikowanie danych rekordów w tabeli nie jest zadaniem ALTER TABLE; do tego celu używa się polecenia UPDATE, które pozwala na zmianę wartości w konkretnych kolumnach rekordów. Ponadto, usuwanie tabeli z bazy danych realizuje się za pomocą polecenia DROP TABLE, natomiast dodawanie nowych tabel wymaga użycia polecenia CREATE TABLE. Takie rozróżnienie jest podstawowe dla prawidłowego zarządzania bazą danych. Zrozumienie, że ALTER TABLE dotyczy struktury tabeli, a nie danych w nich zawartych, jest kluczowe dla unikania błędów w projektowaniu systemów baz danych. Często pomijanym aspektem jest również to, że zmiany wprowadzane przez ALTER TABLE mogą wpływać na integralność danych oraz wydajność operacji bazodanowych, dlatego praktyka dobrego zarządzania schematem bazy danych wymaga staranności i przemyślenia przed wykonaniem jakichkolwiek operacji zmieniających strukturę tabeli. Z tego powodu, użytkownicy powinni być świadomi, jakie polecenia są przeznaczone do konkretnych zadań, aby uniknąć nieporozumień i błędów w ich pracy.
Pytanie 16

Jakie dane zostaną wybrane po wykonaniu poniższej kwerendy na pokazanych rekordach?

SELECT id FROM samochody WHERE rocznik LIKE "2%4";

idmarkamodelrocznik
1FiatPunto2016
2FiatPunto2002
3FiatPunto2007
4OpelCorsa2016
5OpelAstra2003
6ToyotaCorolla2016
7ToyotaCorolla2014
8ToyotaYaris2004
A. Tylko id równe 8
B. Pole id równe 7 oraz 8
C. Wszystkie id
D. Brak danych
Odpowiedź jest prawidłowa, ponieważ zapytanie SQL SELECT id FROM samochody WHERE rocznik LIKE '2_4'; filtruje rekordy, które mają w kolumnie rocznik wartość z drugą cyfrą równą '2' i czwartą cyfrą równą '4'. W złożonym zapytaniu SQL zastosowano operator LIKE z użyciem symbolu podkreślenia (_) jako symbolu zastępczego dla pojedynczego znaku. To oznacza, że szukamy dowolnego roku, który zaczyna się od cyfry '2', ma dowolną cyfrę na drugiej pozycji i cyfrę '4' na ostatniej pozycji. Praktycznie oznacza to, że wybierane są identyfikatory pojazdów, które mają rocznik odpowiadający temu wzorcowi. W dostarczonym zbiorze danych tylko rekordy o id 7 i 8 spełniają ten warunek, ponieważ rocznik to 2014 i 2004. Tego rodzaju konstrukcja SQL jest użyteczna w sytuacjach, gdy potrzebujemy selektywnie uzyskać dane na podstawie wzorców. Operator LIKE jest bardzo efektywny w analizie danych tekstowych w bazach danych np. w raportach analitycznych gdzie kluczowe jest wyszukiwanie na podstawie wzorców. Warto zaznaczyć, że takie podejście jest zgodne ze standardami SQL, ułatwiającymi zarządzanie i filtrowanie danych w złożonych systemach bazodanowych.
Pytanie 17

Rekordy do raportu mogą pochodzić z

A. innego raportu
B. makropolecenia
C. tabeli
D. zapytania INSERT INTO
Wybór innego raportu jako źródła danych może wydawać się logiczny na pierwszy rzut oka, jednak w rzeczywistości, raporty są zazwyczaj wynikiem analizy danych już zgromadzonych w bazach danych, a nie bezpośrednim źródłem tych danych. Raport oparty na innym raporcie może prowadzić do niepotrzebnej złożoności oraz braku przejrzystości w dostępie do danych. Ponadto użycie makropolecenia jako źródła do generowania raportu jest niewłaściwe, ponieważ makropolecenia są narzędziami do automatyzacji zadań, a nie strukturami danych. W kontekście zapytania 'INSERT INTO', należy zauważyć, że jest to instrukcja służąca do dodawania nowych rekordów do tabeli, a nie do pobierania danych. Wybranie takiego podejścia mogłoby wprowadzić w błąd, ponieważ nie odzwierciedla rzeczywistego procesu raportowania, który wymaga analizy istniejących danych. Często błędy myślenia w tym kontekście wynikają z pomylenia celów automatyzacji z celami analizy danych. Poprawne zrozumienie roli tabel w bazach danych pozwala na wydajne raportowanie i podejmowanie decyzji na podstawie rzeczywistych i aktualnych informacji.
Pytanie 18

W tabeli samochody w bazie danych, pole kolor może przyjmować jedynie wartości zdefiniowane w słowniku lakier. Jaką kwerendę należy wykorzystać, aby ustanowić relację między tabelami samochody a lakier?

A. ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);
B. ALTER TABLE samochody ADD FOREIGN KEY kolor REFERENCES lakier;
C. ALTER TABLE samochody ADD FOREIGN KEY barwa REFERENCES samochody.lakier;
D. ALTER TABLE samochody ADD FOREIGN KEY (barwa) REFERENCES samochody(kolor);
Aby połączyć tabele 'samochody' i 'lakier' za pomocą klucza obcego, należy zastosować kwerendę ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);. W tym przypadku 'kolor' w tabeli 'samochody' odnosi się do identyfikatora 'lakierId' w tabeli 'lakier', co zapewnia integralność referencyjną między tymi dwoma tabelami. Klucz obcy jest mechanizmem, który pozwala na zapewnienie, że wartości w kolumnie 'kolor' w tabeli 'samochody' muszą odpowiadać wartościom w kolumnie 'lakierId' w tabeli 'lakier', co zapobiega wprowadzeniu danych, które nie mają odpowiednika w tabeli 'lakier'. Przykładowo, jeżeli próbujemy dodać samochód w kolorze, który nie istnieje w tabeli 'lakier', system nie pozwoli na to działanie. Taka struktura bazy danych jest zgodna z zasadami normalizacji, która ma na celu eliminację redundancji danych oraz zwiększenie ich spójności. Stosowanie kluczy obcych jest standardem w projektowaniu relacyjnych baz danych, ponieważ ułatwia zarządzanie danymi oraz ich integralność.
Pytanie 19

Na ilustracji pokazano relację jeden do wielu. Łączy ona

Ilustracja do pytania
A. klucz podstawowy id tabeli filmy z kluczem obcym rezyserzy_id tabeli rezyserzy
B. klucz obcy rezyserzy_id tabeli filmy z kluczem obcym id tabeli rezyserzy
C. klucz podstawowy id tabeli filmy z kluczem podstawowym id tabeli rezyserzy
D. klucz obcy rezyserzy_id tabeli filmy z kluczem podstawowym id tabeli rezyserzy
W kontekście relacji jeden do wielu w bazach danych często dochodzi do nieporozumień związanych z błędnym przypisaniem kluczy. Klucz podstawowy w jednej tabeli nigdy nie może być kluczem obcym w innej relacji tego typu, ponieważ klucz podstawowy musi być unikalny i jednoznacznie identyfikować rekord w swojej tabeli. Podobne błędy pojawiają się przy przypisywaniu klucza obcego jako odnoszącego się do innego klucza obcego, co nie jest prawidłowym podejściem, ponieważ klucz obcy powinien odnosić się do klucza podstawowego w innej tabeli, aby zapewnić integralność referencyjną. Klucz obcy nie może być kluczem podstawowym w relacji jeden do wielu, ponieważ naruszałoby to zasadę unikalności wymaganej dla klucza podstawowego. Częstym błędem jest także mylenie kierunku relacji, co prowadzi do projektowania niepraktycznych struktur danych, które są trudne do zarządzania i skalowania. Prawidłowe zastosowanie kluczy obcych i podstawowych oraz zrozumienie ich roli w strukturze bazy danych stanowi fundament dla efektywnego modelowania danych, co jest zgodne z najlepszymi praktykami w projektowaniu systemów zarządzania relacyjnymi bazami danych. Kluczowe jest, aby projektanci baz danych byli świadomi tych zasad i potrafili je stosować w praktyce, aby uniknąć problemów z integralnością danych i późniejszymi trudnościami przy ich modyfikacji lub rozszerzaniu struktury bazy danych. Poprawne zrozumienie relacji między tabelami oraz ich implementacja jest niezbędna dla utrzymania spójności i wydajności systemów bazodanowych w długim okresie użytkowania.
Pytanie 20

Jakim poleceniem SQL można zlikwidować z tabeli artykuly wiersze, które zawierają słowo "sto" w dowolnej lokalizacji pola tresc?

A. DELETE FROM artykuly WHERE tresc LIKE "%sto%"
B. DELETE * FROM artykuly WHERE tresc = "%sto%"
C. DELETE * FROM artykuly WHERE tresc LIKE "%sto%"
D. DELETE FROM artykuly WHERE tresc = "%sto%"
Wybór odpowiedzi "DELETE * FROM artykuly WHERE tresc = '%sto%';" jest po prostu zły z paru powodów. Po pierwsze, w SQL nie używamy znaku '*' przy DELETE. Jak chcemy usunąć wiersze, to piszemy tylko "DELETE FROM nazwa_tabeli". To '*' sugeruje, że chcesz usunąć jakieś konkretne kolumny, a to w SQL się nie sprawdzi. Druga sprawa to operator '=' zamiast 'LIKE'. '=' używamy do porównania wartości, nie do wyszukiwania wzorców, a tu właśnie szukamy wystąpienia słowa 'sto' w dłuższym tekście. Dlatego operator LIKE z wildcardami jest tu konieczny, by znaleźć i usunąć te wiersze, które mają 'sto' gdziekolwiek. Często ludzie mylą te operatory w SQL, co prowadzi do problemów i nieefektywnego wyszukiwania.
Pytanie 21

Obiekt bazy danych, którego głównym przeznaczeniem jest drukowanie lub wyświetlanie zestawień danych, to

A. raport.
B. makro.
C. formularz.
D. moduł.
W tym pytaniu łatwo się pomylić, bo w bazach danych mamy kilka typów obiektów, które „coś pokazują” użytkownikowi. Kluczowe jest jednak rozróżnienie: czym innym jest narzędzie do automatyzacji, czym innym interfejs do wprowadzania danych, a czym innym obiekt przeznaczony typowo do drukowania i prezentacji zestawień. Makro w bazie danych służy głównie do automatyzacji czynności: otwarcie formularza, uruchomienie kwerendy, wydruk raportu, eksport danych do pliku i tym podobne rzeczy. To jest taki prostszy mechanizm skryptowy, który pozwala zdefiniować sekwencję akcji bez pisania klasycznego kodu w języku programowania. Makro samo z siebie nie jest obiektem do drukowania danych, raczej „wywołuje” inne obiekty, na przykład raport, który dopiero generuje wydruk. Moduł z kolei to już typowo programistyczny element – w Accessie jest to moduł VBA (Visual Basic for Applications). Tam umieszcza się procedury, funkcje, bardziej złożoną logikę biznesową, obsługę zdarzeń. Moduł działa w tle, nie jest przeznaczony do bezpośredniej prezentacji danych użytkownikowi, tylko do ich przetwarzania, walidacji, sterowania działaniem aplikacji bazodanowej. Wybór modułu oznacza pomieszanie warstwy logiki z warstwą prezentacji. Formularz często kusi jako odpowiedź, bo też „wyświetla dane”. Jednak jego głównym celem jest interakcja: wprowadzanie, edycja, przeglądanie rekordów, czasem proste filtrowanie. Formularz jest zoptymalizowany do pracy na pojedynczych rekordach lub niewielkich listach, a nie do tworzenia eleganckich, wielostronicowych zestawień z nagłówkami, stopkami, grupowaniem i sumami. Typowy błąd myślowy polega na tym, że skoro coś widać na ekranie, to znaczy, że nadaje się do drukowania raportów. W praktyce w poprawnie zaprojektowanej bazie formularze służą do pracy bieżącej z danymi, a raporty – do tworzenia końcowych dokumentów: wydruków, plików PDF, załączników do maili. Właśnie dlatego właściwą odpowiedzią jest raport, bo to on jest standardowym obiektem bazy danych zaprojektowanym specjalnie do prezentacji zestawionych danych w formie wydruku lub podglądu.
Pytanie 22

W tabeli psy znajdują się kolumny: imie, rasa, telefon_wlasciciela, rok_szczepienia. Jakie polecenie SQL należy zastosować, aby uzyskać numery telefonów właścicieli psów, które były szczepione przed rokiem 2015?

A. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia > 2015
B. SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015
C. SELECT imie, rasa FROM psy WHERE rok_szczepienia > 2015
D. SELECT psy FROM rok_szczepienia < 2015
Wybór błędnych odpowiedzi wynika z nieporozumienia dotyczącego zastosowania różnych operatorów porównania i struktury zapytań SQL. W pierwszej analizowanej odpowiedzi 'SELECT imie, rasa FROM psy WHERE rok_szczepienia > 2015', zamiast wydobywać telefony właścicieli, zapytanie skupia się na imionach i rasach psów, co nie odpowiada na zadane pytanie. Użycie operatora '>' w kontekście roku szczepienia jest sprzeczne z wymaganiem, które dotyczy psów zaszczepionych przed 2015 rokiem, co jest podstawowym błędem logicznym. Inna odpowiedź, 'SELECT psy FROM rok_szczepienia < 2015', jest niepoprawna z powodu błędnej składni SQL; nie można wybierać całej tabeli w ten sposób, co pokazuje brak znajomości podstaw struktury zapytań. Ostatnia niepoprawna odpowiedź, 'SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia > 2015', również wskazuje na błąd w interpretacji kryteriów czasowych, ponieważ operator '>' nie uwzględnia psów zaszczepionych przed rokiem 2015. Ta sytuacja pokazuje, jak ważne jest dokładne czytanie wymagań oraz znajomość podstawowych zasad składni SQL, aby unikać błędów i skutecznie korzystać z baz danych.
Pytanie 23

W bazie danych znajduje się tabela ksiazki, która zawiera pola: tytul, id_autora, data_wypoz oraz id_czytelnika. Co dzień generowany jest raport dotyczący książek wypożyczonych w danym dniu, który prezentuje tylko tytuły książek. Która z poniższych kwerend SQL będzie odpowiednia do utworzenia tego raportu?

A. SELECT tytul FROM ksiazki
B. SELECT * FROM ksiazki
C. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E()
D. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()
Wybór innych kwerend nie spełnia wymagania, by uzyskać tylko tytuły wypożyczonych książek z konkretnego dnia. Kwerenda 'SELECT tytul FROM ksiazki;' zwraca wszystkie tytuły książek z tabeli, nie uwzględniając daty wypożyczenia. Takie podejście mogłoby prowadzić do nieefektywnego przetwarzania danych oraz przeciążenia systemu, ze względu na duże ilości danych. W kontekście baz danych, selekcja zbyt ogólnych danych jest niezalecana, ponieważ nie dostarcza istotnych informacji i nie spełnia wymagań użytkowników, prowadząc do frustracji. Kwerenda 'SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E();' zawiera błąd w nazwie funkcji, jako że 'CURRDATE_NT_E()' nie jest standardową funkcją SQL, co skutkuje błędem wykonania zapytania. Dodatkowo, nawet gdyby była poprawna, ta kwerenda zwracałaby więcej danych niż potrzebne, co znowu nie jest praktyką zgodną z efektywnym zarządzaniem danymi. Ostatnia propozycja, 'SELECT * FROM ksiazki;', również nie jest odpowiednia, ponieważ zwraca wszystkie kolumny z tabeli, a nie tylko tytuły książek, co skutkuje nieoptymalnym przetwarzaniem i brakiem precyzyjnych informacji. Kluczową lekcją jest to, że kwerendy w SQL powinny być precyzyjnie dopasowane do potrzeb użytkowników, aby minimalizować obciążenie bazy danych oraz maksymalizować użyteczność raportów.
Pytanie 24

Dana jest tabela studenci o polach id_albumu, ubezpieczenie. Modyfikacja w kolumnie ubezpieczenie polegająca na zmianie wierszy bez wartości (NULL) na ciąg znaków „brak” zostanie wykonana kwerendą

A. UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak';
B. ALTER TABLE studenci ADD ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
C. ALTER TABLE studenci MODIFY COLUMN ubezpieczenie='brak' NOT NULL;
D. UPDATE studenci SET ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
W tym zadaniu łatwo wpaść w kilka typowych pułapek związanych z rozumieniem różnicy między modyfikacją danych a modyfikacją struktury tabeli. W SQL mamy dwa zupełnie różne światy: polecenia typu UPDATE, DELETE, INSERT działają na rekordach, czyli na zawartości tabeli, natomiast ALTER TABLE służy do zmiany schematu – dodawania kolumn, zmiany typów, ustawiania ograniczeń. Próba użycia ALTER TABLE do modyfikowania konkretnych wartości w wybranych wierszach po prostu nie pasuje do logiki języka SQL. Jeśli w poleceniu pojawia się ALTER TABLE z klauzulą ADD i jednocześnie WHERE, to widać tu pomieszanie pojęć. ADD dodaje nową kolumnę lub ograniczenie do całej tabeli, nie ma możliwości, żeby ALTER TABLE działał tylko na wierszach spełniających jakiś warunek. Warunek WHERE jest typowy dla operacji na danych (SELECT, UPDATE, DELETE), a nie na strukturze. Podobnie MODIFY COLUMN w SQL służy do zmiany typu, rozmiaru lub właściwości kolumny (np. z NULL na NOT NULL, zmiana długości VARCHAR), ale nie do ustawiania konkretnej wartości tekstowej w wybranych rekordach. Ustawienie NOT NULL bez zrozumienia aktualnej zawartości kolumny jest zresztą ryzykowne – jeżeli w tabeli są jakieś wartości NULL, baza może w ogóle nie przyjąć takiej zmiany albo wymagać wartości domyślnej, ale to nadal nie oznacza, że te NULL-e zostaną zamienione na sensowny ciąg znaków. Czasem pojawia się też błąd składniowy polegający na pominięciu słowa SET przy UPDATE albo błędnym umieszczeniu warunku IS NULL. Standard SQL wymaga postaci: UPDATE nazwa_tabeli SET kolumna=wartość WHERE warunek;. Próba napisania UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak'; łamie tę strukturę – parser SQL nie jest w stanie tego poprawnie zinterpretować, bo po nazwie tabeli nie może stać od razu warunek, tylko ewentualny alias, a potem musi być słowo SET. Z mojego doświadczenia wynika, że wiele osób myli kolejność elementów w zapytaniu, zwłaszcza gdy łączy warunki z modyfikacją danych. Podsumowując, żeby zamienić wartości NULL na ciąg znaków „brak” w konkretnej kolumnie, potrzebne jest czyste UPDATE z prawidłową składnią i z warunkiem WHERE ubezpieczenie IS NULL. ALTER TABLE nie nadaje się do takiej operacji, a pominięcie SET albo błędne użycie IS NULL skutkuje albo błędem składni, albo niepoprawnym działaniem. Dobra praktyka w pracy z bazami danych to wyraźne oddzielanie operacji na strukturze od operacji na danych i dokładne pilnowanie składni w tego typu poleceniach.
Pytanie 25

Jaką relację w projekcie bazy danych należy zdefiniować pomiędzy tabelami przedstawionymi na rysunku, zakładając, że każdy klient sklepu internetowego składa przynajmniej dwa zamówienia?

Ilustracja do pytania
A. 1:1
B. n:n
C. 1:n, gdzie 1 jest po stronie Zamówienia, a wiele po stronie Klienta
D. 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia
Relacja 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia, jest prawidłowa, ponieważ odzwierciedla rzeczywiste założenie, że każdy klient może złożyć wiele zamówień. W praktyce baza danych musi odwzorowywać te zależności, co pozwala na efektywne zarządzanie danymi. Każdy klient posiada unikalny identyfikator, zwykle klucz podstawowy, który nie może się powtarzać w tabeli Klient. Tabela Zamówienie posiada natomiast klucz obcy, który odnosi się do klucza podstawowego w tabeli Klient, umożliwiając przechowywanie wielu zamówień przypisanych do jednego klienta. Dzięki temu możemy łatwo wykonywać operacje takie jak wyszukiwanie wszystkich zamówień danego klienta czy śledzenie historii zakupów. Dobre praktyki projektowania baz danych podkreślają znaczenie poprawnego zdefiniowania relacji między tabelami, co zwiększa spójność danych i ułatwia ich późniejsze przetwarzanie. W systemach e-commerce taka struktura bazy danych jest niezbędna do obsługi klientów i śledzenia ich zamówień, co jest podstawą do analizy sprzedaży i tworzenia strategii marketingowych.
Pytanie 26

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 sklepy FROM nazwa WHERE branza='spożywczy' BETWEEN miasto='Wrocław';
B. SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND 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.
Pytanie 27

Wartość atrybutu w tabeli, który pełni rolę klucza głównego

A. jest używana do szyfrowania zawartości tabeli
B. musi być unikalna
C. może przyjmować wartość null (NULL)
D. nigdy nie jest innego typu niż numeryczny
Rozumienie, co to jest klucz podstawowy, jest mega istotne, zwłaszcza gdy projektujesz bazy danych. Klucz podstawowy nie ma nic wspólnego z tym, jak szyfrujesz dane w tabeli. Szyfrowanie dotyczy bardziej bezpieczeństwa informacji, a klucz podstawowy to sposób na identyfikację rekordów. Warto też wiedzieć, że klucz podstawowy nie musi być zawsze numeryczny. Może być tekstowy czy alfanumeryczny, w zależności od tego, jak go użyjesz. Na przykład, w niektórych systemach identyfikatory mogą być ciągami znaków, co jest ważne, kiedy integrujesz różne systemy. Tak czy siak, klucz podstawowy nigdy nie może mieć wartości pustej (NULL), bo to by wszystko zrujnowało. Jeśli ktoś myśli, że klucz podstawowy może być pusty, to może się narazić na spore kłopoty. Klucz podstawowy to nie tylko identyfikacja, ale też ważny element, który pomaga w normalizacji danych, co z kolei wpływa na ich spójność. Dlatego warto znać te zasady, bo mają duży wpływ na to, jak działają bazy danych.
Pytanie 28

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

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

Tabele: Studenci, Zapisy, Zajecia są powiązane relacją. Aby wybrać jedynie nazwiska studentów oraz odpowiadające im idZajecia dla studentów z grupy 15, należy wydać kwerendę

Ilustracja do pytania
A. SELECT nazwisko, idZajecia FROM Studenci INNER JOIN Zapisy ON Studenci.id = Zapisy.idStudenta;
B. SELECT nazwisko, idZajecia FROM Studenci JOIN Zapisy ON Studenci.id = Zapisy.idZajecia WHERE grupa = 15;
C. SELECT nazwisko, idZajecia FROM Studenci JOIN Zapisy ON Studenci.id = Zapisy.idStudenta WHERE grupa = 15;
D. SELECT nazwisko, idZajecia FROM Studenci INNER JOIN Zapisy WHERE grupa= 15;
W tej odpowiedzi zostało wszystko zrobione zgodnie z zasadami projektowania relacyjnych baz danych oraz praktyk SQL. Użycie JOIN zamiast starego stylu łączenia tabel przez przecinek i warunek WHERE to nie tylko kwestia czytelności, ale już od dawna standard branżowy. JOIN jasno pokazuje, na jakiej zasadzie łączą się tabele, w tym wypadku Studenci i Zapisy – łączymy po id studenta, bo tylko w taki sposób faktycznie powiążemy konkretne osoby z ich zapisami na zajęcia. WHERE grupa = 15 dodatkowo ogranicza wynik do tej konkretnej grupy studentów, co jest bardzo powszechną praktyką filtrowania wyników w zapytaniach. Przy bardziej złożonych systemach, gdzie mamy dużo relacji, taki zapis jest czytelny i łatwy do modyfikacji. Z mojego doświadczenia, jeżeli ktoś pracuje z większą ilością danych, czy nawet pisze bardziej skomplikowane raporty, to dokładnie taki zapis – z wyraźnie określonym JOIN-em i selekcją kolumn – bardzo ułatwia życie. Warto też pamiętać, że w praktyce biznesowej często chcemy wyciągnąć konkretną informację o użytkownikach lub powiązanych encjach, a nie wszystko naraz. W tym zadaniu to właśnie połączenie po idStudenta i selekcja po grupie daje najprecyzyjniejszy i najczystszy rezultat, zgodny i z logiką, i praktyką codziennej pracy z bazami danych.
Pytanie 30

W poleceniu CREATE TABLE zastosowanie klauzuli PRIMARY KEY przy definiowaniu kolumny tabeli spowoduje, że ta kolumna stanie się

A. indeksem klucza
B. indeksem unikalnym
C. kluczem podstawowym
D. kluczem obcym
Odpowiedzi, które zostały podane jako alternatywne do klucza podstawowego, opierają się na niewłaściwym zrozumieniu zasad definiowania relacji w bazach danych. Indeks klucza to struktura, która wspomaga wyszukiwanie rekordów w tabeli, ale sama w sobie nie zapewnia unikalności, która jest kluczowa dla klucza podstawowego. Indeks unikalny także pozwala na szybkie wyszukiwanie, ale jego głównym celem jest zapewnienie, że wartości w danej kolumnie są unikalne, co nie zawsze jest związane z identyfikacją rekordu w sposób jednoznaczny. Klucz obcy z kolei to mechanizm, który łączy dwie tabele, zapewniając, że wartość w kolumnie klucza obcego w jednej tabeli odpowiada wartości w kluczu podstawowym innej tabeli. To jest fundamentalne dla relacji w bazach danych, ale nie ma związku z samodzielnym definiowaniem unikalnego identyfikatora rekordu. Często popełnianym błędem jest mylenie klucza podstawowego z innymi typami kluczy, co prowadzi do nieprawidłowego projektowania bazy danych. Właściwe zrozumienie tych koncepcji jest kluczowe dla zapewnienia integralności danych i efektywności operacji na bazie, a ich ignorowanie może prowadzić do poważnych problemów w zarządzaniu danymi.
Pytanie 31

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

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

Istnieje tabela o nazwie przedmioty, która zawiera kolumny ocena i uczenID. Jakie zapytanie należy wykorzystać, aby obliczyć średnią ocen ucznia z ID równym 7?

A. SELECT COUNT(ocena) FROM przedmioty WHERE uczenID=7;
B. COUNT SELECT ocena FROM przedmioty WHERE uczenID=7;
C. AVG SELECT ocena FROM przedmioty WHERE uczenID=7;
D. SELECT AVG(ocena) FROM przedmioty WHERE uczenID=7;
Odpowiedź SELECT AVG(ocena) FROM przedmioty WHERE uczenID=7; jest prawidłowa, ponieważ wykorzystuje funkcję agregującą AVG, która oblicza średnią wartość dla podanego zestawu danych. W tym przypadku skupiamy się na ocenach ucznia o ID równym 7, co osiągamy poprzez zastosowanie klauzuli WHERE. Funkcje agregujące, takie jak AVG, są standardowym narzędziem w SQL do analizy danych, szczególnie przydatnym w kontekście raportowania i analityki. Dzięki takiemu zapytaniu możemy szybko uzyskać średnią ocen ucznia, co może być wykorzystane do oceny jego postępów w nauce lub do podejmowania decyzji z zakresu pedagogiki w oparciu o zebrane dane. W praktyce, takie podejście jest zgodne z najlepszymi praktykami w pracy z bazami danych, pozwalając na wydobycie istotnych informacji z dużych zbiorów danych bez konieczności przetwarzania ich ręcznie. Użycie AVG w połączeniu z klauzulą GROUP BY mogłoby również być zastosowane, gdybyśmy chcieli uzyskać średnie oceny dla wielu uczniów jednocześnie, co dodatkowo podkreśla elastyczność i moc SQL w analizie danych.
Pytanie 33

Na ilustracji przedstawiono dwie tabele. Aby ustanowić między nimi relację jeden do wielu, gdzie jedna strona to Klienci, a druga strona to Zamowienia, należy

Ilustracja do pytania
A. dodać pole klucza obcego do tabeli Klienci i powiązać je z ID tabeli Zamowienia.
B. stworzyć trzecią tabelę z dwoma kluczami obcymi. Jeden klucz połączyć z ID tabeli Klienci, a drugi klucz połączyć z ID tabeli Zamowienia.
C. wprowadzić pole klucza obcego do tabeli Zamowienia i powiązać je z ID tabeli Klienci.
D. powiązać relacją pola ID z obu tabel.
Tworzenie relacji jeden do wielu między tabelami w bazie danych wymaga zrozumienia, jak działa klucz podstawowy i klucz obcy. W tym przypadku tabela Klienci posiada pole ID, które jest kluczem podstawowym. Aby utworzyć relację jeden do wielu, należy dodać do tabeli Zamowienia pole klucza obcego, które będzie połączone z polem ID z tabeli Klienci. Dzięki temu każdy rekord w tabeli Zamowienia będzie mógł być przypisany do jednego klienta, ale jeden klient może mieć wiele zamówień. Taka struktura jest zgodna z normalizacją baz danych, która ma na celu eliminację redundancji danych i zapewnienie integralności danych. W praktyce, w systemach takich jak SQL, relacje te są wykorzystywane do wykonywania operacji takich jak wyszukiwanie wszystkich zamówień dla konkretnego klienta, co jest wykonywane przez dołączenie tabel za pomocą klucza obcego. Implementacja kluczy obcych w bazach danych jest standardową praktyką, która zwiększa spójność i bezpieczeństwo danych, minimalizując ryzyko błędów podczas operacji CRUD (Create Read Update Delete).
Pytanie 34

Każde informacje, które odnoszą się do innych informacji, określane są jako

A. metadata.
B. markup language.
C. databus.
D. metalanguage.
Odpowiedzi takie jak 'databus', 'metalanguage' oraz 'markup language' nie są odpowiednie w kontekście pytania o dane opisujące inne dane. Termin 'databus' odnosi się do architektury komunikacyjnej, która umożliwia przesyłanie danych pomiędzy różnymi aplikacjami lub systemami, ale nie odnosi się do opisu danych. 'Metalanguage' z kolei to język używany do opisu innego języka, co również nie pasuje do definicji metadanych. Użycie metalanguage może być przydatne w kontekście analizy języków programowania czy gramatyk formalnych, jednak nie wiąże się bezpośrednio z przekazywaniem informacji o danych. Z kolei 'markup language' odnosi się do języków znaczników, takich jak HTML czy XML, które służą do formatowania tekstu i strukturyzacji dokumentów, a nie do opisywania danych. Chociaż te języki mogą wykorzystywać metadane do opisu swojej struktury, same w sobie nie spełniają funkcji metadanych. Często mylnie uważa się, że wszystkie te terminy są ze sobą związane, jednak kluczowa różnica polega na tym, że metadane to informacje o danych, podczas gdy pozostałe odpowiedzi dotyczą różnych aspektów technologii informacyjnej i komunikacyjnej. Prawidłowe zrozumienie tych terminów jest kluczowe dla efektywnego zarządzania danymi oraz ich analizy w kontekście nowoczesnych rozwiązań IT.
Pytanie 35

Instrukcja zapisana w SQL, przedstawiona poniżej, ilustruje kwerendę:

UPDATE katalog SET katalog.cena = [cena]*1.1;
A. krzyżowej
B. dołączającej
C. aktualizującej
D. usuwającej
Odpowiedzi, które sugerują inne typy kwerend, są niepoprawne w kontekście przedstawionej instrukcji SQL. Kwerenda krzyżowa, znana również jako kwerenda CROSS JOIN, służy do łączenia wszystkich rekordów z dwóch lub więcej tabel, co nie ma związku z aktualizowaniem wartości w tabeli. Działania te są bardziej skomplikowane i nie mają zastosowania w kontekście zmiany wartości kolumn. Z kolei kwerenda usuwająca, czyli DELETE, służy do eliminacji rekordów z tabeli, co również nie odnosi się do sytuacji, w której zmieniamy wartości. Dodatkowo, kwerenda dołączająca, czyli INSERT, jest używana do dodawania nowych danych do tabeli, a nie do ich modyfikacji. Typowym błędem myślowym, który prowadzi do tych niepoprawnych wniosków, jest zrozumienie, że wszystkie operacje na danych w SQL są podobne. W rzeczywistości różne polecenia mają swoje specyficzne zastosowania i należy je stosować w odpowiednich kontekstach. Dlatego ważne jest, aby dokładnie rozumieć rodzaje kwerend SQL oraz ich przeznaczenie, co pozwala na efektywne zarządzanie danymi i uniknięcie nieporozumień w przyszłości.
Pytanie 36

Które z poniższych stwierdzeń na temat klucza głównego jest prawdziwe?

A. Składa się wyłącznie z jednego pola
B. Może przyjmować wyłącznie wartości liczbowe
C. Jest unikalny dla danej tabeli
D. W przypadku tabeli z danymi osobowymi może to być pole nazwisko
Wiele osób myli pojęcie klucza podstawowego z innymi właściwościami atrybutów w tabeli. Chociaż klucz podstawowy może składać się tylko z jednego pola, nie jest to warunek konieczny. Klucze podstawowe mogą również być złożone, co oznacza, że mogą składać się z wielu pól. Na przykład, w tabeli rejestrującej sprzedaż można wykorzystać kombinację kolumn takich jak 'ID produktu' i 'ID zamówienia' jako klucz podstawowy, co jest częstą praktyką w projektowaniu baz danych. Z kolei twierdzenie, że pole nazwisko może być kluczem podstawowym w tabeli danych osobowych, jest również problematyczne, ponieważ nazwiska mogą się powtarzać. W związku z tym, wybór atrybutów do klucza podstawowego powinien opierać się na ich unikalności oraz stabilności, a nie na ich powszechności. Ostatnia nieprawidłowa koncepcja sugeruje, że klucz podstawowy może przyjmować tylko wartości liczbowe, co jest wprowadzeniem w błąd. Klucz podstawowy może być zarówno liczbowy, jak i tekstowy; klucz identyfikujący użytkownika może zawierać np. adres e-mail, co jest także przykładem spójnego podejścia w projektowaniu baz danych. Typowe błędy myślowe prowadzące do takich wniosków to uproszczenia związane z rozumieniem właściwości atrybutów oraz zbyt wąskie podejście do koncepcji unikalności w kontekście baz danych.
Pytanie 37

Aby przesłać informacje za pomocą funkcji mysqli_query) w skrypcie PHP, który dodaje do bazy danych dane uzyskane z formularza na stronie internetowej, jako jeden z argumentów trzeba użyć kwerendy

A. INSERT INTO
B. ALTER
C. UPDATE
D. SELECT
Odpowiedzi takie jak 'UPDATE', 'SELECT' oraz 'ALTER' nie są odpowiednie w kontekście wstawiania nowych danych do bazy. Kwerenda 'UPDATE' służy do modyfikacji istniejących rekordów, co oznacza, że używając jej, zmieniamy już zapisane dane, a nie dodajemy nowe. Na przykład, użycie 'UPDATE uzytkownicy SET email = '[email protected]' WHERE imie = 'Jan'' zmienia adres e-mail Jana, ale nie wstawia nowych informacji. 'SELECT' z kolei jest używana do pobierania danych z bazy, co oznacza, że nie ma zastosowania w procesie dodawania nowych rekordów. W przypadku 'SELECT' moglibyśmy chcieć wyświetlić wszystkie dane użytkowników, co również nie wpisuje się w kontekst wstawiania. Natomiast 'ALTER' służy do zmiany struktury tabeli, co oznacza, że przy jej użyciu możemy dodawać lub usuwać kolumny, ale nie jest to bezpośrednio związane z wprowadzaniem nowych danych. Często niepoprawne zrozumienie działania kwerend SQL prowadzi do zamieszania, zwłaszcza w kontekście operacji CRUD (Create, Read, Update, Delete), gdzie każdy z tych terminów ma swoje ściśle określone znaczenie. Warto zatem przyswoić sobie podstawowe różnice między tymi kwerendami, aby móc skutecznie zarządzać danymi w bazie danych.
Pytanie 38

W tabeli personel znajdują się pola: imię, nazwisko, pensja, staż. Aby obliczyć średnią pensję osób zatrudnionych z doświadczeniem od 10 do 20 lat włącznie, należy przeprowadzić kwerendę:

A. SELECT AVG(pensja) FROM personel WHERE staz >= 10 AND staz <= 20
B. SELECT COUNT(pensja) FROM personel WHERE staz >= 10 AND staz <= 20
C. SELECT COUNT(*) FROM personel WHERE staz >= 10 AND staz <= 20
D. SELECT AVG(*) FROM personel WHERE staz >= 10 AND staz <= 20
Ta odpowiedź jest prawidłowa, ponieważ używa funkcji agregującej AVG, która oblicza średnią wartość z określonego pola, w tym przypadku pensji. Warunek WHERE zapewnia, że tylko pracownicy z stażem od 10 do 20 lat są brani pod uwagę w obliczeniach. Użycie funkcji AVG w kontekście SQL jest standardową praktyką, gdy chcemy uzyskać średnią z danych numerycznych. Na przykład, jeśli w tabeli mamy pracowników z różnymi pensjami, a chcemy zrozumieć, jak wygląda średnia wynagrodzeń w określonym przedziale stażu, to właśnie ta kwerenda dostarcza nam niezbędnej informacji. Dobre praktyki w analizie danych wskazują, że obliczenie średniej pensji jest kluczowe dla zarządzania zasobami ludzkimi i podejmowania decyzji dotyczących polityki wynagrodzeń. Przykładem może być sytuacja, gdy firma decyduje o podwyżkach lub bonusach, a analiza średniej pensji w danej grupie pracowników może znacząco wpłynąć na te decyzje.
Pytanie 39

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

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

Na zakończenie dnia w bazie danych sklepu spożywczego generowany jest raport, który pokazuje produkty wraz z ich dostawcami, dla których liczba sztuk w magazynie jest poniżej 10. Do stworzenia tego raportu użyto kwerendy

A. INSERT INTO
B. CHECK TABLE
C. SELECT
D. UPDATE
Wybór instrukcji UPDATE, INSERT INTO oraz CHECK TABLE jako metod do generowania raportu w bazie danych jest niepoprawny. Instrukcja UPDATE służy do modyfikacji istniejących danych w tabeli, co oznacza, że nie można jej użyć do wyświetlania informacji. Gdyby użytkownik spróbował użyć UPDATE do generowania raportu, mógłby nieumyślnie zmienić wartości w bazie danych, co jest sprzeczne z zamierzeniem uzyskania jedynie informacji. Z kolei INSERT INTO jest używane do dodawania nowych rekordów do bazy danych i również nie ma zastosowania w kontekście generowania raportów. Ta instrukcja nie tylko nie udostępnia żadnych informacji o istniejących danych, ale także może prowadzić do nieporozumień, gdyż wprowadza nowe dane zamiast ich przeszukiwać. Natomiast CHECK TABLE jest instrukcją używaną do sprawdzania integralności tabeli w bazie danych i nie ma związku z pobieraniem danych ani ich wyświetlaniem. Z tego powodu, wszystkie te trzy odpowiedzi są nieodpowiednie w kontekście tworzenia raportu w bazie danych, ponieważ każda z nich działa na zupełnie innych zasadach niż SELECT, który jest właściwym narzędziem do przeszukiwania i wyświetlania danych.
Rozpocznij nowy egzamin
Powrót do strony głównej