Wyniki egzaminu

Informacje o egzaminie:
  • Zawód: Technik informatyk
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 23 kwietnia 2026 13:36
  • Data zakończenia: 23 kwietnia 2026 14:08

Egzamin zdany!

Wynik: 20/40 punktów (50,0%)

Wymagane minimum: 20 punktów (50%)

Nowe
Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania
Pochwal się swoim wynikiem!
Szczegółowe wyniki:
Pytanie 1

Aby zoptymalizować operacje na bazie danych, należy stworzyć indeksy dla pól, które są często wyszukiwane lub sortowane?

A. stworzyć osobną tabelę przechowującą tylko te pola.
B. dodać klucz obcy.
C. utworzyć indeks.
D. dodać więzy integralności.
Dodawanie kluczy obcych ma na celu utrzymanie integralności danych oraz relacji między tabelami, co jest niezwykle ważne w przypadku baz danych złożonych z wielu tabel. Klucz obcy wskazuje na rekord w innej tabeli, co umożliwia zachowanie spójności danych, ale nie przyspiesza operacji wyszukiwania ani sortowania w obrębie pojedynczej tabeli. Bezpośrednio nie wpływa to na wydajność zapytań do tabeli, w której te klucze są zdefiniowane, ponieważ wciąż może być konieczne przeszukiwanie całej tabeli w celu znalezienia odpowiednich rekordów. Więzy integralności, takie jak unikalność czy niepustość kolumn, również służą do utrzymania spójności danych, ale nie przyspieszają operacji wyszukiwania. Są one narzędziem do zapewnienia, że dane są zgodne z określonymi regułami, co jest istotne, ale nie wpływa na wydajność zapytań. Stworzenie osobnej tabeli przechowującej tylko te pola mogłoby w pewnych okolicznościach pomóc w organizacji danych, jednak w praktyce wprowadziłoby to dodatkową złożoność w zarządzaniu relacjami oraz zapytaniami. Takie podejście może prowadzić do większej liczby operacji JOIN, co w dłuższym okresie może spowolnić operacje, zamiast je przyspieszyć. W rezultacie, wszystkie te metody mają swoje miejsce w architekturze baz danych, ale nie są odpowiednie w kontekście optymalizacji operacji wyszukiwania i sortowania na danych.

Pytanie 2

Do jakiego celu służy polecenie mysqldump?

A. sprawdzenia integralności bazy
B. optymalizacji bazy
C. naprawy niespójnej bazy
D. stworzenia kopii zapasowej bazy
Niektóre odpowiedzi mogą wydawać się na pierwszy rzut oka sensowne, jednak ich analiza pokazuje, że nie oddają one rzeczywistej funkcji mysqldump. Naprawa niespójnej bazy danych jest zadaniem, które wymaga zastosowania innych narzędzi, takich jak `myisamchk` dla silnika MyISAM lub `innodb_force_recovery` dla silnika InnoDB. Mysqldump nie zawiera mechanizmów naprawczych, więc jego użycie w tym kontekście jest błędne. Ponadto proces optymalizacji bazy danych, taki jak reorganizacja indeksów czy usuwanie nieużywanych danych, również nie jest domeną mysqldump, lecz narzędzi takich jak `OPTIMIZE TABLE` czy `ANALYZE TABLE`. Kolejnym błędnym podejściem jest sugestia, że mysqldump służy do sprawdzania integralności bazy danych. Integralność danych w bazach MySQL zapewniają różne mechanizmy, w tym transakcje, a także kontrola spójności danych na poziomie aplikacji. Mysqldump nie jest narzędziem do przeprowadzania walidacji danych ani analizy ich integralności, a skupić się powinien przede wszystkim na tworzeniu kopii zapasowych. W związku z tym, aby poprawnie zrozumieć zastosowanie mysqldump, warto wystrzegać się mylnych przekonań dotyczących jego funkcji, bazując na rzeczywistych możliwości tego narzędzia. Właściwe zrozumienie ról różnych narzędzi w ekosystemie baz danych jest kluczowe dla efektywnego zarządzania i ochrony danych.

Pytanie 3

Określ na podstawie diagramu, jaką liczebność należy zdefiniować przy związku pomiędzy encjami Podręcznik i Wydawnictwo zakładając, że dane dotyczące różnych podręczników odpowiadają jednemu wydawnictwu.

Ilustracja do pytania
A. 1-N (1 przy encji Podręcznik, N przy encji Wydawnictwo)
B. M-N (M przy encji Podręcznik, N przy encji Wydawnictwo)
C. N-1 (N przy encji Podręcznik, 1 przy encji Wydawnictwo)
D. 1-1 (1 przy encji Podręcznik, 1 przy encji Wydawnictwo)
Opisany w pytaniu związek jasno sugeruje sytuację, w której wiele różnych podręczników jest powiązanych z jednym wydawnictwem. To typowy przypadek relacji N–1, czyli wiele‑do‑jednego z punktu widzenia encji Podręcznik. Błędne odpowiedzi wynikają zwykle z pomylenia kierunku patrzenia na relację albo z prób „uogólnienia” modelu ponad to, co naprawdę wynika z założeń. Relacja 1–1 między Podręcznik a Wydawnictwo oznaczałaby, że każdemu wydawnictwu odpowiada dokładnie jeden podręcznik i odwrotnie. To kompletnie nie pasuje do realnego świata, gdzie wydawnictwa mają całe katalogi książek. W modelowaniu danych 1–1 stosuje się rzadko, raczej do technicznego dzielenia tabeli, a nie do takich typowo biznesowych bytów jak książka i wydawnictwo. Odpowiedź 1–N jest myląca, bo odwraca kierunek: oznaczałaby, że pojedynczy podręcznik jest powiązany z wieloma wydawnictwami. To byłby przypadek, gdzie ten sam egzemplarz podręcznika ma kilku wydawców jednocześnie, co jest sprzeczne z treścią zadania. Czasem ktoś myli tu pojęcie „wiele wydań w różnych wydawnictwach”, ale wtedy relacja i tak jest między wydaniem a wydawnictwem, a nie między jednym podręcznikiem a wieloma wydawnictwami w tym samym modelu. Z kolei M–N (lub M–N/M–N w różnych notacjach) opisuje sytuację, w której wiele podręczników może być powiązanych z wieloma wydawnictwami i wymagałaby dodatkowej tabeli asocjacyjnej. To podejście jest stosowane np. przy relacji Student–Przedmiot, ale tutaj zadanie wyraźnie mówi, że różne podręczniki „odpowiadają jednemu wydawnictwu”, więc nie ma podstaw do wprowadzania związku wiele‑do‑wielu. Typowy błąd myślowy polega na tym, że ktoś próbuje projektować „na zapas” i zakłada wszystkie możliwe warianty, zamiast trzymać się dokładnie specyfikacji i odróżniać kierunek relacji: z perspektywy podręcznika jest jeden wydawca, z perspektywy wydawnictwa jest wiele podręczników, stąd poprawne N–1.

Pytanie 4

W SQL przy użyciu kwerendy ALTER można

