Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik programista
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 10 kwietnia 2026 09:44
Data zakończenia: 10 kwietnia 2026 09:50

Egzamin niezdany

Wynik: 7/40 punktów (17,5%)

Wymagane minimum: 20 punktów (50%)

Nowe

Analiza przebiegu egzaminu— sprawdź jak rozwiązywałeś pytania

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Aby utworzyć relację wiele do wielu pomiędzy tabelami A i B, należy

A. wiele wpisów z tabeli A zduplikuje się w tabeli B

B. wprowadzić trzecią tabelę zawierającą klucze obce do tabel A i B

C. tabelę A połączyć z tabelą B przez utworzenie kluczy obcych

D. tabela A będzie miała identyczne pola jak tabela B

Twierdzenie, że wystarczy połączyć tabelę A z tabelą B za pomocą zdefiniowania kluczy obcych, jest błędne, ponieważ taka operacja tworzy jedynie relację jeden do wielu, a nie wiele do wielu. W przypadku relacji jeden do wielu jedna tabela (np. tabela A) może być połączona z wieloma rekordami w drugiej tabeli (np. tabela B), ale nie odwrotnie. Co więcej, zduplikowanie wielu rekordów z tabeli A w tabeli B prowadziłoby do powstania redundancji i nieefektywnego zarządzania danymi, co jest sprzeczne z zasadami normalizacji baz danych. Wreszcie, posiadanie tabeli A z takimi samymi polami co tabela B jest nieadekwatne i niezgodne z ideą relacji wiele do wielu. Tego typu rozwiązanie prowadziłoby do chaosu w strukturze bazy danych oraz utrudniałoby jakiekolwiek operacje na zbiorach danych. Aby zrealizować relację wiele do wielu, należy zawsze wprowadzić osobną tabelę, która będzie w stanie efektywnie łączyć obie oryginalne tabele, umożliwiając ich prawidłowe powiązanie i zarządzanie danymi.

Pytanie 2

Formularz główny używany do poruszania się w bazie danych pomiędzy formularzami i kwerendami dostępnymi w systemie określany jest jako formularz

A. głównym

B. pierwotnym

C. sterującym

D. zagnieżdżonym

Odpowiedzi takie jak 'główny', 'pierwotny' czy 'zagnieżdżony' nie odpowiadają rzeczywistości funkcjonalnej formularzy w systemach baz danych. Formularz główny może być mylony z formularzem sterującym, jednakże jego funkcjonalność jest zazwyczaj ograniczona do wyświetlania danych w jednym kontekście, bez zapewnienia możliwości nawigacji między różnymi sekcjami bazy. Z kolei termin 'pierwotny' nie jest standardowym określeniem w kontekście formularzy; może prowadzić do nieporozumień związanych z terminologią baz danych, gdzie termin 'pierwotny klucz' zyskuje znaczenie w innej sferze. Formularz zagnieżdżony odnosi się do formularzy umieszczonych wewnątrz innych formularzy, co jest zupełnie inną koncepcją i nie ma związku z ogólną nawigacją po systemie. Typowe błędy myślowe, które prowadzą do takich odpowiedzi, obejmują mylenie różnych typów formularzy i ich funkcji. Użytkownicy powinni być świadomi, że prawidłowe nazewnictwo i zrozumienie kontekstu jest kluczowe w pracy z bazami danych, co może wpływać na efektywność działania oraz na jakość wytwarzanych aplikacji.

Pytanie 3

W języku SQL, aby z tabeli Uczniowie wyodrębnić rekordy dotyczące wyłącznie uczennic o imieniu "Aleksandra", które przyszły na świat po roku "1998", należy sformułować zapytanie

A. SELECT * FROM Uczniowie WHERE imie="Aleksandra" OR rok_urodzenia > "1998"

B. SELECT * FROM Uczniowie WHERE imie ="Aleksandra" OR rok_urodzenia < "1998"

C. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia < "1998"

D. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia > "1998"

Wybór odpowiedzi zawierającej operator OR prowadzi do niepoprawnych wyników w kontekście tego zapytania. Operator OR wprowadza możliwość selekcji rekordów, które spełniają przynajmniej jeden z warunków, co nie odpowiada wymaganiu, aby zwracać wyłącznie te uczennice, które mają imię 'Aleksandra' oraz są urodzone po 1998 roku. Na przykład, w przypadku pierwszej odpowiedzi, zwrócone zostaną uczennice o imieniu 'Aleksandra' urodzone przed 1998 rokiem, co jest sprzeczne z wymaganiem, aby uwzględniać tylko uczennice urodzone po 1998 roku. Podobnie, druga odpowiedź również zwróciłaby uczennice o innych imionach, które urodziły się po 1998 roku, co nie jest zgodne z celem zapytania. Odpowiedź zawierająca operator AND jest preferowana w tym przypadku, ponieważ pozwala na dokładne określenie i weryfikację danych, co jest kluczowe w pracy z bazami danych. Prawidłowe zrozumienie różnicy między tymi operatorami jest istotne, aby unikać nieścisłości w wynikach zapytań SQL, szczególnie w kontekście przetwarzania danych w systemach informacyjnych. Operator AND jest używany w celu ograniczenia zbioru wyników, co zwiększa dokładność analizy danych, ułatwia raportowanie i podejmowanie decyzji opartych na danych.

Pytanie 4

Które ograniczenie w bazach danych, należy przypisać kolumnie tabeli, aby wartości wpisywane do niej nie powtarzały się?

A. NO REPEAT

B. SINGLE

C. UNIQUE

D. NOT NULL

Poprawnie – w relacyjnych bazach danych to właśnie ograniczenie UNIQUE zapewnia, że wartości w danej kolumnie nie będą się powtarzały. Technicznie rzecz biorąc, UNIQUE to constraint integralności, który wymusza unikalność danych w obrębie wskazanej kolumny lub zestawu kolumn. Jeżeli spróbujesz wstawić rekord z wartością, która już istnieje w tej kolumnie, silnik bazy (np. MySQL, PostgreSQL, SQL Server) zgłosi błąd naruszenia ograniczenia unikalności. Można to zobaczyć na prostym przykładzie: CREATE TABLE uzytkownicy ( id INT PRIMARY KEY, email VARCHAR(255) UNIQUE, login VARCHAR(50) UNIQUE ); Tutaj zarówno email, jak i login nie mogą się duplikować. W praktyce to jest standardowa dobra praktyka: na polach takich jak email, numer PESEL, NIP, numer indeksu, numer seryjny urządzenia czy nawet nazwa użytkownika bardzo często zakłada się UNIQUE, żeby w systemie nie pojawiły się dwa różne konta z tym samym identyfikatorem. Moim zdaniem, przy projektowaniu bazy danych warto od razu zastanowić się, które pola mają pełnić rolę „identyfikatorów biznesowych” i od razu nadać im ograniczenie UNIQUE. Warto też wiedzieć, że UNIQUE nie oznacza „klucz główny”. PRIMARY KEY automatycznie jest unikalny i nie może być NULL, natomiast UNIQUE pozwala na NULL (zależnie od silnika bazy, ale zazwyczaj wiele NULL-i jest dozwolonych). To pozwala projektować tabele bardziej elastycznie, np. kolumna może być opcjonalna, ale jeśli już ktoś poda wartość, to musi być ona niepowtarzalna. W praktyce UNIQUE często łączy się z indeksami – większość systemów bazodanowych automatycznie zakłada indeks unikalny na takiej kolumnie, co przyspiesza wyszukiwanie i walidację danych. To rozwiązanie jest zgodne z dobrymi praktykami normalizacji i kontroli spójności danych w systemach produkcyjnych.

Pytanie 5

