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: 8 czerwca 2026 14:18
  • Data zakończenia: 8 czerwca 2026 14:21

Egzamin niezdany

Wynik: 15/40 punktów (37,5%)

Wymagane minimum: 20 punktów (50%)

Udostępnij swój wynik
Szczegółowe wyniki:
Pytanie 1

W tabeli artykuly w bazie danych sklepu znajduje się pole o nazwie nowy. Jak należy wykonać kwerendę, aby wypełnić to pole wartościami TRUE dla wszystkich rekordów?

A. UPDATE artykuly SET nowy=TRUE;
B. INSERT INTO artykuly VALUE nowy=TRUE;
C. UPDATE nowy FROM artykuly VALUE TRUE;
D. INSERT INTO nowy FROM artykuly SET TRUE;
Pozostałe odpowiedzi są błędne z kilku powodów. Pierwsza, 'INSERT INTO artykuly VALUE nowy=TRUE;', jest niepoprawna, bo instrukcja INSERT służy do dodawania nowych rekordów, a nie do aktualizacji tych, które już są. Używanie tej komendy w kontekście aktualizacji to poważny błąd w zrozumieniu baz danych. Druga odpowiedź, 'UPDATE nowy FROM artykuly VALUE TRUE;', też nie jest dobra, bo składnia tutaj jest błędna. Komenda UPDATE nie używa słowa 'FROM' w taki sposób i brakuje też struktury, która określałaby, które rekordy mają być zmienione. Ostatnia odpowiedź, 'INSERT INTO nowy FROM artykuly SET TRUE;', jeszcze bardziej myli, bo 'INSERT INTO' nie służy do zmiany wartości w kolumnie. Raczej dodaje nowe wiersze do tabeli. Takie podejście łamie zasady SQL i może prowadzić do błędów w zapytaniach. Ważne jest, żeby zrozumieć różnice pomiędzy INSERT a UPDATE, aby skutecznie zarządzać danymi.

Pytanie 2

Na zaprezentowanej tabeli dotyczącej samochodów wykonano zapytanie SQL SELECT

SELECT model FROM samochody WHERE rocznik=2016;
Jakie wartości zostaną zwrócone w wyniku tego zapytania?
Ilustracja do pytania
A. Fiat, Opel, Toyota
B. Czerwony, grafitowy
C. Punto, Corsa, Corolla
D. Punto, Corsa, Astra, Corolla, Yaris
Zapytanie SQL, które podałeś, czyli SELECT model FROM samochody WHERE rocznik=2016, jest zaprojektowane tak, żeby wyciągnąć z tabeli samochody wszystkie modele aut z rocznika 2016. To ogranicza wynik tylko do tych modeli, które spełniają ten właśnie warunek. Patrząc na dostarczoną tabelę, widzimy, że modele z rocznika 2016 to Punto, Corsa i Corolla. Więc z tego zapytania otrzymamy tylko te trzy modele. W realnym świecie, zapytania SQL są mega przydatne przy filtrowaniu danych w bazach. Zrozumienie, jak pisać zapytania SELECT, jest naprawdę ważne, zwłaszcza dla analityków i administratorów. Dobrze jest znać zasady budowania zapytań, żeby były one jasne i precyzyjne, bo to pozwala lepiej zarządzać i analizować dane. Ta wiedza to podstawa w analizie danych, gdzie umiejętność wyciągania odpowiednich informacji jest kluczowa do podejmowania dobrych decyzji biznesowych.

Pytanie 3

W tabeli podzespoly należy zaktualizować wartość pola URL na "toshiba.pl" dla wszystkich rekordów, w których pole producent jest równe TOSHIBA. Jak będzie wyglądała ta zmiana w języku SQL?

A. UPDATE podzespoly SET URL = 'toshiba.pl';
B. UPDATE producent='TOSHIBA' SET URL = 'toshiba.pl';
C. UPDATE podzespoly.producent='TOSHIBA' SET URL = 'toshiba.pl';
D. UPDATE podzespoly SET URL='toshiba.pl' WHERE producent='TOSHIBA';
Wszystkie odpowiedzi, które nie zawierają poprawnej składni SQL, prowadzą do błędów w wykonywaniu aktualizacji. Przykładowo, pierwsze podejście do aktualizacji polega na usunięciu klauzuli WHERE, co skutkuje zaktualizowaniem wartości URL dla wszystkich rekordów w tabeli, a nie tylko dla tych, które dotyczą producenta 'TOSHIBA'. Taki błąd może prowadzić do masowej utraty danych, co jest niedopuszczalne w zarządzaniu bazami danych. W drugiej niepoprawnej odpowiedzi następuje zmiana w logicznym układzie zapytania, co prowadzi do błędu składniowego. Nie możemy zacząć od przypisania wartości do pola producent, a następnie ustawić URL; składnia aktualizacji wymaga innego porządku. Trzecia odpowiedź również jest niepoprawna, ponieważ sugeruje użycie kropki w odniesieniu do pola producent, co jest sprzeczne z konwencjami SQL. W SQL nie stosuje się kropki do oddzielania pól i tabeli w kontekście aktualizacji. Takie błędy składniowe mogą prowadzić do tego, że zapytanie nie zostanie wykonane, a użytkownik nie osiągnie zamierzonego efektu aktualizacji. Użycie niepoprawnej składni w SQL nie tylko ogranicza funkcjonalność, ale może również generować poważne problemy w zarządzaniu danymi.

Pytanie 4

Jakie uprawnienia są wymagane do tworzenia i przywracania kopii zapasowej w MS SQL Server?

A. zwykłego użytkownika (Users)
B. użytkownika zabezpieczeń
C. użytkownika lokalnego
D. administratora systemu
Tworzenie i przywracanie kopii zapasowej całej bazy w MS SQL Server to operacja krytyczna dla bezpieczeństwa danych, dlatego wymaga najwyższych uprawnień - poziomu administratora systemu (np. roli sysadmin). Zwykły użytkownik bazy ich nie ma. Dlatego do backupu i przywracania potrzebne są uprawnienia administratora systemu.

Pytanie 5

W SQL prawo SELECT w poleceniu GRANT umożliwia użytkownikowi bazy danych na