A. stworzyć tabelę
B. zmienić strukturę tabeli
C. dodać dane do tabeli
D. zlikwidować tabelę
Kwerenda SQL <i>ALTER</i> jest kluczowym narzędziem do modyfikacji istniejących struktur tabel w bazach danych. Umożliwia programistom dostosowanie tabel do zmieniających się wymagań aplikacji lub organizacji. Przykładowo, za pomocą polecenia <i>ALTER TABLE</i> możemy dodać nową kolumnę, usunąć istniejącą, zmienić typ danych kolumny czy również ustawić nowe ograniczenia, takie jak klucze obce. W praktyce, gdy firma rozwija swoje usługi, często zachodzi potrzeba dostosowania struktury bazy danych, co może być realizowane przez odpowiednie kwerendy <i>ALTER</i>. Dobrą praktyką jest również regularne przeglądanie i aktualizowanie struktury bazy danych, aby zapewnić optymalizację wydajności oraz zgodność z wymaganiami biznesowymi. Standard SQL, który definiuje te operacje, jest szeroko używany i uznawany za fundamentalny w pracy z relacyjnymi bazami danych. Znajomość kwerendy <i>ALTER</i> jest zatem niezbędna dla wszystkich, którzy zajmują się administracją baz danych i programowaniem aplikacji opartych na danych.

Pytanie 5

System baz danych gromadzi multimedia, co wiąże się z przechowywaniem znacznych ilości danych binarnych. Jakiego typu danych należy użyć w tym przypadku?

A. DOUBLE
B. BLOB
C. ENUM
D. LONGTEXT
Wybór innych typów danych, takich jak ENUM, DOUBLE czy LONGTEXT, do przechowywania danych multimedialnych jest nieodpowiedni z kilku powodów. ENUM jest typem danych służącym do przechowywania z góry zdefiniowanych wartości, co oznacza, że jego zastosowanie ogranicza się do małych zestawów danych, takich jak kategorie czy statusy, a nie do dużych, binarnych plików multimedialnych. Przykładowo, jeśli chcielibyśmy przechować obraz jako ENUM, napotkalibyśmy na problem z rozmiarem oraz elastycznością tego rozwiązania, co w praktyce byłoby nieefektywne. DOUBLE z kolei jest typem służącym do przechowywania liczb zmiennoprzecinkowych, co również nie ma zastosowania w kontekście danych binarnych, takich jak multimedia. Użycie DOUBLE do przechowywania plików audio czy wideo byłoby błędne, ponieważ nie jest on przystosowany do przechowywania danych binarnych, a jedynie do reprezentacji wartości numerycznych. LONGTEXT, mimo że może pomieścić dużą ilość danych tekstowych, również nie jest odpowiedni do przechowywania danych binarnych. Jest to typ przeznaczony do długich łańcuchów znaków, co nie pasuje do formatu plików multimedialnych, które wymagają innego podejścia. Użycie niewłaściwych typów danych w bazach danych może prowadzić do problemów z wydajnością, a także do trudności w zarządzaniu danymi. Dlatego ważne jest, aby dobrze rozumieć różnice między typami danych i ich zastosowaniem w praktyce, aby zapewnić optymalne przechowywanie i zarządzanie danymi w aplikacjach.

Pytanie 6

W bazach danych typ DECIMAL jest przeznaczony do przechowywania

A. danych napisowych o określonej długości.
B. liczb rzeczywistych zmiennoprzecinkowych.
C. liczb rzeczywistych stałoprzecinkowych.
D. liczb zapisanych w systemie binarnym.
W tym pytaniu łatwo się złapać na skojarzeniach z innymi typami danych, dlatego warto sobie to porządnie poukładać. Typ DECIMAL nie ma nic wspólnego z „liczbami zapisanymi w systemie binarnym” w takim sensie, w jakim często myśli się o typach zmiennoprzecinkowych. Oczywiście fizycznie wszystko i tak jest binarne, ale chodzi o model reprezentacji logicznej. Klasyczne typy zmiennoprzecinkowe (FLOAT, DOUBLE) trzymają wartość w formacie binarnym IEEE 754, co powoduje znane problemy z dokładnością, np. 0.1 + 0.2 ≠ 0.3 idealnie. DECIMAL jest zaprojektowany właśnie po to, żeby unikać tych błędów i zapewnić precyzyjną reprezentację dziesiętną z określoną liczbą miejsc po przecinku. Dlatego utożsamianie DECIMAL z „typem binarnym” albo ogólnie z „liczbami w systemie binarnym” to takie lekkie pomieszanie poziomów abstrakcji. Kolejna pułapka to traktowanie DECIMAL jako typu do przechowywania danych napisowych. Dane tekstowe o określonej długości trzymamy w typach CHAR(n) lub VARCHAR(n). One przechowują ciągi znaków, a nie wartości numeryczne, więc nie wykonamy na nich sensownie operacji arytmetycznych, agregacji typu SUM, AVG itp. Oczywiście czasem ktoś z lenistwa zapisuje np. kwoty jako VARCHAR, ale to jest sprzeczne z dobrymi praktykami projektowania schematu bazy i potem mści się przy raportach i walidacji. Częsty błąd myślowy polega też na wrzuceniu wszystkich „liczb z przecinkiem” do jednego worka i uznaniu, że to zawsze są liczby zmiennoprzecinkowe. W rzeczywistości w SQL rozróżniamy typy przybliżone (FLOAT, DOUBLE, REAL) i typy dokładne (DECIMAL, NUMERIC). Te pierwsze są dobre do obliczeń naukowych, pomiarów, gdzie dopuszczalne jest małe odchylenie, za to są szybsze i mniej pamięciożerne. Te drugie, stałoprzecinkowe, są stosowane tam, gdzie ważna jest bezwzględna poprawność wartości dziesiętnej, np. finanse, księgowość, rozliczenia magazynowe. Traktowanie DECIMAL jako „liczby rzeczywistej zmiennoprzecinkowej” zaciera tę bardzo ważną granicę. Z mojego doświadczenia w projektach komercyjnych wybór między DECIMAL a FLOAT/DOUBLE to jedno z kluczowych miejsc, gdzie początkujący projektanci baz popełniają błędy. Jeśli typ dobierzemy źle, to później pojawiają się trudne do wytłumaczenia różnice groszowe, błędne sumy w raportach, problemy z porównaniami w WHERE. Dlatego warto zapamiętać: DECIMAL to liczby rzeczywiste stałoprzecinkowe, z dokładnie określoną precyzją i skalą, a nie typ tekstowy ani przybliżony typ binarny.

Pytanie 7

Na podstawie tabeli Towar wykonano poniższe zapytanie SQL. Jaki będzie rezultat tej operacji?

SELECT nazwa_towaru
FROM`Towar`
WHERE cena_katalogowa<65
ORDER BY waga DESC
IDnazwa_towarucena_katalogowawagakolor
1Papier ksero A4112.3biel
2Zeszyt A54.20.13wielokolorowy
3Zeszyt A5 w linie3.50.12niebieski
4Kredki 24 kolory90.3wielokolorowy
5Plecak szkolny65.51.3zielony
A. Zeszyt A5, Zeszyt A5 w linie, Kredki 24 kolory, Papier ksero A4
B. Papier ksero A4, Kredki 24 kolory, Zeszyt A5 w linie, Zeszyt A5
C. Zeszyt A5 w linie, Zeszyt A5, Kredki 24 kolory, Papier ksero A4
D. Papier ksero A4, Kredki 24 kolory, Zeszyt A5, Zeszyt A5 w linie
Patrząc na błędne odpowiedzi, widzę, że poważnym błędem było niezrozumienie klauzuli WHERE oraz ORDER BY. Klauzula WHERE w SQL po prostu wyklucza towary z ceną 65 lub wyższą, co jest kluczowe, bo pozwala filtrować dane. Jak się to zignoruje, to produkt, który nie powinien się tam znaleźć, jak plecak szkolny, mógłby się pojawić. Co więcej, sporo osób myli sortowanie. ORDER BY waga DESC mówi nam, żeby sortować według wagi w kolejności malejącej. Niektórzy źle to interpretują, myśląc, że to jest w porządku rosnącym, albo całkowicie lekceważą wagę w sortowaniu. Wiedza o tym, jak działają te klauzule, jest ważna, gdy się pracuje z SQL. Trzeba zrozumieć, jak działa filtrowanie i sortowanie, bo to jest bazą pracy analityka danych i specjalisty od baz danych. W projektowaniu zapytań SQL każdy element powinien mieć swój cel i być dobrze zrozumiany, żeby pasował do logiki biznesowej i wymagań analizy danych.

