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: 6 kwietnia 2026 12:29
Data zakończenia: 6 kwietnia 2026 12:48

Egzamin niezdany

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

Wymagane minimum: 20 punktów (50%)

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Jakiej funkcji w języku PHP należy użyć, aby nawiązać połączenie z bazą danych pod nazwą zwierzaki?

A. $polacz = server_connect('localhost', 'root', '', 'zwierzaki')

B. $polacz = db_connect('localhost', 'root', '', 'zwierzaki')

C. $polacz = sql_connect('localhost', 'root', '', 'zwierzaki')

D. $polacz = mysqli_connect('localhost', 'root', '', 'zwierzaki')

Odpowiedź $polacz = mysqli_connect('localhost', 'root', '', 'zwierzaki'); jest poprawna, ponieważ wykorzystuje funkcję mysqli_connect, która jest dedykowana do nawiązywania połączeń z bazami danych MySQL w języku PHP. Funkcja ta przyjmuje cztery argumenty: adres serwera (w tym przypadku 'localhost'), nazwę użytkownika ('root'), hasło (które jest puste w tym przykładzie) oraz nazwę bazy danych ('zwierzaki'). Użycie mysqli jest zgodne z aktualnymi standardami i dobrą praktyką w programowaniu, ponieważ oferuje szereg usprawnień w porównaniu do starszych metod, takich jak mysql_connect, które zostały usunięte w nowszych wersjach PHP. Mysqli (MySQL Improved) wspiera zarówno programowanie obiektowe, jak i proceduralne, co czyni go bardziej elastycznym. W przypadku nawiązywania połączenia warto również pamiętać o obsłudze błędów, co można osiągnąć poprzez dodatkowe sprawdzenie, czy połączenie zostało nawiązane pomyślnie za pomocą funkcji mysqli_connect_error(). Przykład poprawnego użytkowania w kodzie mógłby wyglądać następująco: $polacz = mysqli_connect('localhost', 'root', '', 'zwierzaki'); if (!$polacz) { die('Connection failed: ' . mysqli_connect_error()); }

Pytanie 2

Funkcja agregująca MIN w języku SQL ma na celu określenie

A. średniej wartości kolumny obserwowanej w wyniku zapytania

B. wartości minimalnej z kolumny zwróconej przez kwerendę

C. liczby wierszy zwróconych przez kwerendę

D. liczby znaków w rekordach zwróconych przez kwerendę

Funkcja agregująca MIN w języku SQL służy do wyznaczania wartości minimalnej w zadanej kolumnie, co jest kluczowym aspektem analizy danych w bazach danych. Przykładowo, gdy korzystasz z zapytania SELECT MIN(wiek) FROM pracownicy, otrzymasz najniższy wiek pracownika w tabeli. To narzędzie jest niezwykle przydatne w raportowaniu oraz przy podejmowaniu decyzji opartych na danych, gdyż pozwala na szybkie określenie najniższych wartości w zestawieniach, takich jak najstarszy pracownik w firmie, najniższa cena produktu, czy najkrótszy czas realizacji zamówienia. W praktyce, używanie funkcji MIN pomaga organizacjom w identyfikacji problemów oraz w optymalizacji procesów. Stosowanie funkcji agregujących, takich jak MIN, jest zgodne z najlepszymi praktykami w zakresie analizy danych, ponieważ umożliwia efektywne przetwarzanie dużych zbiorów informacji i wyciąganie z nich wartościowych wniosków, co jest kluczowe w zarządzaniu danymi i tworzeniu raportów analitycznych.

Pytanie 3

Aby baza danych działała poprawnie i konsekwentnie, konieczne jest wprowadzenie w każdej tabeli

A. kluczy PRIMARY KEY i FOREIGN KEY

B. klucza obcego z wartością NOT NULL i UNIQUE

C. klucza PRIMARY KEY z wartością NOT NULL i UNIQUE

D. klucza FOREIGN KEY z wartością NOT NULL

Każda z pozostałych opcji jest błędna z perspektywy podstawowych zasad projektowania baz danych. Klucz FOREIGN KEY jest ważnym elementem w relacyjnych bazach danych, jednak jego sama obecność nie wystarcza do zapewnienia integralności danych w tabeli. Klucz obcy służy jako odniesienie do klucza głównego innej tabeli, co pozwala na łączenie danych, ale nie gwarantuje, że każdy rekord w tabeli będzie miał unikalny identyfikator. W przypadku wartości NOT NULL, nie jest to wymagane dla klucza FOREIGN KEY, ponieważ klucz obcy może odnosić się do wartości NULL w tabeli głównej. Wprowadzenie ograniczenia UNIQUE na kluczu obcym również nie jest konieczne, ponieważ jego głównym celem jest relacja pomiędzy tabelami, a nie zapewnienie unikalności w obrębie jednej tabeli. Dodatkowo, klucz PRIMARY KEY z wartością NOT NULL i UNIQUE jest niezbędny, ponieważ to właśnie te cechy zapewniają, że tabela będzie dobrze zorganizowana i efektywna. Dlatego też, aby zapewnić spójność i integralność danych, klucz PRIMARY KEY odgrywa kluczową rolę, a inne opcje nie mogą zastąpić jego fundamentalnych właściwości.

Pytanie 4

Podana jest tabela książki z kolumnami: tytuł, autor (w formie tekstowej), cena (w formie liczbowej). Jaką kwerendę SELECT należy wykorzystać, aby otrzymać tylko tytuły, których cena jest niższa niż 50 zł?

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

B. SELECT tytul FROM ksiazki WHERE cena < 50;

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

D. SELECT * FROM ksiazki WHERE cena < 50;

Odpowiedzi, które zostały podane jako niepoprawne, zawierają różne błędy w składni oraz logiczne nieścisłości. W pierwszym przypadku, zapytanie "SELECT * FROM ksiazki WHERE cena < 50;" zwraca wszystkie kolumny z tabeli, co nie jest zgodne z wymaganiami pytania, które prosi o zwrócenie jedynie tytułów książek. Użycie operatora * zamiast konkretnego pola jest nieefektywne, co prowadzi do większego obciążenia, szczególnie przy dużych zbiorach danych. Innym zapytaniem, które jest niepoprawne, jest "SELECT tytul FROM ksiazki WHERE cena > '50 zł';". To zapytanie zawiera błąd w operatorze porównania, ponieważ zamiast poszukiwać książek tańszych niż 50 zł, filtruje te droższe. Dodatkowo, zawarcie ceny jako tekstu ('50 zł') wprowadza nieprawidłowe zachowanie porównania, ponieważ SQL nie przetwarza wartości tekstowych jako liczb. Wreszcie, zapytanie "SELECT ksiazki FROM tytul WHERE cena < '50 zł';" jest całkowicie błędne, ponieważ sugeruje, że wybieramy kolumnę z tabeli 'ksiazki' na podstawie warunków dotyczących innej kolumny. Tego typu błędne zrozumienie struktury i składni SQL często prowadzi do frustracji w pracy z bazami danych. Kluczowe w nauce SQL jest zrozumienie, że każdy element zapytania ma swoje miejsce i rolę, co pozwala na tworzenie poprawnych i efektywnych kwerend.

Pytanie 5

Podane w ramce polecenie SQL nadaje prawo SELECT

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

A. do wszystkich pól w tabeli hurtownia.

B. do wszystkich tabel w bazie hurtownia.

C. dla użytkownika 'root' na serwerze sprzedawca.

D. dla użytkownika 'root' na serwerze localhost.