A. zmianę danych w tabeli
B. usuwanie danych z tabeli
C. pobieranie danych z tabeli
D. tworzenie nowych tabel
Wybór innych opcji jako odpowiedzi jest błędny, ponieważ każda z nich odnosi się do różnych operacji, które nie są związane z przywilejem SELECT. Pierwsza z błędnych odpowiedzi sugeruje, że GRANT SELECT pozwala na modyfikowanie danych w tabeli, co jest nieprawdziwe, gdyż operacje modyfikujące dane wymagają przywileju UPDATE. Użytkownicy muszą mieć odpowiednie uprawnienia do zmiany danych, a SELECT nie daje takich możliwości. Druga odpowiedź wskazuje na usuwanie danych z tabeli, co również jest błędne, ponieważ usuwanie rekordów wymaga przywileju DELETE. Przywilej SELECT nie ma żadnego związku z operacjami, które niszczą lub eliminują dane, a jego rolą jest jedynie umożliwienie ich odczytu. Trzecia niepoprawna odpowiedź dotyczy tworzenia tabeli, co wymaga przywileju CREATE. Przywilej SELECT nie daje użytkownikowi możliwości wprowadzania strukturalnych zmian w bazie danych, a jego funkcjonalność ogranicza się jedynie do odczytu danych. W związku z tym, przyznanie przywileju SELECT nie daje użytkownikowi żadnych uprawnień do modyfikowania, usuwania ani tworzenia tabel, co czyni te odpowiedzi nieadekwatnymi w kontekście pytania.

Pytanie 6

Które polecenie nadaje użytkownikowi „uczen” najniższy poziom uprawnień (tylko odczyt, bez zmiany danych i struktury)?

A.
GRANT DROP ON szkola.przedmioty TO uczen;
B.
GRANT SELECT ON szkola.przedmioty TO uczen;
C.
GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
D.
GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;
Pozostałe polecenia nadają uprawnienia znacznie szersze i bardziej ryzykowne. DROP pozwala usuwać obiekty bazy (np. całe tabele), więc to bardzo wysokie uprawnienie. Połączenie INSERT i DROP daje prawo dodawania danych oraz kasowania obiektów - dużo więcej niż sam odczyt. ALTER umożliwia zmianę struktury tabeli (dodawanie/usuwanie kolumn). Najniższy poziom - tylko podgląd danych - zapewnia GRANT SELECT, dlatego ta odpowiedź jest poprawna.

Pytanie 7

Z jakim problemem wiąże się poziom izolacji transakcji Repeatable Read (powtarzalny odczyt)?

A. z odczytami widmowymi (phantom reads)
B. z utratą aktualizacji
C. z brudnymi odczytami
D. z niepowtarzalnymi odczytami
Poziom izolacji Repeatable Read gwarantuje, że te same wiersze odczytane w transakcji nie zmienią się - ale wciąż dopuszcza ODCZYTY WIDMOWE (phantom reads): gdy inna transakcja DODA nowe wiersze pasujące do warunku, powtórne zapytanie może zwrócić ich więcej. Zapamiętaj: Repeatable Read blokuje zmiany istniejących wierszy, lecz nie pojawianie się nowych (widm).

Pytanie 8

Tabela faktury w bazie danych zawiera pola: numer, data, id_klienta, wartość oraz status. Każdego dnia tworzony jest raport dotyczący faktur z dnia bieżącego. Zawiera on jedynie numery oraz wartości faktur. Która z poniższych kwerend SQL pozwoli na wygenerowanie tego raportu?

A. SELECT * FROM faktury;
B. SELECT numer, wartość FROM faktury;
C. SELECT * FROM faktury WHERE data=CURRENT_DATE();
D. SELECT numer, wartosc FROM faktury WHERE data=CURRENT_DATE();
Analizując inne dostępne kwerendy, możemy zauważyć, że nie spełniają one wymogów skutecznego raportowania faktur z bieżącego dnia. Pierwsza z nich, która wykorzystuje 'SELECT * FROM faktury;', zwraca wszystkie kolumny z tabeli faktury, co nie jest zgodne z wymaganiami, ponieważ nie ogranicza wyników do tylko dwóch pożądanych pól, czyli numeru i wartości. Takie podejście generowałoby zbędne dane, co mogłoby prowadzić do niewłaściwej analizy. Druga kwerenda, 'SELECT numer, wartość FROM faktury;', z kolei nie zawiera żadnego filtra daty, przez co zwracałaby numery i wartości wszystkich faktur, niezależnie od daty ich wystawienia. To podejście nie dostarczałoby potrzebnych informacji dotyczących tylko bieżącego dnia, co jest kluczowe w kontekście tworzenia codziennego raportu. Ostatnia z błędnych odpowiedzi to 'SELECT * FROM faktury WHERE data=CURRENT_DATE();'. Choć ta kwerenda zawiera właściwy warunek daty, to znowu, użycie '*' powoduje, że zwracane są wszystkie kolumny, a nie tylko te, które są istotne dla raportu. Takie podejście jest nieefektywne, a także niezgodne z najlepszymi praktykami tworzenia raportów, które powinny być zwięzłe i skoncentrowane na kluczowych informacjach.

Pytanie 9

Która kwerenda ustawi wartość 0 w kolumnie przebieg tabeli samochody?

A.
UPDATE samochody SET przebieg = 0;
B.
UPDATE przebieg SET 0 FROM samochody;
C.
UPDATE przebieg SET 0 TABLE samochody;
D.
UPDATE samochody SET przebieg VALUE 0;
Pozostałe zapisy mają błędną składnię. Po UPDATE musi stać nazwa TABELI (samochody), a nie kolumny, więc UPDATE przebieg ... jest błędne. SET wymaga przypisania kolumna = wartość, a nie VALUE. Poprawne jest UPDATE samochody SET przebieg = 0;.

Pytanie 10

Tabela wycieczki ma pola nazwa, cena, miejsca. Która kwerenda zwróci nazwy wycieczek tańszych niż 2000 i z CO NAJMNIEJ 4 wolnymi miejscami?

A.
SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3;
B.
SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4;
C.
SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4;
D.
SELECT * FROM wycieczki WHERE cena < 2000 OR miejsca > 3;
Pozostałe zapytania zawodzą. OR wystarczyłoby spełnić jeden warunek, więc zwróciłby też wycieczki drogie lub bez miejsc. miejsca > 4 pomija wycieczki z DOKŁADNIE 4 miejscami, choć te spełniają „co najmniej 4”. SELECT * zwraca wszystkie kolumny zamiast samych nazw. Poprawne jest cena < 2000 AND miejsca > 3.

Pytanie 11

Którego typu danych w MySQL należy użyć, aby w jednym polu zapisać datę i czas?

A.
DATE
B.
YEAR
C.
BOOLEAN
D.
TIMESTAMP
Pozostałe typy przechowują tylko fragment informacji lub coś innego. DATE zapisuje samą datę (bez godziny) - nie da się w nim zapamiętać czasu. YEAR przechowuje wyłącznie rok, więc to jeszcze mniej danych. BOOLEAN to typ logiczny przyjmujący prawda/fałsz, zupełnie niezwiązany z datą. Datę razem z czasem przechowuje TIMESTAMP (lub DATETIME), dlatego ta odpowiedź jest poprawna.

Pytanie 12

Jakie zapytanie pozwoli Administratorowi cofnąć uprawnienia do przeglądania oraz modyfikacji danych w bazie gazeta dla użytkownika redaktor?