Pytanie 8

W bazie danych księgarni znajduje się tabela ksiazki, która zawiera pola: id, idAutor, tytul, ileSprzedanych, oraz tabela autorzy z polami: id, imie, nazwisko. Jak można utworzyć raport sprzedanych książek zawierający tytuły oraz nazwiska autorów?

A. należy zdefiniować relację l..n pomiędzy tabelami ksiazki a autorzy, a następnie stworzyć kwerendę łączącą obie tabele
B. należy zdefiniować relację 1..1 pomiędzy tabelami ksiazki a autorzy, a następnie stworzyć kwerendę łączącą obie tabele
C. konieczne jest stworzenie kwerendy, która wyszukuje tytuły książek
D. trzeba utworzyć dwie oddzielne kwerendy: pierwsza do wyszukiwania tytułów książek, druga do wyszukiwania nazwisk autorów
Relacja l..n między tabelami 'ksiazki' i 'autorzy' jest naprawdę ważna. To oznacza, że jeden autor może napisać kilka książek, co jest całkiem normalne w świecie księgarni. Dzięki tej relacji, dla każdego 'idAutor' w tabeli 'ksiazki' możemy mieć wiele wpisów, co super ułatwia powiązanie tytułów z autorami. Jakbyś stworzył kwerendę, która łączy te obie tabele, to bez problemu uzyskasz dane, które jasno pokazują te relacje. Na przykład, taka kwerenda SQL mogłaby wyglądać tak: SELECT ksiazki.tytul, autorzy.nazwisko FROM ksiazki JOIN autorzy ON ksiazki.idAutor = autorzy.id; Taki sposób działania jest zgodny z normalizacją danych, co sprawia, że nasze bazy danych będą efektywne i dobrze zorganizowane.

Pytanie 9

Aby uzyskać dane z tabeli pracownicy wyłącznie dla osób, które osiągnęły 26 lat, należy zastosować zapytanie

A. SELECT * FROM pracownicy AND wiek > '25'
B. SELECT * FROM pracownicy WHERE wiek > '25'
C. SELECT * FROM pracownicy OR wiek > '25'
D. SELECT * FROM wiek WHERE pracownicy > '25'
Poprawne zapytanie to 'SELECT * FROM pracownicy WHERE wiek > '25';'. To zapytanie jest zgodne z zasadami SQL i pozwala na wyświetlenie wszystkich rekordów z tabeli 'pracownicy', które spełniają określony warunek dotyczący wieku. Używając klauzuli WHERE, precyzyjnie filtrujemy wyniki i zwracamy tylko tych pracowników, którzy mają więcej niż 25 lat. Warto pamiętać, że w SQL operator '>' jest wykorzystywany do porównywania wartości, a w tym przypadku pozwala nam na wybranie pracowników, którzy ukończyli 26 lat. Przy projektowaniu zapytań SQL, kluczowe jest stosowanie odpowiednich warunków filtrujących, aby ograniczyć zwracane dane do tych istotnych dla analiz. Przykładowo, analiza wieku pracowników w kontekście przyznawania dodatków lub przeprowadzania szkoleń może opierać się na takich zapytaniach. W praktyce, ważne jest także wykorzystanie indeksów w bazach danych, aby zwiększyć wydajność zapytań, zwłaszcza w dużych zbiorach danych.

Pytanie 10

Tworząc raport w systemie zarządzania relacyjnymi bazami danych, umożliwia się

A. dodawanie danych do tabel
B. usuwanie danych z tabel
C. aktualizowanie danych w tabelach
D. analizę wybranych danych
Analiza wybranych danych w systemie obsługi relacyjnych baz danych jest kluczowym aspektem raportowania. Umożliwia to zrozumienie wzorców i trendów, co jest niezbędne dla podejmowania świadomych decyzji biznesowych. Poprzez odpowiednie zapytania SQL, użytkownicy mogą selektywnie wybierać dane, które są dla nich istotne, a następnie przetwarzać je w celu generowania raportów. Przykładem może być analiza sprzedaży w danym okresie czasu, co pozwala na identyfikację najlepiej sprzedających się produktów. Praktyczne zastosowanie raportów obejmuje również monitoring efektywności działań marketingowych, co jest zgodne z najlepszymi praktykami w dziedzinie zarządzania danymi. W kontekście standardów branżowych, raportowanie powinno opierać się na zasadzie przejrzystości, co oznacza, że użytkownicy powinni mieć łatwy dostęp do zrozumiałych i czytelnych wyników analizy. Umożliwia to nie tylko identyfikację problemów, ale również wykorzystanie danych do prognozowania i planowania przyszłych działań.

Pytanie 11

Efektem wykonania kwerendy dla przedstawionej tabeli rezerwacje jest

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

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

Pytanie 12

Utworzono bazę danych zawierającą tabelę podzespoły, która składa się z pól: model, producent, typ, cena. Aby uzyskać listę wszystkich modeli pamięci RAM od firmy Kingston uporządkowaną według ceny, zaczynając od najniższej, należy wykorzystać zapytanie:

A. SELECT model FROM podzespoly WHERE typ="RAM" AND producent="Kingston" ORDER BY cena DESC
B. SELECT model FROM podzespoly WHERE typ="RAM" OR producent="Kingston" ORDER BY cena DESC
C. SELECT model FROM podzespoly WHERE typ="RAM" AND producent="Kingston" ORDER BY cena ASC
D. SELECT model FROM producent WHERE typ="RAM" OR producent="Kingston" ORDER BY podzespoly ASC
Wybór tej odpowiedzi jest prawidłowy, ponieważ kwerenda wykorzystuje poprawną składnię SQL do wyboru modeli pamięci RAM od producenta Kingston. Klauzula WHERE filtruje rekordy, aby uwzględnić tylko te, które mają typ 'RAM' oraz producenta 'Kingston', co jest kluczowe dla uzyskania właściwych wyników. Użycie operatora AND w tym kontekście zapewnia, że obie te cechy muszą być spełnione, co jest zgodne z zamiarem wyświetlenia wszystkich modeli pamięci RAM tego producenta. Dodatkowo, klauzula ORDER BY cena ASC sortuje wyniki w kolejności rosnącej według ceny, co jest wymagane do poprawnego przedstawienia danych od najtańszej do najdroższej pamięci. Takie podejście jest zgodne z dobrymi praktykami SQL, gdzie precyzyjne filtrowanie danych i porządkowanie wyników są kluczowe dla efektywności i dokładności zapytań. W praktyce, takie kwerendy mogą być używane w aplikacjach do zarządzania produktami czy bazach danych e-commerce, aby pomóc użytkownikom w szybkim odnajdywaniu pożądanych produktów w oparciu o konkretne kryteria.

Pytanie 13

W SQL wykonano poniższe instrukcje GRANT. Kto będzie miał prawa do przeglądania oraz modyfikacji danych?