Które z poleceń przyznaje użytkownikowi uczen najniższe uprawnienia w kontekście modyfikacji danych oraz struktury tabeli?

A. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;

B. GRANT DROP ON szkola.przedmioty TO uczen;

C. GRANT SELECT ON szkola.przedmioty TO uczen;

D. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;

Patrząc na błędne odpowiedzi, można zauważyć, że większość z nich przyznaje użytkownikowi 'uczen' zbyt wiele uprawnień, które mogą prowadzić do niebezpiecznych sytuacji. Na przykład, opcja GRANT DROP ON szkola.przedmioty TO uczen pozwala na usunięcie całej tabeli 'przedmioty', co, moim zdaniem, jest zdecydowanie przesadą dla ucznia. Podobnie, jeśli dajemy GRANT ALTER, SELECT ON szkola.przedmioty TO uczen, to on może zmieniać strukturę tabeli, co dla kogoś, kto dopiero się uczy, nie jest dobrym pomysłem, bo mogą się pojawić błędy i problemy z danymi. Uprawnienia GRANT INSERT, DROP ON szkola.przedmioty TO uczen także są kiepskim pomysłem, bo taki użytkownik mógłby dodawać nowe wiersze czy usuwać istniejące, co znowu zagraża integralności danych. Często myślimy, że im więcej uprawnień damy, tym lepiej, ale w praktyce taka szeroka swoboda może przynieść więcej szkody niż pożytku. Dlatego ważne jest, żeby stosować zasadę minimalnych uprawnień i dokładnie przemyśleć, co naprawdę potrzebne, żeby uczeń mógł spokojnie uczyć się przedmiotów.

Pytanie 6

W poniższym zapytaniu SQL znak „*” wskazuje, że w wyniku tego zapytania zostaną zwrócone:

SELECT * FROM mieszkancy WHERE imie = 'Anna';

A. zostanie pokazane pole zatytułowane „*” (gwiazdka)

B. warunek dotyczący imienia zostanie pominięty

C. zostaną wyświetlone wszystkie kolumny tabeli mieszkańcy

D. wszystkie rekordy z tabeli mieszkańcy będą widoczne

W analizowanym zapytaniu SQL istotne jest zrozumienie roli symbolu '*' w kontekście wywołania zapytania. Zbytnie uproszczenie może prowadzić do nieporozumień, przy założeniu, że znaczenie gwiazdki jest bardziej skomplikowane niż tylko proste pobieranie danych. Odpowiedź sugerująca, że warunek 'imie = 'Anna'' zostanie zignorowany, jest nieprawidłowa, ponieważ w rzeczywistości to zapytanie filtruje dane, a symbol '*' jedynie wskazuje, że wszystkie kolumny powinny być zwrócone dla tych rekordów, które spełniają warunek. Z kolei stwierdzenie, że zostanie wyświetlone pole o nazwie '*', również jest mylące, ponieważ '*' nie jest nazwą kolumny, lecz specjalnym symbolem w SQL. Warto zauważyć, że z perspektywy wydajności, stosowanie '*' w dużych bazach danych może być nieefektywne. W praktyce lepiej jest określić konkretne kolumny, które są potrzebne, co może znacznie zwiększyć szybkość zapytań oraz zmniejszyć obciążenie serwera. Poprawne zrozumienie struktury danych oraz efektywne formułowanie zapytań SQL to kluczowe umiejętności w pracy z bazami danych, które pozwalają nie tylko na efektywne zarządzanie danymi, ale również na lepszą optymalizację procesów. Właściwe podejście do tworzenia zapytań SQL może znacznie podnieść jakość aplikacji bazodanowych.

Pytanie 7

Dla których imion klauzula LIKE jest prawdziwa?

SELECT imie FROM mieszkancy WHERE imie LIKE 'o_%_a';

A. Oda, Oksana, Oktawia

B. Oktawia, Oktawian, Olga

C. Oksana, Ola, Olga

D. Oksana, Oktawia, Olga

Wybrana odpowiedź nie jest prawidłowa. Przeanalizujmy dokładnie wzorzec użyty w klauzuli LIKE, aby zrozumieć, które imiona faktycznie spełniają podany warunek. Wzorzec 'o_%_a' składa się z pięciu elementów: litery „o" na początku, znaku podkreślenia oznaczającego dokładnie jeden dowolny znak, symbolu procentu reprezentującego zero lub więcej dowolnych znaków, kolejnego znaku podkreślenia (znów dokładnie jeden znak) oraz litery „a" na końcu. Z tej struktury wynikają trzy warunki, które musi spełnić prawidłowe imię: musi zaczynać się od litery „o", kończyć się na literę „a" oraz mieć co najmniej cztery znaki długości. Ten ostatni warunek jest kluczowy i często pomijany - dwa znaki podkreślenia wymuszają obecność minimum dwóch znaków pomiędzy pierwszą a ostatnią literą. Dlatego imiona takie jak „Ola" czy „Oda", mimo że zaczynają się na „o" i kończą na „a", są zbyt krótkie - mają tylko trzy znaki. Z kolei „Oktawian" odpada, ponieważ kończy się na literę „n", nie „a". Prawidłowa odpowiedź to Oksana, Oktawia i Olga - każde z nich ma odpowiednią długość i właściwe litery na początku oraz końcu.

Pytanie 8

W SQL przy użyciu kwerendy ALTER można

A. stworzyć tabelę

B. dodać dane do tabeli

C. zmienić strukturę tabeli

D. zlikwidować tabelę

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

Pytanie 9

GRANT SELECT, INSERT, UPDATE ON klienci TO anna; Przy założeniu, że użytkownik nie miał wcześniej przyznanych żadnych uprawnień, to polecenie SQL przypisuje użytkownikowi anna wyłącznie prawa do

A. wybierania, wstawiania oraz aktualizacji danych w tabeli o nazwie klienci

B. wybierania, dodawania kolumn oraz zmiany struktury tabeli o nazwie klienci

C. wybierania, dodawania kolumn oraz zmiany struktury wszystkich tabel w bazie o nazwie klienci

D. wybierania, wstawiania oraz aktualizacji danych w każdej tabeli w bazie o nazwie klienci

Podane odpowiedzi przedstawiają różne koncepcje związane z przyznawaniem uprawnień, które są jednak nieprawidłowe w kontekście polecenia GRANT przedstawionego w pytaniu. Po pierwsze, odpowiedzi sugerujące, że użytkownik anna ma prawo do dodawania pól lub zmiany struktury tabeli, są błędne. GRANT w tym kontekście nie przyznaje uprawnień do modyfikacji strukturalnych tabeli, takich jak dodawanie kolumn; te operacje wymagają osobnych uprawnień, jak ALTER. Po drugie, koncepcja przyznawania praw do wszystkich tabel w bazie danych jest mylna, ponieważ polecenie odnosi się wyłącznie do konkretnej tabeli o nazwie klienci. W praktyce oznacza to, że nawet jeśli użytkownik ma uprawnienia do jednej tabeli, nie ma automatycznie dostępu do innych tabel w bazie. Często mylnie przyjmuje się, że nadanie praw na poziomie jednej tabeli automatycznie rozszerza te prawa na wszystkie elementy w bazie danych, co jest fundamentalnym błędem w zrozumieniu zarządzania uprawnieniami. Kluczowe w tej problematyce jest zrozumienie, że uprawnienia w systemach baz danych są przyznawane w sposób bardzo precyzyjny i specyficzny, co pozwala na ochronę danych i kontrolę dostępu zgodnie z najlepszymi praktykami w zakresie bezpieczeństwa informacji.

Pytanie 10

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

A. ALTER TABLE

B. GRANT