A. REVOKE SELECT, UPDATE ON gazeta.* FROM 'redaktor'@'localhost';
B. REVOKE SELECT, ALTER ON gazeta.* FROM 'redaktor'@'localhost';
C. GRANT SELECT, UPDATE ON gazeta.* TO 'redaktor'@'localhost';
D. GRANT SELECT, ALTER ON gazeta.* TO 'redaktor'@'localhost';
Wybór innych odpowiedzi prowadzi do nieporozumień dotyczących zarządzania uprawnieniami w bazach danych. Na przykład, REVOKE SELECT, ALTER ON gazeta.* FROM 'redaktor'@'localhost'; jest niewłaściwe, ponieważ ALTER nie jest związane z przeglądaniem ani aktualizowaniem danych, lecz z modyfikowaniem struktury bazy danych, co nie jest celem tego pytania. Użytkownik mógłby mylnie uznać, że ALTER jest potrzebne do zarządzania danymi, jednak w rzeczywistości dotyczy to jedynie zmiany tabel, kolumn czy indeksów. Podobnie, polecenie GRANT SELECT, UPDATE ON gazeta.* TO 'redaktor'@'localhost'; jest całkowicie przeciwne do zamierzonego celu, ponieważ GRANT przyznaje uprawnienia, a nie je odbiera, co oznacza, że narusza zasadę, która miałaby zlikwidować dostęp do bazy danych. Ostatnia propozycja, GRANT SELECT, ALTER ON gazeta.* TO 'redaktor'@'localhost'; również jest fałszywa, ponieważ wprowadza dodatkowe uprawnienia, co może prowadzić do nieautoryzowanego dostępu do danych. Kluczowym błędem myślowym jest nieodróżnienie poleceń REVOKE i GRANT oraz nieznajomość różnicy między rodzajami uprawnień, co jest fundamentalne w zarządzaniu bezpieczeństwem danych.

Pytanie 13

Jak zbudować zapytanie SELECT, aby wyświetlić nazwiska mieszkańców bez powtórzeń (unikalne)?

A.
SELECT nazwisko FROM mieszkancy ORDER BY nazwisko;
B.
SELECT DISTINCT nazwisko FROM mieszkancy;
C.
SELECT TOP 10 nazwisko FROM mieszkancy;
D.
SELECT AVG(nazwisko) FROM mieszkancy;
Pozostałe zapytania nie usuwają duplikatów. Wariant z ORDER BY jedynie ułoży nazwiska alfabetycznie - powtarzające się wpisy nadal się pojawią, tylko obok siebie. TOP 10 obetnie wynik do dziesięciu wierszy, co nie ma związku z unikalnością, a w MySQL i tak używa się raczej LIMIT. AVG(nazwisko) to funkcja agregująca licząca średnią z wartości liczbowych - dla tekstu jak nazwisko jest bezużyteczna. Każde nazwisko raz zwróci SELECT DISTINCT.

Pytanie 14

W systemie baz danych sklepu znajdują się dwie tabele powiązane ze sobą relacją: produkty oraz oceny. Tabela oceny zawiera dowolną liczbę ocen wystawionych przez klientów dla konkretnego produktu, które są zdefiniowane przez pola: id, ocena (pole numeryczne), produktID (klucz obcy). Aby uzyskać maksymalną ocenę dla produktu o ID równym 10, należy użyć zapytania

A. MAX SELECT ocena FROM oceny WHERE produktID = 10;
B. SELECT MAX(ocena) FROM oceny WHERE produktID = 10;
C. COUNT MAX SELECT ocena FROM oceny WHERE produktID = 10;
D. SELECT MAX COUNT(ocena) FROM oceny WHERE produktID = 10;
W odpowiedziach błędnych występują różne nieporozumienia dotyczące składni SQL oraz sposobu korzystania z funkcji agregujących. Przykładowo, pierwsza propozycja "MAX SELECT ocena FROM oceny WHERE produktID = 10;" jest niepoprawna, ponieważ nie przestrzega właściwej składni SQL. Słowo kluczowe MAX() powinno być używane jako funkcja, a nie jako część polecenia SELECT. Z kolei trzecia odpowiedź "COUNT MAX SELECT ocena FROM oceny WHERE produktID = 10;" również nie ma sensu, ponieważ COUNT() jest inną funkcją agregującą, która zlicza rekordy, a nie znajduje maksymalnej wartości. Kolejna sugestia, "SELECT MAX COUNT(ocena) FROM oceny WHERE produktID = 10;", jest niepoprawna z tego samego powodu - nie można użyć MAX() i COUNT() razem w taki sposób. Często takie nieprawidłowe podejścia wynikają z nieporozumienia dotyczącego funkcji agregujących i ich zastosowania w kontekście SQL. Kluczowe jest, aby rozumieć, że funkcje takie jak MAX() i COUNT() służą do różnych celów: MAX() znajduje najwyższą wartość, podczas gdy COUNT() zlicza wystąpienia danej wartości. Dlatego niezbędne jest solidne zrozumienie działania tych funkcji oraz ich odpowiedniego użycia w zapytaniach SQL, co stanowi fundament dobrych praktyk w analizie danych w relacyjnych bazach danych.

Pytanie 15

Co chce osiągnąć poniższe zapytanie MySQL?

ALTER TABLE ksiazki
MODIFY tytul VARCHAR(100) NOT NULL;
A. Zmienić typ kolumny w tabeli ksiazki
B. Dodać do tabeli ksiazki kolumnę tytul
C. Usunąć kolumnę tytul z tabeli ksiazki
D. Zmienić nazwę kolumny w tabeli ksiazki
Rozważając inne odpowiedzi, warto zrozumieć, dlaczego nie są poprawne. Dodanie kolumny do tabeli w SQL realizowane jest za pomocą polecenia ADD, co różni się od użytego tutaj MODIFY. Polecenie ADD jest używane, gdy chcemy wprowadzić nową kolumnę, której wcześniej w tabeli nie było. Z kolei usunięcie kolumny wymaga użycia DROP COLUMN, co także odbiega od przedstawionego polecenia. Polecenie DROP COLUMN jest bardziej destrukcyjne, ponieważ usuwa całą kolumnę i jej dane. Zmiana nazwy kolumny w SQL zazwyczaj wymaga użycia polecenia RENAME, które służy do zmiany nazewnictwa kolumn lub tabel. W zależności od systemu zarządzania bazą danych (DBMS), składnia może się różnić, ale w MySQL często używa się RENAME COLUMN. Błędne rozumienie tych poleceń często wynika z niewystarczającego zapoznania się z dokumentacją danego DBMS, co może prowadzić do zastosowania nieodpowiednich poleceń. Praktyka i znajomość standardów SQL pomagają uniknąć takich pomyłek, zapewniając poprawną i efektywną pracę z bazą danych.