GRANT ALL ON firmy TO 'admin'@'localhost';
GRANT ALTER, CREATE, DROP ON firmy TO 'anna'@'localhost';
GRANT SELECT, INSERT, UPDATE ON firmy TO 'tomasz'@'localhost';
A. Tomasz i Anna
B. Adam i Anna
C. Tylko Tomasz
D. Tomasz i Adam
Prawidłowa odpowiedź to Tylko Tomasz ponieważ polecenie GRANT SELECT INSERT UPDATE ON firmy TO 'tomasz'@'localhost' przyznaje Tomaszowi uprawnienia do przeglądania danych i ich zmiany w bazie danych firmy. Uprawnienia SELECT INSERT i UPDATE są wystarczające do przeglądania i modyfikowania danych. SELECT pozwala na odczyt danych z tabeli INSERT umożliwia dodawanie nowych rekordów a UPDATE pozwala na modyfikację istniejących danych. To przyznaje Tomaszowi pełną kontrolę nad przeglądaniem i aktualizacją danych. Inni użytkownicy jak Anna czy Adam nie posiadają wszystkich tych uprawnień. Anna ma jedynie uprawnienia ALTER CREATE i DROP co pozwala na zmianę struktury bazy danych ale nie na przeglądanie i edytowanie danych. Zrozumienie tych różnic jest kluczowe w administracji bazami danych gdyż precyzyjne zarządzanie uprawnieniami użytkowników zapewnia bezpieczeństwo danych i efektywność działania systemu. Tomasz dzięki przyznanym uprawnieniom może efektywnie zarządzać danymi co jest ważnym aspektem w kontekście zarządzania bazami danych w organizacji.

Pytanie 14

Fragment kwerendy SQL zaprezentowany w ramce ma na celu uzyskanie

SELECT COUNT(wartosc) FROM ...
A. liczbę wierszy.
B. sumę wartości w kolumnie wartosc.
C. liczbę kolumn.
D. średnią wartość w kolumnie wartosc.
SELECT COUNT(wartosc) w zapytaniu SQL jest często mylone z innymi funkcjami agregującymi, co może prowadzić do nieporozumień dotyczących jego działania. COUNT jest specyficznie zaprojektowany do zliczania niepustych wartości w określonej kolumnie, dlatego nie jest używany do obliczania sumy czy średniej wartości. Suma w kolumnie wartosc wymagałaby użycia funkcji SUM(wartosc), która zlicza wartości liczbowe. Z kolei obliczanie średniej wartości w kolumnie wymagałoby zastosowania funkcji AVG(wartosc), która dzieli sumę wartości przez liczbę niepustych wierszy. Mylenie tych funkcji może prowadzić do błędnych interpretacji danych i niepoprawnych wyników, co jest kluczowe w środowisku biznesowym, gdzie precyzja i dokładność są niezbędne. Warto zauważyć, że zrozumienie różnic w działaniu funkcji agregujących jest fundamentalne dla efektywnej analizy danych. Stosowanie odpowiednich funkcji pozwala na optymalizację zapytań oraz zapewnia, że uzyskane wyniki są zgodne z oczekiwaniami analitycznymi, co jest kluczowe w podejmowaniu decyzji opartych na danych.

Pytanie 15

W SQL, aby usunąć wszystkie rekordy z tabeli, ale zachować jej strukturę, należy użyć polecenia:

A. DROP TABLE
B. TRUNCATE
C. REMOVE
D. DELETE FROM
Istnieje kilka nieporozumień związanych z usuwaniem danych z tabel SQL, co może prowadzić do błędów. Polecenie <code>DROP TABLE</code> jest często mylone z <code>DELETE FROM</code>. Jednak <code>DROP TABLE</code> usuwa zarówno dane, jak i strukturę tabeli, co oznacza, że po jego użyciu nie będzie można odzyskać tabeli bez jej ponownego stworzenia. To polecenie jest destrukcyjne i powinno być używane tylko wtedy, gdy mamy pewność, że tabela nie jest już potrzebna. Z kolei <code>REMOVE</code> nie jest poprawnym poleceniem SQL. To może wynikać z mylnego przekonania, że istnieje takie polecenie w języku SQL, jednak w rzeczywistości nie jest ono częścią standardu SQL. Tego typu błędy wynikają często z nieznajomości składni SQL lub mylenia z innymi językami programowania, które mogą mieć podobne polecenia. Na koniec, <code>ERASE TABLE</code> również nie jest poprawnym poleceniem SQL. Może to być wynikiem intuicyjnego podejścia do nazewnictwa poleceń, ale w rzeczywistości SQL posługuje się innymi komendami. Kluczowe jest, by dobrze zrozumieć standardy języka SQL i znać właściwe polecenia dla zamierzonych operacji, aby uniknąć potencjalnie destrukcyjnych działań na bazie danych.

Pytanie 16

Dane są zapisy w tabeli uczniowie, które zostały przedstawione na rysunku. Jaki będzie rezultat wykonania podanego zapytania SQL?

Ilustracja do pytania
A. Wartość 3.5
B. Liczba wierszy równa 4
C. Dane 4, 3, 4, 3
D. Suma ocen równa 14
Zapytanie SQL SELECT AVG(ocena) FROM uczniowie ma na celu obliczenie średniej wartości kolumny ocena w tabeli uczniowie. Średnia arytmetyczna jest obliczana poprzez zsumowanie wszystkich ocen i podzielenie wyniku przez liczbę rekordów. W tym przypadku mamy cztery oceny: 4 3 4 i 3. Suma tych ocen wynosi 14 a liczba rekordów to 4 co daje średnią arytmetyczną równą 3.5. W przypadku baz danych funkcja AVG() jest standardowym sposobem na obliczanie średniej wartości w zestawie danych i jest powszechnie używana w analizie danych gdzie często zachodzi potrzeba określenia centralnej tendencji. Takie podejście pozwala na szybką ocenę ogólnej wydajności lub trendów w zbiorze danych. Praktyczne zastosowanie tego mechanizmu obejmuje analizy biznesowe gdzie przeciętna wartość sprzedaży lub innych metryk może dostarczyć cennych informacji. Warto również podkreślić że AVG() ignoruje wartości NULL co jest korzystne w analizie zestawów danych o niepełnych wpisach.

Pytanie 17

Wskaż PRAWIDŁOWE stwierdzenie dotyczące polecenia: CREATE TABLE IF NOT EXISTS ADRES(ulica VARCHAR(70) CHARACTER SET utf8);

A. Rekordem tabeli nie może być 3 MAJA
B. IF NOT EXISTS jest stosowane opcjonalnie, aby upewnić się, że tabela nie istnieje już w bazie danych
C. Klauzula CHARACTER SET utf8 jest wymagana
D. Do tabeli nie można wprowadzać ulic, które zawierają w nazwie polskie znaki
Stwierdzenie, że 'IF NOT EXISTS' stosuje się opcjonalnie, aby upewnić się, że brak w bazie danych takiej tabeli, jest jak najbardziej prawdziwe. Klauzula ta jest używana w kontekście tworzenia tabel, aby uniknąć błędu, który wystąpiłby, gdyby tabela o tej samej nazwie już istniała. Dzięki temu programista może mieć pewność, że operacja tworzenia tabeli przebiegnie pomyślnie, bez konieczności wcześniejszego sprawdzania, czy tabela już istnieje. Przykładowo, w praktyce programistycznej, podczas automatyzacji skryptów do zarządzania bazami danych, często wykorzystuje się tę klauzulę, aby zapewnić, że skrypty są odporne na błędy wynikające z istniejących obiektów. Jest to zgodne z dobrymi praktykami w programowaniu baz danych, które koncentrują się na minimalizowaniu ryzyka i poprawie efektywności pracy.