C. UPDATE

D. INSERT INTO

Wybór odpowiedzi 'INSERT INTO' jest błędny, ponieważ to polecenie służy do wstawiania nowych danych do tabeli, a nie do modyfikacji jej struktury. W praktyce, jeśli chcemy dodać nowy rekord do tabeli, użyjemy składni 'INSERT INTO tabela (kolumna1, kolumna2) VALUES (wartość1, wartość2);'. Z kolei 'UPDATE' również nie jest właściwym poleceniem w kontekście zmiany struktury tabeli, ponieważ to polecenie jest używane do modyfikacji istniejących danych w tabeli, a nie do zmiany jej budowy. Na przykład, aby zmienić wartość w kolumnie, użyjemy 'UPDATE tabela SET kolumna = nowa_wartość WHERE warunek;'. Dodatkowo, odpowiedź 'GRANT' jest nieodpowiednia, ponieważ to polecenie dotyczy przyznawania uprawnień do bazy danych, a nie zmiany jej struktury. Przyznawanie uprawnień jest kluczowe w kontekście bezpieczeństwa bazy danych, ale nie ma związku z modyfikowaniem struktury tabel. Typowymi błędami, które prowadzą do takich niepoprawnych wyborów, są pomylenie operacji na danych z operacjami na strukturze bazy danych oraz brak zrozumienia specyfiki poleceń SQL.

Pytanie 11

W języku SQL, aby wybrać wszystkie rekordy z tabeli B, w tym część wspólną z tabelą A, należy zastosować typ związku

A. A LEFT JOIN B

B. A FULL OUTER JOIN B

C. A INNER JOIN B

D. A RIGHT JOIN B

W tym pytaniu pułapka polega na tym, że łatwo pomylić pojęcie części wspólnej z całością jednego ze zbiorów. Diagram pokazuje całą tabelę B (włącznie z przecięciem z A), a nie tylko przecięcie. W SQL typ złączenia określa, z której tabeli bierzemy wszystkie rekordy, a z której tylko te pasujące. To, że widzimy też obszar wspólny, jest naturalnym efektem działania złączeń zewnętrznych, ale nie oznacza jeszcze, że chodzi o `INNER JOIN`. Jeśli ktoś wybiera `A LEFT JOIN B`, to zwykle wynika z myślenia „chcę część wspólną i coś jeszcze”, ale myli kierunek. `LEFT JOIN` gwarantuje wszystkie rekordy z **lewej** tabeli (A), a z prawej (B) tylko dopasowane. Diagram z pytania pokazuje dokładnie odwrotną sytuację: komplet danych z B, a z A tylko tam, gdzie istnieje relacja. `A LEFT JOIN B` odpowiadałoby sytuacji, gdzie podświetlony jest cały zbiór A i przecięcie, a nie B. Z kolei `A INNER JOIN B` zwróciłby wyłącznie część wspólną A∩B, czyli tylko te rekordy, które mają dopasowanie po obu stronach. Na diagramie byłby wtedy zaznaczony wyłącznie środek, a nie cały zielony obszar B. To typowy błąd: utożsamianie każdego JOIN z „częścią wspólną”. INNER JOIN jest dobry, gdy interesują nas tylko powiązane dane (np. zamówienia, które mają istniejącego klienta), ale w zadaniu wyraźnie mowa o „wszystkich rekordach z B”. `A FULL OUTER JOIN B` idzie w drugą stronę – zwraca wszystko z A **i** wszystko z B, niezależnie od tego, czy jest dopasowanie, czy nie. To byłby diagram z zaznaczonymi obiema kółkami, czyli suma zbiorów A∪B. W standardzie SQL taki typ złączenia jest opisany jako pełne złączenie zewnętrzne i stosuje się go rzadziej, np. do porównywania różnic między dwiema tabelami. Tutaj jest to za szeroki zakres danych w stosunku do pytania. Poprawne podejście wymaga więc skojarzenia, że skoro chcemy wszystkie rekordy z tabeli B, to w zapisie `A ... JOIN B` tabela B musi być po tej stronie, która jest „obowiązkowa”. Właśnie to zapewnia `RIGHT JOIN`: pełny zestaw wierszy z prawej tabeli, plus dopasowania z lewej tam, gdzie istnieją. Świadome operowanie tymi pojęciami bardzo ułatwia projektowanie zapytań raportowych i unikanie nieoczekiwanych braków lub duplikacji danych.

Pytanie 12

W utworzonej tabeli pole należące do typu BLOB służy do składowania

A. łańcuchów znaków o nieokreślonej długości

B. danych logicznych takich jak true

C. liczb całkowitych, które przekraczają zakres typu INT

D. danych binarnych o dużych rozmiarach, takich jak grafika

Wydaje się, że odpowiedzi dotyczące danych logicznych, łańcuchów znaków czy liczb całkowitych nie są zgodne z przeznaczeniem pola BLOB. Dane logiczne, takie jak 'true' lub 'false', są zazwyczaj przechowywane w typach danych, takich jak BOOLEAN, które są zoptymalizowane do zarządzania wartościami binarnymi, ale nie są odpowiednie dla dużych obiektów binarnych. Z kolei łańcuchy znaków nieokreślonej długości są lepiej przechowywane w typach VARCHAR lub TEXT, które są zoptymalizowane do zarządzania tekstem, a nie danymi binarnymi. Liczby całkowite, które przekraczają zakres typu INT, powinny być przechowywane jako BIGINT, co jest bardziej odpowiednie do zarządzania dużymi liczbami całkowitymi, a nie BLOB. Właściwe zrozumienie typów danych i ich zastosowań jest kluczowe w projektowaniu efektywnych baz danych. Stosowanie niewłaściwych typów danych może prowadzić do nieefektywności, zwiększonego zużycia pamięci, a także problemów z wydajnością w aplikacjach korzystających z tych baz danych. Dlatego ważne jest, aby każdorazowo dobierać odpowiedni typ danych zgodnie z jego specyfiką i przeznaczeniem.

Pytanie 13

Aby dodać nowy rekord do tabeli Pracownicy, konieczne jest zastosowanie polecenia SQL

A. INSERT INTO Pracownicy VALUES ('Jan',' Kowalski')

B. INSERT VALUES (Jan, Kowalski) INTO Pracownicy

C. INSERT VALUES Pracownicy INTO (Jan, Kowalski)

D. INSERT (Jan, Kowalski) INTO Pracownicy

Aby dodać nowy rekord do tabeli Pracownicy w bazie danych, należy skorzystać z polecenia SQL INSERT INTO, które jest standardowym sposobem na wprowadzenie nowych danych do tabeli. Poprawna składnia polecenia to 'INSERT INTO <nazwa_tabeli> VALUES (<wartości>)'. W przypadku podanego przykładu, używamy 'INSERT INTO Pracownicy VALUES ('Jan', 'Kowalski');', co jest zgodne z wymaganiami SQL. Polecenie to wprowadza dwa nowe atrybuty: imię 'Jan' oraz nazwisko 'Kowalski' do tabeli Pracownicy. Ważne jest, aby wartości były poprawnie otoczone apostrofami w przypadku typów danych tekstowych. Zgodnie z normami SQL, zapis ten pozwala na dodanie rekordu, pod warunkiem, że kolumny tabeli są zgodne z wprowadzanymi danymi, a tabela Pracownicy została wcześniej zdefiniowana w bazie danych. Przykładem może być sytuacja, w której tabela Pracownicy ma kolumny 'Imie' i 'Nazwisko', a wprowadzenie wartości bezpośrednio do tych kolumn jest zgodne z ich definicją.

Pytanie 14

W SQL polecenie ALTER TABLE służy do