Pytanie 16

Jak określa się część strukturalnego języka zapytań, która dotyczy tworzenia zapytań do bazy danych za pomocą polecenia SELECT?

A. SQL DML (ang. Data Manipulation Language)
B. SQL DCL (ang. Data Control Language)
C. SQL DDL (ang. Data Definition Language)
D. SQL DQL (ang. Data Query Language)
Wybór SQL DML, SQL DCL lub SQL DDL jako odpowiedzi na to pytanie wskazuje na nieporozumienie dotyczące funkcji poszczególnych podzbiorów SQL. SQL DML (Data Manipulation Language) odnosi się do poleceń, które modyfikują dane w bazie, takich jak INSERT, UPDATE i DELETE. Myląc te pojęcia, można sądzić, że polecenia te są odpowiednie do pobierania danych, co jest błędne. Z kolei SQL DCL (Data Control Language) służy do zarządzania uprawnieniami użytkowników i kontroli dostępu do danych, co również nie ma związku z formułowaniem zapytań do bazy danych. Na przykład, polecenia GRANT i REVOKE są kluczowe w kontekście DCL, ale nie mają nic wspólnego z wyciąganiem danych. SQL DDL (Data Definition Language) dotyczy definicji struktury bazy danych, czyli tworzenia, modyfikowania i usuwania tabel oraz innych obiektów bazy danych (np. CREATE, ALTER, DROP). Wybór któregokolwiek z tych podzbiorów zamiast DQL wskazuje na brak zrozumienia hierarchii i celów SQL jako całości. Zrozumienie różnic między tymi podzbiorami jest kluczowe dla skutecznego zarządzania danymi i efektywnej pracy z bazami danych. Dobrą praktyką jest zapoznanie się z pełnym zakresem możliwości SQL, aby lepiej wykorzystać jego potencjał w codziennej pracy z danymi.

Pytanie 17

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

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

idmarkamodelrocznik
1FiatPunto2016
2FiatPunto2002
3FiatPunto2007
4OpelCorsa2016
5OpelAstra2003
6ToyotaCorolla2016
7ToyotaCorolla2014
8ToyotaYaris2004
A. Wszystkie id
B. Pole id równe 7 oraz 8
C. Tylko id równe 8
D. Brak danych
Podczas analizy zapytania SQL należy zwrócić uwagę na sposób, w jaki operator LIKE działa na ciągach znaków w kolumnach baz danych. Zapytanie w tym przypadku używa składni LIKE w połączeniu z symbolem podkreślenia (_) jako znakiem zastępczym, który reprezentuje dowolny pojedynczy znak. Często błędnie zakłada się, że zapytanie wybiera wszystkie rekordy zawierające wartość '4' na końcu rocznika, co jest niepoprawne. Operator LIKE jest bardziej złożony i używa symbolu podkreślenia do reprezentowania dokładnie jednego znaku. Dlatego wzorzec '2_4' oznacza, że rok musi mieć na drugiej pozycji cyfrę '2' a na ostatniej '4'. To oznacza, że jedynie roczniki 2014 i 2004 spełniają ten wzorzec, dlatego odpowiadające im identyfikatory to 7 i 8. Częstym błędem jest nieprawidłowe zrozumienie funkcji LIKE i traktowanie jej podobnie jak operatora równości, co może prowadzić do niepoprawnych wniosków dotyczących zakresu danych, które zostaną wybrane. Dlatego zrozumienie działania różnych operatorów SQL oraz uważność w analizie wzorców jest kluczowe w pracy z bazami danych.

Pytanie 18

Tabele Klienci oraz Zgloszenia są związane relacją jeden do wielu. Jakie polecenie należy wydać, aby uzyskać tylko opis zgłoszenia oraz odpowiadające mu nazwisko klienta dla zgłoszenia numer 5?

Ilustracja do pytania
A. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.Klienci_id WHERE Klienci.id = 5
B. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.Klienci_id WHERE Zgloszenia.id = 5
C. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci WHERE Klienci.id = 5
D. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.id WHERE Zgloszenia.id = 5
Ta odpowiedź jest prawidłowa, ponieważ używa poprawnej składni SQL do wykonania zapytania z dwóch tabel powiązanych relacją jeden do wielu. Kluczowym elementem jest użycie klauzuli JOIN, która łączy tabelę Zgloszenia z tabelą Klienci poprzez pole Klienci_id, będące kluczem obcym w tabeli Zgloszenia. Dzięki temu możliwe jest powiązanie odpowiednich rekordów z dwóch tabel. Warunek w klauzuli WHERE Zgloszenia.id = 5 precyzuje, że zapytanie ma zwrócić dane tylko dla zgłoszenia o identyfikatorze 5. Taki sposób pisania zapytań SQL jest zgodny z normami ANSI SQL i jest powszechnie stosowany w systemach zarządzania bazami danych jak MySQL, PostgreSQL czy SQL Server. Korzystanie z JOIN, zwłaszcza z klauzulą ON, jest dobrą praktyką, ponieważ zapewnia czytelność i bezpieczeństwo zapytań. W realnych zastosowaniach, takie zapytania są używane do łączenia danych z różnych źródeł w celu ich analizy lub raportowania. Prawidłowa struktura zapytania ułatwia jego modyfikację i integrację z innymi operacjami bazy danych, co jest niezbędne w zarządzaniu danymi w dużych systemach informatycznych. Zrozumienie mechanizmu JOIN oraz użycie klauzuli WHERE w celu ograniczenia wyników jest kluczowe w efektywnym zarządzaniu i analizie danych w relacyjnych bazach danych.

Pytanie 19

W bazie danych istnieje tabela ksiazki, która posiada pola: tytul, id_autora, data_wypoz, id_czytelnika. Codziennie tworzony jest raport dotyczący książek wypożyczonych w danym dniu, który wyświetla jedynie tytuły książek. Która kwerenda SQL jest odpowiednia do generowania tego raportu?

A. SELECT tytul FROM ksiazki
B. SELECT * FROM ksiazki
C. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()
D. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATENT_E()
Wybór innych kwerend związany jest z różnymi nieprawidłowymi założeniami. Kwerenda SELECT tytul FROM ksiazki; nie uwzględnia żadnego filtrowania daty wypożyczenia, przez co generowany raport zawierałby wszystkie tytuły książek, niezależnie od daty ich wypożyczenia. Takie podejście jest nieefektywne, ponieważ nie spełnia założonego celu raportu, jakim jest prezentacja książek wypożyczonych jedynie w danym dniu. Z kolei SELECT * FROM ksiazki; zwraca wszystkie kolumny z tabeli książek, co prowadzi do nadmiaru danych i utrudnia analizę wyników. Raport powinien być zwięzły i dostarczać tylko istotnych informacji. Kwerenda SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATENT_E(); zawiera literówkę i jest niepoprawna syntaktycznie. Warto zwrócić uwagę na typowe błędy, takie jak błędne użycie funkcji i brak filtracji danych, które mogą prowadzić do nieefektywnych i nieczytelnych raportów. Dobrą praktyką jest zawsze dokładne zrozumienie celu zapytania oraz odpowiednie stosowanie klauzul WHERE, aby uniknąć zbędnych danych i skupić się na analizie konkretnych przypadków.