Poprawnie wychwyciłeś najważniejszy element składni: zapis hurtownia.* po słowie ON oznacza całą bazę danych o nazwie hurtownia, a nie pojedynczą tabelę. W składni GRANT w MySQL i innych systemach bazodanowych mamy kilka poziomów nadawania uprawnień: można nadać uprawnienia do całej bazy (database), do konkretnej tabeli, a nawet do pojedynczych kolumn. Kluczowe jest to, co znajduje się po słowie ON. Jeżeli podamy nazwa_bazy.* – tak jak tutaj – to uprawnienie SELECT dotyczy wszystkich tabel w tej bazie danych. Gdyby chodziło o jedną tabelę, składnia wyglądałaby np. GRANT SELECT ON hurtownia.zamowienia TO 'sprzedawca'@'localhost'; i wtedy prawo dotyczyłoby wyłącznie tabeli zamowienia. W tym poleceniu dodatkowo jasno określony jest użytkownik: 'sprzedawca'@'localhost'. W MySQL użytkownik jest identyfikowany parą nazwa_użytkownika@host, więc nie jest to ani root, ani żaden inny login, tylko konkretny użytkownik o nazwie sprzedawca, który łączy się z serwera localhost. To jest typowy scenariusz np. dla aplikacji sprzedażowej instalowanej na tym samym serwerze co baza. Taki użytkownik często dostaje tylko SELECT do bazy hurtownia, żeby mógł odczytywać dane (np. listę produktów, stany magazynowe, historię zamówień), ale nie miał uprawnień do modyfikacji struktury bazy czy kasowania rekordów. Moim zdaniem jest to bardzo dobra praktyka bezpieczeństwa: tworzy się osobnych użytkowników o wąskim zakresie uprawnień zamiast wszędzie używać konta root. W realnych projektach webowych, np. w PHP czy innych językach backendowych, w pliku konfiguracyjnym aplikacji podaje się właśnie takiego technicznego użytkownika, który ma GRANT SELECT (czasem też INSERT/UPDATE) tylko na jedną, konkretną bazę. Dzięki temu nawet jeśli aplikacja zostanie zhakowana, atakujący ma dużo mniejsze pole do popisu, bo nie dysponuje pełnymi uprawnieniami administracyjnymi. Dobrze też zapamiętać, że GRANT SELECT nie daje prawa do tworzenia nowych tabel ani zmiany struktury – to są osobne uprawnienia (CREATE, ALTER, DROP). Tutaj mówimy wyłącznie o możliwości wykonywania zapytań odczytujących dane ze wszystkich tabel w bazie hurtownia, co w praktyce oznacza, że użytkownik sprzedawca może spokojnie robić SELECT * FROM jakakolwiek_tabela; pod warunkiem, że ta tabela znajduje się właśnie w tej bazie.

Pytanie 6

Istnieje tabela o nazwie wycieczki z kolumnami: nazwa, cena oraz miejsca (reprezentujące liczbę dostępnych miejsc). Aby wyświetlić tylko nazwy wycieczek, których cena jest mniejsza od 2000 zł oraz mają co najmniej cztery wolne miejsca, należy użyć zapytania

A. SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4

B. SELECT * FROM wycieczki WHERE cena < 2000 OR miejsca > 3

C. SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3

D. SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4

Wszystkie inne odpowiedzi są po prostu błędne i prowadzą do złych wyników w kontekście pytania. Na przykład zapytanie z operatorem OR, czyli 'SELECT nazwa FROM wycieczki WHERE cena < 2000 OR miejsca > 4', pozwala na zwrócenie wycieczek, które spełniają tylko jeden z warunków. To oznacza, że mogą być pokazywane wycieczki droższe, które mają wystarczająco dużo miejsc, co jest niezgodne z wymaganiami. Jeszcze innym błędnym przypadkiem jest użycie operatora AND w 'SELECT nazwa FROM wycieczki WHERE cena < 2000 AND miejsca > 3', gdzie ten drugi warunek jest zbyt ogólny. Powinien precyzować, że miejsc musi być co najmniej cztery, a nie tylko więcej niż trzy. Co więcej, zapytanie 'SELECT * FROM wycieczki WHERE cena < 2000 AND miejsca > 4' zwróci wszystkie kolumny, a nie tylko nazwy wycieczek, co też nie jest tym, czego potrzebujemy. Typowe błędy w myśleniu, które prowadzą do tych błędnych wniosków, to złe łączenie warunków i niewłaściwe zrozumienie, co jest ważne w kontekście wymagań. Aby dobrze pisać zapytania SQL, kluczowe jest zrozumienie struktury danych i logiki, która pozwala na wybranie odpowiednich rekordów.

Pytanie 7

W tabeli psy znajdują się kolumny: imię, rasa, telefon_właściciela, rok_szczepienia. Jakie polecenie SQL należy zastosować, aby znaleźć numery telefonów właścicieli psów, które zostały zaszczepione przed 2015 rokiem?

A. SELECT imię, rasa FROM psy WHERE rok_szczepienia > 2015

B. SELECT telefon_właściciela FROM psy WHERE rok_szczepienia > 2015

C. SELECT telefon_właściciela FROM psy WHERE rok_szczepienia < 2015

D. SELECT psy FROM rok_szczepienia < 2015

Wybór odpowiedzi, które nie są zgodne z wymaganiami pytania, zazwyczaj wynika z nieprawidłowego zrozumienia zarówno struktury zapytania SQL, jak i kontekstu problemu. Na przykład, pierwsza odpowiedź sugeruje użycie 'SELECT psy FROM rok_szczepienia < 2015', co jest błędne, ponieważ polecenie to nie zawiera kolumn, które chcemy wybrać, a także nieprawidłowo formułuje warunek. SQL wymaga, aby w klauzuli SELECT wskazać konkretne kolumny, a nie całą tabelę. Kolejna odpowiedź, wskazująca na 'SELECT imię, rasa FROM psy WHERE rok_szczepienia > 2015', jest również błędna, ponieważ zamiast telefonów właścicieli, wybiera dane dotyczące imion i ras psów oraz zawiera niewłaściwy warunek dotyczący roku szczepienia. Z kolei ostatnia odpowiedź zawiera błąd w interpretacji, wybierając telefony właścicieli psów, które były szczepione po 2015 roku, co jest sprzeczne z założeniem problemu. Tego typu błędy myślowe, jak pomylenie kryteriów wyboru lub wybór nieodpowiednich kolumn, mogą prowadzić do nieprawidłowych wyników w bazach danych. Aby skutecznie korzystać z SQL, kluczowe jest zrozumienie, jak funkcjonują podstawowe konstrukcje zapytań oraz jak poprawnie stosować warunki filtrowania w kontekście wymaganych rezultatów. Właściwe umiejscowienie warunków w klauzuli WHERE oraz precyzyjne definiowanie wybieranych kolumn to fundamenty, które każdy, kto pracuje z bazami danych, powinien opanować.

Pytanie 8

Aby zwiększyć wydajność operacji na bazie danych, powinno się dla pól, które są często używane w wyszukiwaniach lub sortowaniach

A. utworzyć indeks.

B. dodać więzy integralności.

C. dodać klucz obcy.

D. utworzyć osobną tabelę przechowującą wyłącznie te pola.

Utworzenie indeksu jest jedną z najskuteczniejszych metod przyspieszania operacji na bazach danych, szczególnie w kontekście pól, które są często wyszukiwane lub sortowane. Indeksy działają na zasadzie tworzenia struktury danych, która umożliwia szybsze lokalizowanie rekordów w tabeli. Przykładami mogą być indeksy B-drzewiaste lub bitmapowe, które są powszechnie stosowane w systemach zarządzania bazami danych (DBMS). Dzięki indeksom, zapytania takie jak SELECT z klauzulą WHERE lub ORDER BY mogą zyskać na wydajności, ponieważ DBMS nie musi przeszukiwać całej tabeli, ale korzysta z indeksu, aby szybko znaleźć interesujące dane. Warto również zauważyć, że tworzenie indeksów nie jest pozbawione kosztów; przy dodawaniu lub aktualizacji rekordów w tabeli, DBMS musi także aktualizować odpowiadające im indeksy. Dlatego ważne jest, aby tworzyć indeksy na tych kolumnach, które rzeczywiście będą intensywnie wykorzystywane w zapytaniach, zgodnie z najlepszymi praktykami projektowania baz danych, aby zbalansować wydajność i koszty utrzymania bazy. Ponadto, warto regularnie analizować ich użycie i optymalizować, aby dostosować się do zmieniających się wzorców korzystania z danych.

Pytanie 9

Kod```SELECT imie, pesel, wiek FROM dane WHERE wiek IN (18,30)```wybiera

A. imiona, numery PESEL oraz wiek osób mieszczących się w przedziale od 18 do 30 lat

B. imiona, numery PESEL oraz wiek osób, które mają więcej niż 30 lat

C. imiona, nazwiska oraz numery PESEL osób, które mają mniej niż 18 lat

D. imiona, numery PESEL oraz wiek osób w wieku dokładnie 18 lub 30 lat