A. zmiany kolumn w tabeli

B. dodawania tabeli do bazy danych

C. zmiany danych w rekordach tabeli

D. usuwania tabeli z bazy danych

Polecenie ALTER TABLE w języku SQL jest kluczowym narzędziem do modyfikacji struktury tabeli w bazie danych. Umożliwia dodawanie, modyfikowanie oraz usuwanie kolumn, co jest niezbędne w przypadku zmieniających się wymagań biznesowych lub technicznych. Na przykład, jeśli firma decyduje się na dodanie nowego atrybutu do produktu, można to zrobić za pomocą ALTER TABLE, co zapewni elastyczność w zarządzaniu danymi. Przykładowe polecenie może wyglądać tak: ALTER TABLE produkty ADD COLUMN kolor VARCHAR(30); Warto podkreślić, że zmiany wprowadzone za pomocą ALTER TABLE są trwałe i mogą wpływać na już istniejące dane, dlatego przed ich zastosowaniem zaleca się wykonanie kopii zapasowej bazy danych. Praktyki związane z właściwym używaniem ALTER TABLE powinny obejmować także testowanie w środowisku developerskim przed wdrożeniem zmian w produkcji, aby uniknąć nieprzewidzianych problemów.

Pytanie 15

Które z poniższych stwierdzeń o językach programowania jest fałszywe?

A. JavaScript to język skryptowy

B. PHP służy do tworzenia stron w czasie rzeczywistym

C. C++ jest językiem obiektowym

D. SQL jest językiem programowania strukturalnego

C++ jest językiem programowania, który wspiera paradygmat programowania obiektowego, ale nie ogranicza się jedynie do tego modelu. Język ten umożliwia również programowanie proceduralne, co sprawia, że jest niezwykle elastyczny. Oprócz możliwości tworzenia klas i obiektów, C++ pozwala na bezpośrednią manipulację pamięcią, co daje programistom dużą kontrolę nad wydajnością aplikacji. JavaScript, z kolei, jest językiem skryptowym, który jest głównie używany w kontekście aplikacji webowych, umożliwiając interaktywność i dynamiczne aktualizacje treści na stronach internetowych. Jego wszechstronność sprawia, że jest podstawowym narzędziem w tworzeniu nowoczesnych aplikacji. PHP to język skryptowy stworzony z myślą o tworzeniu dynamicznych stron internetowych. Umożliwia on generowanie treści w czasie rzeczywistym, w zależności od zachowań użytkowników i danych w bazach danych. Dzięki integracji z HTML i bazami danych, PHP pozwala na tworzenie złożonych aplikacji webowych. Wszystkie te języki posiadają swoje unikalne cechy i zastosowania, które czynią je istotnymi w różnych kontekstach programowania.

Pytanie 16

Kod SELECT imie, pesel, wiek FROM dane WHERE wiek IN (18,30) spowoduje wybranie

A. imion, nazwisk i numerów PESEL osób młodszych niż 18 lat

B. imion, numerów PESEL oraz wieku osób w przedziale 18 do 30 lat

C. imion, numerów PESEL oraz wieku ludzi mających ponad 30 lat

D. imion, numerów PESEL i wieku osób, które mają 18 lub 30 lat

Pierwsza odpowiedź, która wskazuje na osoby poniżej 18 lat, jest błędna. To zapytanie SQL nie ma na celu wybrania młodszych; przecież filtruje tych, którzy mają 18 lub 30 lat. Co do drugiej odpowiedzi, to sugeruje, jakoby zapytanie wybierało osoby w przedziale od 18 do 30, co też jest pomyłką. Operator IN wskazuje konkretne liczby, a nie przedzial, dlatego w tym przypadku wiek pośredni nie ma miejsca. Trzecia odpowiedź, dotycząca osób powyżej 30 lat, kompletnie nie pasuje, bo nie dotyczy tego, co jest w zapytaniu. Właściwie to nie ma związku między tą składnią SQL a osobami, które mają więcej niż 30 lat. Każda z tych odpowiedzi wynika z niepoprawnego zrozumienia, jakie jest intencja zapytania, które jasno wybiera osoby tylko w dwóch podanych przedziałach. Myślę, że ważne jest, żeby dobrze rozumieć, jak działają operatory w SQL, żeby unikać takich pomyłek i nieporozumień.

Pytanie 17

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

A. klucz podstawowy id tabeli filmy z kluczem obcym rezyserzy_id tabeli rezyserzy

B. klucz obcy rezyserzy_id tabeli filmy z kluczem podstawowym id tabeli rezyserzy

C. klucz obcy rezyserzy_id tabeli filmy z kluczem obcym id tabeli rezyserzy

D. klucz podstawowy id tabeli filmy z kluczem podstawowym id tabeli rezyserzy

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

Pytanie 18

W instrukcji CREATE TABLE w SQL atrybut wskazujący, która kolumna w tabeli pełni rolę klucza podstawowego, to

A. PRIMARY KEY

B. IDENTITY FIELD

C. MAIN KEY

D. UNIQUE

Odpowiedzi takie jak 'UNIQUE', 'MAIN KEY' oraz 'IDENTITY FIELD' są niepoprawne z różnych powodów. Rozpoczynając od 'UNIQUE', warto zaznaczyć, że choć atrybut ten jest używany do zapewnienia unikalności wartości w kolumnie, nie definiuje on klucza podstawowego. Klucz podstawowy automatycznie implikuje unikalność, ale atrybut UNIQUE może być użyty w innych kontekstach, gdzie nie jest on kluczem podstawowym. Przechodząc do 'MAIN KEY', istotne jest, aby zauważyć, że nie istnieje taki standardowy termin w SQL; poprawnym terminem jest 'PRIMARY KEY', co może prowadzić do nieporozumień w zrozumieniu struktury bazy danych. Wreszcie, 'IDENTITY FIELD' odnosi się do konkretnej cechy kolumny w bazach danych, która automatycznie inkrementuje wartość (typowe dla kolumn klucza podstawowego), ale nie jest terminem używanym do definiowania klucza podstawowego jako takiego. Łatwo jest pomylić te koncepcje, zwłaszcza dla osób początkujących w SQL, dlatego ważne jest, aby zrozumieć specyfikę każdego z atrybutów oraz ich zastosowanie. Klucz podstawowy pełni fundamentalną rolę w zarządzaniu danymi i jego poprawna definicja jest kluczowa dla efektywności oraz integralności całej bazy.

Pytanie 19

Przedstawione zapytanie SQL przydziela uprawnienie SELECT

GRANT SELECT ON hurtownia.*
 TO 'sprzedawca'@'localhost';

A. do wszystkich kolumn w tabeli hurtownia

B. dla użytkownika root na serwerze sprzedawca

C. dla użytkownika root na serwerze localhost

D. do wszystkich tabel w bazie hurtownia

Polecenie GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost'; nie przyznaje praw do użytkownika root ani do serwera localhost, co wyklucza te możliwości. W SQL, użytkownik root zazwyczaj posiada pełne uprawnienia administracyjne, a przypisanie mu dodatkowych specyficznych praw nie jest konieczne ani typowe w kontekście tego typu polecenia. Z kolei wskazanie serwera localhost w tym kontekście dotyczy tylko ograniczenia dostępu użytkownika do tego konkretnego hosta, a nie nadania mu praw selektywnych. Błędne jest również stwierdzenie, że polecenie to nadaje prawa do wszystkich pól w tabeli hurtownia. W rzeczywistości, wyrażenie hurtownia.* w kontekście GRANT odnosi się do wszystkich tabel, a nie do pól, które w SQL nazywane są kolumnami. Właściwe przypisanie uprawnień w systemach bazodanowych wymaga zrozumienia kontekstu, w którym dane polecenie jest stosowane, oraz znajomości specyfiki składni SQL. Wiele błędów wynika z niepełnego zrozumienia różnicy między tabelami a kolumnami oraz ról poszczególnych użytkowników w systemie zarządzania bazą danych. Praktyka i ciągłe doskonalenie wiedzy w zakresie zarządzania bazami danych jest kluczowe dla unikania takich pomyłek oraz dla utrzymania bezpieczeństwa i spójności danych w organizacjach.