Pytanie 20

W tabeli zwierzeta znajdują się pola: nazwa, gatunek, gromada, cechy oraz dlugosc_zycia. Aby uzyskać listę nazw zwierząt, które dożywają przynajmniej 20 lat i są ssakami, należy wykonać zapytanie:

A. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >=20;
B. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >=20 AND gromada = 'ssak';
C. SELECT nazwa FROM zwierzeta WHERE gromada = 'ssak';
D. SELECT nazwa FROM zwierzeta WHERE dlugosc_zycia >=20 OR gromada = 'ssak';
Twoja odpowiedź jest jak najbardziej na miejscu, bo spełnia te dwa ważne wymagania z pytania: pokazuje nazwy zwierząt, które żyją przynajmniej 20 lat i są ssakami. Użycie AND w klauzuli WHERE sprawia, że w wynikach są tylko te zwierzęta, które pasują do obu kryteriów. To zapytanie ma swoje zastosowanie, na przykład w analizach zoologicznych, gdzie długość życia niektórych gatunków ssaków może być kluczowa, zwłaszcza w kontekście ochrony i badań nad ich ekologią. Z osobistego doświadczenia mogę powiedzieć, że dobrze jest stosować takie zapytania w bazach danych, bo to zapewnia lepszą efektywność i wydajność w przetwarzaniu danych. Generalnie w tworzeniu zapytań SQL warto zawsze ustalać konkretne warunki w klauzuli WHERE, żeby uniknąć niechcianych wyników i zmniejszyć obciążenie bazy danych.

Pytanie 21

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

A. Określenie kluczy głównych tabel, Określenie zbioru danych, Selekcja, Określenie relacji
B. Określenie zbioru danych, Selekcja, Określenie kluczy głównych tabel, Określenie relacji
C. Selekcja, Określenie relacji, Określenie kluczy głównych tabel, Określenie zbioru danych
D. Określenie relacji, Określenie kluczy głównych tabel, Selekcja, Określenie zbioru danych
Poprawna odpowiedź to 'Określenie zbioru danych, Selekcja, Określenie kluczy podstawowych tabel, Określenie relacji'. Ta kolejność pokazuje, jak działa projektowanie relacyjnej bazy danych. Na początku trzeba określić, jakie dane będą przechowywane, czyli stworzyć zbiór danych. Potem trzeba wybrać, które z tych informacji są ważne i jak je ułożyć. Następnie ustalamy klucze podstawowe dla tabel. To ważne, żeby dane były unikalne i łatwe do zidentyfikowania. Na końcu definiujemy relacje między tabelami, co pozwala zrozumieć, jak dane ze sobą współpracują. Na przykład, kiedy projektujemy bazę danych dla szkoły, zbór danych może obejmować uczniów, nauczycieli i przedmioty. Wybierając dane, możemy zdecydować, że potrzebujemy imienia, nazwiska i przedmiotów, które uczniowie uczą się. Klucze podstawowe są wtedy używane do identyfikacji uczniów, a relacje pokazują, jak uczniowie są powiązani z nauczycielami i przedmiotami.

Pytanie 22

W teorii relacji operacja selekcji polega na

A. wybraniu krotek, które nie zawierają wartości NULL
B. eliminuje krotki z powtarzającymi się polami
C. pozbywaniu się pustych wierszy
D. wybraniu krotek, które spełniają określone warunki
Operacja selekcji w algebrze relacji polega na wydobywaniu z bazy danych krotek, które spełniają określone warunki. Tego rodzaju operacje są kluczowe w kontekście zapytań do baz danych, ponieważ pozwalają na precyzyjne filtrowanie danych. Na przykład, jeśli mamy tabelę 'Klienci' z informacjami o klientach, możemy użyć selekcji, aby wybrać tylko tych, którzy mają status 'aktywny', co pozwala nam skoncentrować się na aktualnych użytkownikach. Takie podejście jest zgodne z podstawowymi zasadami zarządzania danymi, w tym z zasadą minimalizacji danych, która mówi, że należy pracować tylko z tymi informacjami, które są istotne do danego zadania. Ponadto, operacja selekcji jest często używana w połączeniu z innymi operacjami, takimi jak projekcja czy łączenie, co pozwala na budowanie bardziej złożonych zapytań i uzyskiwanie bardziej szczegółowych informacji. W praktyce, umiejętność skutecznego stosowania selekcji jest niezbędna dla każdego, kto pracuje z bazami danych, a znajomość tej operacji stanowi podstawę dla bardziej zaawansowanych technik analizy danych.

Pytanie 23

W relacyjnych bazach danych encja jest przedstawiana przez

A. rekord.
B. tabelę.
C. relację.
D. kwerendę.
Nieprawidłowe odpowiedzi wskazują na pewne nieporozumienia dotyczące definicji podstawowych elementów relacyjnych baz danych. Rekord, chociaż jest istotnym składnikiem tabeli, nie reprezentuje encji, lecz pojedynczą instancję encji. Mylne jest również utożsamianie tabeli z relacją, ponieważ relacja w kontekście teorii zbiorów odnosi się do zbioru krotek, podczas gdy tabela jest fizycznym i trwałym przedstawieniem tychże zbiorów w bazie danych. Kwerenda natomiast to instrukcja używana do uzyskiwania danych z bazy danych, a nie do ich reprezentacji. To podejście do zrozumienia modeli relacyjnych może prowadzić do błędnych wniosków w projektowaniu baz danych. Dla przykładu, nieumiejętność rozróżnienia między tabelą a rekordem może skutkować niewłaściwym modelowaniem danych, co wpłynie negatywnie na wydajność i integralność bazy danych. Warto zwrócić uwagę na znaczenie właściwego stosowania terminologii oraz zrozumienie struktury danych w relacyjnych bazach danych, co jest kluczowe dla efektywnego zarządzania danymi i ich relacjami.

Pytanie 24

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

A. stworznie nowego użytkownika oraz przydzielenie mu uprawnień do bazy
B. utworzenie użytkownika
C. pokazanie danych o istniejącym użytkowniku
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 25

Co oznacza polecenie:

UPDATE artykuly SET cena = cena * 0.7 WHERE kod = 2;
?
A. obniża wartość pola cena dla rekordów, gdzie kod = 2
B. dodaje do tabeli nowe pola cena i kod
C. obniża cenę o 30% dla WSZYSTKICH artykułów
D. dodaje pole cena z atrybutem kod
Polecenie UPDATE artykuly SET cena = cena * 0.7 WHERE kod = 2; mnoży dotychczasową cenę przez 0,7 (czyli obniża ją o 30%), ale TYLKO dla rekordów, gdzie kod = 2 - warunek WHERE ogranicza zmianę do wybranych wierszy. Dlatego obniża cenę dla rekordów z kod = 2.

Pytanie 26

W bazie danych dotyczącej pojazdów pole kolor w tabeli samochody może mieć wartości jedynie z definicji lakier. Aby nawiązać relację między tabelami samochody a lakier, należy użyć kwerendy

A. ALTER TABLE samochody ADD FOREIGN KEY barwa REFERENCES samochody.lakier;
B. ALTER TABLE samochody ADD FOREIGN KEY kolor REFERENCES lakier;
C. ALTER TABLE lakier ADD FOREIGN KEY (barwa) REFERENCES samochody(kolor);
D. ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);
Odpowiedź "ALTER TABLE samochody ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);" jest poprawna, ponieważ prawidłowo definiuje klucz obcy w tabeli samochody, wskazując, że kolumna kolor w tej tabeli odnosi się do kolumny lakierId w tabeli lakier. Umożliwia to zapewnienie integralności referencyjnej, co oznacza, że wartości koloru w tabeli samochody będą mogły przyjmować tylko te wartości, które istnieją w tabeli lakier. Jest to standardowa praktyka w projektowaniu baz danych, która pomaga zapobiegać błędom, takim jak wprowadzenie koloru, który nie jest dostępny w zbiorze dozwolonych opcji. W praktyce, podczas dodawania nowego wpisu do tabeli samochody, system bazy danych automatycznie sprawdzi, czy dany kolor istnieje w tabeli lakier. Takie podejście zapewnia większą spójność danych oraz ułatwia zarządzanie them, zwłaszcza w większych aplikacjach, gdzie liczba potencjalnych wartości kolorów może być znaczna. Stosowanie kluczy obcych jest zgodne z zasadami normalizacji baz danych, co przyczynia się do ich efektywności i skalowalności.

Pytanie 27

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

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

Pytanie 28

Co oblicza funkcja agregująca MIN w SQL?

A. najmniejszą wartość w kolumnie wyniku
B. długość tekstu w rekordach
C. liczbę zwróconych wierszy
D. średnią wartości pól rekordu
Funkcja agregująca MIN zwraca NAJMNIEJSZĄ wartość z kolumny w wyniku zapytania - np. najniższą cenę czy najwcześniejszą datę. Dlatego MIN oblicza najmniejszą wartość w kolumnie.

Pytanie 29

Tworząc tabelę produkty, dla pola „cena” (kwota z groszami) najlepszy typ danych to:

A.
ENUM
B.
DECIMAL(10, 2)
C.
INTEGER(11)
D.
TINYTEXT
Pozostałe typy nie nadają się do dokładnej kwoty. ENUM pozwala wybrać jedną z wcześniej zdefiniowanych wartości tekstowych - nie służy do liczb ani cen. INTEGER przechowuje wyłącznie liczby całkowite, więc nie zapisze groszy (części po przecinku). TINYTEXT to typ tekstowy - kwota zapisana jako tekst utrudniałaby obliczenia i sortowanie po wartości. Dokładną cenę z groszami przechowuje DECIMAL(10, 2), dlatego ta odpowiedź jest poprawna.

Pytanie 30

Utworzono bazę danych z tabelą mieszkancy, która zawiera pola: nazwisko, imie, miasto. Następnie zrealizowano poniższe zapytanie do bazy:

SELECT nazwisko, imie FROM mieszkancy WHERE miasto="Poznań" UNION ALL SELECT nazwisko, imie FROM mieszkancy WHERE miasto="Kraków"
Wskaż zapytanie, które zwróci te same dane:
A. SELECT nazwisko, imie FROM mieszkancy WHERE miasto="Poznań" OR miasto="Kraków"
B. SELECT nazwisko, imie FROM mieszkancy AS "Poznań" OR "Kraków"
C. SELECT nazwisko, imie FROM mieszkancy WHERE miasto BETWEEN "Poznań" OR "Kraków"
D. SELECT nazwisko, imie FROM mieszkancy WHERE miasto HAVING "Poznań" OR "Kraków"
Wybrana odpowiedź jest poprawna, ponieważ wykorzystuje operator logiczny OR do połączenia dwóch warunków w klauzuli WHERE. W wyniku tego zapytania zostaną zwrócone wszystkie rekordy z tabeli 'mieszkancy', gdzie miasto to 'Poznań' lub 'Kraków'. To podejście jest zgodne z zasadami SQL, gdzie operator OR umożliwia łączenie warunków, co jest powszechnie stosowane w praktyce. Warto zauważyć, że zapytanie z wykorzystaniem operatora UNION ALL, które było pierwotnie zdefiniowane, również łączy wyniki z dwóch zapytań, ale każdy SELECT działa osobno. Użycie OR w tym przypadku jest bardziej efektywne, ponieważ pozwala na jedno zapytanie, co może przyspieszyć wykonanie w porównaniu do kilku zapytań UNION. W praktycznych zastosowaniach, gdy mamy do czynienia z wieloma kryteriami, stosowanie operatorów logicznych jest kluczowe dla uzyskania precyzyjnych wyników.

Pytanie 31

Model, w którym wszystkie dane są zapisane w jednej tabeli, określa się mianem

A. sieciowym
B. hierarchicznym
C. relacyjnym
D. jednorodnym
Modele sieciowe i hierarchiczne są zupełnie inne od modelu jednorodnego, bo wprowadzają więcej złożoności w to, jak dane są trzymane. Na przykład model sieciowy pozwala tworzyć różne powiązania jak w grafie, co daje większą elastyczność, ale już dla prostych aplikacji to może być przesada. Z kolei model hierarchiczny z tą swoją drzewiastą strukturą też potrafi namieszać, bo trudniej wtedy zarządzać informacjami. Żeby dobrze zrozumieć, jak to wszystko działa, trzeba pojąć hierarchię i jak ze sobą te dane grają, co czasami bywa problematyczne, jak relacje się zmieniają. Moim zdaniem, w modelu relacyjnym, gdzie dane są w różnych tabelach połączonych kluczami, zyskujemy więcej elastyczności, ale też zwiększa się złożoność. Dlatego często można się zagubić w tych wszystkich możliwościach, a model jednorodny zazwyczaj jest najlepszy tylko tam, gdzie nic skomplikowanego nie trzeba. Większość systemów bazodanowych korzysta jednak z modelu relacyjnego, bo to zgodne ze standardami SQL, co ułatwia życie na dłuższą metę.