Odpowiedź jest prawidłowa, ponieważ zapytanie SQL `SELECT imie, pesel, wiek FROM dane WHERE wiek IN (18,30)` w sposób precyzyjny selekcjonuje dane tylko dla osób, których wiek wynosi dokładnie 18 lub 30 lat. Użycie operatora `IN` pozwala na wskazanie konkretnych wartości, które nas interesują, w tym przypadku są to dwa liczby: 18 i 30. Takie podejście jest zgodne z najlepszymi praktykami w tworzeniu zapytań SQL, gdyż umożliwia efektywne filtrowanie danych i minimalizowanie obciążenia bazy danych poprzez ograniczenie ilości przetwarzanych rekordów. W kontekście aplikacji, które wymagają analizy danych demograficznych, na przykład w systemach monitorujących wiek klientów, tego typu zapytania są niezwykle przydatne. Pozwalają na szybkie wyciąganie informacji potrzebnych do podejmowania decyzji, jak na przykład dostosowywanie ofert marketingowych do określonych grup wiekowych. Przykładowo, w instytucji finansowej analiza wieku klientów może być kluczowa w tworzeniu ofert produktów kredytowych skierowanych do osób młodych oraz do tych w średnim wieku, co pozwala na lepsze zrozumienie i zaspokojenie ich potrzeb.

Pytanie 10

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

mysql -u ******* -p Sklep < towary.sql

A. liczbę importowanych obiektów bazy.

B. nazwę użytkownika.

C. nazwę odzyskiwanej tabeli.

D. adres IP bazy danych.

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

Pytanie 11

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

A. makropolecenie

B. kwerenda

C. formularz

D. raport

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

Pytanie 12

Baza danych 6-letniej szkoły podstawowej zawiera tabelę uczniowie z kolumnami: imie, nazwisko, klasa. Wszyscy uczniowie w klasach 1 - 5 zaliczyli do następnej klasy. Aby zwiększyć wartość w kolumnie klasa o 1, należy wykorzystać następujące polecenie

A. UPDATE nazwisko, imie SET klasa=klasa+1 WHERE klasa>1 OR klasa<5;

B. SELECT nazwisko, imie FROM klasa=klasa+1 WHERE klasa>1 OR klasa<5;

C. UPDATE uczniowie SET klasa=klasa+1 WHERE klasa>=1 AND klasa<=5;

D. SELECT uczniowie FROM klasa=klasa+1 WHERE klasa>=1 AND klasa<=5;

Wybór innych odpowiedzi jest wynikiem nieporozumienia dotyczącego składni i logiki poleceń SQL. Na przykład, pierwsza odpowiedź używa konstrukcji 'SELECT', co jest błędne, ponieważ polecenie SELECT służy do pobierania danych z bazy, a nie do ich aktualizacji. W kontekście SQL, klauzula SELECT nie ma możliwości modyfikacji wartości w tabeli, co czyni tę odpowiedź nieadekwatną do postawionego pytania. Kolejny błąd wynika z użycia niepoprawnej składni w drugiej odpowiedzi, która również używa SELECT i nieprawidłowo wskazuje kolumny do aktualizacji. Poza tym, warunek klauzuli 'OR' w tej odpowiedzi nie ogranicza wyników do klas 1-5, co prowadzi do niepożądanych efektów. W trzeciej odpowiedzi, mimo że zawiera ona poprawne podejście do aktualizacji danych, użycie 'UPDATE nazwisko, imie' jest niewłaściwe, ponieważ nie można aktualizować kolumn w ten sposób. W SQL, aby zaktualizować kolumny, należy wskazać jedną tabelę, a nie różne kolumny jako odrębne byty. Typowym błędem myślowym, który prowadzi do takich zawirowań, jest mylenie koncepcji aktualizacji i selekcji, co jest fundamentalne w pracy z bazami danych. Zrozumienie różnicy między tymi operacjami jest kluczowe dla efektywnego i bezbłędnego zarządzania danymi w SQL.

Pytanie 13

Na ilustracji widoczne są dwie tabele. Aby stworzyć relację jeden do wielu, gdzie jeden jest po stronie Klienci, a wiele po stronie Zamowienia, należy

A. Wprowadzić pole klucza obcego do tabeli Klienci i połączyć je z ID tabeli Zamowienia

B. Utworzyć trzecią tabelę z dwoma kluczami obcymi. Jeden klucz połączyć z ID tabeli Klienci, a drugi z ID tabeli Zamowienia

C. Wprowadzić pole klucza obcego do tabeli Zamowienia i połączyć je z ID tabeli Klienci

D. Połączyć relacją pola ID z obu tych tabel

Dodanie pola klucza obcego do tabeli Klienci i połączenie go z ID tabeli Zamowienia nie jest poprawne ponieważ relacja jeden do wielu wymaga aby klucz obcy znajdował się po stronie tabeli która reprezentuje wiele elementów czyli w tym przypadku Zamowienia Jeśli połączymy relacją pola ID z obu tabel nie uzyskamy semantyki relacji jeden do wielu a jedynie relację równoważności co nie odzwierciedla rzeczywistego scenariusza w którym jeden klient może posiadać wiele zamówień Zdefiniowanie trzeciej tabeli z dwoma kluczami obcymi przypomina projektowanie tabeli asocjacyjnej stosowanej raczej w relacjach wiele do wielu niż jeden do wielu Taka konstrukcja jest bardziej skomplikowana i niepotrzebna w tym konkretnym przypadku wprowadza nadmiarowość oraz dodatkowe obciążenie operacyjne Takie błędne podejścia mogą wynikać z niezrozumienia podstawowych zasad modelowania danych oraz zaniedbania w stosowaniu dobrych praktyk projektowych takich jak normalizacja baz danych i optymalizacja struktury relacyjnej Prowadzą one do nieefektywnego przetwarzania danych i trudności w ich późniejszym zarządzaniu

Pytanie 14

Na podstawie relacji przedstawionej na ilustracji, można stwierdzić, że jest to relacja

A. jeden do wielu, gdzie kluczem obcym jest pole w tabeli kadra

B. jeden do jednego, gdzie obie tabele mają przypisane klucze obce

C. wiele do wielu pomiędzy kluczami głównymi obu tabel

D. jeden do wielu, gdzie kluczem obcym jest pole w tabeli uslugi

Odpowiedzi błędne opierają się na niewłaściwym zrozumieniu relacji w bazach danych. Pierwsza z błędnych koncepcji sugeruje relację jeden do wielu, gdzie kluczem obcym jest pole w tabeli kadra, co jest odwrotne do przedstawionej struktury, gdyż w rzeczywistości pole kadra_id znajduje się w tabeli uslugi, wskazując na tabelę kadra. Relacja jeden do jednego, w której obie tabele mają klucze obce, oznaczałoby, że każdy rekord w jednej tabeli jest ściśle powiązany z jednym rekordem w drugiej, co nie jest przypadkiem dla tych danych. Takie podejście zwykle stosuje się, gdy tabele przechowują różne aspekty tego samego podmiotu, co nie jest odzwierciedlone na diagramie. Relacja wiele do wielu między kluczami głównymi obu tabel wymagałaby użycia dodatkowej tabeli łączącej, co umożliwiałoby powiązanie wielu rekordów każdej z tabel z wieloma rekordami drugiej, co również nie jest przedstawione tutaj. Typową pomyłką przy analizie tego typu relacji jest nieuwzględnienie struktury kluczy obcych i ich roli w łączeniu danych poprzez zrozumienie ich jako jedynie strukturalne powiązania, zamiast narzędzi umożliwiających integralność i spójność danych w bazie. Ważne jest, aby zawsze analizować kierunek relacji i rolę kluczowych pól w kontekście aplikacji i modelu danych, co zapobiega błędnym interpretacjom i wspiera prawidłowe projektowanie bazy danych, zgodnie z jej wymaganiami funkcjonalnymi i wydajnościowymi.

Pytanie 15

W MS SQL Server predefiniowana rola o nazwie dbcreator umożliwia użytkownikowi

A. zarządzanie plikami na nośniku

B. wykonywanie wszelkich operacji na serwerze oraz posiadanie praw do każdej bazy

C. zarządzanie zabezpieczeniami systemu

D. tworzenie, aktualizowanie, usuwanie oraz przywracanie bazy danych