Pytanie 20

Która z funkcji agregujących dostępnych w SQL służy do obliczania średniej z wartości znajdujących się w określonej kolumnie?

A. MIN

B. SUM

C. COUNT

D. AVG

Wybór opcji MIN, SUM lub COUNT zamiast AVG pokazuje pewne nieporozumienie dotyczące roli funkcji agregujących w SQL. Funkcja MIN służy do znajdowania najmniejszej wartości w kolumnie, co jest użyteczne, gdy potrzebujemy zidentyfikować najniższą wartość w zbiorze danych, ale nie dostarcza informacji o średniej. Z kolei SUM dodaje wszystkie wartości w określonej kolumnie, co może być przydatne, gdy chcemy uzyskać całkowitą sumę, ale nie pozwala nam na obliczenie średniej. Funkcja COUNT zlicza liczbę wierszy, które spełniają określone kryteria, co również nie ma związku z obliczaniem średniej. Te funkcje mają różne zastosowania, ale ich wybór w kontekście obliczania średniej wartości jest błędny. Często użytkownicy mogą mylić te funkcje, nie rozumiejąc, że każda z nich spełnia inną rolę w analizie danych. W praktyce, aby uzyskać średnią, należy zawsze korzystać z AVG, a nie z innych funkcji, które mogą dostarczyć informacji o różnych aspektach danych, ale nie odpowiadają na pytanie o średnią wartość.

Pytanie 21

Przy założeniu, że użytkownik nie miał wcześniej żadnych uprawnień, polecenie SQL

GRANT SELECT, INSERT, UPDATE ON klienci TO anna;

nada użytkownikowi anna uprawnienia wyłącznie do

A. wybierania, dodawania kolumn oraz zmiany struktury tabeli o nazwie klienci

B. wybierania, dodawania kolumn oraz zmiany struktury wszystkich tabel w bazie o nazwie klienci

C. wybierania, wstawiania oraz aktualizacji danych w tabeli o nazwie klienci

D. wybierania, wstawiania oraz aktualizacji danych we wszystkich tabelach w bazie o nazwie klienci

Zrozumienie praw dostępu w bazach danych jest kluczowe dla bezpieczeństwa oraz efektywnego zarządzania danymi. Niepoprawne odpowiedzi często wynikają z mylącego interpretowania pojęć związanych z uprawnieniami. Na przykład, odpowiedź sugerująca, że użytkownik 'anna' ma możliwość dodawania pól w tabeli, jest błędna, ponieważ polecenie GRANT nie obejmuje uprawnień do modyfikacji struktury tabeli. Uprawnienia do dodawania kolumn (ALTER) są odrębną kategorią praw i muszą być przyznane w osobnym poleceniu. Kolejna nieprawidłowa koncepcja dotyczy rozumienia zakresu uprawnień. Odpowiedzi, które sugerują, że prawa te dotyczą wszystkich tabel w bazie danych, mylą pojęcie 'ON klienci' z szerszymi uprawnieniami, co mogłoby prowadzić do nadużyć. GRANT SELECT, INSERT, UPDATE na konkretnej tabeli 'klienci' dotyczy tylko tej tabeli, co jest zgodne z zasadą ograniczonego dostępu. Należy również pamiętać, że udzielanie zbyt szerokich uprawnień może narazić bazę danych na nieautoryzowane manipulacje, co jest sprzeczne z najlepszymi praktykami zarządzania bezpieczeństwem. W kontekście projektowania systemów bazodanowych, kluczowe jest zrozumienie oraz umiejętne zarządzanie uprawnieniami w celu zapewnienia odpowiedniego poziomu ochrony danych.

Pytanie 22

Czym jest DBMS?

A. Kaskadowy arkusz stylów do opisu wyglądu witryny www

B. Strukturalny język zapytań do bazy danych

C. System zarządzania bazą danych

D. Obiektowy język programowania służący do tworzenia stron www

Wybór niepoprawnych odpowiedzi wskazuje na pewne nieporozumienia dotyczące podstawowych koncepcji zarządzania danymi w informatyce. Kaskadowy arkusz stylów (CSS) służy do opisu wyglądu strony internetowej, a nie do zarządzania danymi. CSS jest używany do określenia, jak HTML ma być wyświetlany, korzystając z reguł stylizacji, ale nie ma żadnej funkcji związanej z przechowywaniem ani przetwarzaniem informacji. Z kolei obiektowy język programowania do generowania stron internetowych odnosi się do technologii, które są używane do tworzenia interaktywnych aplikacji, ale nie obejmuje on funkcji zarządzania danymi, które są kluczowe w pracy z bazą danych. Dodatkowo, strukturalny język zapytań kierowanych do bazy danych, czyli SQL, jest rzeczywiście związany z interakcją z DBMS, ale nie jest samodzielnym systemem. SQL jest językiem zapytań, który służy do komunikacji z bazą danych w DBMS, a nie do jej zarządzania jako całości. Często mylone jest pojęcie języka programowania z systemem, co prowadzi do błędnych wniosków. Zrozumienie, że DBMS jest kluczowym elementem w architekturze baz danych, jest istotne dla efektywnego projektowania aplikacji i rozwiązań informatycznych, które wymagają wydajnego zarządzania danymi.

Pytanie 23

Tabele Klienci oraz Zgłoszenia są ze sobą połączone relacją jeden do wielu. W celu uzyskania jedynie opisu zgłoszenia oraz odpowiadającego mu nazwiska klienta dla zgłoszenia o numerze 5, należy wykonać polecenie

A. SELECT opis, nazwisko FROM Zgłoszenia JOIN Klienci ON Klienci.id = Zgłoszenia.id WHERE Zgłoszenia.id = 5

B. SELECT opis, nazwisko FROM Zgłoszenia JOIN Klienci WHERE Klienci.id = 5

C. SELECT opis, nazwisko FROM Zgłoszenia JOIN Klienci ON Klienci.id = Zgłoszenia.Klienci_id WHERE Klienci.id = 5

D. SELECT opis, nazwisko FROM Zgłoszenia JOIN Klienci ON Klienci.id = Zgłoszenia.Klienci_id WHERE Zgłoszenia.id = 5

Niepoprawne odpowiedzi wynikają z błędnego zrozumienia, jak działa relacja klucz główny-klucz obcy w bazach danych. W relacyjnych bazach danych tabele są często powiązane relacjami, gdzie jedna tabela posiada klucz obcy odnoszący się do klucza głównego innej tabeli. W kontekście zapytania SQL, aby poprawnie połączyć tabele i uzyskać odpowiednie dane, musimy użyć klauzuli JOIN z właściwym warunkiem ON. Błędne odpowiedzi pokazują typowe nieporozumienia: jedna z alternatywnych odpowiedzi próbuje połączyć tabele bez użycia klauzuli ON, co prowadzi do błędnych wyników, ponieważ nie określa w jaki sposób rekordy z tabeli Klienci są powiązane z rekordami z tabeli Zgłoszenia. Inna odpowiedź błędnie zakłada, że filtrujemy dane na podstawie id klienta zamiast id zgłoszenia, co prowadzi do nieprawidłowego zestawu wyników niezgodnego z założeniami zadania. Takie błędy mogą wynikać z niedostatecznego zrozumienia struktury bazy danych oraz mechanizmów filtracji i łączenia danych w SQL. Kluczem do poprawnego zapytania jest jasne zrozumienie, jak relacje w bazach danych pozwalają na efektywne łączenie danych i selekcję pożądanych rekordów, co jest podstawą analizy danych i ich raportowania w systemach informacyjnych. Unikanie takich błędów wymaga znajomości syntaktyki SQL i logicznego sposobu myślenia o danych i ich powiązaniach.