Pytanie 18

Tabela Pracownicy zawiera informacje o zatrudnionych w różnych działach, co jest określone przez pole liczbowe dzial. Z uwagi na to, że zazwyczaj wykonuje się kwerendy jedynie dla działu równego 2, można uprościć zapytania do tej tabeli, tworząc wirtualną tabelę o nazwie Prac_dzial2 przy użyciu zapytania

A. VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2
B. CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2
C. CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2
D. VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2
Odpowiedź 'CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2;' jest poprawna, ponieważ syntaktycznie i semantycznie odnosi się do standardów SQL używanych do tworzenia widoków. Komenda 'CREATE VIEW' służy do zdefiniowania wirtualnej tabeli, która agreguje dane według określonych kryteriów. W tym przypadku, widok 'Prac_dzial2' wyciąga wszystkie rekordy z tabeli 'Pracownicy', które spełniają warunek, że wartość pola 'dzial' wynosi 2. Używanie widoków jest praktyką zalecaną, ponieważ pozwala na uproszczenie złożonych zapytań oraz zabezpiecza przed niepożądanym dostępem do danych. Dzięki temu, użytkownicy mogą łatwiej filtrować dane, co zwiększa wydajność zapytań i poprawia organizację kodu. Widoki są także korzystne w kontekście zarządzania danymi, ponieważ mogą być zaktualizowane, a ich struktura może być zmieniana w zależności od potrzeb użytkownika, co czyni je elastycznym narzędziem w bazach danych.

Pytanie 19

Aby zmienić strukturę tabeli w bazie danych MySQL, należy użyć komendy

A. UPDATE
B. INSERT INTO
C. GRANT
D. ALTER TABLE
Odpowiedź 'ALTER TABLE' jest poprawna, gdyż to polecenie w MySQL służy do modyfikacji struktury istniejącej tabeli. Dzięki niemu możemy dodawać nowe kolumny, zmieniać typy danych kolumn, usuwać kolumny, a także zmieniać właściwości tabeli, takie jak klucze główne czy unikalne. Przykład zastosowania polecenia ALTER TABLE to dodanie kolumny do tabeli: 'ALTER TABLE pracownicy ADD COLUMN wiek INT;' co skutkuje dodaniem kolumny 'wiek' o typie INT do tabeli 'pracownicy'. Zgodnie z najlepszymi praktykami, przed wykonaniem takich operacji warto wykonać kopię zapasową bazy danych, aby uniknąć utraty danych w przypadku nieprawidłowego wykonania polecenia. Używanie ALTER TABLE jest kluczowe podczas rozwoju aplikacji, gdyż często zachodzi potrzeba dostosowania struktury bazy danych do zmieniających się wymagań biznesowych.

Pytanie 20

ALTER TABLE artykuły MODIFY cena float; Ta kwerenda ma na celu wprowadzenie zmian w tabeli artykuły.

A. zmiana typu na float dla kolumny cena
B. dodanie kolumny cena o typie float, o ile nie istnieje
C. usunięcie kolumny cena o typie float
D. zmiana nazwy kolumny cena na float
Odpowiedź była trafna, bo dotyczyła zmiany typu danych w kolumnie w tabeli. Kiedy piszesz 'ALTER TABLE artykuły MODIFY cena float;', to tak naprawdę modyfikujesz kolumnę 'cena', żeby mogła przyjmować liczby zmiennoprzecinkowe. Używanie typu float jest naprawdę przydatne, gdyż ceny często mają wartości z przecinkiem, więc nie ma sensu tego trzymać w innym formacie. Z mojego doświadczenia, takie zmiany są ważne, bo pomagają w dokładnym przechowywaniu danych, co jest kluczowe w przy aplikacjach związanych z finansami czy sprzedażą online. Ale pamiętaj, że warto zawsze mieć kopię zapasową, bo jeśli masz już jakieś dane, które się nie zmieszczą w nowym typie, to może być kłopot. Generalnie, używanie 'ALTER TABLE' to podstawowa rzecz w zarządzaniu bazami danych i dobrze wiedzieć, co się robi.

Pytanie 21

Na tabeli muzyka, przedstawionej na schemacie, wykonano następującą kwerendę SQL. Co zostanie zwrócone przez tę zapytanie? SELECT wykonawca FROM `muzyka` WHERE wykonawca LIKE 'C%w';

Ilustracja do pytania
A. pusty wynik
B. Czesław
C. Czesław, Niemen
D. Czesław, Czechowski
Odpowiedź 'pusty wynik' jest poprawna, ponieważ zapytanie SQL 'SELECT wykonawca FROM `muzyka` WHERE wykonawca LIKE 'C%w';' poszukuje wykonawców, których imię i nazwisko zaczynają się na literę 'C' i kończą na literę 'w'. Operator LIKE w SQL używany jest do wyszukiwania wzorców w tekstach, gdzie '%' zastępuje dowolną liczbę znaków. W tabeli muzyka nie ma żadnego wykonawcy, którego imię i nazwisko pasowałoby do tego wzorca. Oba wystąpienia 'Czesław Niemen' i 'Mikołaj Czechowski' nie spełniają warunku, ponieważ ich nazwiska nie kończą się na 'w'. SQL jest powszechnie stosowany w zarządzaniu bazami danych, a zrozumienie, jak używać wyrażeń LIKE, jest kluczowe w efektywnej pracy z danymi. Praktyczne zastosowanie tej wiedzy obejmuje filtrowanie danych w raportach, ekstrakcję specyficznych informacji oraz poprawę wydajności zapytań przy użyciu indeksów. Warto zwrócić uwagę na optymalizację zapytań pod kątem wydajności, co jest szczególnie ważne w przypadku dużych zbiorów danych. Operator LIKE może mieć wpływ na wydajność, dlatego zaleca się użycie pełnotekstowych indeksów, jeśli to możliwe, w bardziej złożonych scenariuszach. Umiejętność tworzenia precyzyjnych zapytań SQL jest kluczowa w branży IT, zwłaszcza w analizie danych i administracji bazami danych. Efektywne zastosowanie tej techniki pozwala na szybkie i skuteczne wyszukiwanie informacji w dużych zbiorach danych, co jest nieocenione w wielu zastosowaniach biznesowych i technologicznych.

Pytanie 22

Klucz obcy w tabeli jest używany w celu

A. połączenia go z innymi kluczami obcymi w tabeli
B. umożliwienia jednoznacznej identyfikacji rekordu w danej tabeli
C. opracowania formularza do wprowadzania danych do tabeli
D. zdefiniowania relacji 1..n łączącej go z kluczem głównym innej tabeli
Klucz obcy w tabeli pełni kluczową rolę w definiowaniu relacji między tabelami w bazach danych. Dzięki zastosowaniu klucza obcego możliwe jest określenie relacji 1..n, co oznacza, że jeden rekord w tabeli głównej może być powiązany z wieloma rekordami w tabeli podrzędnej. Przykładem może być tabela 'Klienci' i tabela 'Zamówienia', gdzie klucz obcy w tabeli 'Zamówienia' wskazuje na klucz główny w tabeli 'Klienci'. To pozwala na gromadzenie wielu zamówień dla jednego klienta, co jest niezbędne w systemach e-commerce. Praktyczne wdrożenie kluczy obcych wspiera integralność danych oraz zapobiega ich duplikacji. Właściwe projektowanie relacji w bazach danych zgodnie z zasadami normalizacji wprowadza przejrzystość i efektywność w zarządzaniu danymi, a także ułatwia ich późniejszą analizę i raportowanie. W branży IT standardem jest stosowanie kluczy obcych w celu zapewnienia spójności i relacyjności danych, co jest istotne dla każdej aplikacji opierającej się na bazach danych.