Odpowiedź nr 3 jest poprawna, ponieważ rola dbcreator w MS SQL Server umożliwia użytkownikowi tworzenie, modyfikowanie, usuwanie oraz odzyskiwanie baz danych. Użytkownik z tą rolą ma prawo do pełnej kontroli nad bazami danych, co jest istotne w kontekście zarządzania i utrzymania infrastruktury danych. Przykład praktyczny to sytuacja, w której administrator bazy danych potrzebuje utworzyć nową bazę dla aplikacji. Dzięki roli dbcreator może to zrobić bez dodatkowych uprawnień. Rola ta jest zgodna z najlepszymi praktykami w zakresie zarządzania dostępem, gdzie ogranicza się uprawnienia do niezbędnego minimum, ale jednocześnie umożliwia wykonanie kluczowych zadań związanych z zarządzaniem bazą danych. Warto zaznaczyć, że nadmierne przyznawanie uprawnień może prowadzić do problemów związanych z bezpieczeństwem, dlatego istotne jest przydzielanie ról zgodnie z zasadą najmniejszych uprawnień (Least Privilege Principle). Użytkownicy z rolą dbcreator powinni być odpowiednio przeszkoleni i świadomi swoich działań, aby nie wprowadzać niezamierzonych zmian w środowisku produkcyjnym.

Pytanie 16

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

A. GRANT DROP ON szkola.przedmioty TO uczen;

B. GRANT ALTER, SELECT 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 17

Polecenie GRANT w języku SQL służy do

A. odbierania użytkownikom praw do obiektów.

B. nadawania użytkownikom praw do obiektów.

C. umieszczania nowych danych w bazie.

D. aktualizacji istniejących danych w bazie.

Poprawnie – polecenie GRANT w SQL służy właśnie do nadawania użytkownikom praw do obiektów w bazie danych. W praktyce GRANT jest jednym z kluczowych narzędzi mechanizmu kontroli dostępu, czyli tzw. autoryzacji. Najpierw ktoś łączy się z bazą (to jest uwierzytelnianie – login/hasło, certyfikat itd.), a dopiero potem baza sprawdza, jakie uprawnienia ma ten użytkownik. I tu wchodzi GRANT. Administrator lub właściciel obiektu może przyznać użytkownikowi np. prawo SELECT do tabeli `klienci`, prawo INSERT do tabeli `zamowienia`, albo prawo EXECUTE do procedury składowanej. Składnia jest dość prosta, np.: `GRANT SELECT, INSERT ON klienci TO jan;`. W większości systemów (np. PostgreSQL, Oracle, MySQL/MariaDB, SQL Server) idea jest podobna, różnią się tylko szczegóły i nazwy ról czy typów uprawnień. W dobrych praktykach bezpieczeństwa nie daje się użytkownikom uprawnień typu „wszystko na wszystkim”, tylko dokładnie to, czego potrzebują (tzw. zasada najmniejszych uprawnień – least privilege). Moim zdaniem warto już na etapie nauki SQL odróżniać polecenia do pracy na danych (SELECT, INSERT, UPDATE, DELETE) od poleceń do zarządzania uprawnieniami, takich jak GRANT i REVOKE. W codziennej pracy administratora baz, programisty backendu czy nawet osoby od DevOps, GRANT pojawia się bardzo często: przy tworzeniu nowych kont aplikacyjnych, przy separacji środowisk (dev/test/prod), przy ograniczaniu dostępu do wrażliwych tabel, np. z danymi osobowymi. Dobre zrozumienie GRANT pomaga też szybko diagnozować błędy typu „permission denied” i świadomie projektować politykę bezpieczeństwa w systemie.

Pytanie 18

Które polecenie SQL zaktualizuje w tabeli tab wartość Ania na Zosia w kolumnie kol?

A. ALTER TABLE tab CHANGE kol='Ania' kol='Zosia';

B. UPDATE tab SET kol='Ania' WHERE kol='Zosia';

C. ALTER TABLE tab CHANGE kol='Zosia' kol='Ania';

D. UPDATE tab SET kol='Zosia' WHERE kol='Ania';

W przypadku błędnych odpowiedzi, mamy do czynienia z niepoprawnym użyciem SQL i niezrozumieniem, jak zmieniać wartości w tabelach. Pierwsza błędna odpowiedź używa UPDATE, ale zmienia 'Zosia' na 'Ania', co jest zupełnie na opak. Takie coś może wprowadzić zamieszanie, zwłaszcza jeśli w tabeli już jest 'Zosia' i np. nie chcemy, żeby się to zmieniało. Druga odpowiedź korzysta z ALTER TABLE, co jest totalnie nie o to. ALTER TABLE zmienia strukturę tabeli, a nie dane w kolumnie. A zmiana nazwy kolumny, jak sugeruje ta odpowiedź, nie ma sensu, bo chodzi o dane, a nie o to, jak kolumna się nazywa. Ostatnia błędna odpowiedź też ciśnie na ALTER TABLE, co pokazuje, że te odpowiedzi nie rozumieją, co mają robić. W skrócie, te odpowiedzi mylą różne funkcje SQL i podkreślają, jak ważne jest zrozumienie, kiedy i jak używać danych instrukcji w zarządzaniu informacjami.

Pytanie 19

Na tabeli dania, której wiersze zostały pokazane poniżej, wykonano przedstawioną kwerendę:

SELECT * FROM dania WHERE typ < 3 AND cena < 30 LIMIT 5;

Ile wierszy wybierze ta kwerenda?

id	typ	nazwa	cena
1	1	Gazpacho	20
2	1	Krem z warzyw	25
3	1	Gulaszowa ostra	30
4	2	Kaczka i owoc	30
5	2	Kurczak pieczony	40
6	3	wierzbowy przysmak	35
7	2	Mintał w panierce	30
8	2	Alle kotlet	30
9	3	Owoce morza	20
10	3	Grzybki, warzywka, sos	15
11	3	Orzechy i chipsy	10
12	3	Tatar i jajo	15
13	3	Bukiet warzyw	10

A. 2

B. 5

C. 13

D. 8

Trochę nie tak zrozumiałeś, jak działają klauzule 'WHERE' i 'LIMIT' w SQL. Klauzula 'WHERE' filtruje wiersze, a w tym przypadku miały być dwa warunki: 'typ' musi być mniejszy od 3 i 'cena' mniejsza od 30. Te warunki są połączone przez AND, więc wszystkie muszą być spełnione naraz. W tabeli tylko jeden wiersz to spełnia. Klauzula 'LIMIT' natomiast ustala maksymalną liczbę wierszy, które mogą się pojawić w wynikach, ale tu, nawet z limitem 5, wynik się nie zmienia, bo tylko jeden wiersz spełnia te kryteria. Zrozumienie, jak to wszystko współdziała, jest naprawdę ważne, żeby dobrze korzystać z SQL.

Pytanie 20

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

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

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

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

D. SELECT nazwisko FROM klienci LIMIT 3

Odpowiedzi, które nie prowadzą do poprawnego wyniku, często bazują na niewłaściwym zrozumieniu składni SQL oraz logiki działania kwerend. W pierwszej opcji zastosowano klauzulę LIMIT 3, ale przy wyborze nazwisk z tabeli klienci użyto sortowania po nazwisku zamiast punktach. To podejście prowadzi do niepoprawnego wyniku, gdyż nie uwzględnia kryterium, które jest kluczowe dla określenia najlepszych klientów. W drugiej opcji, kwerenda SELECT nazwisko FROM klienci LIMIT 3 nie zawiera żadnego sortowania, co skutkuje losowym wyborem trzech klientów z tabeli, niezależnie od ich punktów, co jest całkowicie nieadekwatne do zadania. Z kolei w trzeciej propozycji, chociaż zastosowano sortowanie, wybór odbywa się po nazwisku, co nie spełnia wymagania dotyczącego punktów. Typowe błędy myślowe, które mogą prowadzić do takich odpowiedzi, to niepełne zrozumienie funkcji klauzuli ORDER BY oraz roli, jaką odgrywa LIMIT w kontekście selekcji danych. Aby efektywnie operować danymi w SQL, niezbędne jest zrozumienie, jak właściwie formułować zapytania, aby uzyskać oczekiwane wyniki. Praktyka w tworzeniu kwerend, a także znajomość struktury danych, pomagają unikać tych pułapek i pozwalają na skuteczniejsze zarządzanie informacjami w bazach danych.

Pytanie 21

Jakie obiekty w bazie danych służą do podsumowywania, prezentacji oraz drukowania danych?

A. raport

B. formularz

C. zapytanie

D. zestawienie

