Wyniki egzaminu

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

Egzamin niezdany

Wynik: 14/40 punktów (35,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

Podane zapytanie SQL przyznaje użytkownikowi adam@localhost uprawnienia:

GRANT SELECT, INSERT, UPDATE, DELETE
ON klienci TO adam@localhost
A. do manipulowania danymi bazy danych klienci
B. do zarządzania strukturą bazy danych klienci
C. do zarządzania strukturą tabeli klienci
D. do manipulowania danymi w tabeli klienci
Pozostałe opcje wskazują na zarządzanie strukturą bazy danych lub tabeli co w kontekście podanego polecenia SQL nie jest prawidłowe Zarządzanie strukturą bazy danych odnosi się do operacji takich jak tworzenie usuwanie lub modyfikowanie tabel indeksów i innych obiektów bazy danych Przykłady takich operacji to polecenia CREATE ALTER i DROP które zmieniają definicję strukturalną tabel lub innych obiektów bazodanowych W przypadku zarządzania strukturą tabeli moglibyśmy mówić o dodawaniu nowych kolumn zmienianiu typu danych istniejących kolumn czy zmianach w kluczach indeksach Tego typu zmiany nie są objęte poleceniem GRANT SELECT INSERT UPDATE DELETE które koncentruje się wyłącznie na manipulacji danymi w istniejącej strukturze Dlatego też typowym błędem myślowym jest utożsamianie operacji na danych z operacjami modyfikującymi strukturę bazy danych takimi jak dodawanie tabel czy kolumn Operatorzy SQL są precyzyjnie zdefiniowani i rozdzieleni na kategorie manipulacji danymi DML oraz definicji danych DDL co jest kluczowym rozróżnieniem w pracy z bazami danych
Pytanie 2

Czy poniższy kod PHP działa poprawnie, wyświetlając na stronie dane pobrane z bazy danych? Ile pól zostanie zaprezentowanych?

$ile = mysqli_num_rows($zapytanie);
for ($i = 0; $i < $ile; $i++)
{
  $wiersz = mysqli_fetch_row($zapytanie);
  echo "<p>Klient: $wiersz[0] $wiersz[1], adres: $wiersz[2] </p>";
}
A. Z dwóch pól
B. Z trzech pól
C. Z jednego pola
D. Z czterech pól
W analizowanym fragmencie kodu PHP wykorzystano funkcję mysqli_fetch_row do pobrania danych z wyników kwerendy wykonanej na bazie danych. Wiersz z wyników jest zwracany jako tablica indeksowana liczbowo co jest kluczowe dla zrozumienia jakie dane zostaną wyświetlone. W kodzie używane są trzy elementy tej tablicy: $wiersz[0] $wiersz[1] oraz $wiersz[2]. Oznacza to że z każdego wiersza danych pobierane są trzy pola które następnie są wykorzystywane do budowy dynamicznego paragrafu HTML. Częstym błędem w interpretacji tego kodu jest założenie że funkcja mysqli_fetch_row zwraca tylko jedno pole. W rzeczywistości zwraca ona cały wiersz jako tablicę gdzie każdy element odpowiada jednemu polu z zapytania SQL. Inny błąd może wynikać z mylnego utożsamiania indeksu tablicy z liczbą wyświetlanych pól. Warto zawsze weryfikować strukturę danych zwracanych przez funkcje bazy danych i zrozumieć sposób ich przetwarzania. W kontekście dobrych praktyk ważne jest również unikanie potencjalnych zagrożeń związanych z nieodpowiednim przetwarzaniem danych z bazy oraz stosowanie odpowiednich mechanizmów zabezpieczeń takich jak walidacja i sanitacja danych wejściowych aby zapewnić bezpieczne działanie aplikacji webowych. Poprawne zrozumienie działania funkcji przetwarzających dane jest kluczowe dla tworzenia wydajnych i bezpiecznych systemów informatycznych
Pytanie 3

Ustalenie klucza obcego jest konieczne do skonstruowania

A. transakcji
B. klucza podstawowego
C. relacji 1..1
D. relacji 1..n
Zdefiniowanie klucza obcego nie jest bezpośrednio związane z relacjami 1..1, transakcjami czy kluczem podstawowym, ponieważ każde z tych pojęć odnosi się do innego aspektu zarządzania danymi w relacyjnych bazach danych. W przypadku relacji 1..1, każdemu rekordowi w jednej tabeli odpowiada dokładnie jeden rekord w drugiej tabeli, co oznacza, że nie ma potrzeby stosowania klucza obcego, gdyż relacja ta nie wymaga wskazywania powiązań między różnymi rekordami. Ponadto, transakcje są zbiorem operacji, które muszą być wykonane w całości lub wcale, a klucz obcy nie ma bezpośredniego wpływu na ich działanie - klucze obce służą głównie do zapewnienia integralności danych, a nie do zarządzania transakcjami. Klucz podstawowy, z drugiej strony, to unikalny identyfikator każdego rekordu w tabeli, a jego definicja jest odrębna od definicji klucza obcego. W praktyce, pomylenie tych pojęć prowadzi do błędnych wniosków o strukturyzacji danych oraz ich relacjach, co może skutkować nieefektywnym projektowaniem baz danych oraz trudnościami w późniejszym zarządzaniu danymi.
Pytanie 4

Z tabel Klienci oraz Uslugi należy wyodrębnić tylko imiona klientów oraz odpowiadające im nazwy usług, które kosztują więcej niż 10 zł. Kwerenda uzyskująca te informacje ma formę

Ilustracja do pytania
A. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = klienci.id
B. SELECT imie, nazwa FROM klienci, uslugi WHERE cena < 10
C. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id
D. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id WHERE cena > 10
Pozostałe odpowiedzi zawierają istotne błędy w składni SQL oraz w interpretacji relacji między tabelami w bazie danych. Odpowiedź używająca WHERE cena < 10 jest błędna, ponieważ warunek ten wybiera usługi tańsze niż 10 zł, co jest sprzeczne z wymogami zadania. Innym błędem jest użycie niepoprawnego połączenia ON bez odpowiedniego dopasowania kluczy. Użycie klauzuli JOIN bez precyzyjnego określenia relacji, jak w przypadku ON uslugi.id = klienci.id, nie odzwierciedla rzeczywistego związku danych, co prowadzi do błędów logicznych w wynikach. Prawidłowe korzystanie z JOIN wymaga zrozumienia struktury bazy danych oraz relacji między tabelami. Właściwe połączanie tabel z wykorzystaniem klucza obcego jest kluczową praktyką, która zapewnia integralność danych i optymalizację zapytań. Ponadto, brak zastosowania warunków filtracyjnych lub nieodpowiednie ich użycie prowadzi do zwracania niekompletnych lub niepoprawnych danych. Wiedza o strukturze bazy danych oraz umiejętność stosowania poprawnych zapytań SQL są niezbędne dla osób zajmujących się projektowaniem i zarządzaniem bazami danych. Praktyczne doświadczenie w stosowaniu tych umiejętności jest kluczowe dla zapewnienia skuteczności oraz wydajności operacji w bazach danych. Poprawne zapytania są podstawą każdej operacji bazodanowej, zarówno w kontekście codziennych operacji, jak i skomplikowanych analiz danych.
Pytanie 5

Jak można utworzyć kopię zapasową bazy danych MySQL?

A. modyfikowaniem danych
B. agregowaniem danych
C. importowaniem bazy
D. eksportowaniem bazy
Eksport bazy danych MySQL to proces, który pozwala na tworzenie kopii zapasowych danych znajdujących się w bazie. Narzędzie do eksportu, takie jak mysqldump, umożliwia nie tylko zapisanie danych w formacie SQL, ale także w innych formatach, takich jak CSV czy JSON. Eksport jest kluczowy w przypadku migracji danych pomiędzy różnymi środowiskami baz danych lub w sytuacji, gdy zachodzi potrzeba odzyskania danych po awarii. Proces ten można zautomatyzować, korzystając z harmonogramów zadań (cron), co zapewnia regularne tworzenie kopii zapasowych. Zgodnie z najlepszymi praktykami, zaleca się, aby eksportować bazy danych regularnie oraz przechowywać kopie zapasowe w bezpiecznych lokalizacjach, aby zminimalizować ryzyko utraty danych. Standardy takie jak ISO 27001 podkreślają znaczenie odpowiednich procedur zarządzania danymi, w tym tworzenia kopii zapasowych, co czyni eksportu kluczowym elementem strategii ochrony danych w organizacjach.
Pytanie 6

Jakie funkcje należy najpierw wywołać, aby aplikacja PHP mogła nawiązać połączenie z bazą danych?

A. mysql_create_db
B. mysql_select_db
C. mysqli_close
D. mysqli_connect
Odpowiedź 'mysqli_connect' jest prawidłowa, ponieważ to właśnie ta funkcja jest pierwszym krokiem w nawiązywaniu połączenia z bazą danych w PHP. Funkcja ta przyjmuje parametry takie jak nazwa hosta, użytkownik, hasło oraz nazwa bazy danych, co pozwala na zbudowanie komunikacji między aplikacją a bazą danych. Dzięki temu, programista uzyskuje dostęp do danych przechowywanych w bazie, co jest kluczowe dla dynamicznych aplikacji webowych. Przykład użycia tej funkcji to: $link = mysqli_connect('localhost', 'username', 'password', 'database_name');. Warto pamiętać, że dobrym zwyczajem jest również sprawdzenie, czy połączenie zostało nawiązane poprawnie, co można zrobić za pomocą instrukcji if, aby uniknąć błędów w działaniu aplikacji. W kontekście najlepszych praktyk, ważne jest, aby unikać używania przestarzałych funkcji, takich jak mysql_connect, które nie obsługują nowoczesnych standardów bezpieczeństwa. Użycie mysqli_connect zapewnia większą funkcjonalność i bezpieczeństwo, a także jest zgodne z aktualnymi standardami programowania w PHP.
Pytanie 7

Jakie prawa: CREATE, ALTER, DROP zostały użyte w poleceniu GRANT?

A. przyznawania uprawnień innym użytkownikom
B. pracy ze strukturą
C. pobierania danych z bazy
D. pracy z danymi
Odpowiedź dotycząca manipulowania strukturą jest poprawna, ponieważ polecenia GRANT z zestawem praw CREATE, ALTER i DROP koncentrują się na zmianie i zarządzaniu strukturą bazy danych. CREATE pozwala na tworzenie nowych obiektów w bazie danych, takich jak tabele czy widoki. ALTER umożliwia modyfikację istniejących obiektów, na przykład dodawanie kolumn do tabeli. DROP służy do usuwania obiektów z bazy danych. Przykładowo, po nadaniu uprawnień CREATE, użytkownik może utworzyć nową tabelę, co jest kluczowe w procesie projektowania bazy danych. W praktyce, odpowiednie zarządzanie tymi uprawnieniami jest istotne w kontekście bezpieczeństwa i organizacji danych. Standardy branżowe, takie jak te określone przez SQL ANSI, zalecają precyzyjne zarządzanie uprawnieniami, aby uniknąć nieautoryzowanych zmian w strukturze bazy danych, co może prowadzić do utraty danych lub naruszeń bezpieczeństwa.
Pytanie 8

W relacyjnych bazach danych dane zapisywane są w

A. tabelach.
B. kolejkach.
C. listach.
D. wektorach.
W modelu relacyjnych baz danych kluczowe jest zrozumienie, że podstawową strukturą przechowywania danych jest tabela, a nie ogólne pojęcia typu lista, kolejka czy wektor. Te inne struktury występują częściej w programowaniu, w kodzie aplikacji, a nie jako główny element fizycznej organizacji danych w systemach takich jak MySQL czy PostgreSQL. Lista kojarzy się z prostym zbiorem elementów zapisanych jeden po drugim, bez sztywnych kolumn i typów danych. W kodzie możemy mieć listę obiektów użytkowników, ale kiedy te dane trafiają do relacyjnej bazy, lądują w tabeli z jasno zdefiniowanymi kolumnami. Baza danych musi zapewnić integralność, indeksy, klucze, możliwość złożonych zapytań SQL – zwykła lista tego nie ogarnia. Kolejka z kolei to struktura typu FIFO, używana np. w systemach kolejkowania zadań, komunikatach między serwisami, przetwarzaniu asynchronicznym. W bazach danych można co najwyżej zaimplementować logikę działania kolejki na tabeli (np. kolumna status, czas dodania, pobieranie najstarszego zadania), ale fizycznie to dalej jest tabela, a nie specjalny typ „kolejka” w sensie modelu relacyjnego. Wektor natomiast to pojęcie bardziej z matematyki i programowania niskopoziomowego, czasem używane jako tablica dynamiczna. W silnikach baz danych oczywiście istnieją wewnętrzne struktury w pamięci, jakieś tablice, strony danych, indeksy, ale użytkownik pracuje z tabelami, relacjami, widokami. Typowym błędem myślowym jest przenoszenie pojęć z programowania obiektowego czy struktur danych 1:1 do świata relacyjnych baz. W praktyce, niezależnie od tego, czy obsługujesz system CRM, sklep internetowy czy prosty blog, zawsze kończysz z tabelami: użytkownicy, posty, komentarze, produkty itd. Reszta struktur, takich jak listy czy kolejki, to bardziej narzędzia w warstwie aplikacji, nie fundament modelu relacyjnego. Dlatego przy pytaniach o relacyjne bazy danych warto automatycznie myśleć o tabelach, kolumnach, wierszach i kluczach, bo to jest absolutna podstawa pracy z SQL.
Pytanie 9

Jakie jest polecenie SQL, które pozwala na usunięcie bazy danych o nazwie firma?

A. DROP firma;
B. ALTER firma DROP DATABASE;
C. DROP DATABASE firma;
D. ALTER firma DROP;
Polecenia 'DROP firma;', 'ALTER firma DROP;' oraz 'ALTER firma DROP DATABASE;' są nieprawidłowe z różnych powodów, które dotyczą zarówno składni SQL, jak i logiki związanej z zarządzaniem bazami danych. Pierwsze polecenie, 'DROP firma;', jest błędne, ponieważ brakuje w nim specyfikacji, że operacja dotyczy bazy danych. 'DROP' to ogólne polecenie, które wymaga podania pełnej struktury, takiej jak 'DATABASE', aby określić, co dokładnie ma zostać usunięte. W przypadku drugiego polecenia, 'ALTER firma DROP;', występuje niepoprawne użycie słowa kluczowego 'ALTER', które służy do modyfikacji istniejących obiektów w bazie danych, a nie do ich usuwania. 'DROP' i 'ALTER' pełnią różne funkcje i nie mogą być stosowane zamiennie. Ponadto, trzecie polecenie 'ALTER firma DROP DATABASE;' jest błędne, ponieważ nie można modyfikować bazy danych w taki sposób, aby ją usunąć; usunięcie wymaga użycia polecenia 'DROP DATABASE', które wykonuje tę operację w sposób bezpośredni. W praktyce, powszechnym błędem jest mylenie funkcji poleceń DDL i DML, co prowadzi do niepoprawnych prób modyfikacji i usuwania obiektów w bazach danych. Kluczową zasadą w zarządzaniu bazami danych jest dobra znajomość składni SQL oraz zrozumienie, jakie operacje są dostępne dla różnych typów obiektów, co pozwala na unikanie takich pułapek w przyszłości.
Pytanie 10

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

A. tylko funkcję mysqli_error
B. funkcje mysqli_error i mysqli_error_number
C. funkcje mysqli_error i mysqli_errno
D. funkcje mysqli_error i mysqli_connect_errno
Odpowiedź zawierająca funkcje mysqli_error i mysqli_errno jest prawidłowa, ponieważ obie te funkcje dostarczają istotnych informacji dotyczących błędów w kontekście operacji na bazie danych w PHP. Funkcja mysqli_error() zwraca opis ostatniego błędu, który wystąpił w kontekście połączenia z bazą danych. Natomiast mysqli_errno() zwraca numer tego błędu, co jest niezwykle przydatne w diagnostyce. Używanie obu funkcji razem pozwala nie tylko zidentyfikować błąd, ale również zrozumieć jego istotę. Na przykład, jeśli próbujemy wykonać zapytanie, które jest błędne syntaktycznie, można użyć tych funkcji do uzyskania zarówno komunikatu o błędzie, jak i jego kodu, co ułatwia debugowanie. W praktyce, stosowanie tych funkcji jest zgodne z najlepszymi praktykami w programowaniu PHP, ponieważ umożliwia skuteczne zarządzanie wyjątkami i błędami, co jest kluczowe w zapewnieniu stabilności aplikacji.
Pytanie 11

Jak określa się podzbiór strukturalnego języka zapytań, który dotyczy formułowania zapytań do bazy danych przy użyciu polecenia SELECT?

A. SQL DDL (ang. Data Definition Language)
B. SQL DQL (ang. Data Query Language)
C. SQL DCL (ang. Data Control Language)
D. SQL DML (ang. Data Manipulation Language)
W odpowiedziach pojawiają się różne podzbiory języka SQL, które pełnią odrębne funkcje. SQL DML (Data Manipulation Language) jest odpowiedzialny za manipulację danymi, tj. ich wstawianie, aktualizację oraz usuwanie. Chociaż DML wydaje się być blisko związany z zapytaniami, to jednak jego głównym celem jest zarządzanie danymi, a nie ich pobieranie. Z kolei SQL DDL (Data Definition Language) służy do definiowania struktury bazy danych, w tym tworzenia, modyfikowania i usuwania tabel oraz innych obiektów bazodanowych. DDL jest kluczowy w projektowaniu baz danych, ale nie ma zastosowania w kontekście pobierania danych. SQL DCL (Data Control Language) odnosi się do zarządzania uprawnieniami dostępu do danych i obiektów bazy danych, co również nie jest związane z formułowaniem zapytań. DCL pozwala na kontrolowanie, kto może korzystać z danych i co może z nimi robić, a nie na ich pobieranie. Typowym błędem jest mylenie DML i DQL, gdyż obydwa dotyczą danych, ale DQL jest wyłącznie dla zapytań, podczas gdy DML dla ich manipulacji. Właściwe rozumienie różnic między tymi podzbiorami SQL jest kluczowe dla efektywnej pracy z bazami danych.
Pytanie 12

Jak można zweryfikować spójność danych w bazie MySQL?

A. REPAIR TABLE
B. CHECK TABLE
C. mysqldump
D. mysql
Polecenie CHECK TABLE w MySQL służy do sprawdzania integralności danych w tabeli. Umożliwia to identyfikację problemów, takich jak zduplikowane klucze, uszkodzone wskaźniki lub nieprawidłowe struktury danych. Przykładem zastosowania tego polecenia jest sytuacja, gdy administrator bazy danych podejrzewa, że tabela mogła ulec uszkodzeniu na skutek błędów systemowych lub nieprawidłowych operacji użytkownika. W takim przypadku używając CHECK TABLE, można szybko zdiagnozować problemy i podjąć odpowiednie działania, takie jak naprawa za pomocą polecenia REPAIR TABLE, jeśli to konieczne. Dobre praktyki w zakresie zarządzania bazami danych sugerują regularne sprawdzanie integralności tabel, co pozwala na szybsze wykrywanie problemów oraz minimalizację ryzyka utraty danych. Warto również pamiętać, że CHECK TABLE dostarcza szczegółowych informacji o stanie tabeli, co jest szczególnie przydatne w kontekście monitorowania wydajności i stabilności bazy danych. Z tego względu to polecenie jest kluczowym narzędziem w arsenale każdego administratora MySQL.
Pytanie 13

Co oznacza pojęcie integralności referencyjnej?

A. Każda encja musi mieć zdefiniowany klucz podstawowy o wartości unikatowej i różnej od NULL.
B. Baza jest odporna na błędy i awarie wynikające z zawodności sprzętu i oprogramowania.
C. Wartość atrybutu należy do jego dziedziny.
D. Każdej wartości klucza obcego odpowiada dokładnie jedna wartość klucza podstawowego.
Integralność referencyjna to jedna z kluczowych zasad projektowania relacyjnych baz danych. Chodzi w niej o to, żeby wszystkie powiązania między tabelami były spójne i „nie urywały się w powietrzu”. Dlatego poprawne jest stwierdzenie, że każdej wartości klucza obcego musi odpowiadać dokładnie jedna istniejąca wartość klucza podstawowego w tabeli nadrzędnej. Klucz obcy (FOREIGN KEY) wskazuje na klucz główny (PRIMARY KEY) albo unikalny w innej tabeli i DBMS pilnuje, żeby te powiązania były zawsze poprawne. W praktyce oznacza to np. że w tabeli Zamówienia nie można wpisać id_klienta, którego nie ma w tabeli Klienci. System zarządzania bazą danych (MySQL, PostgreSQL, SQL Server, Oracle itd.) przy próbie wstawienia takiego rekordu po prostu zgłosi błąd naruszenia integralności referencyjnej. To samo dotyczy usuwania – jeśli chcesz usunąć klienta, do którego są przypisane zamówienia, to albo system na to nie pozwoli, albo (jeśli tak zaprojektujesz) automatycznie usunie lub zaktualizuje powiązane rekordy zgodnie z regułami ON DELETE / ON UPDATE (CASCADE, RESTRICT, SET NULL itp.). Moim zdaniem integralność referencyjna to absolutna podstawa przy poważnych projektach – bez tego szybko robi się bałagan: „osierocone” rekordy, błędne raporty, problemy z analityką. Dobre praktyki mówią jasno: zawsze definiuj klucze obce między tabelami powiązanymi relacjami 1‑wiele lub wiele‑wiele (przez tabelę pośredniczącą), nie polegaj tylko na logice aplikacji. Dzięki temu baza sama wymusza poprawność danych niezależnie od tego, czy łączy się z nią PHP, JavaScript (np. przez API), czy cokolwiek innego. To bardzo podnosi jakość i bezpieczeństwo danych w całym systemie.
Pytanie 14

Podaj właściwą sekwencję przy tworzeniu bazy danych?

A. Zdefiniowanie celu, normalizacja, utworzenie relacji, stworzenie tabel
B. Zdefiniowanie celu, normalizacja, utworzenie tabel, stworzenie relacji
C. Zdefiniowanie celu, utworzenie relacji, stworzenie tabel, normalizacja
D. Zdefiniowanie celu, stworzenie tabel, utworzenie relacji, normalizacja
Prawidłowa odpowiedź wskazuje, że pierwszym krokiem w procesie tworzenia bazy danych jest określenie celu, co jest kluczowe dla zrozumienia, jakie dane będą gromadzone i w jaki sposób będą one używane. Następnie, stworzenie tabel to fundament, na którym opiera się cała baza danych. Tabele definiują struktury danych, które będą przechowywane, a ich projektowanie powinno uwzględniać normalizację, czyli proces eliminowania redundancji danych i zapewniania ich integralności. Utworzenie relacji między tabelami jest kolejnym krokiem, który pozwala na efektywne łączenie danych w różnych tabelach, co z kolei umożliwia bardziej złożone zapytania. Normalizacja, będąca ostatnim krokiem, pozwala na optymalizację struktury bazy, co zwiększa wydajność operacji. Przykład zastosowania tej kolejności można zobaczyć w projektowaniu systemów zarządzania bazami danych w przedsiębiorstwach, gdzie dokładne określenie potrzeb biznesowych wpływa na przyszłe modele danych i ich relacje.
Pytanie 15

W SQL polecenie INSERT INTO służy do

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

Dostępna jest tabela pracownicy zawierająca pola id, nazwisko, imię oraz wynagrodzenie. Kolumnę wynagrodzenie można usunąć przy użyciu następującej instrukcji

A. ALTER TABLE pracownicy DELETE COLUMN wynagrodzenie
B. ALTER TABLE pracownicy DELETE wynagrodzenie
C. DROP TABLE pracownicy DELETE COLUMN wynagrodzenie
D. ALTER TABLE pracownicy DROP COLUMN wynagrodzenie
W niepoprawnych odpowiedziach pojawiają się błędy związane z użyciem SQL i polecenia ALTER TABLE. Na przykład w pierwszej odpowiedzi ktoś użył kombinacji DROP TABLE i DELETE COLUMN, co jest totalnie pomyłką, bo DROP TABLE usuwa całą tabelę, a nie tylko kolumnę. Może to wynikać z pomylenia usuwania tabeli z usuwaniem kolumny. W następnej odpowiedzi, ALTER TABLE pracownicy DELETE COLUMN, mamy do czynienia z błędem, bo w SQL nie ma czegoś takiego jak DELETE COLUMN. Ludzie mogą to mylić z instrukcją DELETE, która dotyczy usuwania wierszy, a nie kolumn. Ostatnia odpowiedź, czyli ALTER TABLE pracownicy DELETE wynagrodzenie, też jest błędna, bo nie zaznacza, że chodzi o kolumnę, a użycie słowa DELETE w tym kontekście jest mylące. Takie błędy mogą wynikać z niepełnego zrozumienia podstawowych konceptów związanych z bazami danych i SQL. Żeby tego uniknąć, dobrze jest regularnie przeglądać dokumentację oraz ćwiczyć pisanie zapytań, bo to naprawdę pomaga w lepszym rozumieniu tego, co się robi.
Pytanie 17

Tabela samochody zawiera dane przedstawione poniżej:

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

Aby zliczyć wszystkie wiersze w tabeli Koty, należy wykorzystać zapytanie

A. SELECT COUNT(*) FROM Koty
B. SELECT COUNT(ROWNUM) FROM Koty
C. SELECT COUNT(Koty) AS ROWNUM
D. SELECT ROWNUM() FROM Koty
Aby policzyć wszystkie wiersze tabeli Koty, należy skorzystać z polecenia SQL SELECT COUNT(*), które zwraca liczbę wszystkich rekordów w danej tabeli. Funkcja COUNT(*) jest częścią standardu SQL i działa na zasadzie zliczania wszystkich wierszy, niezależnie od tego, czy zawierają one wartości NULL. Wartością zwróconą przez to polecenie będzie liczba całkowita, która przedstawia całkowitą liczbę wierszy w tabeli Koty. Przykład zastosowania tego polecenia w praktyce może wyglądać następująco: po wykonaniu zapytania na bazie danych, użytkownik otrzyma wynik, który jasno wskazuje, ile kotów znajduje się w tabeli. Ten sposób zliczania jest efektywny i szeroko stosowany w aplikacjach zarządzających bazami danych, umożliwiając szybkie i precyzyjne uzyskanie potrzebnych informacji. Przy indeksowaniu i optymalizacji zapytań, COUNT(*) jest najczęściej używaną funkcją, co czyni ją kluczowym narzędziem w pracy z relacyjnymi bazami danych.
Pytanie 19

Zgodnie z zasadami ACID, które odnoszą się do realizacji transakcji, wymóg trwałości (ang. durability) oznacza, że

A. dane zatwierdzone przez transakcję powinny być dostępne niezależnie od wydarzeń, które nastąpią po jej zakończeniu
B. w trakcie wykonywania transakcji dane mogą być zmieniane przez inne transakcje
C. w przypadku naruszenia spójności bazy danych transakcja usuwa tabele z kluczami obcymi
D. transakcja może w pewnych okolicznościach być podzielona na dwa niezależne etapy
Wybranie odpowiedzi, że w przypadku naruszenia spójności bazy danych transakcja usuwa tabele z kluczami obcymi, nie jest zbyt mądre. Usuwanie tabel mogłoby naprawdę zaszkodzić strukturze danych i doprowadzić do poważnych problemów. Spójność baz danych to jeden z elementów ACID, ale to nie znaczy, że w razie kłopotów można po prostu rzucać się na tabele. W kontekście trwałości (durability) warto unikać działań, które mogą skutkować utratą danych. Zauważyłem też, że druga opcja sugeruje, że dane mogą być zmieniane przez inne transakcje w trakcie trwania jednej. To jest naruszenie zasady izolacji, która mówi, że każda transakcja powinna działać niezależnie. Zmiany równocześnie mogą prowadzić do chaosu, a zasady ACID starają się temu zapobiegać. Co do podziału transakcji na dwa etapy, to też jest niezgodne z zasadami ACID, zwłaszcza w kontekście trwałości i izolacji. Takie coś może tylko skomplikować sprawę i doprowadzić do niespójności. Dlatego, żeby dobrze zarządzać transakcjami w bazach danych, trzeba naprawdę zrozumieć zasady ACID i wdrażać strategie, które pomogą unikać błędów i zapewnić porządek.
Pytanie 20

Można wydać instrukcję transakcyjną ROLLBACK, aby

A. cofnąć działanie transakcji
B. zatwierdzić transakcję
C. zatwierdzić jedynie wybrane modyfikacje transakcji
D. cofnąć transakcję po zastosowaniu instrukcji COMMIT
Odpowiedź 2 jest poprawna, ponieważ instrukcja ROLLBACK jest używana w systemach zarządzania bazami danych, aby cofnąć wszystkie zmiany wprowadzone w bieżącej transakcji. ROLLBACK przywraca stan bazy danych do momentu sprzed rozpoczęcia transakcji, co jest niezwykle istotne w kontekście zapewnienia integralności danych. W sytuacjach, gdy transakcja kończy się błędem lub występują nieprzewidziane okoliczności, ROLLBACK umożliwia usunięcie wszystkich niepoprawnych lub niekompletnych operacji. Na przykład, podczas aktualizacji danych w bazie, jeśli część operacji zakończy się niepowodzeniem, a część nie, zastosowanie ROLLBACK pozwala na ochronę danych przed niespójnym stanem. W praktyce, ROLLBACK powinien być stosowany w ramach transakcji, co jest zgodne z zasadami ACID (Atomicity, Consistency, Isolation, Durability), które są kluczowe dla bezpieczeństwa i spójności operacji w bazach danych. Dobrą praktyką jest również testowanie scenariuszy, w których mogą wystąpić błędy, aby upewnić się, że ROLLBACK działa poprawnie w sytuacjach awaryjnych, co może pomóc w ochronie przed utratą danych oraz w utrzymaniu zaufania użytkowników względem systemu.
Pytanie 21

Jakiego rodzaju oprogramowanie narzędziowe jest wymagane, aby użytkownik mógł przeprowadzać operacje na zebranych danych?

A. Klucz obcy
B. Otwarty mechanizm komunikacji bazy danych
C. Obiektowy System Zarządzania Bazą Danych
D. System Zarządzania Bazą Danych (SZBD)
System Zarządzania Bazą Danych (SZBD) to kluczowy element w architekturze aplikacji, który umożliwia użytkownikom przechowywanie, modyfikowanie i zarządzanie danymi. Dzięki SZBD użytkownicy mogą wykonywać operacje takie jak dodawanie, usuwanie, modyfikacja danych oraz wykonywanie zapytań, co jest niezbędne w każdym systemie informacyjnym. Przykłady powszechnie stosowanych SZBD to MySQL, PostgreSQL oraz Oracle Database. W praktyce, SZBD obsługuje relacje między danymi, co pozwala na zapewnienie integralności i spójności danych. Dodatkowo, SZBD implementują standardy takie jak ACID (Atomicity, Consistency, Isolation, Durability), co jest gwarancją niezawodności transakcji. Aby efektywnie korzystać z SZBD, warto zapoznać się z językiem SQL, który jest standardem do komunikacji z bazą danych. W kontekście dobrych praktyk, umiejętność projektowania prawidłowej struktury bazy danych oraz znajomość zasad normalizacji danych są kluczowe dla optymalizacji wydajności aplikacji oraz minimalizacji ryzyka błędów danych.
Pytanie 22

Przedstawiona jest tabela pracownicy, w której umieszczono rekordy widoczne obok. Jaką wartość zwróci wykonanie umieszczonej w ramce kwerendy SQL?

SELECT MAX(pensja) FROM pracownicy WHERE pensja < 3000;
idimienazwiskopensja
1AnnaKowalska3400
2MonikaNowak1300
3EwelinaNowakowska2600
4AnnaPrzybylska4600
5MariaKowal2200
6EwaNowacka5400
A. 2600
B. 2200
C. 5400
D. 1300
Kwerenda SQL SELECT MAX(pensja) FROM pracownicy WHERE pensja < 3000; służy do znalezienia maksymalnej wartości w kolumnie pensja z rekordów spełniających warunek pensja mniejsza niż 3000. Przeszukując tabelę pracownicy widzimy że wartości spełniające ten warunek to 1300 2600 i 2200. Najwyższą z tych wartości jest 2600 co czyni tę odpowiedź poprawną. Zrozumienie tego typu kwerend SQL jest kluczowe w pracy z bazami danych ponieważ pozwala na wyciąganie konkretnych informacji z dużych zbiorów danych. W praktyce takie zapytania mogą być używane do analizowania danych pracowniczych w firmach gdzie na przykład chcemy zidentyfikować pracowników z wynagrodzeniem poniżej określonego progu. Jest to zgodne z dobrymi praktykami w branży gdzie używa się agregacji danych do celów analitycznych. Zrozumienie jak działa funkcja MAX() w połączeniu z klauzulą WHERE umożliwia efektywne filtrowanie i przetwarzanie danych co jest niezbędne w wielu aplikacjach biznesowych.
Pytanie 23

Wymień dwa sposoby na zabezpieczenie bazy danych Microsoft Access

A. Ustalanie hasła do otwarcia bazy danych oraz zabezpieczeń na poziomie użytkownika
B. Zaszyfrowanie pliku bazy danych oraz wiadomości SMS z kodem autoryzacyjnym
C. Ustalenie zabezpieczeń na poziomie użytkownika oraz w sesji
D. Funkcje anonimowe oraz ustawienie hasła do otwarcia bazy danych
Zabezpieczenie bazy danych Microsoft Access wymaga zastosowania odpowiednich technik, które niestety nie są w pełni reprezentowane w niepoprawnych odpowiedziach. Funkcje anonimowe, choć mogą być używane w kontekście prywatności, nie odpowiadają rzeczywistym potrzebom ochrony bazy danych. Ustalanie hasła otwarcia bazy danych jest dobrym krokiem, ale sama metoda nie wystarcza w przypadku wysoce wrażliwych danych. Nie można opierać bezpieczeństwa wyłącznie na jednym mechanizmie. Zaszyfrowanie pliku bazy danych jest metodą, jednak SMS-y z kodem autoryzującym to błędne podejście, ponieważ nie są one standardowo wspierane w Microsoft Access jako forma zabezpieczenia bazy danych. Powinno się raczej korzystać z bardziej zaawansowanych systemów autoryzacji, które są lepiej zintegrowane z aplikacjami bazodanowymi. Ustalanie zabezpieczeń na poziomie użytkownika i sesji, mimo że teoretycznie mogą wydawać się skuteczne, w praktyce często pomijają kluczowe aspekty zarządzania rolami i uprawnieniami w systemach bazodanowych. To prowadzi do ryzyka nieautoryzowanego dostępu, jeśli nie zostaną spełnione odpowiednie normy zabezpieczeń. Warto zwrócić uwagę na metodologię zarządzania dostępem, która powinna być zgodna z zaleceniami branżowymi oraz regulacjami prawnymi dotyczącymi ochrony danych, takimi jak RODO.
Pytanie 24

W kolumnie, która pełni funkcję klucza głównego w tabeli, powinny się znajdować

A. inny typ niż inne kolumny.
B. ciągłe numery.
C. wartości unikalne.
D. liczby.
Kolumna, która pełni rolę klucza głównego w tabeli, powinna mieć unikalne wartości. To takie ważne w projektowaniu baz danych. Klucz główny to coś, co pozwala jasno zidentyfikować każdy rekord w tabeli. Czyli dla każdego wpisu w tej kolumnie musi być jedna, jedyna wartość, która nie powtarza się w innych wierszach. Na przykład w tabeli użytkowników kolumna 'ID' często jest kluczem głównym. Dzięki temu, jak chcemy znaleźć konkretnego użytkownika, to robimy to bez żadnych pomyłek, szukając go za pomocą tego jedynego identyfikatora. W praktyce używanie unikalnych wartości w kluczu głównym jest zgodne z zasadami normalizacji baz danych. To pomaga zredukować zbędne dane i zwiększa ich poprawność. No bo nie ma co ukrywać, unikalność klucza głównego to podstawa skutecznego zarządzania danymi i zapewnia porządek w aplikacjach bazodanowych. To zgodne z najlepszymi praktykami w branży.
Pytanie 25

Kiedy należy użyć kwerendy SELECT DISTINCT, aby wybrać rekordy?

A. tak, aby w wskazanej kolumnie nie powtarzały się wartości.
B. obecne w bazie tylko raz.
C. pogrupowane.
D. uporządkowane w kolejności malejącej lub rosnącej.
Wybór nieodpowiednich odpowiedzi, takich jak pogrupowane, występujące w bazie tylko raz czy posortowane malejąco lub rosnąco, wskazuje na pewne nieporozumienia dotyczące funkcji kwerendy SELECT DISTINCT. Kwerenda ta nie jest używana do grupowania danych. Gdybyśmy chcieli pogrupować dane, zastosowalibyśmy grupowanie poprzez klauzulę GROUP BY, która agreguje dane na podstawie określonego kryterium, co jest zupełnie inną operacją. Podobnie, stwierdzenie, że SELECT DISTINCT wybiera rekordy występujące w bazie tylko raz, jest mylące. Funkcja DISTINCT nie ma na celu eliminacji wszystkich rekordów, które się powtarzają, ale raczej skupienie się na unikalnych wartościach w kontekście zadanej kolumny. Dodatkowo, posortowanie danych, niezależnie od kierunku (malejącego lub rosnącego), jest zupełnie inną operacją, którą osiągamy za pomocą klauzuli ORDER BY. W rzeczywistości, DISTINCT i ORDER BY mogą być używane razem, ale ich funkcje są różne. Typowe błędy myślowe prowadzące do tych niepoprawnych wniosków obejmują mylenie funkcji agregujących z funkcjami selekcyjnymi, co jest kluczowe do zrozumienia przy pracy z bazami danych. W rezultacie, kluczowym elementem jest umiejętność rozróżnienia funkcji i celów poszczególnych zapytań SQL, co jest niezbędne w efektywnym zarządzaniu danymi.
Pytanie 26

Użytkownik Jan będzie mógł wykonywać

GRANT ALL PRIVILEGES ON dane.* TO 'Jan'@'localhost';
A. wszystkie operacje na tabelach bazy dane.
B. jedynie operacje CREATE, ALTER, DROP na tabelach bazy dane.
C. wszystkie operacje na tabelach bazy dane oraz nadawać prawa innym użytkownikom.
D. jedynie operacje manipulowania danymi i zmienić jedynie swoje prawa.
Wszystkie pozostałe odpowiedzi są niepoprawne z różnych powiedział. Druga odpowiedź sugeruje, że Jan może wykonywać tylko operacje CREATE, ALTER, DROP. Jest to nieprawidłowe, ponieważ otrzymał on pełne uprawnienia do bazy danych, co zdecydowanie wykracza poza te trzy operacje. Trzecia odpowiedź zawiera błędne przekonanie, że Jan może nadawać uprawnienia innym użytkownikom. Pomimo posiadania pełnych uprawnień do bazy danych, nie oznacza to, że ma on możliwość zarządzania uprawnieniami innych użytkowników. Czwarta odpowiedź jest również błędna, twierdząc, że Jan może manipulować danymi i zmieniać tylko swoje uprawnienia. W rzeczywistości, Jan nie ma uprawnień do zmiany swoich własnych uprawnień - to zadanie zazwyczaj spoczywa na administratorze bazy danych. Wszystkie te błędy wynikają z niewłaściwego zrozumienia zarządzania uprawnieniami w bazach danych i roli konstrukcji GRANT. W rzeczywistości, GRANT pozwala na precyzyjne i granularne zarządzanie uprawnieniami, a pełne uprawnienia oznaczają pełną kontrolę nad bazą danych, ale nie nad uprawnieniami innych użytkowników.
Pytanie 27

W systemie zarządzania bazami danych MySQL komenda CREATE USER pozwala na

A. pokazanie danych o istniejącym użytkowniku
B. utworzenie użytkownika
C. stworznie nowego użytkownika oraz przydzielenie mu uprawnień do bazy
D. zmianę hasła dla już istniejącego użytkownika
Odpowiedzi sugerujące utworzenie użytkownika i nadanie mu praw do bazy lub wyświetlenie informacji o istniejącym użytkowniku nie są poprawne, ponieważ CREATE USER służy jedynie do definicji konta użytkownika, a nie do przypisywania mu uprawnień. W rzeczywistości, aby przyznać dostęp do bazy danych, należy użyć osobnego polecenia GRANT, które zarządza uprawnieniami dla już istniejących użytkowników. Z tego powodu pomylenie tych dwóch poleceń może prowadzić do nieefektywnego zarządzania użytkownikami w systemie bazy danych. Innym błędnym podejściem jest przypisanie funkcji wyświetlania informacji o użytkownikach do CREATE USER. W MySQL do uzyskania takich informacji wykorzystuje się zapytania do systemowych tabel informacyjnych lub polecenie SHOW GRANTS, które pozwala na przeglądanie przyznanych uprawnień dla konkretnego użytkownika. Z kolei zmiana hasła istniejącego użytkownika z wykorzystaniem CREATE USER jest również pomyłką, gdyż do takiej operacji należy używać polecenia ALTER USER, co pozwala na aktualizację danych logowania bez konieczności usuwania i ponownego tworzenia konta. Błędy te wynikają często z niepełnego zrozumienia funkcji poszczególnych poleceń SQL, co może prowadzić do nieefektywnego zarządzania bazą danych oraz zwiększonego ryzyka bezpieczeństwa.
Pytanie 28

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

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

W SQL, aby uniemożliwić stworzenie konta przy wykonywaniu kwerendy CREATE USER, gdy konto już istnieje, można zastosować następującą składnię

A. CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
B. CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
C. CREATE OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
D. CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';
Odpowiedzi, które nie zawierają klauzuli 'IF NOT EXISTS', nie są optymalne, ponieważ mogą prowadzić do błędów, gdy próbuje się utworzyć konto, które już istnieje. W przypadku polecenia 'CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';', jeśli konto 'anna' jest już w systemie, użytkownik otrzyma błąd, co skutkuje niepowodzeniem całego skryptu. W kontekście administracji baz danych, jest to szczególnie problematyczne, gdy skrypty są uruchamiane automatycznie, ponieważ mogą one przerywać dalsze operacje. Natomiast składnia 'CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' jest nieprawidłowa, ponieważ nie istnieje w standardzie SQL. Użytkownicy mogą mylić 'DROP' z opcją usunięcia konta, co w praktyce nie powinno być podejmowane bez wyraźnej intencji. Ostatecznie, 'CREATE OR REPLACE USER...' działa odmiennie, ponieważ nie jest standardową operacją w SQL dla użytkowników; bardziej odpowiednie byłoby jej zastosowanie w kontekście obiektów, takich jak procedury czy widoki. Kluczowe jest zrozumienie, że błędne podejście do tworzenia użytkowników może prowadzić do chaosu w zarządzaniu bazą danych i stwarzać potencjalne zagrożenia dla bezpieczeństwa. Dlatego tak istotne jest stosowanie klauzuli 'IF NOT EXISTS', co jest zgodne z najlepszymi praktykami w branży zarządzania systemami baz danych.
Pytanie 30

W bazie danych znajduje się tabela uczniowie z kolumnami: imie, nazwisko, klasa. Jakie polecenie SQL należy wykorzystać, aby znaleźć imiona oraz nazwiska uczniów, których nazwiska zaczynają się na literę M?

A. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko = 'M%';
B. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko IN 'M%';
C. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko LIKE 'M%';
D. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko IN 'M%';
Podejście, które wykorzystuje IN w kontekście wyszukiwania wzorców jest niepoprawne, ponieważ operator IN służy do porównywania wartości z zestawem możliwych wartości, a nie do wyszukiwania wzorców. W SQL IN używa się, gdy chcemy sprawdzić, czy dana kolumna posiada jedną z kilku określonych wartości. Na przykład, gdybyśmy chcieli znaleźć wszystkich uczniów o nazwiskach 'Mroz', 'Michał' lub 'Malinowski', moglibyśmy użyć zapytania z IN, ale nie w kontekście wzorców. Kolejny błąd w zapytaniu dotyczy użycia ORDER BY w sposób, który nie ma sensu w kontekście filtrowania danych. ORDER BY służy do sortowania wyników, a nie do ich selekcji. Próba użycia tej konstrukcji do stworzenia warunku wyszukiwania prowadzi do nieporozumień, ponieważ nie można łączyć warunków filtrujących z sortowaniem w jednym poleceniu w podany sposób. Podobnie, użycie '=' w połączeniu z LIKE jest błędne, ponieważ '=' nie obsługuje symboli wieloznacznych. Typowym błędem jest mylenie funkcji służących do wyszukiwania z funkcjami do porządkowania danych, co skutkuje niepoprawnym zrozumieniem sposobu działania SQL. Ważne jest, aby znać funkcjonalność i ograniczenia poszczególnych operatorów SQL, aby poprawnie formułować zapytania i osiągać zamierzone cele w pracy z bazami danych.
Pytanie 31

Określ rodzaj powiązania pomiędzy tabelami: Tabela1 oraz Tabela3

Ilustracja do pytania
A. Wiele do jednego
B. Jeden do wielu
C. Jeden do jednego
D. Wiele do wielu
Zrozumienie typów relacji w bazach danych jest kluczowym aspektem projektowania efektywnych i zrównoważonych systemów informatycznych. Jednym z najczęstszych błędów jest mylenie relacji wiele do wielu z innymi rodzajami relacji, takimi jak jeden do wielu lub jeden do jednego. Relacja jeden do wielu oznacza, że jeden rekord w jednej tabeli jest powiązany z wieloma rekordami w innej tabeli, co w przypadku Tabela1 i Tabela3 nie jest stosowne, ponieważ wymagałoby to bezpośredniego połączenia między tymi tabelami bez użycia tabeli pośredniej. Z kolei relacja jeden do jednego implikuje, że każdy rekord w jednej tabeli odpowiada dokładnie jednemu rekordowi w drugiej tabeli, co ogranicza elastyczność danych i nie pasuje do struktur gdzie występuje wiele powiązań, jak w przypadku szkół, gdzie wielu uczniów może mieć zajęcia z tym samym nauczycielem. Wreszcie, relacja wiele do jednego jest odwrotnością relacji jeden do wielu, gdzie wiele rekordów w jednej tabeli odpowiada jednemu rekordowi w drugiej tabeli, co również nie znajduje odzwierciedlenia w przedstawionym schemacie, jako że nie opisuje wzajemnych powiązań uczniów i nauczycieli. Zrozumienie i prawidłowe zastosowanie relacji wiele do wielu eliminuje redundancję danych i umożliwia efektywne przechowywanie oraz przetwarzanie informacji w systemach zarządzania bazami danych. Kluczem do sukcesu jest tutaj wykorzystanie tabel pośrednich do prawidłowego mapowania powiązań między tabelami, co jest standardem w dobrych praktykach projektowania baz danych.
Pytanie 32

Jakie zadanie wykonuje funkcja COUNT w języku SQL?

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

$x = mysql_query('SELECT * FROM mieszkanci'); if (!$x) echo "??????????????????????????????"; W podanym kodzie PHP, w miejscu znaków zapytania powinien wyświetlić się komunikat:

A. Błąd w trakcie przetwarzania zapytania
B. Nieprawidłowa nazwa bazy danych
C. Złe hasło do bazy danych
D. Zapytania zakończono sukcesem
W przedstawionym kodzie PHP mamy do czynienia z próbą wykonania zapytania SQL do bazy danych przy pomocy funkcji mysql_query. Ta funkcja zwraca wartość false, jeśli wystąpił błąd w trakcie przetwarzania zapytania. W kontekście tego kodu, komunikat 'Błąd przetwarzania zapytania.' jest odpowiedni, ponieważ wskazuje, że zapytanie nie zostało poprawnie wykonane. Istotne jest, aby programista zrozumiał, że błędy mogą wynikać z różnych przyczyn, takich jak błędna składnia SQL, problemy z połączeniem do bazy danych lub inne czynniki techniczne. Ważną praktyką jest dodawanie mechanizmów obsługi błędów, które mogą dać więcej informacji na temat problemu, np. użycie mysql_error() do uzyskania szczegółowych informacji o błędzie. Standardy dotyczące programowania w PHP oraz najlepsze praktyki wskazują na konieczność stosowania try-catch dla lepszej kontroli błędów oraz logowania, co może pomóc w diagnozowaniu problemów na etapie produkcyjnym. Warto zaznaczyć, że mysql_query jest przestarzałą funkcją, a obecnie zaleca się użycie mysqli lub PDO do komunikacji z bazą danych, co poprawia bezpieczeństwo i wydajność aplikacji.
Pytanie 34

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

A. TINYTEXT
B. DECIMAL(10, 2)
C. ENUM
D. INTEGER(11)
Wybór typów ENUM, INTEGER(11) i TINYTEXT dla pola przechowującego cenę produktu może prowadzić do istotnych problemów. ENUM to typ danych, który przechowuje zestaw z góry określonych wartości. Jest to użyteczne dla ograniczonego zestawu opcji, np. dla koloru lub statusu, ale nie nadaje się do przechowywania wartości liczbowych, takich jak ceny, które mogą być zmienne i nieprzewidywalne. Z kolei typ INTEGER(11) przechowuje jedynie liczby całkowite, co oznacza, że nie będzie w stanie reprezentować wartości z miejscami po przecinku. Cena zamówienia 19,99 PLN nie mogłaby być poprawnie zarejestrowana, co byłoby nieakceptowalne w kontekście aplikacji finansowych. TINYTEXT to typ przechowujący tekst, co w kontekście cen jest absolutnie nieodpowiednie, ponieważ nie zapewnia możliwości przechowywania wartości liczbowych, a także nie pozwala na wykonywanie kalkulacji arytmetycznych. Stąd wynika, że wybór tych typów jest oparty na nieporozumieniach dotyczących ich funkcjonalności i zastosowania, co może skutkować nieprawidłowym działaniem aplikacji oraz błędami w obliczeniach. Aby uniknąć takich błędów, ważne jest, by dobrze rozumieć, jakie typy danych są odpowiednie dla określonych zastosowań, a także znać zasady dobrego projektowania baz danych, które skupiają się na precyzyjnej reprezentacji danych oraz ich odpowiednim typie.
Pytanie 35

Zapytanie SQL o treści: UPDATE artykuly SET cena = cena * 0.7 WHERE kod = 2; wskazuje na

A. w tabeli artykuly obniża wartość każdego pola cena o 30% dla wszystkich rekordów artykułów
B. w tabeli artykuly zmniejsza wartość każdego pola cena, dla którego pole kod ma wartość 2
C. dodanie w tabeli artykuly pola o nazwie cena z atrybutem kod
D. dodanie w tabeli artykuly nowych pól cena oraz kod
Patrząc na inne odpowiedzi, można zauważyć, że niektóre z nich mają błeądne założenia na temat tego polecenia SQL. Widziałem, że pisali, iż to polecenie wprowadza nowe pola, ale to nie jest prawda, bo 'UPDATE' jest do aktualizacji danych, a nie do ich dodawania. Nowe pola tworzymy za pomocą 'ALTER TABLE' albo 'INSERT', co jest zupełnie czym innym. Jeszcze inny błąd, który się pojawia, to twierdzenie, że cena jest obniżana dla wszystkich artykułów – to nie jest prawda, bo klauzula 'WHERE kod = 2' ogranicza aktualizację tylko do rekordów, gdzie kod wynosi 2. To naprawdę ważne, bo bez takiego warunku moglibyśmy przypadkowo obniżyć ceny dla wszystkich produktów, co byłoby ogromnym ryzykiem. Krótko mówiąc, zrozumienie, jak działają polecenia SQL, jest kluczowe, żeby bezpiecznie pracować z danymi. Dlatego warto znać różnice między tymi komendami, żeby unikać typowych błędów.
Pytanie 36

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

A. związkiem.
B. dziedziną.
C. atrybutem.
D. krotką.
W tym pytaniu łatwo pomylić kilka podstawowych pojęć z teorii baz danych, szczególnie jeśli ktoś kojarzy je tylko z praktyki SQL, a nie z modelu ER. W modelu encja‑związek interesuje nas opis świata rzeczywistego na wyższym poziomie abstrakcji. Zbiory encji to na przykład Pracownicy, Projekty, Produkty, a powiązania między nimi opisujemy właśnie jako związki. Natomiast „krotka” to pojęcie z modelu relacyjnego, czyli z poziomu tabel. Krotka to po prostu pojedynczy wiersz w tabeli, jeden rekord zawierający konkretne wartości atrybutów. Ktoś może intuicyjnie pomyśleć, że skoro wiersz „łączy” wartości atrybutów, to jest jakimś powiązaniem, ale to zupełnie inny poziom opisu: krotka nie jest relacją między zbiorami encji, tylko instancją danych w jednym zbiorze. „Dziedzina” z kolei to zbiór dopuszczalnych wartości dla atrybutu, na przykład dziedzina dla kolumny wiek może być liczbą całkowitą z określonego przedziału, a dla kolumny email – tekstem spełniającym pewien wzorzec. Dziedzina opisuje typ i zakres danych, ale nie opisuje tego, jak tabele czy encje są ze sobą powiązane. Częsty błąd polega na wrzucaniu do jednego worka wszystkich pojęć typu: tabela, rekord, pole, domena, relacja, atrybut, związek – a każde z nich ma dość konkretną definicję. „Atrybut” to po prostu cecha encji, coś w rodzaju kolumny w tabeli: imię, nazwisko, data_urodzenia, cena, ilość. Atrybut opisuje właściwości pojedynczego obiektu, nie tworzy sam z siebie powiązania między zbiorami encji. Oczywiście atrybut może być kluczem obcym, czyli w modelu relacyjnym służyć do realizacji relacji, ale nadal jest to atrybut, a nie sam związek w sensie modelu ER. Z mojego doświadczenia wynika, że największy problem pojawia się, gdy miesza się poziom konceptualny (ER) z poziomem fizycznym (tabele SQL). Na diagramie ER powiązanie między dwoma zbiorami encji nazywamy właśnie związkiem i to ono określa typ relacji (1:1, 1:N, N:M), opcjonalność oraz reguły biznesowe. Dopiero później to powiązanie odwzorowujemy w postaci kluczy obcych, tabel pośredniczących i ograniczeń w konkretnej bazie danych. Dlatego poprawne rozróżnienie tych pojęć jest kluczowe przy profesjonalnym projektowaniu baz danych i zgodne z klasycznymi standardami modelowania danych, które stosuje się w poważnych projektach komercyjnych.
Pytanie 37

Aby zwiększyć wydajność operacji na bazie danych, należy dla pól, które są często wyszukiwane lub sortowane

A. dodać więzy integralności
B. stworzyć osobną tabelę przechowującą tylko te pola
C. dodać klucz obcy
D. utworzyć indeks
Tworzenie indeksu na polach, które często przeszukujesz lub sortujesz, to naprawdę ważna rzecz, jeśli chodzi o wydajność baz danych. Indeksy działają trochę jak spis treści w książkach – pozwalają systemowi szybko znaleźć te dane, których potrzebujesz, bez przeszukiwania całego folderu. Dzięki nim zapytania SELECT mogą iść jak burza, co ma ogromne znaczenie w aplikacjach, gdzie liczy się czas. Przykład? Jeśli zrobisz indeks na kolumnie 'email' w tabeli 'Users', to znacznie szybciej odnajdziesz użytkowników po adresie email. W praktyce warto też regularnie monitorować, jak działają te indeksy i je optymalizować, na przykład usuwając te, które są zbędne, żeby nie przeciążać bazy danych. Dobrze jest pamiętać, że przy dodawaniu lub aktualizowaniu danych, indeksy mogą trochę spowolnić działanie, więc lepiej używać ich z głową.
Pytanie 38

Jakie uprawnienia posiada użytkownik jan po wykonaniu poniższych poleceń na bazie danych? ```GRANT ALL PRIVILEGES ON klienci TO jan;``` ```REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;```

A. Będzie miał możliwość wyszukiwania danych w tabeli klienci
B. Będzie miał możliwość wstawiania rekordów do tabeli klienci
C. Będzie miał możliwość zmiany struktury tabeli klienci
D. Będzie miał możliwość usuwania rekordów z tabeli klienci
Użytkownik jan po wykonaniu podanych poleceń SQL nie będzie miał możliwości usuwania rekordów z tabeli klienci. W rzeczywistości polecenie GRANT ALL PRIVILEGES na początku miało na celu nadanie wszystkich uprawnień do tej tabeli, jednak po wykonaniu polecenia REVOKE SELECT, INSERT, UPDATE, DELETE odebrano mu możliwość wykonywania podstawowych operacji na danych, takich jak wstawianie, usuwanie czy aktualizowanie rekordów. Jest to częsty błąd w myśleniu, gdzie użytkownicy mogą sądzić, że uprawnienia ogólne obejmują również wszystkie podkategorie, nawet jeśli nie zostały określone. Podobnie, możliwość wyszukiwania danych w tabeli klienci również została usunięta z uwagi na odebranie uprawnienia SELECT. To pokazuje, jak kluczowe jest zrozumienie struktury uprawnień w SQL, gdzie każdy typ uprawnienia ma swoje własne znaczenie. W praktyce, w wielu organizacjach ważne jest, aby administracja bazą danych była przeprowadzana zgodnie z zasadą najmniejszych uprawnień, aby ograniczyć dostęp do krytycznych operacji oraz zminimalizować ryzyko błędów i incydentów związanych z bezpieczeństwem. Z tego powodu, odpowiedzi sugerujące, że jan ma jakieś uprawnienia do wstawiania lub usuwania danych w tabeli klienci, są nieprawidłowe, ponieważ zostały one jasno odwołane w ostatnim poleceniu.
Pytanie 39

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

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

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

A. zmiana nazwy kolumny cena na float
B. usunięcie kolumny cena o typie float
C. zmiana typu na float dla kolumny cena
D. dodanie kolumny cena o typie float, o ile nie istnieje
Odpowiedzi, które mówią o usunięciu kolumny albo zmianie jej nazwy, pokazują, że coś nie do końca zrozumiałeś polecenie ALTER TABLE. Jak chcesz usunąć kolumnę, to robisz to przez 'DROP COLUMN', a nie poprzez modyfikację, jak w tym przypadku. Jeśli chodzi o zmianę nazwy kolumny, to używa się polecenia 'RENAME', a nie 'MODIFY'. Takie mylne interpretacje mogą prowadzić do nieporozumień, szczególnie w zarządzaniu tabelami w bazach danych. Ważne, żeby wiedzieć, że 'ALTER TABLE artykuły MODIFY cena float;' modyfikuje istniejącą kolumnę, a nie dodaje nową. Odpowiedzi sugerujące dodawanie kolumny są w tej sytuacji po prostu błędne. W praktyce, dobrze jest znać różnice między dodawaniem, usuwaniem i modyfikowaniem, bo to fundamentalne dla zrozumienia SQL i zarządzania danymi.
Rozpocznij nowy egzamin
Powrót do strony głównej