Pytanie 24

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

A. DROP DATABASE firma;

B. DROP firma;

C. ALTER firma DROP DATABASE;

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 25

Wskaż zapytanie, które z tabeli klienci wybierze wyłącznie nazwiska trzech najlepszych klientów, czyli takich, którzy posiadają najwięcej punktów na swoim koncie (pole całkowite punkty)?

A. SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3

B. SELECT nazwisko FROM klienci ORDER BY punkty DESC LIMIT 3

C. SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC

D. SELECT nazwisko FROM klienci LIMIT 3

Analiza niepoprawnych odpowiedzi ujawnia szereg kluczowych błędów w interpretacji zapytania SQL. W pierwszym przypadku, 'SELECT LIMIT 3 nazwisko FROM klienci ORDER BY nazwisko DESC;' następuje nieprawidłowa składnia, ponieważ klauzula LIMIT powinna być umieszczona po klauzuli ORDER BY. Taki błąd sprawia, że zapytanie nie zostanie zrealizowane przez system baz danych. Kolejna odpowiedź, 'SELECT nazwisko FROM klienci LIMIT 3;', pomija istotny element sortowania, dlatego zwróci po prostu pierwsze trzy nazwiska z tabeli, bez względu na ilość punktów. Takie podejście jest mało efektywne, ponieważ nie identyfikuje najlepszych klientów na podstawie ich punktów, co jest kluczowe dla analizy jakości klientów. Ostatnia odpowiedź, 'SELECT nazwisko FROM klienci ORDER BY nazwisko DESC LIMIT 3;', znów koncentruje się na sortowaniu alfabetycznym nazwisk zamiast na punktach, co nie spełnia kryteriów określonych w pytaniu. Takie błędy ukazują typowe nieporozumienia w zakresie funkcji SQL, gdzie kluczowe jest rozróżnienie pomiędzy różnymi metodami sortowania i ograniczania wyników. Istotne jest, aby w analizach danych zawsze zwracać uwagę na odpowiednie kryteria oraz zasady, które mają realny wpływ na proces podejmowania decyzji.

Pytanie 26

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 OR REPLACE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

B. CREATE USER 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

C. CREATE USER OR DROP 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

D. CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';

Odpowiedź 'CREATE USER IF NOT EXISTS 'anna'@'localhost' IDENTIFIED BY 'yu&T%';' jest poprawna, ponieważ użycie klauzuli 'IF NOT EXISTS' pozwala na uniknięcie błędów w sytuacji, gdy konto użytkownika już istnieje w bazie danych. W praktyce oznacza to, że wykonanie tego polecenia nie spowoduje żadnej zmiany ani błędu, jeśli konto 'anna' jest już zdefiniowane, co jest szczególnie przydatne w skryptach automatyzujących tworzenie użytkowników. Dzięki temu można uniknąć powtarzania kodu sprawdzającego istnienie użytkownika przed jego utworzeniem. Zaleca się stosowanie tej formy w celu uproszczenia procesu zarządzania użytkownikami i zapewnienia, że skrypty wykonują się bez zakłóceń. W kontekście bezpieczeństwa, ważne jest używanie silnych haseł, jak w tym przykładzie, aby zabezpieczyć konta przed nieautoryzowanym dostępem. Warto także pamiętać o dobrych praktykach w zakresie nadawania uprawnień oraz regularnego przeglądania kont użytkowników, aby zapewnić, że wszystkie konta są wykorzystywane i zarządzane odpowiednio.

Pytanie 27

Fragment kodu SQL wskazuje, że klucz obcy

A. stanowi odniesienie do siebie samego

B. jest ustawiony na kolumnie obiekty

C. jest obecny w tabeli obiekty

D. wiąże się z kolumną imiona

Klucz obcy w SQL nie umieszcza się w kolumnie obiekty, ani nie jest referencją do samego siebie. Główną funkcją klucza obcego jest zapewnienie, że dane w jednej tabeli są zgodne z danymi w innej tabeli, co jest podstawą utrzymania integralności referencyjnej w bazie danych. Po pierwsze, klucz obcy nie odnosi się do samego siebie, ponieważ jego celem jest wskazywanie na klucze główne lub unikalne kolumny w innej tabeli. Samoistne odniesienie nie miałoby sensu w kontekście zapewniania spójności danych. Po drugie, klucz obcy nie jest fizycznie umieszczony w jakiejkolwiek kolumnie w tabeli obiekty. Zamiast tego, jego definicja w kodzie SQL wskazuje, że istnieje logiczne powiązanie między kolumnami dwóch tabel. Istnieje również mylne założenie, że klucz obcy może być ustawiony na dowolną kolumnę w tabeli, na przykład w tabeli obiekty. W rzeczywistości klucz obcy musi być zdefiniowany w kontekście relacji między dwiema tabelami, a jego zadaniem jest wskazywanie na kolumnę w tabeli docelowej, która powinna zawierać wartości odpowiadające wartościom w kolumnie źródłowej. Takie niejasne rozumienie klucza obcego może prowadzić do błędów w projektowaniu struktury baz danych, co w dłuższej perspektywie może skutkować problemami z integralnością danych i wydajnością zapytań do bazy danych. Zrozumienie poprawnego zastosowania kluczy obcych jest kluczowe dla skutecznego zarządzania relacyjnymi bazami danych, dlatego ważne jest unikanie tych typowych błędów przy ich implementacji.

Pytanie 28

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

GRANT ALL ON firmy TO 'admin'@'localhost';
GRANT ALTER, CREATE, DROP ON firmy TO 'anna'@'localhost';
GRANT SELECT, INSERT, UPDATE ON firmy TO 'tomasz'@'localhost';

A. Tomasz i Adam

B. Tomasz i Anna

C. Tylko Tomasz

D. Adam i Anna

Nieprawidłowe rozumienie problemu wynika z błędnej interpretacji przyznanych uprawnień SQL. Anna choć posiada uprawnienia ALTER CREATE i DROP które odnoszą się do zarządzania strukturą bazy danych takie jak dodawanie czy usuwanie tabel lub zmiana ich struktury nie ma uprawnień do przeglądania czy modyfikowania zawartości tabel. To oznacza że nie może przeglądać ani modyfikować danych co wyklucza ją jako osobę mającą prawo do przeglądania i zmiany danych w kontekście tego pytania. Adam w przesłanych komendach nie jest wymieniony co jasno wskazuje że żadne uprawnienia nie zostały mu przyznane. Często popełnianym błędem jest założenie że posiadanie uprawnień do zmiany struktury bazy danych automatycznie pozwala na przeglądanie danych jednak w rzeczywistości uprawnienia te są rozdzielone co jest kluczowe dla zapewnienia bezpieczeństwa danych. Rozróżnienie między uprawnieniami do zarządzania danymi a ich strukturyzowania jest fundamentalne w pracy z bazami danych i niezbędne do skutecznego administrowania dostępem użytkowników. Tomasz jako jedyny uzyskał odpowiednie uprawnienia do przeglądania i modyfikacji danych co jasno wynika z przyznanych mu uprawnień SQL.

Pytanie 29