Raport jest narzędziem w bazach danych, które umożliwia podsumowywanie, wyświetlanie i wydruk danych w zorganizowanej formie. Jego głównym celem jest przedstawienie informacji w sposób zrozumiały i estetyczny, co jest szczególnie ważne w kontekście analizy danych oraz podejmowania decyzji biznesowych. Raporty mogą być wykorzystane do generowania zestawień wyników finansowych, analiz sprzedaży czy statystyk użytkowników. Umożliwiają one również prezentację danych w formie tabel, wykresów i diagramów, co zwiększa ich czytelność. W branży IT i zarządzania danymi, dobrą praktyką jest korzystanie z narzędzi raportowych, które integrują się z bazami danych, co pozwala na automatyczne aktualizowanie danych oraz lepszą wizualizację. Warto również wspomnieć o różnych formatach, w jakich raporty mogą być generowane, takich jak PDF, XLSX czy HTML, co umożliwia ich łatwe udostępnianie i archiwizowanie.

Pytanie 22

Tabele Osoby i Adresy są połączone relacją jeden do wielu. Które zapytanie SQL należy wykonać, aby korzystając z tej relacji, prawidłowo wyświetlić nazwiska oraz przyporządkowane im miasta?

A. SELECT nazwisko, Miasto FROM Osoby JOIN Adresy ON Osoby.Adresy_id = Adresy.id;

B. SELECT nazwisko, Miasto FROM Osoby, Adresy;

C. SELECT nazwisko, Miasto FROM Osoby, Adresy WHERE Osoby.id = Adresy.id;

D. SELECT nazwisko, Miasto FROM Osoby.Adresy_id = Adresy.id FROM Osoby, Adresy;

W tym zadaniu widać kilka typowych pułapek związanych z łączeniem tabel w SQL. Często spotyka się podejście, że wystarczy wypisać kilka tabel po przecinku w klauzuli FROM i baza danych sama się domyśli, jak je połączyć. Niestety tak to nie działa. Jeśli podamy FROM Osoby, Adresy bez żadnego warunku, otrzymamy tzw. iloczyn kartezjański. Oznacza to, że każda osoba zostanie połączona z każdym adresem, co w praktyce daje ogromny, kompletnie bezsensowny zestaw danych. To jest bardzo częsty błąd początkujących: zapytanie technicznie się wykonuje, ale wynik nie ma żadnego logicznego związku z modelem danych. Drugi problem to łączenie tabel po niewłaściwych kolumnach. Zdarza się założenie, że skoro obie tabele mają kolumnę id, to można je po prostu zrównać w warunku WHERE Osoby.id = Adresy.id. Jest to myślenie intuicyjne, ale błędne z punktu widzenia projektowania relacyjnego. Kolumna id w każdej tabeli jest zwykle osobnym kluczem głównym i nie ma powodu, żeby ich wartości się pokrywały. W poprawnym modelu relacji używa się klucza obcego, tutaj Osoby.Adresy_id, który jawnie wskazuje na Adresy.id. To właśnie te dwie kolumny należy ze sobą powiązać. Kolejna pułapka to mylenie składni JOIN z warunkiem łączenia. Fragment Osoby.Adresy_id = Adresy.id nie może znajdować się w miejscu, gdzie SQL oczekuje listy tabel po FROM albo słowa kluczowego JOIN. To jest wyrażenie logiczne, które powinno znaleźć się w klauzuli ON (w przypadku JOIN) lub w WHERE (w starszym stylu zapisu). Moim zdaniem ważne jest, żeby w głowie rozdzielić trzy elementy: najpierw wymieniamy tabele, które chcemy połączyć, potem określamy typ złączenia (JOIN, LEFT JOIN itd.), a dopiero na końcu definiujemy warunek powiązania ON klucz_obcy = klucz_główny. Jeśli pomieszamy te poziomy, wychodzą dziwne konstrukcje, które są po prostu niezgodne ze składnią SQL. Dobra praktyka branżowa jest taka, że używamy jawnych JOIN-ów z precyzyjnym warunkiem ON i zawsze sprawdzamy, czy łączymy po właściwych kolumnach wynikających z relacji w modelu danych.

Pytanie 23

Tabela filmy zawiera klucz główny id oraz klucz obcy rezyserID, natomiast tabela rezyserzy ma klucz główny id. Obydwie tabele są połączone relacją jeden do wielu, gdzie strona rezyserzy odnosi się do strony filmy. Jak należy zapisać kwerendę SELECT, aby połączyć tabele filmy i rezyserzy?

A. ... filmy JOIN rezyserzy ON filmy.id = rezyserzy.id ...

B. ... filmy JOIN rezyserzy ON filmy.rezyserID = rezyserzy.id ...

C. ... filmy JOIN rezyserzy ON filmy.id = rezyserzy.filmyID ...

D. ... filmy JOIN rezyserzy ON filmy.rezyserID = rezyserzy.filmyID ...

W przypadku błędnych odpowiedzi, takich jak używanie rezyserzy.filmyID lub porównywanie kluczy głównych tabeli rezyserzy z kluczami głównymi tabeli filmy, istotne jest zrozumienie, że klucze muszą być stosowane zgodnie z ich rolami w relacji. Klucz obcy w tabeli filmy (rezyserID) jest przeznaczony do wskazywania na odpowiedni klucz główny w tabeli rezyserzy (id). Używanie rezyserzy.filmyID jest całkowicie błędne, ponieważ tabela rezyserzy nie ma kolumny o takiej nazwie; nie ma relacji, która by wskazywała na filmy w tej tabeli. Z kolei porównywanie filmy.id z rezyserzy.id nie jest sensowne, ponieważ porównujemy dwa różne klucze, które nie mają ze sobą bezpośredniego związku, co prowadzi do niepoprawnych wyników zapytań. Klucz rezyserID w tabeli filmy jest odpowiedzialny za powiązanie konkretnego reżysera z filmem, a nie odwrotnie. Warto również zauważyć, że nieprzestrzeganie zasad normalizacji oraz poprawnego stosowania kluczy obcych może prowadzić do niejednoznacznych danych oraz trudności w utrzymaniu spójności bazy danych.

Pytanie 24

Wskaż właściwą zasadę odnoszącą się do integralności danych w bazie danych?

A. w relacji 1..n pole klucza obcego łączy się z polem klucza podstawowego innej tabeli

B. pole klucza podstawowego nie powinno być puste

C. pole klucza podstawowego musi mieć utworzony indeks

D. pole klucza obcego nie powinno być puste

Wybór odpowiedzi dotyczącej klucza obcego, klucza podstawowego z indeksem lub relacji 1..n nie jest dostosowany do rzeczywistych zasad spójności danych w bazach danych. Klucz obcy, choć istotny dla relacji pomiędzy tabelami, może być pusty, jeżeli nie jest konieczne wskazanie powiązania z innym rekordem. Oznacza to, że pole klucza obcego w przypadku niektórych relacji może pozostawać puste bez naruszania integralności danych, co jest szczególnie widoczne w relacjach opcjonalnych. Odnośnie klucza podstawowego, również może pojawić się nieporozumienie, ponieważ pole klucza podstawowego wymaga utworzenia indeksu, ale nie jest to bezpośrednim wymogiem, aby pole to było puste. W praktyce, wielokrotnie można zaobserwować błędne założenia, że obecność indeksu automatycznie implikuje poprawność klucza podstawowego, co jest nieprawidłowe. Dodatkowo, niepoprawne jest również stwierdzenie, że pole klucza obcego jest zawsze powiązane z innym kluczem obcym; relacja 1..n oznacza, że klucz obcy w tabeli podrzędnej wskazuje na klucz podstawowy w tabeli głównej, a nie na inny klucz obcy. Te błędne koncepcje prowadzą do nieporozumień w projektowaniu baz danych oraz mogą skutkować nieefektywnymi, narażonymi na błędy systemami zarządzania danymi, które mogą naruszać zasady spójności oraz integralności danych.

Pytanie 25

Aby zaktualizować maksymalną długość kolumny imie w tabeli klienci do 30 znaków, należy zastosować w języku SQL poniższy kod

A. CHANGE TABLE klienci MODIFY imie CHAR(30);

B. ALTER TABLE klienci MODIFY COLUMN imie VARCHAR(30);

C. ALTER TABLE klienci CHANGE imie TEXT;

D. CHANGE TABLE klienci TO COLUMN imie SET CHAR(30);