Pytanie 32

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

A. Zdefiniowanie celu, normalizacja, utworzenie tabel, stworzenie relacji
B. Zdefiniowanie celu, stworzenie tabel, utworzenie relacji, normalizacja
C. Zdefiniowanie celu, normalizacja, utworzenie relacji, stworzenie tabel
D. Zdefiniowanie celu, utworzenie relacji, stworzenie tabel, 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 33

Podczas przechowywania hasła użytkownika serwisu internetowego (np. bankowości online), aby chronić je przed ujawnieniem, zazwyczaj stosuje się funkcję

A. mieszających.
B. abstrakcyjnych.
C. klucza.
D. cyklometrycznych.
Mieszające funkcje, choć istotne w kryptografii, nie są właściwym podejściem do zabezpieczania haseł użytkowników. Ich głównym celem jest zapewnienie, że nawet niewielka zmiana w danych wejściowych prowadzi do drastycznie różniącego się wyniku, co jest przydatne w kontekście tworzenia funkcji hashujących, ale nie wystarcza do ochrony haseł. Funkcje abstrakcyjne, z kolei, dotyczą bardziej teoretycznych modeli czy algorytmów, które nie mają bezpośredniego zastosowania w procesie zabezpieczania haseł. Kluczowe jest, aby zrozumieć, że hasła powinny być przede wszystkim szyfrowane przy użyciu odpowiednich algorytmów, a nie jedynie mieszane czy abstrakcyjne. Cyklometryczne metody również nie mają zastosowania w kontekście ochrony haseł, gdyż ich zastosowanie jest ograniczone do analizy danych czy grafów, a nie do rzeczywistych procesów szyfrowania czy zabezpieczania informacji. Dlatego błędem jest przypuszczenie, że inne metody mogą zastąpić funkcje klucza w kontekście ochrony haseł. W praktyce, stosowanie nieodpowiednich metod zabezpieczających prowadzi do poważnych luk w bezpieczeństwie, które mogą być wykorzystane przez cyberprzestępców.

Pytanie 34

Polecenie w języku SQL w formie

ALTER TABLE 'miasta' 
ADD 'kod' text; 
A. w tabeli miasta zmienia nazwę kolumny kod na text.
B. zmienia nazwę tabeli miasta na kod.
C. dodaje do tabeli dwie kolumny o nazwach: kod i text.
D. dodaje do tabeli kolumnę o nazwie kod typu text.
Wszystkie niepoprawne odpowiedzi opierają się na błędnym zrozumieniu polecenia ALTER TABLE oraz jego składni. Po pierwsze, zmiana nazwy kolumny i zmiana nazwy tabeli to operacje, które wymagają użycia innych poleceń SQL, takich jak RENAME COLUMN lub RENAME TABLE, a nie polecenia ADD. W przypadku zmiany nazwy kolumny, nie dodajemy nowej kolumny, lecz po prostu modyfikujemy istniejącą. Co więcej, zmiana tabeli za pomocą ALTER TABLE nie powoduje zamiany jej nazwy na nową, jak sugeruje jedna z odpowiedzi. Dodawanie dwóch kolumn w jednym poleceniu również jest błędne, ponieważ polecenie ADD w tym kontekście dotyczy tylko jednej kolumny. W praktyce, gdy chcemy dodać więcej niż jedną kolumnę, stosujemy wielokrotne polecenia ADD w ramach jednego ALTER TABLE lub używamy składni, która pozwala na dodanie wielu kolumn jednocześnie, ale to nadal nie jest to, co przedstawiono w tym pytaniu. Błędy te mogą wynikać z braku zrozumienia składni SQL oraz funkcji poszczególnych poleceń, co prowadzi do mylnych interpretacji i błędnych wniosków. Właściwe zrozumienie tych podstaw jest kluczowe dla efektywnego projektowania i zarządzania bazami danych.

Pytanie 35

Przedstawione polecenie MySQL ma za zadanie:

ALTER TABLE ksiazki
MODIFY tytul VARCHAR(100) NOT NULL;
A. zmienić typ kolumny tytul w tabeli ksiazki.
B. dodać do tabeli ksiazki kolumnę tytul.
C. usunąć kolumnę tytul z tabeli ksiazki.
D. zmienić nazwę kolumny w tabeli ksiazki.
Dobra robota, Twoja odpowiedź jest właściwa! W poleceniu użyto ALTER TABLE, co to jest ten typowy sposób na modyfikowanie tabel w bazach danych. No i to słowo kluczowe MODIFY wskazuje, że zmieniamy coś w już istniejącej kolumnie. W tym przypadku chodzi o kolumnę 'tytul' w tabeli 'ksiazki', której typ zmieniamy na VARCHAR(100), co znaczy, że teraz może ona mieć teksty do 100 znaków długości. Dodatkowo dodajemy ograniczenie NOT NULL, więc 'tytul' musi być zawsze wypełniony. To normalna rzecz, kiedy na przykład musimy dostosować strukturę danych, gdy na przykład zauważymy, że tytuły książek stają się dłuższe albo musimy mieć pewność, że zawsze są wprowadzone.

Pytanie 36

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

A. now
B. len
C. upper
D. year
Wybór funkcji, które pobierają argumenty, jak 'len', 'upper' i 'year', wskazuje na brak zrozumienia różnic pomiędzy funkcjami w SQL. Funkcje takie jak 'len', która zwraca długość ciągu znaków, wymagają przynajmniej jednego argumentu - ciągu, którego długość ma być obliczona. Na przykład, użycie 'len(nazwa) zwróci ilość znaków w nazwie', co jest kluczowe w scenariuszach wymagających walidacji danych. Podobnie, 'upper' przekształca wszelkie litery w podanym ciągu na wielkie litery, co również wymaga argumentu, czyli tekstu do przetworzenia. W przypadku 'year', funkcja ta wydobywa rok z daty, co również implikuje konieczność podania argumentu w postaci daty. Wybierając funkcje, które wymagają argumentów, można nieświadomie skomplikować proces, co jest sprzeczne z zasadami efektywnego pisania kodu. Błędem jest także mylenie funkcji bezargumentowych z tymi, które działają na przekazanych wartościach, co może prowadzić do nieefektywnego zarządzania danymi w bazach. Zrozumienie, jak i kiedy używać różnych typów funkcji, jest kluczowe w procesie projektowania i zarządzania bazami danych, co podkreśla znaczenie znajomości standardów SQL oraz najlepszych praktyk w programowaniu.

Pytanie 37

W tabeli zadania znajduje się pole tekstowe status. Jakie zapytanie należy użyć, aby usunąć te zadania, które mają status 'zamknięte'?