Pytanie 23

Aby zapewnić integralność danych w bazie programu Microsoft Access, należy zastosować

A. defragmentację bazy
B. więzy integralności
C. archiwizację bazy
D. kwerendę aktualizującą
Wybór więzów integralności jako metody zapewnienia spójności danych w programie Microsoft Access jest właściwy, ponieważ więzy te definiują zasady, które muszą być spełnione w bazie danych, aby utrzymać spójność i poprawność danych. Przykładowo, można ustawić więzy integralności, które zapobiegają wprowadzeniu duplikatów w kluczowych polach, takich jak identyfikator klienta, co jest kluczowe dla unikania konflikty i błędów w analityce danych. Więzy integralności mogą obejmować takie elementy jak klucze główne, klucze obce oraz unikalne ograniczenia, które pomagają w zachowaniu logiki relacyjnej w bazie danych. Dobrą praktyką jest regularne przeglądanie i aktualizowanie więzów integralności, aby zapewnić ich adekwatność do zmieniających się potrzeb danych. Ponadto, w sytuacjach, gdy dane są wprowadzane przez wiele źródeł, więzy integralności stają się kluczowym narzędziem w zarządzaniu jakością i spójnością danych, co jest zgodne z najlepszymi praktykami w zakresie zarządzania danymi.

Pytanie 24

W systemie zarządzania bazą danych MySQL, aby uzyskać listę wszystkich przywilejów przyznanych użytkownikowi anna, można użyć polecenia

A. REVOKE GRANTS FROM anna;
B. SHOW GRANTS FOR anna;
C. SELECT GRANTS FOR anna;
D. GRANT * TO anna;
Odpowiedzi 1, 2 i 3 są nietrafione, bo nie odpowiadają na pytanie o to, jak zobaczyć przydzielone uprawnienia dla użytkownika 'anna'. Pierwsza opcja, 'SELECT GRANTS FOR anna;', jest błędna, bo w MySQL nie ma takiej składni do zdobywania informacji o uprawnieniach. Możliwe, że po prostu pomyliłeś, bo SELECT kojarzy się z pozyskiwaniem danych, ale nie o uprawnieniach. Druga opcja, 'REVOKE GRANTS FROM anna;', też jest niepoprawna, bo REVOKE służy do odbierania uprawnień, a nie ich wyświetlania. Niektórzy mogą myśleć, że odbieranie uprawnień w jakiś sposób pokaże, co wcześniej przyznano, ale to zupełnie coś innego. Trzecia odpowiedź, 'GRANT * TO anna;', sugeruje przyznawanie uprawnień zamiast ich wyświetlania. Użytkownicy mogą myśleć, że znak '*' oznacza wszystkie możliwe uprawnienia, co może prowadzić do niebezpiecznych sytuacji, jeżeli uprawnienia są nadawane bez głębszej analizy. Dlatego zarządzanie uprawnieniami jest mega ważne dla bezpieczeństwa bazy danych, a zrozumienie, jak różne polecenia działają, jest kluczowe.

Pytanie 25

W języku SQL, aby wstawić wiersz danych do tabeli w bazie danych, należy zastosować polecenie

A. SELECT ROW
B. INSERT INTO
C. CREATE ROW
D. CREATE INTO
Poprawną składnią do wstawiania nowych wierszy w SQL jest polecenie INSERT INTO i to jest taki absolutny fundament pracy z bazą danych. Standard SQL (ANSI/ISO) definiuje właśnie tę komendę jako podstawowy mechanizm dodawania rekordów do tabeli. Typowy zapis wygląda na przykład tak: INSERT INTO klienci (imie, nazwisko, email) VALUES ('Jan', 'Kowalski', '[email protected]');. Najpierw podajemy nazwę tabeli, potem listę kolumn, a następnie wartości w dokładnie tej samej kolejności. W praktyce, w aplikacjach webowych, to właśnie INSERT INTO stoi za dodawaniem nowych użytkowników, zamówień, wpisów na blogu czy logów systemowych. Moim zdaniem warto od razu wyrabiać sobie dobre nawyki: zawsze jawnie wypisuj nazwy kolumn, zamiast polegać na kolejności kolumn w tabeli. Dzięki temu, jeśli ktoś kiedyś doda nową kolumnę albo zmieni ich układ, Twoje zapytania dalej będą działały poprawnie. Jest też drugi, często używany wariant: INSERT INTO tabela VALUES (...), ale on jest bezpieczny tylko wtedy, gdy dokładnie kontrolujesz strukturę tabeli. INSERT INTO może też współpracować z SELECT, np. do masowego kopiowania danych: INSERT INTO archiwum_zamowien SELECT * FROM zamowienia WHERE data < '2023-01-01';. W systemach produkcyjnych łączy się tę komendę z transakcjami (BEGIN, COMMIT, ROLLBACK), żeby zapewnić spójność danych. Warto pamiętać, że różne silniki (MySQL, PostgreSQL, SQL Server) mają swoje rozszerzenia, ale sama idea INSERT INTO jest wspólna i zgodna ze standardem. To takie must-have dla każdego, kto poważnie myśli o pracy z bazami danych.

Pytanie 26

Jakie słowo kluczowe w języku SQL należy zastosować, aby usunąć powtarzające się rekordy?

A. ORDER BY
B. GROUP BY
C. LIKE
D. DISTINCT
Słowo DISTINCT w SQL to taki sprytny sposób na pozbycie się duplikatów w wynikach zapytań. Jak robisz zapytanie SELECT, które zwraca różne wiersze, to dzięki DISTINCT dostaniesz tylko unikalne wartości w kolumnach, które wybierzesz. Na przykład, mając tabelę 'pracownicy' z kolumną 'miasto', jak użyjesz zapytania 'SELECT DISTINCT miasto FROM pracownicy;', to dostaniesz listę wszystkich miast, w których są pracownicy, a powtórzenia polecą w odstawkę. Warto pamiętać, że DISTINCT działa na całej kombinacji kolumn, które zwracasz. Jak dodasz więcej kolumn w zapytaniu, to SQL wyciągnie unikalne zestawienia tych kolumn. To naprawdę przydatne, zwłaszcza przy dużych zbiorach danych, gdzie duplikaty mogą namieszać w analizach i raportach. DISTINCT jest standardowym elementem w SQL i działa praktycznie w każdym systemie zarządzania bazami danych, jak MySQL czy PostgreSQL, co czyni to narzędzie mega uniwersalnym w codziennym grzebaniu w danych.

Pytanie 27

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

SELECT MAX(wiek) - MIN(wiek) FROM uczestnicy;
A. średnią wartość wieku uczestników
B. ilość najstarszych uczestników
C. różnicę wieku pomiędzy najstarszym a najmłodszym uczestnikiem
D. najmłodszy i najstarszy wiek 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 28

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

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