Aby zmienić maksymalną długość pola 'imie' w tabeli 'klienci' na 30 znaków, używamy polecenia SQL 'ALTER TABLE', które jest standardowym sposobem modyfikacji struktury tabeli w bazach danych. W tym przypadku wykorzystujemy 'MODIFY COLUMN', co jest istotne, ponieważ pozwala na precyzyjne określenie, że chcemy zmienić właściwości konkretnej kolumny. Typ danych 'VARCHAR' oznacza, że kolumna może przechowywać zmienne długości tekstu, a wartość 30 oznacza maksymalną liczbę znaków. Przykładowo, jeśli w bazie danych już istnieją rekordy, to zmiana ta nie wpłynie na dane, które są krótsze niż 30 znaków, ale może być problematyczna, jeśli próbujemy wprowadzić dane dłuższe niż dozwolone, ponieważ takie operacje mogą kończyć się błędami. Warto również zaznaczyć, że różne systemy zarządzania bazami danych, takie jak MySQL, PostgreSQL czy Oracle, mogą mieć drobne różnice w składni, ale zasada działania polecenia 'ALTER TABLE' pozostaje zasadniczo taka sama. To podejście jest zgodne z zaleceniami standardu SQL i jest powszechnie stosowane w praktykach administracji bazami danych.

Pytanie 26

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

A. INTEGER(11)

B. TINYTEXT

C. DECIMAL(10, 2)

D. ENUM

Typ DECIMAL(10, 2) jest odpowiedni dla pola ceny w tabeli produktów, ponieważ umożliwia dokładne przechowywanie wartości liczbowych z określoną precyzją i skalą. W tym przypadku liczba 10 oznacza maksymalną liczbę cyfr, które mogą być przechowywane, a 2 oznacza liczbę cyfr po przecinku. Dzięki temu można przechowywać wartości cenowe, które mają do dwóch miejsc po przecinku, co jest standardem w większości aplikacji związanych z handlem. Przykładem może być cena produktu wynosząca 19,99 PLN. Użycie typu DECIMAL jest zgodne z dobrymi praktykami w projektowaniu baz danych, ponieważ zapobiega problemom związanym z zaokrąglaniem, które mogą występować przy użyciu typów zmiennoprzecinkowych. Stosowanie DECIMAL jest szczególnie istotne w aplikacjach finansowych, gdzie precyzja wartości jest kluczowa. Warto dodać, że zgodnie z normami SQL, stosowanie tego typu danych pozwala na wykonywanie dokładnych zapytań i obliczeń, co jest niezbędne do prawidłowego funkcjonowania systemów zarządzania danymi.

Pytanie 27

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.

Poprawna odpowiedź to 'dodaje do tabeli kolumnę o nazwie kod typu text'. Polecenie SQL ALTER TABLE służy do modyfikacji struktury istniejącej tabeli, a w tym przypadku dodaje nową kolumnę do tabeli 'miasta'. Składnia ADD 'kod' text oznacza, że do tabeli zostanie dodana kolumna o nazwie 'kod', której typ danych to 'text'. Typ danych 'text' jest używany do przechowywania długich ciągów tekstowych, co jest przydatne w przypadku danych takich jak opisy czy komentarze. W praktyce, dodawanie kolumn do tabeli jest często wykorzystywane w procesie rozwoju bazy danych, aby dostosować strukturę do zmieniających się potrzeb aplikacji. W przypadku dodawania kolumn w sposób nieinwazyjny, jak w tym przykładzie, zapewniamy, że istniejące dane nie zostaną utracone, a nowa kolumna będzie dostępna do natychmiastowego użycia. Warto również pamiętać, aby stosować konwencje nazewnictwa, które poprawiają czytelność i zrozumiałość kodu SQL, co jest zalecane w dobrych praktykach projektowania baz danych.

Pytanie 28

Który typ danych należy przypisać kolumnie z kodami pocztowymi w tabeli relacyjnej bazy danych, aby przechowywała dane w formie łańcuchów znakowych o zdefiniowanej, stałej długości?

A. CHAR

B. TEXT

C. DECIMAL

D. BLOB

Przy typie danych dla kodów pocztowych łatwo wpaść w pułapkę myślenia „składa się z cyfr, więc to liczba”. To jeden z częstszych błędów przy projektowaniu schematów baz danych. Kod pocztowy jest w rzeczywistości identyfikatorem tekstowym, a nie wartością numeryczną do obliczeń. Dlatego wybór typów takich jak TEXT, BLOB czy DECIMAL prowadzi do różnych problemów logicznych i wydajnościowych. Duży typ tekstowy, taki jak TEXT, jest przeznaczony do przechowywania dłuższych opisów, komentarzy, treści artykułów i innych pól o zmiennej, zazwyczaj nieograniczonej długości. Silnik bazy danych zwykle przechowuje te dane poza główną strukturą rekordu, co ma sens dla długich stringów, ale dla krótkiego kodu pocztowego jest po prostu przerostem formy nad treścią. Tracisz też jasną informację, że długość powinna być stała, trudniej jest narzucić sensowne ograniczenia, a indeksowanie takich pól bywa mniej efektywne. Jeszcze mniej pasuje BLOB, który służy do binarnych danych, takich jak obrazy, pliki PDF, dane multimedialne. Traktowanie kodu pocztowego jako ciągu bajtów bez kontekstu znakowego kompletnie mija się z celem. Taki typ utrudnia sortowanie, filtrowanie, walidację formatu i w zasadzie odcina cię od naturalnych mechanizmów operowania na tekstach, jakie oferuje SQL. DECIMAL wygląda pozornie kusząco, bo „kod to cyfry”, ale tutaj właśnie leży klasyczny błąd. Typy numeryczne są projektowane do obliczeń matematycznych, a nie do identyfikatorów. Możesz wtedy stracić zera wiodące, co w kodach pocztowych ma krytyczne znaczenie. Dodatkowo w wielu krajach kody zawierają litery czy myślniki, więc DECIMAL po prostu nie pozwoli na poprawne zapisanie takich wartości. Z mojego doświadczenia, gdy ktoś wybiera typ liczbowy dla kodu pocztowego, potem i tak musi migrować schemat, bo pojawiają się nowe wymagania, inne formaty, integracja z zagranicznymi systemami. W dobrze zaprojektowanych modelach danych przyjmuje się zasadę: identyfikatory i kody, które nie służą do liczenia, przechowujemy jako tekst o kontrolowanej długości. W tym wypadku idealnie pasuje CHAR o odpowiednim rozmiarze, bo jasno komunikuje, że długość jest stała i pozwala silnikowi bazy optymalizować przechowywanie oraz indeksy. Wybór innego typu zwykle wynika z mylenia „cyfr” z „liczbami”, co na etapie projektowania wydaje się drobiazgiem, a później odbija się na jakości całego systemu.

Pytanie 29

Polecenie SQL:

GRANT SELECT, INSERT, UPDATE, DELETE ON klienci TO adam@localhost

Przedstawione polecenie SQL nadaje użytkownikowi adam@localhost prawa:

A. do manipulowania danymi w tabeli klienci

B. do zarządzania strukturą tabeli klienci

C. do zarządzania strukturą bazy danych klienci

D. do manipulowania danymi bazy danych klienci

W kontekście analizy niepoprawnych odpowiedzi, odpowiedzi dotyczące zarządzania strukturą tabeli klienci oraz zarządzania strukturą bazy danych klienci są niepoprawne, ponieważ polecenie GRANT nie odnosi się do tych aspektów. Zarządzanie strukturą tabeli zazwyczaj obejmuje takie operacje jak tworzenie lub modyfikowanie tabel, co jest realizowane przez polecenia takie jak CREATE TABLE czy ALTER TABLE. W przypadku polecenia GRANT, nie ma mowy o wprowadzaniu zmian w strukturze tabeli, a jedynie o nadawaniu uprawnień do manipulacji danymi. Podobnie, zarządzanie strukturą bazy danych dotyczy bardziej operacji administracyjnych, takich jak tworzenie bazy danych, co również nie jest tożsame z uprawnieniami do operacji na danych. Ostatnia z niepoprawnych odpowiedzi, dotycząca manipulowania danymi bazy danych klienci, jest również myląca, ponieważ odnosi się do całej bazy danych jako całości, podczas gdy polecenie dotyczy wyłącznie konkretnej tabeli. W praktyce, zarządzanie danymi w kontekście bazy danych oznacza operacje na zbiorze danych, a nie na pojedynczych rekordach w tabelach. Dlatego kluczowe jest zrozumienie, że GRANT pozwala na nadawanie uprawnień do działania na konkretnej tabeli, a nie na całej bazie danych czy jej strukturze.

Pytanie 30

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

A. funkcje mysqli_error i mysqli_errno

B. funkcje mysqli_error i mysqli_connect_errno