A. TRUNCATE TABLE zadania;
B. DELETE FROM zadania WHERE status = 'zamknięte';
C. DELETE FROM zadania;
D. TRUNCATE TABLE zadania WHERE status = 'zamknięte';
Odpowiedź DELETE FROM zadania WHERE status = 'zamknięte' jest poprawna, ponieważ wykorzystuje standardową składnię SQL do usuwania rekordów z tabeli na podstawie zadanych warunków. W tym przypadku, kwerenda ta usuwa tylko te wiersze, które mają wartość 'zamknięte' w polu status. Jest to podejście zgodne z dobrymi praktykami, ponieważ pozwala na precyzyjne określenie, które dane mają zostać usunięte, co minimalizuje ryzyko przypadkowego usunięcia innych rekordów. Na przykład, w systemie zarządzania projektami, możemy mieć wiele zadań z różnymi statusami, takimi jak 'otwarte', 'w trakcie', czy 'zamknięte'. Użycie tej kwerendy pozwala na oczyszczenie bazy danych z nieaktualnych zadań, co jest kluczowe dla utrzymania porządku i efektywności w zarządzaniu projektami. Ponadto, stosując tę metodę, możemy w przyszłości łatwo modyfikować warunki usuwania, na przykład zmieniając status na 'wstrzymane', zachowując elastyczność w zarządzaniu danymi.

Pytanie 38

W bazie danych samochodów pole kolor z tabeli samochody przyjmuje wartości kolorów jedynie ze słownika lakier. Aby połączyć tabele samochody i lakier relacją należy, zastosować kwerendę

A. ALTER TABLE samochody
   ADD FOREIGN KEY kolor REFERENCES lakier;

B. ALTER TABLE samochody
   ADD FOREIGN KEY (kolor) REFERENCES lakier(lakierId);

C. ALTER TABLE samochody
   ADD FOREIGN KEY barwa REFERENCES samochody.lakier;

D. ALTER TABLE lakier
   ADD FOREIGN KEY (barwa) REFERENCES samochody(kolor);
A. A.
B. B.
C. C.
D. D.
Odpowiedź B jest prawidłowa, ponieważ ciało odpowiedzi zawiera prawidłową składnię SQL do połączenia dwóch tabel: 'samochody' i 'lakier'. W przypadku relacji między tabelami, klucz obcy w jednej tabeli odpowiada kluczowi głównemu w drugiej tabeli. W tym przypadku, pole 'kolor' w tabeli 'samochody' jest kluczem obcym, który odwołuje się do klucza głównego w tabeli 'lakier' (założenie: 'lakierId'). W praktyce, połączenie tabel na podstawie relacji między kluczem obcym a kluczem głównym jest fundamentalnym aspektem projektowania bazy danych, umożliwiającym sprawną organizację i odnajdywanie danych. Dobrą praktyką jest utrzymanie integralności referencyjnej, zapewniającej, że relacje między tabelami są zawsze spójne. To z kolei umożliwia realizację zapytań złożonych, które łączą dane z wielu tabel w celu uzyskania potrzebnych informacji.

Pytanie 39

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

SELECT MAX(wiek) - MIN(wiek) FROM uczestnicy;
A. różnicę wieku pomiędzy najstarszym a najmłodszym uczestnikiem
B. najmłodszy i najstarszy wiek uczestników
C. średnią wartość wieku uczestników
D. ilość najstarszych uczestników
Wybór odpowiedzi, która sugeruje, że zapytanie zwraca minimalny oraz maksymalny wiek uczestników, jest błędny, ponieważ zapytanie wykorzystuje operację odejmowania wyników funkcji MAX i MIN. Użyte tutaj funkcje agregujące nie zwracają osobno wartości minimalnej i maksymalnej, a jedynie ich różnicę. Zrozumienie operacji MAX i MIN jest kluczowe; funkcje te są stosowane do obliczeń w celu uzyskania jednej wartości z grupy. Odpowiedź dotycząca średniej arytmetycznej wieku uczestników również jest myląca, ponieważ do obliczenia średniej potrzeba użyć funkcji AVG, a nie różnicy, która jest przedstawiona w zapytaniu. Ostatecznie, wybór opcji dotyczącej liczby najstarszych uczestników nie ma żadnego związku z zapytaniem, ponieważ nie ma w nim mowy o zliczaniu, a jedynie o różnicy wieku. Takie nieporozumienia mogą wynikać z braku jasności co do podstawowych funkcji SQL oraz ich zastosowania w analizie danych. Dlatego kluczowe jest, aby na etapie nauki SQL zwracać szczególną uwagę na kontekst użycia różnych funkcji i ich właściwe zrozumienie, aby uniknąć błędnych interpretacji wyników zapytań.

Pytanie 40

Z bazy danych trzeba uzyskać zapytaniem SQL nazwiska pracowników, którzy sprawują funkcję kierownika, a ich wynagrodzenie mieści się w jednostronnie domkniętym przedziale (3000, 4000>. Która klauzula weryfikuje ten warunek?

A. WHERE kierownik = true OR pensja > 3000 OR pensja <= 4000
B. WHERE kierownik = true AND pensja => 3000 OR pensja < 4000
C. WHERE kierownik = true AND pensja > 3000 AND pensja <= 4000
D. WHERE kierownik = true AND pensja => 3000 AND pensja <= 4000
Nieprawidłowe odpowiedzi bazują na mylnych założeniach dotyczących operatorów logicznych oraz porównawczych w SQL. Przykładowo, w przypadku użycia klauzuli 'WHERE kierownik = true OR pensja > 3000 OR pensja <= 4000;' spełniony jest warunek dla każdej z trzech części, co prowadzi do zbyt szerokiego zakresu wyników. Operator OR zwraca wyniki, jeśli przynajmniej jeden z warunków jest prawdziwy, co w rezultacie może obejmować pracowników, którzy nie są kierownikami. Klauzula 'WHERE kierownik = true AND pensja => 3000 OR pensja < 4000;' również jest niepoprawna, gdyż składnia operatora => jest błędna (powinno być >=), a ponadto użycie OR sprawia, że wyniki mogą obejmować pracowników, którzy nie spełniają wymagań pensjowych. Kolejna nieadekwatna klauzula 'WHERE kierownik = true AND pensja => 3000 AND pensja < 4000;' również zawiera błąd w zapisie operatora porównania, co uniemożliwia poprawne wykonanie zapytania. Przyczyną tych błędów są często nieznajomość operatorów oraz niepoprawne rozumienie logiki zapytań SQL. W praktyce, zrozumienie różnicy pomiędzy AND a OR oraz prawidłowe stosowanie operatorów porównawczych jest kluczowe dla uzyskania oczekiwanych wyników w bazach danych. W kontekście profesjonalnego podejścia do SQL, ważne jest także, aby zapytania były nie tylko poprawne syntaktycznie, ale również semantycznie, co zapewnia ich efektywność i wiarygodność.