Pytanie 29

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. wprowadzić pole klucza obcego do tabeli Zamowienia i powiązać je z ID tabeli Klienci.
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. powiązać relacją pola ID z obu tabel.
D. dodać pole klucza obcego do tabeli Klienci i powiązać je z ID tabeli Zamowienia.
Zrozumienie, dlaczego inne podejścia do tworzenia relacji jeden do wielu są błędne, wymaga wyjaśnienia działania kluczy podstawowych i obcych. Połączenie pól ID z obu tabel nie tworzy poprawnej relacji jeden do wielu, ponieważ nie definiuje, które pole służy jako klucz obcy. Tego typu połączenie może prowadzić do niejednoznaczności i problemów z integralnością danych. Dodanie klucza obcego do tabeli Klienci i połączenie go z ID tabeli Zamowienia również nie jest prawidłowe, ponieważ przeczyłoby to logice relacji jeden do wielu, gdzie jeden klient może mieć wiele zamówień, a nie odwrotnie. W praktyce takie podejście mogłoby prowadzić do powielania danych w tabeli Klienci i komplikacji przy zarządzaniu danymi. Zdefiniowanie trzeciej tabeli z dwoma kluczami obcymi jest podejściem stosowanym przy relacjach wiele do wielu, a nie jeden do wielu, jak w tym przypadku. Takie rozwiązanie byłoby nieefektywne w tej sytuacji i niepotrzebnie skomplikowałoby strukturę bazy danych. Poprawne zrozumienie tych koncepcji jest kluczowe dla projektowania wydajnych i spójnych systemów baz danych, zgodnych z zasadami normalizacji i dobrych praktyk inżynierii danych.

Pytanie 30

W tabeli Recepta, kolumny Imie i Nazwisko odnoszą się do pacjenta, na którego wystawiona jest recepta. Jaką kwerendę należy wykorzystać, aby dla każdej recepty uzyskać datę jej wystawienia oraz imię i nazwisko lekarza, który ją wystawił?

Ilustracja do pytania
A. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta
B. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id
C. SELECT Imie, Nazwisko, DataWystawienia FROM Recepta
D. SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id
Błędne odpowiedzi wynikają z nieprawidłowego zrozumienia struktury relacyjnej baz danych i mechanizmu łączenia tabel. W przypadku odpowiedzi pierwszej, kwerenda SELECT Imie, Nazwisko, DataWystawienia FROM Recepta; pobiera dane o pacjencie, a nie o lekarzu, ponieważ kolumny Imie i Nazwisko w tabeli Recepta odnoszą się do pacjenta. Chociaż uzyskujemy datę wystawienia recepty, brakuje kluczowej informacji o lekarzu wystawiającym. Odpowiedź druga, SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta;, jest błędna, ponieważ nie zawiera mechanizmu JOIN, który jest niezbędny do połączenia danych z tabeli Recepta z tabelą Lekarz. Bez tego połączenia próba odwołania się do kolumn z tabeli Lekarz zakończy się błędem. Odpowiedź trzecia, SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id;, również nie spełnia wymagań, ponieważ pobiera tylko imię pacjenta (co jest nieprawidłowe), a nie informacje o lekarzu. Podstawowym błędem w tych odpowiedziach jest brak zrozumienia relacji między tabelami oraz poprawnego zastosowania kluczy, co jest kluczowe w pracy z relacyjnymi bazami danych. Zrozumienie mechanizmu JOIN i prawidłowego odniesienia się do kolumn w różnych tabelach jest fundamentem efektywnego projektowania i wykorzystywania baz danych.

Pytanie 31

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

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

Pytanie 32

Element bazy danych, którego podstawowym celem jest generowanie lub prezentowanie zestawień informacji, to

A. moduł
B. makro
C. raport
D. formularz
Makro w bazach danych to trochę inna historia. To służy do automatyzacji, żeby szybko zrobić skomplikowane rzeczy, a nie do prezentacji danych. W sumie, to w ogóle nie jest to, czego szukamy w tym pytaniu. Moduł to z kolei po prostu fragment kodu, który robi coś określonego w bazach danych. Ale znowu, on nie służy do pokazywania danych. Moim zdaniem, moduły są ważne do rozwijania funkcji aplikacji, ale nie mają nic wspólnego z wizualizacją. Formularz to narzędzie do wprowadzania danych i edytowania ich, co jest istotne, ale też nie pozwala na drukowanie czy pokazywanie zestawień. Tak ogólnie, makra, moduły i formularze mają różne zastosowania, które nie dotyczą raportów, które są stworzone właśnie do analizy i prezentacji danych.

Pytanie 33

Aby przywrócić bazę danych o nazwie Sklep z pliku towary.sql, należy w miejsce gwiazdek wpisać nazwę użytkownika. Polecenie wygląda następująco:

mysql -u ******* -p Sklep < towary.sql
A. liczbę importowanych obiektów bazy.
B. nazwę odzyskiwanej tabeli.
C. adres IP bazy danych.
D. nazwę użytkownika.
Polecenie mysql ma dość sztywną i dobrze udokumentowaną składnię, więc warto ją sobie poukładać raz a dobrze. W przedstawionym przykładzie mamy: mysql -u ******* -p Sklep < towary.sql. Przełącznik -u w kliencie MySQL zawsze oznacza nazwę użytkownika, czyli konto w systemie bazy danych, którym się logujemy. To nie jest ani adres IP, ani nazwa tabeli, ani żadna liczba obiektów. Klient mysql w ogóle nie przyjmuje w tym miejscu takich danych. Częsty błąd polega na mieszaniu pojęć: adres IP czy hostname serwera bazy podaje się inną opcją, -h (np. -h 192.168.1.10 lub -h db.example.com). Parametr -u nie ma nic wspólnego z lokalizacją serwera, tylko z tożsamością użytkownika w systemie uprawnień MySQL. Podobnie nazwa odzyskiwanej tabeli nie jest nigdzie wpisywana w linii poleceń mysql przy imporcie. Tabele są tworzone i wypełniane wewnątrz pliku SQL – to tam znajdują się instrukcje CREATE TABLE i INSERT, więc nie ma potrzeby ani możliwości podania nazwy jednej konkretnej tabeli w miejscu, gdzie klient oczekuje nazwy użytkownika. Jeśli importujemy tylko jedną tabelę, to i tak cały proces kontroluje zawartość pliku towary.sql, a nie argument -u. Równie mylące jest myślenie o „liczbie importowanych obiektów bazy”. Narzędzie mysql nie ma opcji, w której wpisujemy jakąś liczbę tabel czy rekordów do zaimportowania. Importuje po prostu wszystko, co jest w skrypcie SQL, aż do końca pliku lub do wystąpienia błędu. Właściwy sposób myślenia jest taki: -h mówi „do jakiego serwera się łączę”, -u mówi „kim się loguję”, -p wymusza podanie hasła, dalej podajemy nazwę bazy (Sklep), a znak < przekierowuje zawartość pliku towary.sql na wejście programu. Z mojego doświadczenia wynika, że jak się raz zrozumie to rozdzielenie ról poszczególnych parametrów, to znika większość nieporozumień przy pracy z kopią zapasową i przywracaniem baz danych.

Pytanie 34

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

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

Pytanie 35

Jakie zapytanie należy zastosować, aby pokazać tylko imię, nazwisko oraz ulicę wszystkich mieszkańców?