C. funkcje mysqli_error i mysqli_error_number

D. tylko funkcję mysqli_error

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

Pytanie 31

Co oznacza skrót SQL?

A. Simple Query Logic

B. Standard Quality Language

C. Structured Query Language

D. Sequential Question Language

Podczas gdy SQL oznacza Structured Query Language, pozostałe propozycje nazw są błędne i nie odzwierciedlają prawdziwego znaczenia skrótu. Często spotykanym błędem jest mylenie skrótów związanych z technologią z innymi, które brzmią podobnie, ale nie mają związku z kontekstem technicznym. W przypadku Standard Quality Language, jest to przykład błędnego dopasowania, ponieważ nie ma bezpośredniego związku z bazami danych ani językiem zapytań. Podobnie, Sequential Question Language brzmi jakby miało związek z zadawaniem pytań w sekwencji, co jest całkowitym nieporozumieniem w kontekście SQL. Z kolei Simple Query Logic może wydawać się związany z logiką zapytań, ale nie oddaje w pełni roli i funkcji SQL jako języka do zarządzania danymi. Takie błędne interpretacje wynikają często z nieznajomości terminologii technicznej i mogą prowadzić do nieporozumień w kontekście zawodowym. Ważne jest, aby dobrze rozumieć podstawową terminologię, zwłaszcza w tak kluczowych dziedzinach jak zarządzanie bazami danych, aby unikać błędów w komunikacji i implementacji rozwiązań technicznych.

Pytanie 32

Jaką rolę pełni funkcja PHP o nazwie mysql_select_db()?

A. pobrać dane z bazy danych na podstawie zapytania

B. nawiązać połączenie bazy danych z serwerem SQL

C. określić tabelę, z której będą pobierane informacje

D. określić bazę, z której będą pobierane dane

Istnieje kilka powszechnych nieporozumień dotyczących funkcji mysql_select_db(), które mogą prowadzić do błędnych wniosków. Niewłaściwe jest myślenie, że ta funkcja służy do określenia tabeli, z której będą pobierane dane. W rzeczywistości, mysql_select_db() nie odnosi się bezpośrednio do tabel; zamiast tego, definiuje bazę, w której te tabele się znajdują. Kolejnym błędem jest przekonanie, że mysql_select_db() odpowiada za połączenie bazy danych z serwerem SQL. To zadanie należy do mysql_connect(), która tworzy połączenie z serwerem. Istnieje również mylne założenie, że funkcja ta pobiera dane z bazy danych. W rzeczywistości, pobieranie danych odbywa się za pomocą osobnych zapytań SQL, które są wykonywane po wcześniejszym wybraniu odpowiedniej bazy danych. Takie nieporozumienia mogą prowadzić do błędów w kodzie, gdzie programista usiłuje używać mysql_select_db() do operacji, które nie są jej przeznaczone. Niezrozumienie roli bazy danych i tabel w kontekście SQL oraz funkcji PHP może skutkować nieefektywnym kodem oraz problemami z jego debugowaniem. Ważne jest, aby mieć jasność co do roli różnych funkcji w interakcji z bazą danych, co pozwala na bardziej efektywne i bezpieczne programowanie.

Pytanie 33

W tabeli podzespoly należy zaktualizować wartość pola URL na 'toshiba.pl' dla wszystkich rekordów, gdzie pole producent to TOSHIBA. W języku SQL ta zmiana będzie wyglądała następująco

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';

Odpowiedź ta jest prawidłowa, ponieważ poprawnie wykorzystuje składnię języka SQL do aktualizacji danych w tabeli. W instrukcji UPDATE podzespoly SET URL='toshiba.pl' WHERE producent='TOSHIBA'; najpierw wskazujemy tabelę, w której chcemy dokonać zmian, czyli 'podzespoly'. Następnie używamy klauzuli SET, aby zdefiniować nową wartość pola URL, a klauzula WHERE precyzuje, które rekordy mają zostać zaktualizowane, w tym przypadku te, gdzie producent to 'TOSHIBA'. To podejście jest zgodne z dobrymi praktykami, ponieważ stosowanie klauzuli WHERE zapobiega masowym aktualizacjom, które mogą prowadzić do niezamierzonych zmian w danych. Przykładowo, jeśli chcielibyśmy zaktualizować tylko określoną grupę produktów, klauzula WHERE pozwala na precyzyjne określenie zakresu zmian. Wprowadzenie takiej modyfikacji w bazie danych, z uwzględnieniem warunków, minimalizuje ryzyko błędów i poprawia integralność danych.

Pytanie 34

Jakie zapytanie SQL będzie odpowiednie do odnalezienia w podanej tabeli tylko imion oraz nazwisk pacjentów, którzy przyszli na świat przed rokiem 2002?

A. SELECT * FROM Pacjenci WHERE rok_urodzenia <= 2002

B. SELECT * FROM Pacjenci WHERE rok_urodzenia LIKE 2002

C. SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < 2002

D. SELECT imie, nazwisko FROM Pacjenci WHERE data_ostatniej_wizyty < 2002

W tym zapytaniu zastosowałeś składnię SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < 2002, co jest super, bo pozwala wyciągnąć tylko te imiona i nazwiska pacjentów, którzy urodzili się przed rokiem 2002. Użycie konkretnych kolumn jak imie i nazwisko zamiast znaku * to niezła sprawa, bo ogranicza wyniki do tego, co naprawdę potrzebujesz. To z kolei może znacząco zwiększyć wydajność przesyłania danych. No i to WHERE rok_urodzenia < 2002 – świetny ruch! Fajnie, że potrafisz filtrować dane według konkretnego warunku. Bez tego miałbyś wszystkie osoby, nie tylko te sprzed 2002 roku. To jest właśnie selekcja warunkowa w SQL, a jej znajomość to podstawa przy analizie danych. Zgadzam się również, że uniknięcie znaków wieloznacznych jak LIKE w tej sytuacji to dobre podejście, bo używasz bezpośrednich porównań liczbowych, co generalnie działa lepiej i daje jaśniejsze wyniki.

Pytanie 35

Rekord w bazie danych identyfikowany jest jednoznacznie przez pole

A. klucza podstawowego

B. relacji

C. klucza obcego

D. numeryczne

Klucz podstawowy jest unikalnym identyfikatorem rekordu w tabeli bazy danych, który zapewnia jednoznaczność każdego wpisu. W praktyce oznacza to, że żaden z wpisów w tabeli nie może mieć tego samego klucza podstawowego, co pozwala na łatwe odnajdywanie i łączenie danych. Klucz podstawowy jest często implementowany jako pole numeryczne, co umożliwia szybką i efektywną indeksację. W standardzie SQL klucz podstawowy definiuje się za pomocą polecenia 'PRIMARY KEY'. Przykładem zastosowania klucza podstawowego może być tabela 'Użytkownicy', w której pole 'ID_Użytkownika' pełni rolę klucza podstawowego, zapewniając unikalność dla każdego użytkownika. Klucz podstawowy może składać się z jednego lub więcej pól, a w przypadku złożonych kluczy podstawowych, wszystkie pola muszą być wypełnione, aby rekord był uznany za unikalny. Dlatego właśnie klucz podstawowy jest fundamentem relacyjnych baz danych, umożliwiającym prawidłowe zarządzanie danymi.

Pytanie 36

Jakie zapytanie należy użyć, aby wyświetlić tylko imię, nazwisko oraz ulicę wszystkich mieszkańców?

A. SELECT * FROM Mieszkancy, Adresy ON Mieszkancy.id = Adresy.id

B. SELECT imie, nazwisko, ulica FROM Mieszkancy, Adresy ON Mieszkancy.Adresy_id = Adresy.id

C. SELECT imie, nazwisko, ulica FROM Mieszkancy JOIN Adresy ON Mieszkancy.Adresy_id = Adresy.id

D. SELECT * FROM Mieszkancy JOIN Adresy ON Adresy.id = Mieszkancy.Adresy.id