W bazie danych znajduje się tabela pracownicy z kolumnami: id, imie, nazwisko, pensja. W nowym roku postanowiono zwiększyć wynagrodzenie wszystkim pracownikom o 100 zł. Jak powinno wyglądać to w aktualizacji bazy danych?

A. UPDATE pracownicy SET pensja = 100;

B. UPDATE pracownicy SET pensja = pensja + 100;

C. UPDATE pensja SET 100;

D. UPDATE pensja SET +100;

Błędne odpowiedzi opierają się na niepoprawnym zrozumieniu składni SQL i koncepcji aktualizacji danych. Odpowiedź 'UPDATE pensja SET +100;' jest nieprawidłowa, ponieważ nie odnosi się do żadnej konkretnej tabeli, a polecenie nie jest zgodne z wymaganym formatem aktualizacji. W SQL każda aktualizacja musi być powiązana z konkretną tabelą, w której chcemy zmienić dane. Kolejną niewłaściwą odpowiedzią jest 'UPDATE pensja SET 100;', która również nie wskazuje na żadną tabelę i nie uwzględnia struktury danych. W SQL musimy zawsze określić, co dokładnie chcemy osiągnąć i w jakiej tabeli. Ostatecznie, 'UPDATE pracownicy SET pensja = 100;' ustawia pensję na stałą wartość 100 zł dla wszystkich pracowników, co nie odpowiada zamierzeniu podniesienia obecnych pensji o 100 zł. Tego rodzaju błędy wynikają często z mylnego przekonania, że operacje na danych są prostsze niż w rzeczywistości. Kluczowym elementem skutecznego zarządzania bazami danych jest umiejętność odczytania i interpretacji poleceń SQL, aby skutecznie modyfikować rekordy zgodnie z wymaganiami biznesowymi.

Pytanie 30

Ustanowienie klucza obcego jest konieczne do stworzenia

A. relacji 1..1

B. transakcji

C. klucza podstawowego

D. relacji 1..n

Zdefiniowanie klucza obcego nie jest związane z tworzeniem transakcji. Transakcje w bazach danych dotyczą grupy operacji, które są wykonane jako jedna jednostka. Klucz obcy odpowiada za relacje między danymi a nie za sposób ich przetwarzania. Nie można również zdefiniować klucza obcego w kontekście relacji 1..1, ponieważ klucz obcy pokazuje powiązanie, gdzie jeden rekord może być związany z wieloma rekordami w innej tabeli. W relacjach 1..1, każdy rekord w jednej tabeli ma dokładnie jeden odpowiadający rekord w drugiej tabeli, co nie wymaga użycia klucza obcego. Ponadto, klucz obcy nie ma nic wspólnego z kluczem podstawowym. Klucz podstawowy (primary key) jest unikalnym identyfikatorem rekordu w tabeli, podczas gdy klucz obcy wskazuje na klucz podstawowy w innej tabeli. W związku z tym, zdefiniowanie klucza obcego ma na celu ustanowienie relacji między różnymi tabelami, a nie transakcji czy relacji 1..1, ani klucza podstawowego.

Pytanie 31

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

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

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

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

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

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

Pytanie 32

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

A. konieczne jest stworzenie kwerendy, która wyszukuje tytuły książek

B. należy zdefiniować relację l..n pomiędzy tabelami ksiazki a autorzy, a następnie stworzyć kwerendę łączącą obie tabele

C. należy zdefiniować relację 1..1 pomiędzy tabelami ksiazki a autorzy, a następnie stworzyć kwerendę łączącą obie tabele

D. trzeba utworzyć dwie oddzielne kwerendy: pierwsza do wyszukiwania tytułów książek, druga do wyszukiwania nazwisk autorów

Jak się przyjrzysz innym odpowiedziom, to zauważysz, że zdefiniowanie relacji 1..1 dla tabel 'ksiazki' i 'autorzy' to trochę nieporozumienie. Takie założenie sugeruje, że każdy autor mógłby napisać tylko jedną książkę, co jest mało prawdopodobne w rzeczywistości. Przecież jeden autor może mieć na swoim koncie wiele tytułów, więc prawidłowa relacja to l..n. Kwerenda, która tylko wyszukuje tytuły książek, nie bierze pod uwagę autorów, co sprawia, że nie dostajemy pełnych informacji o książkach. Dwie osobne kwerendy na tytuły i nazwiska autorów to jakieś nieporozumienie – jest to nieefektywne i nie pozwala na zebranie wyników w jednej, sensownej formie. Często w takich sytuacjach ludzie mylą się, bo nie rozumieją zasad relacyjnych baz danych i nie mają dobrego podejścia do projektowania schematu. To prowadzi później do problemów z zarządzaniem danymi i ich analizą.

Pytanie 33

Aby odzyskać bazę danych z kopii zapasowej na serwerze MSSQL, należy użyć polecenia

A. UNBACKUP DATABASE

B. BACKUP DATABASE

C. RESTORE DATABASE

D. EXPORT DATABASE

Jakbyśmy spojrzeli na inne odpowiedzi, to każda z nich ma jakieś wady, przez które nie nadają się do przywracania bazy danych w MSSQL. Na przykład polecenie EXPORT DATABASE jest błędne, bo w MSSQL nie ma takiej komendy do eksportu całej bazy. Można to robić innymi narzędziami, jak SQL Server Integration Services (SSIS), ale to nie jest metoda przywracania. Z kolei BACKUP DATABASE, mimo że służy do robienia kopii zapasowych, nie nadaje się do przywracania. Ten komendę robimy wręcz odwrotnie — zapisuje obecny stan na dysku, a nie przywraca go. No i ostatnia opcja, UNBACKUP DATABASE, w ogóle nie istnieje w MSSQL. To brzmi jak coś, co mogłoby odwracać kopię zapasową, ale to wcale nie jest dostępne w tym systemie. Więc wybór złych komend może prowadzić do nieefektywnego zarządzania danymi i strat, jakby coś się stało.

Pytanie 34

Zawarte polecenie SQL wykonuje

UPDATE Uczen SET id_klasy = id_klasy + 1;

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

B. ustalić wartość pola Uczen na 1

C. ustalić wartość kolumny id_klasy na 1 dla wszystkich rekordów w tabeli Uczen

D. zwiększyć o jeden wartość w kolumnie id_klasy dla wszystkich rekordów tabeli Uczen

Polecenie SQL, które analizujemy, to: `UPDATE Uczen SET id_klasy = id_klasy + 1;`. Jego celem jest zwiększenie wartości w kolumnie `id_klasy` o jeden dla wszystkich rekordów w tabeli `Uczen`. Wykorzystanie operacji `SET` w poleceniu `UPDATE` umożliwia modyfikację istniejących danych w bazie. W tym przypadku każda wartość w kolumnie `id_klasy` zostaje powiększona o jeden. To technika często stosowana przy aktualizacjach, gdzie potrzebujemy inkrementować wartości, np. w przypadku liczników, numeracji czy przesuwania pozycji. Stosowanie `UPDATE` zgodnie z dobrymi praktykami wymaga ostrożności, zwłaszcza przy operacjach masowych, aby unikać niezamierzonych zmian w danych. Ważne jest, aby przed wykonaniem takich operacji upewnić się, że kopia zapasowa danych jest dostępna, a operacja została przetestowana w środowisku testowym, aby uniknąć potencjalnych problemów w środowisku produkcyjnym.

Pytanie 35

Zamieszczone poniżej zapytanie SQL przyznaje uprawnienie SELECT:

GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost';

A. dla konta root na serwerze sprzedawca

B. dla konta root na serwerze localhost

C. do wszystkich tabel w bazie danych hurtownia

D. do wszystkich kolumn w tabeli hurtownia