Ilustracja do pytania
A. SELECT * FROM Mieszkancy, Adresy ON Mieszkancy.id = Adresy.id
B. SELECT * FROM Mieszkancy JOIN Adresy ON Adresy.id = Mieszkancy.Adresy.id
C. SELECT imie, nazwisko, ulica FROM Mieszkancy, Adresy ON Mieszkancy.Adresy_id = Adresy.id
D. SELECT imie, nazwisko, ulica FROM Mieszkancy JOIN Adresy ON Mieszkancy.Adresy_id = Adresy.id
Prawidłowa odpowiedź wykorzystuje funkcję JOIN, aby połączyć tabele Mieszkancy i Adresy na podstawie wspólnego klucza, czyli Adresy_id z tabeli Mieszkancy i id z tabeli Adresy. Takie podejście jest zgodne z dobrymi praktykami baz danych, ponieważ zapewnia, że tylko powiązane wiersze są zwracane w wyniku. W zapytaniu SELECT imie, nazwisko, ulica FROM Mieszkancy JOIN Adresy ON Mieszkancy.Adresy_id = Adresy.id jasno określamy, że chcemy wyciągnąć tylko kolumny imie, nazwisko oraz ulica, co minimalizuje ilość przetwarzanych danych, a co za tym idzie, zwiększa wydajność. W rzeczywistych scenariuszach, takie zapytania są kluczowe w aplikacjach, gdzie konieczne jest uzyskanie pełnych danych dotyczących mieszkańców i ich adresów bez zbędnych informacji. Dobre praktyki SQL sugerują, aby zawsze wybierać tylko te kolumny, które są potrzebne, co pomaga w optymalizacji zasobów serwera i poprawie szybkości przetwarzania zapytań. JOIN jest preferowany nad starym stylem, jakim jest użycie przecinków i warunku w WHERE, z powodu lepszej czytelności i mniejszej podatności na błędy, co czyni kod bardziej zrozumiałym i łatwiejszym do utrzymania.

Pytanie 36

Źródłem danych dla raportu może być

A. inny raport
B. tabela
C. makropolecenie
D. zapytanie INSERT INTO
Tabela jest podstawowym elementem struktury bazy danych, który służy jako źródło danych dla raportów. Tabele przechowują zorganizowane informacje w formie wierszy i kolumn, co umożliwia łatwy dostęp i analizę danych. Każda kolumna w tabeli reprezentuje atrybut, a każdy wiersz to pojedynczy rekord z danymi. Przykładowo, w tabeli zawierającej informacje o klientach, kolumny mogą obejmować imię, nazwisko, adres e-mail i numer telefonu. Dzięki standardom takim jak SQL (Structured Query Language), można łatwo wykonywać operacje na tych tabelach, takie jak selekcja, aktualizacja czy usuwanie danych. Tabele są fundamentalne w systemach zarządzania bazami danych (DBMS) i stanowią podstawowe źródło dla generowania raportów, które mogą być wykorzystywane w różnych kontekstach biznesowych. W raportach można agregować dane, obliczać różne wskaźniki oraz wizualizować wyniki, co czyni tabele nieocenionym elementem w analizie danych.

Pytanie 37

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 38

Zastosowanie atrybutu NOT NULL dla kolumny jest konieczne w sytuacji, gdy

A. mamy do czynienia z kluczem podstawowym
B. tworzymy definicję wszystkich pól tabeli
C. korzystamy z atrybutu DEFAULT
D. definiujemy wszystkie pola o typie numerycznym
Nieprawidłowe odpowiedzi odzwierciedlają typowe błędne rozumienie działania atrybutu NOT NULL w kontekście tabel baz danych. W przypadku klucza podstawowego, jest to niezbędny warunek, aby zapewnić, że każdy wiersz w tabeli jest jednoznacznie identyfikowalny. Odpowiedzi sugerujące, że atrybut NOT NULL jest wymagany przy użyciu atrybutu DEFAULT, są mylące, ponieważ atrybut DEFAULT służy do ustalania wartości domyślnych dla kolumn, które mogą przyjmować wartość NULL. Użycie atrybutu DEFAULT wcale nie implikuje, że kolumna musi być oznaczona jako NOT NULL. Kolejna niepoprawna koncepcja dotyczy definicji wszystkich pól tabeli. Nie ma wymogu, aby wszystkie kolumny w tabeli były oznaczone jako NOT NULL; zależy to od specyficznych wymagań dotyczących danych w danej aplikacji. Ponadto, definicja wszystkich pól typu numerycznego jako NOT NULL również jest fałszywa, ponieważ pola numeryczne mogą być używane do reprezentacji wartości, które mogą być nieznane lub nieprzydzielone, co prowadziłoby do sytuacji, w której wartość NULL jest jak najbardziej uzasadniona. Zrozumienie tych różnic jest kluczowe dla efektywnego projektowania baz danych oraz zarządzania danymi w aplikacjach, co jest zgodne z najlepszymi praktykami w branży.

Pytanie 39

Wskaż właściwą zasadę związaną z integralnością danych w bazie danych?

A. w relacji 1..n pole klucza obcego łączy się z polem klucza obcego innej tabeli
B. pole klucza podstawowego musi mieć utworzony indeks
C. pole klucza obcego nie może być puste
D. pole klucza podstawowego nie może pozostawać puste
Niepoprawne odpowiedzi wskazują na niewłaściwe zrozumienie zasad spójności danych w kontekście relacyjnych baz danych. Pole klucza obcego, które powinno być używane do tworzenia powiązań między różnymi tabelami, może być puste w przypadku, gdy dany rekord nie odnosi się do innego. Na przykład, w systemie zarządzania zamówieniami, pole klucza obcego, które łączy tabelę zamówień z tabelą klientów, może być puste, jeśli zamówienie jest anonimowe lub tymczasowe. Istotne jest, aby zrozumieć, że klucz obcy nie zawsze musi wskazywać na obiekt zależny, co pozwala na większą elastyczność w projektowaniu bazy danych. Odpowiedzi, które sugerują, że klucz podstawowy musi mieć utworzony indeks lub że w relacji 1..n klucz obcy jest połączony z kluczem obcym innej tabeli, również są mylne. Indeksowanie klucza podstawowego jest praktyką zalecaną, ale nie jest to obowiązkowe z punktu widzenia definicji klucza. Klucz obcy jest używany do ustanawiania relacji i nie musi być połączony z innym kluczem obcym, a może wskazywać tylko na klucz podstawowy innej tabeli. Te nieporozumienia mogą prowadzić do błędnego projektowania bazy danych, co w dłuższej perspektywie wpływa na wydajność, integralność oraz bezpieczeństwo danych.

Pytanie 40

Jakie zadanie wykonuje funkcja COUNT w języku SQL?

A. obliczenie wartości bezwzględnej w polu liczbowym
B. liczenie znaków w polu tekstowym
C. zliczanie rekordów uzyskanych z kwerendy
D. wyliczenie średniej wartości w danej kolumnie
Funkcja COUNT w języku SQL jest jedną z najbardziej fundamentalnych funkcji agregujących, która służy do zliczania liczby rekordów w zestawie danych. Użycie tej funkcji jest kluczowe w kontekście analizy danych, ponieważ pozwala na szybkie uzyskanie informacji o ilości danych, które spełniają określone kryteria. Przykład użycia COUNT może wyglądać następująco: SELECT COUNT(*) FROM klienci WHERE kraj = 'Polska'; Taki zapytanie zwróci liczbę wszystkich klientów z Polski. Funkcja COUNT jest również używana w połączeniu z klauzulą GROUP BY, co umożliwia zliczanie rekordów w podgrupach. Na przykład, SELECT kraj, COUNT(*) FROM klienci GROUP BY kraj; zliczy wszystkich klientów w każdym kraju. Warto podkreślić, że COUNT różni się od innych funkcji agregujących, takich jak AVG czy SUM, które obliczają wartości na podstawie danych, a nie zliczają ich. Funkcja COUNT jest zgodna z normami SQL-92 i jest wspierana przez wszystkie popularne systemy zarządzania bazami danych, co czyni ją uniwersalnym narzędziem w pracy z danymi.