Próbując wybrać tylko konkretne kolumny z powiązanych tabel, ważne jest, żeby poprawnie zastosować składnię SQL. Jak źle podejdziesz do tego, mogą wyjść niepoprawne wyniki albo zapytanie może działać nieefektywnie. Często takie błędy wynikają z tego, że nie do końca rozumiemy relacje między tabelami. Jeśli użyjesz zapytania SELECT * FROM Mieszkancy Adresy ON Mieszkancy.id = Adresy.id, to poległeś, bo nie podałeś poprawnego typu złączenia, a dodatkowo użycie gwiazdki * zwraca wszystkie kolumny, co jest niezgodne z celem tego pytania. Jeszcze gorzej, jeśli napiszesz SELECT * FROM Mieszkancy JOIN Adresy ON Adresy.id = Mieszkancy.Adresy.id – mimo, że JOIN jest ok, używanie gwiazdki sprawia, że nie spełniasz warunków dotyczących selekcji kolumn. W obu przypadkach brakuje selektywności, przez co zapytania są mało efektywne i niezgodne z dobrymi praktykami w projektowaniu baz danych. Zapytanie SELECT imie nazwisko ulica FROM Mieszkancy Adresy ON Mieszkancy.Adresy_id = Adresy.id, chociaż wymienia dobre kolumny, stosuje błędną składnię JOIN, więc jest syntaktycznie złe. SQL wymaga precyzji przy złączaniu, żeby dane były spójne i integralne. Rozumienie, jak poprawnie używać JOIN i jak wybierać kolumny, jest kluczowe do tworzenia skutecznych zapytań, co wpływa na optymalizację pracy z bazami danych.

Pytanie 37

Które z komend przyznaje najniższy poziom uprawnień dla użytkownika uczen w zakresie modyfikacji danych oraz struktury tabeli?

A. GRANT SELECT ON szkola.przedmioty TO uczen

B. DRANT DROP ON szkola.przedmioty TO uczen

C. GRANT INSERT, DROP ON szkola.przedmioty TO uczen

D. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen

Wszystkie pozostałe polecenia przyznają użytkownikowi uczeń szerszy zakres uprawnień, co prowadzi do większego ryzyka nieautoryzowanej modyfikacji danych. Polecenie DRANT DROP ON szkola.przedmioty TO uczen jest nieprawidłowe, ponieważ DRANT nie jest poprawnym poleceniem SQL, co czyni jego interpretację niemożliwą. W kontekście administracji bazami danych, DROP oznacza usunięcie całej tabeli, co w przypadku użytkownika uczeń może prowadzić do katastrofalnych skutków, gdyż może on przypadkowo lub celowo usunąć istotne dane. Kolejne polecenie GRANT INSERT, DROP ON szkola.przedmioty TO uczen przyznaje prawo do wstawiania nowych danych oraz usuwania tabeli. Takie uprawnienia są zdecydowanie nieodpowiednie dla użytkownika uczeń. Umożliwiają one nie tylko dodawanie nieautoryzowanych rekordów, ale także ich usuwanie, co narusza zasady bezpieczeństwa i integralności danych. Podobnie, GRANT ALTER, SELECT ON szkola.przedmioty TO uczen przyznaje prawo do modyfikacji struktury tabeli, co oznacza, że uczeń mógłby zmieniać kolumny, dodawać nowe oraz wprowadzać zmiany, które mogą wpływać na funkcjonowanie całej bazy danych. Prawo do ALTER jest jednym z najszerszych uprawnień w SQL i nie powinno być przyznawane użytkownikom, którzy nie są administratorami, aby zapewnić pełną kontrolę nad bazą danych.

Pytanie 38

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

A. SELECT * FROM pracownicy WHERE wiek > '25'

B. SELECT * FROM pracownicy AND wiek > '25'

C. SELECT * FROM wiek WHERE pracownicy > '25'

D. SELECT * FROM pracownicy OR wiek > '25'

Niepoprawne odpowiedzi wskazują na pewne nieporozumienia związane z konstrukcją zapytań SQL. W pierwszej z nich sugerowana jest składnia 'SELECT * FROM wiek WHERE pracownicy > '25';', co nie tylko używa niewłaściwej tabeli, ale także błędnie odnosi się do struktury zapytania. W SQL każda tabela powinna być podana w kontekście, w którym chcemy wykonać zapytanie. Druga odpowiedź 'SELECT * FROM pracownicy AND wiek > '25';' również jest błędna, ponieważ użycie operatora AND w tej formie jest niepoprawne. Operator AND służy do łączenia kilku warunków w klauzuli WHERE, a nie do wskazywania tabel. Tymczasem w trzeciej opcji 'SELECT * FROM pracownicy OR wiek > '25';' zastosowano operator OR, który jest również niewłaściwy, ponieważ może prowadzić do zwracania wszystkich pracowników, niezależnie od ich wieku. Takie podejście może wprowadzać w błąd i prowadzić do nieefektywnego przetwarzania danych. Kluczowe jest zrozumienie, że zapytania SQL wymagają precyzyjnego określenia zarówno tabel, jak i warunków filtrujących, aby były skuteczne i zgodne z zamierzonymi wynikami. Dlatego w praktyce, twórcy zapytań muszą być ostrożni w doborze składni i logiki, aby uniknąć tych typowych błędów.

Pytanie 39

W tabeli pracownicy zdefiniowano klucz główny jako INTEGER z atrybutami NOT NULL oraz AUTO_INCREMENT. Dodatkowo zdefiniowano kolumny imie oraz nazwisko. W przypadku wykonania poniższej kwerendy SQL wprowadzającej dane, w której pominięto pole klucza, w bazie danych MySQL wystąpi:

INSERT INTO pracownicy (imie, nazwisko) VALUES ('Anna', 'Nowak');

A. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana kolejna wartość naturalna

B. ignorowanie polecenia, tabela nie ulegnie zmianie

C. dodanie rekordu do tabeli, dla klucza głównego zostanie przypisana wartość NULL

D. błąd związany z nieprawidłową liczbą kolumn

Kiedy pomijasz wartość klucza głównego w instrukcji INSERT, to naprawdę może to prowadzić do zamieszania, jeśli nie rozumiesz, jak działają klucze w bazach danych. Mówienie, że pojawi się błąd z nieprawidłową liczbą pól, to tak, jakbyś nie znał zasad działania tabel w MySQL. Jak masz klucz główny ustawiony na AUTO_INCREMENT, to naprawdę nie musisz go podawać, bo system zrobi to za Ciebie. Powinieneś wiedzieć, że klucz główny jest mega ważny do identyfikacji rekordów w tabeli i jest potrzebny, żeby wszystko działało jak należy. Z kolei druga błędna odpowiedź, która mówi, że MySQL zignoruje polecenie, pokazuje, że nie łapiesz koncepcji, jak silnik bazy danych zajmuje się brakującymi danymi. MySQL nie zignoruje tego, tylko zareaguje i przydzieli nową wartość klucza. A jeszcze jedna rzecz – przypisanie wartości NULL do klucza głównego to już w ogóle zła droga, bo klucz musi być unikalny i nigdy nie może być pusty. Tego rodzaju myślenie wskazuje na typowe błędy, które wynikają z niepełnego rozumienia działania kluczy w bazach danych i jak to się ma do wprowadzania nowych rekordów.

Pytanie 40

Zdefiniowano bazę danych z tabelą sklepy, zawierającą pola: nazwa, ulica, miasto, branża. Aby odnaleźć wszystkie nazwy sklepów spożywczych znajdujących się wyłącznie we Wrocławiu, należy użyć kwerendy:

A. SELECT sklepy FROM nazwa WHERE branza='spożywczy' BETWEEN miasto='Wrocław';

B. SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND miasto='Wrocław';

C. SELECT sklepy FROM branza='spożywczy' WHERE miasto='Wrocław';

D. SELECT nazwa FROM sklepy WHERE branza='spożywczy' OR miasto='Wrocław';

Pierwsza odpowiedź nie jest właściwa, bo użycie BETWEEN w SQL po prostu nie ma sensu w tym kontekście. BETWEEN jest do określania zakresów wartości, na przykład dat, a nie do porównania różnych kolumn. No i zapytanie jest źle skonstruowane, bo nie mówi, z jakiej tabeli chcemy pobrać te dane. Druga odpowiedź też myli się w składni, bo zamienia kolejność operatorów i nie dodaje odpowiednich klauzul, co prowadzi do błędnych wyników. Na przykład, użycie branza='spożywczy' tam gdzie powinno być FROM, to wyraźny błąd. Trzecia odpowiedź korzysta z operatora OR, co jest technicznie błędne dla tego zapytania, ponieważ chcemy, żeby oba warunki były spełnione jednocześnie. W rezultacie, wszystkie te odpowiedzi są po prostu błędne i nie spełniają standardów pisania zapytań SQL.

Rozpocznij nowy egzamin

Powrót do strony głównej