Podane polecenie SQL <code>GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost';</code> jest poprawne, ponieważ przyznaje uprawnienia do wykonywania zapytań SELECT na wszystkich tabelach w bazie danych hurtownia. Operator <code>.*</code> w kontekście bazy danych oznacza, że dotyczy to wszystkich tabel znajdujących się w tej bazie. Przyznawanie uprawnień w taki sposób jest zgodne z najlepszymi praktykami zarządzania dostępem w systemach baz danych, ponieważ umożliwia kontrolowanie, którzy użytkownicy mogą uzyskiwać dostęp do danych. W praktyce, jeśli 'sprzedawca' potrzebuje przeglądać dane ze wszystkich tabel w hurtowni, to takie przyznanie uprawnień jest najbardziej efektywne. Takie podejście ułatwia zarządzanie uprawnieniami, pozwalając administratorom na nadawanie ogólnych uprawnień w ramach bazy danych, zamiast przypisywania ich dla każdej tabeli z osobna. Dobrą praktyką jest również regularne przeglądanie i aktualizowanie przydzielonych uprawnień, aby zapewnić bezpieczeństwo i zgodność z zasadami ochrony danych.

Pytanie 36

W języku SQL, w wyniku wykonania poniższego zapytania:

ALTER TABLE osoba DROP COLUMN grupa;

A. zostanie zmieniona nazwa tabeli na grupa

B. zostanie usunięta kolumna grupa

C. zostanie dodana kolumna grupa

D. zostanie zmieniona nazwa kolumny na grupa

Pierwsza odpowiedź sugeruje, że kolumna 'grupa' zostanie dodana do tabeli, co jest błędne, ponieważ użycie słowa 'DROP' sugeruje usunięcie, a nie dodanie. W SQL do dodawania kolumn używa się komendy 'ADD', a nie 'DROP'. Druga odpowiedź, która stwierdza, że kolumna zostanie usunięta, jest poprawna, ale nie są podane inne aspekty jej działania. Trzecia odpowiedź dotyczy zmiany nazwy tabeli na 'grupa', co również jest niepoprawne, ponieważ komenda 'ALTER TABLE' z 'DROP COLUMN' nie ma na celu zmiany nazwy tabeli, lecz jedynie modyfikację jej struktury poprzez usunięcie kolumny. Zmiana nazwy tabeli wymagałaby użycia komendy 'RENAME'. Ostatnia odpowiedź, która mówi, że zmienia nazwę kolumny na 'grupa', jest również fałszywa, ponieważ do zmiany nazwy kolumny w SQL używa się komendy 'ALTER COLUMN' z 'RENAME', a nie 'DROP'. Tak więc, wszystkie te odpowiedzi zawierają błędne interpretacje dotyczące funkcji komendy 'ALTER TABLE DROP COLUMN', a zrozumienie tej komendy jest kluczowe dla prawidłowego zarządzania strukturą bazy danych.

Pytanie 37

Uprawnienia obiektowe przyznawane użytkownikom serwera bazy danych mogą umożliwiać lub ograniczać

A. realizować operacje na bazie, takie jak wstawianie lub modyfikowanie danych

B. przechodzić uprawnienia

C. zmieniać role i konta użytkowników

D. wykonywać polecenia, takie jak tworzenie kopii zapasowej

Uprawnienia obiektowe w systemach baz danych są kluczowym aspektem zarządzania bezpieczeństwem i dostępem do danych. Odpowiedzi dotyczące modyfikacji ról i kont użytkowników, dziedziczenia uprawnień czy wykonywania instrukcji takich jak tworzenie kopii zapasowej, nie odnoszą się bezpośrednio do istoty uprawnień obiektowych. Modyfikacja ról i kont użytkowników jest zazwyczaj związana z uprawnieniami administracyjnymi, a nie obiektowymi. Role i konta użytkowników są koncepcjami wyższego poziomu, które służą do grupowania uprawnień i nie są zazwyczaj zarządzane na poziomie obiektów. Dziedziczenie uprawnień jest bardziej złożonym mechanizmem, który dotyczy hierarchii obiektów i nie jest bezpośrednio związane z podstawowym pojęciem uprawnień obiektowych. Ponadto, wykonywanie instrukcji takich jak tworzenie kopii zapasowej, to działanie administracyjne, które zazwyczaj wymaga odrębnych uprawnień niż te, które dotyczą operacji na danych. Typowym błędem jest pomylenie uprawnień obiektowych z uprawnieniami administracyjnymi, co prowadzi do nieporozumień w zakresie ich zastosowania oraz w kontekście bezpieczeństwa danych. Właściwe zrozumienie tych różnic jest kluczowe dla skutecznego zarządzania dostępem w bazach danych oraz dla zapewnienia ich bezpieczeństwa i integralności.

Pytanie 38

Podano tabelę ksiazki z kolumnami: tytul, autor (w formacie tekstowym), cena (w formacie liczbowym). Aby zapytanie SELECT zwracało jedynie tytuły, dla których cena jest niższa niż 50zł, należy użyć:

A. SELECT ksiazki FROM tytul WHERE cena < '50 zł'

B. SELECT * FROM ksiazki WHERE cena < 50

C. SELECT tytul FROM ksiazki WHERE cena > '50 zł'

D. SELECT tytul FROM ksiazki WHERE cena < 50

W analizowanych odpowiedziach występują różnorodne błędy związane z interpretacją składni SQL oraz zasad dotyczących typów danych. Zastosowanie 'SELECT ksiazki FROM tytul WHERE cena < '50 zł';' jest błędne, ponieważ nie tylko niewłaściwie odnosi się do nazw tabeli i kolumn, ale także używa złego formatu porównania. Cena powinna być traktowana jako wartość liczbową, więc użycie apostrofów wokół '50 zł' prowadzi do błędnej interpretacji i może skutkować błędem wykonania. Kolejny błąd występuje w 'SELECT tytul FROM ksiazki WHERE cena > '50 zł';', gdzie użycie operatora '>' zupełnie ignoruje założenie dotyczące ceny, które powinno być mniejsze niż 50 zł. To pokazuje typowy problem w myśleniu o logicznych warunkach zapytań SQL, w których kluczowe jest zrozumienie, jakie dane chcemy uzyskać. W ostatniej niepoprawnej odpowiedzi 'SELECT * FROM ksiazki WHERE cena < 50;' również występuje problem, ponieważ użycie '*' zwraca wszystkie kolumny z tabeli, podczas gdy pytanie sugeruje, że interesują nas tylko tytuły. To nieefektywne podejście do wyboru danych, ponieważ może prowadzić do zbędnego obciążenia systemu. W kontekście projektowania baz danych i pisania zapytań SQL istotne jest, aby doprecyzować, które kolumny są naprawdę potrzebne oraz stosować odpowiednie typy danych, co pozwala uniknąć problemów związanych z interpretacją wartości. Kluczową nauką jest to, aby nie tylko tworzyć zapytania, ale również zrozumieć ich logikę oraz efektywność w kontekście wydajności systemu.

Pytanie 39

Polecenie w języku SQL w formie

ALTER TABLE 'miasta' 
ADD 'kod' text;

A. w tabeli miasta zmienia nazwę kolumny kod na text.

B. dodaje do tabeli kolumnę o nazwie kod typu text.

C. dodaje do tabeli dwie kolumny o nazwach: kod i text.

D. zmienia nazwę tabeli miasta na kod.

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 40

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

A. DELETE, INSERT, UPDATE

B. DENY, GRANT, REVOKE

C. SELECT, SELECT INTO

D. ALTER, CREATE, DROP

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

Rozpocznij nowy egzamin

Powrót do strony głównej