Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik informatyk
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 27 kwietnia 2026 08:06
Data zakończenia: 27 kwietnia 2026 08:41

Egzamin niezdany

Wynik: 10/40 punktów (25,0%)

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

Które z poniższych poleceń pozwala na dodanie kolumny zadanie_kompletne do tabeli zadania?

A. CREATE INDEX zadania ADD COLUMN zadanie_kompletne int

B. INSERT INTO zadania VALUES zadanie_kompletne

C. ADD COLUMN zadanie_kompletne WITH zadania

D. ALTER TABLE zadania ADD COLUMN zadanie_kompletne int

Dodanie kolumny do istniejącej tabeli w relacyjnej bazie danych może być realizowane za pomocą polecenia ALTER TABLE. To polecenie jest standardem SQL i jest wspierane przez większość systemów zarządzania bazami danych, takich jak MySQL, PostgreSQL, Oracle czy Microsoft SQL Server. W przypadku zapytania 'ALTER TABLE zadania ADD COLUMN zadanie_kompletne int', polecenie to modyfikuje strukturę tabeli 'zadania', dodając nową kolumnę o nazwie 'zadanie_kompletne', która będzie przechowywać dane typu całkowitego (int). Praktycznym przykładem zastosowania tego polecenia może być system zarządzania projektami, w którym chcemy śledzić status zadań. Po dodaniu tej kolumny, możemy wprowadzać wartości 0 lub 1, które mogą reprezentować, czy zadanie zostało ukończone, czy nie. Użycie ALTER TABLE jest niezbędne, gdyż inne polecenia, takie jak CREATE INDEX czy INSERT INTO, służą do innych celów, takich jak tworzenie indeksów lub wstawianie danych, a nie do modyfikacji struktury tabeli. W praktyce, aby upewnić się, że zmiany są zgodne z wymaganiami systemu, zaleca się zawsze wykonanie kopii zapasowej bazy danych przed przeprowadzeniem operacji na strukturze tabeli.

Pytanie 2

Jakie polecenie pozwala na kontrolowanie oraz optymalizację bazy danych?

A. mysqlshow

B. mysqldump

C. mysqlimport

D. mysqlcheck

Odpowiedzi takie jak 'mysqlshow', 'mysqldump' i 'mysqlimport' są mylące, ponieważ nie pełnią roli narzędzi do sprawdzania i optymalizacji bazy danych. Narzędzie mysqlshow służy jedynie do wyświetlania informacji o bazach danych i tabelach, co może być użyteczne do monitorowania istniejących struktur, ale nie wpływa na ich integralność ani wydajność. Z kolei mysqldump jest wykorzystywane do tworzenia zrzutów danych z bazy, co jest kluczowe dla backupów, ale nie ma żadnych funkcji związanych z optymalizacją czy konserwacją. Wreszcie, mysqlimport jest narzędziem do importowania danych z plików zewnętrznych do bazy danych, a więc również nie odnosi się do kwestii sprawdzania czy optymalizacji. Wybierając te odpowiedzi, można dojść do błędnych wniosków, sądząc, że jedno narzędzie może pełnić wiele funkcji, podczas gdy każde z wymienionych narzędzi ma swoje specyficzne zadania. Zrozumienie różnicy między tymi narzędziami jest kluczowe dla efektywnego zarządzania bazami danych oraz stosowania najlepszych praktyk w ich administracji.

Pytanie 3

Dana jest tabela firmy zawierająca następujące kolumny: nazwa, adres, NIP, obrot (obrót w ostatnim miesiącu), rozliczenie, status. Wykonanie kwerendy SQL SELECT sprawi, że zostaną wyświetlone

SELECT nazwa, NIP FROM firmy WHERE obrot < 4000;

A. jedynie nazwa oraz numer NIP firm, które w ostatnim miesiącu miały obrót mniejszy niż 4000 zł.

B. wszystkie dane firm, które w ostatnim miesiącu miały obrót co najmniej 4000 zł.

C. wszystkie dane firm, które w ostatnim miesiącu miały obrót mniejszy niż 4000 zł.

D. jedynie nazwa oraz numer NIP firm, które w ostatnim miesiącu miały obrót co najmniej 4000 zł.

Twoja odpowiedź jest nieprawidłowa. W tym przypadku, pytanie dotyczyło wybrania nie wszystkich, a jedynie niektórych kolumn z tabeli - w tym wypadku nazwy i NIPu firm. Możliwe, że zostałeś wprowadzony w błąd, myśląc, że zawsze wybieramy wszystkie kolumny, co jest częstym błędem początkujących użytkowników SQL. W praktyce jednak, bardzo często zapytania SQL są konstruowane w taki sposób, aby wybierać tylko niektóre kolumny. Kolejnym błędem, który mógł wpłynąć na twoją odpowiedź, jest niezrozumienie klauzuli WHERE w SQL. Klauzula WHERE w SQL jest używana do filtrowania wyników zapytania. W tym przypadku, warunek dotyczył obrotu firmy - pytanie zadało kryterium, że obrót musi być mniejszy niż 4000 zł. Pamiętaj, że zrozumienie struktury i funkcji zapytań SQL jest kluczowe dla efektywnej pracy z bazami danych.

Pytanie 4

Jakiego typu danych w bazie MySQL należy używać, aby zapisać datę oraz czas w jednym polu?

A. BOOLEAN

B. YEAR

C. DATE

D. TIMESTAMP

Typ danych TIMESTAMP w MySQL jest idealnym wyborem do przechowywania zarówno daty, jak i czasu w jednym polu, co czyni go bardzo funkcjonalnym w kontekście aplikacji wymagających ścisłej kontroli nad czasem zdarzeń. TIMESTAMP przechowuje datę i czas jako liczbę sekund, które upłynęły od 1 stycznia 1970 roku, co pozwala na łatwe manipulowanie danymi związanymi z czasem, jak obliczanie różnic między datami czy sortowanie po czasie. Przykładowo, w aplikacjach takich jak systemy rezerwacji, gdzie istotne jest nie tylko kiedy coś zostało zarezerwowane, ale również czas rezerwacji, użycie TIMESTAMP umożliwia efektywne zarządzanie danymi. Dodatkowo, TIMESTAMP automatycznie aktualizuje się, gdy rekord jest zmieniany, co jest niezwykle przydatne w kontekście audytów i monitorowania historii zmian w danych. Warto również zauważyć, że TIMESTAMP w MySQL obsługuje strefy czasowe, co czyni go bardziej uniwersalnym w międzynarodowych zastosowaniach. W standardach branżowych dobre praktyki wskazują na używanie TIMESTAMP dla operacji wymagających ścisłej synchronizacji czasowej oraz tam, gdzie istotna jest informacja o czasie zdarzenia.

Pytanie 5

Instrukcja w SQL ALTER TABLE USA ... ma na celu

A. skasowanie tabeli USA

B. zmianę tabeli USA

C. przypisanie nowej wersji tabeli USA

D. stworzenie nowej tabeli USA

Wybór, żeby usunąć tabelę USA, jest nieodpowiedni, bo ALTER TABLE nie służy do usuwania tabel, a do zmiany ich struktury. Jak chcesz usunąć tabelę, to musisz użyć DROP TABLE, co całkowicie kasuje tabelę i wszystkie dane. Próbując nadpisać tabelę USA, to też nie ma sensu w kontekście ALTER TABLE, bo to polecenie nie zastępuje całej tabeli. Jak potrzebujesz nowej wersji tabeli, to najpierw musisz usunąć starą, a potem stworzyć nową, co niestety oznacza utratę starych danych. Poza tym, nie da się stworzyć nowej tabeli USA używając ALTER TABLE, bo to polecenie tylko zmienia istniejące tabele. Żeby stworzyć nową tabelę, korzysta się z CREATE TABLE, co jest zupełnie inną rzeczą niż modyfikacja tego, co już jest.

Pytanie 6

Jakie znaczenie ma akronim ACID w kontekście SQL?

A. atomic, comming, is, do

B. atomic, consistent, iss, dependable

C. atomic, constaint, isolated, dependable

D. atomic, consistent, isolated, durable

Każda z niepoprawnych odpowiedzi zawiera błędne definicje podstawowych pojęć związanych z właściwościami transakcji w bazach danych. Pierwsza z nich używa terminu "coming" zamiast "consistent", co jest poważnym błędem, ponieważ spójność jest kluczowa dla zapewnienia, że baza danych nie znajduje się w stanie półpełnym po zakończeniu transakcji. Druga odpowiedź zastępuje "durable" słowem "dependable", co nie oddaje rzeczywistego znaczenia trwałości w kontekście baz danych, gdzie ważne jest, aby wszelkie zmiany były zachowane mimo awarii systemu. Ostatnia odpowiedź błędnie używa słowa "constaint" zamiast "consistent", co wskazuje na nieporozumienie dotyczące fundamentalnych zasad działania baz danych. Ograniczenia (constraints) są istotne, ale to nie one definiują spójność transakcji. Właściwości ACID są kluczowe dla każdej operacji w bazach danych, a ich zrozumienie jest niezbędne dla zapewnienia integralności i bezpieczeństwa danych.

Pytanie 7

Jakie parametry powinny być ustawione w funkcji biblioteki mysqli, aby umożliwić połączenie z serwerem oraz bazą danych?

mysqli_connect($a, $b, $c, $d) or die('Brak połączenia z serwerem MySQL.');

A. adres serwera - $c, nazwa bazy danych - $d, login - $b, hasło - $a

B. adres serwera - $c, nazwa bazy danych - $d, login - $a, hasło - $b

C. adres serwera - $a, nazwa bazy danych - $b, login - $c, hasło - $d

D. adres serwera - $a, nazwa bazy danych - $d, login - $b, hasło - $c

W przypadku niepoprawnych odpowiedzi można zauważyć typowe błędy związane z zrozumieniem argumentów funkcji mysqli_connect. Wiele osób myli kolejność zmiennych oraz ich znaczenie. Na przykład, podanie adresu serwera jako $c lub $d jest błędne, ponieważ pierwszy argument zawsze powinien wskazywać na adres serwera. Warto również zwrócić uwagę na znaczenie loginu i hasła – nie można ich zamieniać miejscami, ponieważ każdy z tych parametrów pełni inną funkcję w kontekście autoryzacji do bazy danych. W ramach dobrych praktyk programistycznych, istotne jest także stosowanie raz jeszcze uwierzytelnienia użytkownika, co pozwala uniknąć nieautoryzowanego dostępu do danych. Przykłady niepoprawnych odpowiedzi pokazują też, że błędne przypisanie nazw bazy danych do zmiennych może prowadzić do błędów w aplikacji, co w efekcie utrudnia jej działanie oraz zwiększa ryzyko wycieków danych. Kluczowe jest zrozumienie, że każdy parametr pełni specyficzną rolę w tworzeniu połączenia. Niezrozumienie tego kontekstu może prowadzić do trudności w dalszym programowaniu oraz w diagnostyce problemów z bazą danych.

Pytanie 8

Jakie polecenie należy zastosować, aby cofnąć uprawnienia przyznane użytkownikowi?

A. DROP PRIVILEGES

B. REVOKE

C. GRANT NO PRIVILEGES

D. REMOVE

Użycie poleceń DELETE, DELETE PRIVILEGES oraz GRANT NO PRIVILEGES w kontekście odbierania uprawnień użytkownikom w bazach danych jest mylące i nieprawidłowe. DELETE jest poleceniem służącym do usuwania danych z tabeli, a jego zastosowanie w kontekście uprawnień nie ma sensu. Użytkownicy często mylą DELETE z operacjami zarządzania uprawnieniami, co prowadzi do nieprawidłowego wnioskowania o tym, jak zarządzać dostępem do danych. DELETE PRIVILEGES również nie jest uznawane za standardowe polecenie w systemach baz danych, co może prowadzić do nieporozumień dotyczących przyznawania i odbierania uprawnień. Na koniec, GRANT NO PRIVILEGES może wydawać się logiczne, ale w rzeczywistości jest to niepoprawna konstrukcja — system zarządzania bazą danych nie rozumie tej komendy jako efektywnego sposobu na odebranie uprawnień, co czyni ją bezużyteczną. W związku z tym, aby skutecznie zarządzać uprawnieniami, ważne jest, aby znać właściwe polecenia i ich zastosowanie, aby unikać nieporozumień oraz błędów w zarządzaniu dostępem do danych.

Pytanie 9

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

A. NOT NULL

B. NO REPEAT

C. UNIQUE

D. SINGLE

W bazach danych bardzo łatwo pomylić różne typy ograniczeń, bo wszystkie „coś ograniczają”, ale robią to w zupełnie inny sposób. W tym pytaniu chodzi konkretnie o to, żeby wartości w kolumnie się nie powtarzały – czyli o klasyczną unikalność danych. Do tego służy constraint UNIQUE, który jest standardowym mechanizmem w SQL do wymuszania niepowtarzalnych wartości w obrębie danej kolumny lub kombinacji kolumn. Pojawia się czasem intuicja, że może istnieje coś takiego jak SINGLE albo NO REPEAT, bo nazwa brzmi sensownie po angielsku. W specyfikacji SQL i w popularnych systemach baz danych takie słowa kluczowe jednak po prostu nie występują jako constrainty. SINGLE i NO REPEAT nie są standardowymi ograniczeniami, więc żadna poważna baza danych ich nie zrozumie. To typowy błąd: kierowanie się „ładnie brzmiącą nazwą”, a nie faktycznymi słowami kluczowymi języka SQL. Z kolei NOT NULL jest jak najbardziej prawdziwym ograniczeniem, ale rozwiązuje zupełnie inny problem. NOT NULL mówi tylko tyle, że w danej kolumnie nie wolno przechowywać wartości pustych (NULL). Możesz mieć tabelę, w której kolumna ma NOT NULL i jednocześnie wiele identycznych wartości, np. same zera albo ten sam tekst w każdym wierszu – baza nie będzie protestować, bo nie zabrania powtórek, tylko zabrania braku wartości. To ograniczenie często łączy się z innymi, np. PRIMARY KEY czy UNIQUE, ale samo w sobie nie zapewnia żadnej unikalności. Z mojego doświadczenia przy projektowaniu schematów baz danych najczęstszy błąd myślowy wygląda tak: ktoś zakłada, że skoro pole nie może być puste (NOT NULL), to „jakoś przy okazji” jest traktowane specjalnie i może nawet unikalnie. Niestety tak to nie działa. Dopiero dodanie UNIQUE albo zdefiniowanie PRIMARY KEY wymusza, że dana wartość nie pojawi się drugi raz. Dlatego przy każdej kolumnie, która ma pełnić rolę identyfikatora biznesowego (np. email, numer dokumentu, NIP), trzeba świadomie dobrać właściwy constraint, a nie liczyć na samo NOT NULL czy jakieś „domyślne” zachowanie bazy.

Pytanie 10

W tabeli programiści znajdują się kolumny: id, nick, ilosc_kodu, ocena. W kolumnie ilosc_kodu zapisano liczbę linii kodu, które programista napisał w danym miesiącu. Jakie zapytanie umożliwi obliczenie całkowitej liczby linii kodu stworzonych przez wszystkich programistów?

A. SELECT MAX(ilosc_kodu) FROM programisci

B. SELECT COUNT(programisci) FROM ilosc_kodu;

C. SELECT SUM(ilosc_kodu) FROM programisci;

D. SELECT SUM(ocena) FROM ilosc_kodu;

Wybór polecenia 'SELECT SUM(ocena) FROM ilosc_kodu;' jest nieprawidłowy, ponieważ w tym zapytaniu występuje kilka fundamentalnych błędów w rozumieniu struktury bazy danych oraz funkcji agregujących. Po pierwsze, pole 'ocena' nie jest odpowiednie do zsumowania linii kodu, ponieważ zawiera dane dotyczące ocen programistów, a nie ilości linii kodu, co całkowicie mija się z celem poszukiwania sumy linii kodu. Ponadto, tabela 'ilosc_kodu' nie istnieje jako samodzielna jednostka w kontekście tego pytania; 'ilosc_kodu' jest jedynie kolumną w tabeli 'programisci', co oznacza, że nie możemy bezpośrednio z niej tworzyć zapytań. To podkreśla ważny aspekt projektowania baz danych oraz ich strukturalnych zależności. Podczas pisania zapytań SQL należy zawsze mieć na uwadze, w której tabeli znajdują się interesujące nas dane oraz jakie kolumny są dostępne w tej tabeli. Inne nieprawidłowe odpowiedzi, takie jak 'SELECT COUNT(programisci) FROM ilosc_kodu;' również wskazują na misunderstanding, ponieważ użycie COUNT w tym kontekście nie odnosi się do sumowania linii kodu, a jedynie liczenia wierszy, co w tym przypadku nie jest celem. Ponadto, 'SELECT MAX(ilosc_kodu) FROM programisci;' ma zupełnie inną funkcję, polegającą na znalezieniu maksymalnej liczby linii kodu napisanych przez jednego programistę, co również nie jest zgodne z pierwotnym pytaniem. Wniosek jest taki, że kluczowe jest zrozumienie struktury bazy danych oraz logiczne podejście do formułowania zapytań SQL, aby uzyskiwać prawidłowe i użyteczne wyniki.

Pytanie 11

Głównym celem systemu CMS jest oddzielenie treści witryny informacyjnej od jej wyglądu. Jak osiągany jest ten efekt?

A. ze statycznych plików HTML oraz wyglądu ze zdefiniowanego szablonu

B. z bazy danych oraz wyglądu ze zdefiniowanego szablonu

C. ze statycznych plików HTML oraz wyglądu za pomocą technologii FLASH

D. z bazy danych oraz wyglądu za pomocą atrybutów HTML

Wykorzystanie statycznych plików HTML do generowania treści w kontekście systemów CMS jest koncepcją nieefektywną oraz niezgodną z współczesnymi standardami zarządzania treścią. Statyczne pliki HTML są trudne do aktualizacji, co oznacza, że każda zmiana wymaga edycji każdego pliku osobno. W praktyce prowadzi to do zwiększenia ryzyka błędów oraz obniża efektywność pracy, szczególnie w większych projektach. Z drugiej strony, wykorzystanie atrybutów HTML do definiowania wyglądu nie oddziela treści od prezentacji, co jest kluczowym założeniem CMS. Takie podejście nie tylko zagraża porządku w organizacji treści, ale także może negatywnie wpływać na dostępność oraz responsywność strony. Ponadto, technologia FLASH, która była popularna w przeszłości, obecnie nie jest wspierana przez większość przeglądarek i nie jest zalecana w nowoczesnym projektowaniu stron internetowych. Właściwe podejście do zarządzania treścią wymaga stosowania nowoczesnych narzędzi, takich jak bazy danych w połączeniu z szablonami, co zapewnia elastyczność i wygodę użytkowania. W ten sposób można efektywnie zarządzać zawartością oraz zapewnić optymalną wydajność i estetykę serwisu.

Pytanie 12

Jakiego rodzaju oprogramowanie narzędziowe powinno być zainstalowane, aby umożliwić użytkownikowi przeprowadzanie operacji na zgromadzonych danych?

A. Klucz obcy

B. System Zarządzania Bazą Danych (SZBD)

C. Otwarty mechanizm komunikacji bazy danych

D. Obiektowy System Zarządzania Bazą Danych

Klucz obcy to dość ciekawe zagadnienie, które dotyczy relacji między tabelami w bazach danych. Dzięki niemu można powiązać różne rekordy, ale nie jest to coś, co działa samodzielnie. To nie jest jakieś oprogramowanie, które można zainstalować i oczekiwać, że wszystko będzie działać. Z kolei Obiektowy System Zarządzania Bazą Danych (OSZBD) to inny temat, który opiera się na podejściu obiektowym. Może być przydatny, ale nie jest powszechnym rozwiązaniem. Samo otwarte mechanizmy komunikacji bazy danych też w sumie nie zapewnia skutecznego zarządzania danymi. Błędem jest myślenie, że wybór nieodpowiednich elementów, takich jak klucz obcy czy te mechanizmy, załatwi sprawę. Efektywna praca z danymi w praktyce wymaga wyboru SZBD, który jest stworzony do tego, żeby skutecznie zarządzać danymi i nie pomijanie tego prowadzi do nieporozumień.

Pytanie 13

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

A. Liczba wierszy równa 4

B. Dane 4, 3, 4, 3

C. Wartość 3.5

D. Suma ocen równa 14

W kontekście przedstawionego zapytania SQL błędne jest oczekiwanie że wynikiem będzie dane 4 3 4 3 lub suma ocen równa 14. Wynika to z faktu że funkcja AVG() służy do obliczania średniej a nie zwracania poszczególnych wartości ani ich sumy. Często spotykanym błędem jest mylenie funkcji agregujących takich jak AVG() SUM() COUNT() z prostym wyborem danych. Funkcje agregujące przetwarzają dane aby dostarczyć zagregowany wynik zamiast zwracać pojedyncze rekordy. Zapytanie SELECT AVG(ocena) jest skonstruowane aby obliczyć średnią wartość kolumny ocena przez co nie zwraca pełnego zestawu danych ani ich sumy. Co więcej liczba wierszy równa 4 sugerowałaby użycie funkcji COUNT() która zlicza liczbę rekordów. Zrozumienie różnic między tymi funkcjami jest kluczowe w analizie danych i konstruowaniu zapytań SQL. SQL oferuje różne sposoby manipulacji i analizy danych a skuteczne korzystanie z tych narzędzi wymaga jasnego zrozumienia ich funkcji i zastosowań. Tylko przez właściwe zrozumienie celu każdej funkcji można poprawnie interpretować i analizować dane w kontekście rzeczywistych scenariuszy biznesowych i technicznych.

Pytanie 14

Co oznacza skrót SQL?

A. Structured Query Language

B. Sequential Question Language

C. Standard Quality Language

D. Simple Query Logic

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 15

Jakie polecenie SQL zmieni w tabeli tab wartość w kolumnie kol z Ania na Zosia?

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

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

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

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

Podane odpowiedzi, które nie wykorzystują odpowiedniej składni SQL lub koncepcji manipulacji danymi, są błędne. Na przykład, aktualizacja wartości 'Ania' na 'Zosia' za pomocą polecenia UPDATE tab SET kol = 'Ania' WHERE kol = 'Zosia' nie tylko nie osiągnie zamierzonego celu, ale również wprowadzi w błąd. W rzeczywistości, polecenie to nie zmieni żadnych danych, ponieważ nie ma rekordów, w których kolumna 'kol' zawierałaby wartość 'Zosia', a polecenie próbuje ustawić ją na 'Ania'. Z kolei użycie ALTER TABLE do zmiany wartości w kolumnie jest całkowicie niewłaściwe, ponieważ to polecenie służy do zmiany struktury tabeli, a nie danych w niej zawartych. Alteracja struktury bazy danych jest fundamentalnie różna od aktualizacji wartości w wierszach. Zrozumienie różnicy między tymi dwoma typami operacji jest kluczowe dla efektywnego zarządzania bazami danych. Typowe błędy myślowe obejmują mylenie operacji na danych z operacjami na strukturze bazy danych, co prowadzi do nieefektywnego i błędnego kodowania. Warto także zwrócić uwagę na zapewnienie integralności danych i stosowanie właściwych kryteriów, aby uniknąć przypadkowych modyfikacji lub usunięć danych.

Pytanie 16

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

A. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;

B. SELECT DISTINCT miasto FROM mieszkancy;

C. SELECT COUNT(miasto) FROM mieszkancy;

D. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;

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

Pytanie 17

Jaką relację w projekcie bazy danych należy zdefiniować pomiędzy tabelami przedstawionymi na rysunku, zakładając, że każdy klient sklepu internetowego składa przynajmniej dwa zamówienia?

A. 1:1

B. n:n

C. 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia

D. 1:n, gdzie 1 jest po stronie Zamówienia, a wiele po stronie Klienta

Relacja 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia, jest prawidłowa, ponieważ odzwierciedla rzeczywiste założenie, że każdy klient może złożyć wiele zamówień. W praktyce baza danych musi odwzorowywać te zależności, co pozwala na efektywne zarządzanie danymi. Każdy klient posiada unikalny identyfikator, zwykle klucz podstawowy, który nie może się powtarzać w tabeli Klient. Tabela Zamówienie posiada natomiast klucz obcy, który odnosi się do klucza podstawowego w tabeli Klient, umożliwiając przechowywanie wielu zamówień przypisanych do jednego klienta. Dzięki temu możemy łatwo wykonywać operacje takie jak wyszukiwanie wszystkich zamówień danego klienta czy śledzenie historii zakupów. Dobre praktyki projektowania baz danych podkreślają znaczenie poprawnego zdefiniowania relacji między tabelami, co zwiększa spójność danych i ułatwia ich późniejsze przetwarzanie. W systemach e-commerce taka struktura bazy danych jest niezbędna do obsługi klientów i śledzenia ich zamówień, co jest podstawą do analizy sprzedaży i tworzenia strategii marketingowych.

Pytanie 18

W celu modyfikacji danych w bazie danych można wykorzystać

A. raportem

B. filtrowaniem

C. formularzem

D. kwerendą SELECT

Raporty, filtracja oraz kwerendy SELECT to różne podejścia do pracy z danymi, ale nie są to metody edytowania danych w bazie danych. Raporty są narzędziem do generowania przeglądów danych, które pozwalają na analizę i wizualizację danych w różnych formatach, jednak nie umożliwiają bezpośredniego modyfikowania tych danych. Zwykle są one używane do prezentowania wyników na podstawie kwerend, a ich celem jest informowanie użytkowników o stanie bazy danych, a nie jej edytowanie. Filtracja, z drugiej strony, to proces selekcjonowania konkretnego zbioru danych z większej bazy, który ma na celu ograniczenie widocznych informacji, ale nie zmienia samych danych. Wyszukiwanie za pomocą filtrów jest kluczowe przy analizie danych, jednak samo w sobie nie prowadzi do ich edytowania. Kwerenda SELECT jest z kolei używana do pobierania danych z bazy, co oznacza, że pozwala na odczyt danych, ale nie na ich modyfikację. Kwerendy, które służą do edytowania danych, to kwerendy typu UPDATE czy INSERT, które bezpośrednio manipulują danymi w bazie. Obserwując te różnice, można zauważyć, że niektóre z tych narzędzi mogą być mylnie interpretowane jako metody edytowania, mimo że ich głównym celem jest analiza lub przetwarzanie informacji.

Pytanie 19

Jakie jest zadanie funkcji PHP o nazwie mysql_num_rows()?

A. ponumerować rekordy w bazie danych

B. zwrócić rekord o numerze podanym jako parametr funkcji

C. zwrócić następny rekord z wynikami zapytania

D. zwrócić liczbę wierszy znajdujących się w wyniku zapytania

Funkcja mysql_num_rows() w PHP jest używana do zwracania liczby wierszy w wyniku zapytania SQL, co jest kluczowe w pracy z danymi w bazach danych. Gdy wykonujemy zapytanie, na przykład za pomocą mysql_query(), otrzymujemy wynik w formie zasobu. Funkcja mysql_num_rows() pozwala na określenie, ile wierszy zostało zwróconych przez to zapytanie. To jest szczególnie przydatne w sytuacjach, gdy chcemy wiedzieć, czy dane istnieją, na przykład w aplikacjach webowych, gdzie użytkownik szuka określonych informacji. Oznacza to, że możemy dostosować logikę naszej aplikacji na podstawie liczby wyników. Ponadto, korzystając z tej funkcji, możemy monitorować i optymalizować zapytania, co jest zgodne z najlepszymi praktykami w zakresie wydajności i zarządzania bazami danych. Warto również zauważyć, że mysql_num_rows() działa w kontekście wywołania do bazy danych, co oznacza, że musi być używana w kontekście zasobu wynikowego, aby działać poprawnie.

Pytanie 20

Poniższe zapytanie SQL ma na celu:

UPDATE Uczen SET id_klasy = id_klasy + 1;

A. przypisać wartość kolumny id_klasy jako 1 dla wszystkich wpisów w tabeli Uczen

B. ustawić wartość pola Uczen na 1

C. zwiększyć o jeden wartość kolumny id_klasy dla wszystkich wpisów w tabeli Uczen

D. zwiększyć o jeden wartość pola Uczen

Wybierając błędne odpowiedzi, można wpaść w pułapki związane z interpretacją polecenia SQL. Na przykład, stwierdzenie, że polecenie zwiększa wartość pola Uczen, jest mylące, ponieważ nie odnosi się do konkretnej kolumny. W SQL każde polecenie musi być precyzyjne, a używanie ogólnych terminów prowadzi do nieporozumień. Mówiąc o "ustawieniu na 1 wartości pola Uczen", mylnie sugeruje się, że wszystkie dane są resetowane do jednej wartości, co jest całkowicie błędne w kontekście podanego polecenia. Kolejną nieprawidłową koncepcją jest pomysł, iż polecenie ustawia wartość kolumny na 1 dla wszystkich rekordów. W rzeczywistości, aktualizuje ono istniejące wartości, zwiększając je o jeden, a nie ustawia ich na stałą wartość. Takie nieprecyzyjne zrozumienie języka SQL może prowadzić do katastrofalnych skutków w praktycznych zastosowaniach baz danych, w tym do utraty danych lub niepoprawnych aktualizacji, co jest sprzeczne z dobrymi praktykami zarządzania danymi. Kluczowe jest zrozumienie, że każdy element w SQL odgrywa istotną rolę, a nieprecyzyjność prowadzi do błędów, które mogą być czasochłonne do naprawienia. Z tego powodu, w pracy z SQL, należy zwracać znaczną uwagę na szczegóły oraz logiczną strukturę zapytań.

Pytanie 21

W bazie danych znajdują się dwie tabele, które są ze sobą połączone relacją 1..n. Jakiej klauzuli SQL należy użyć, aby uzyskać odpowiadające sobie dane z obu tabel?

A. AND

B. INNER LINK

C. JOIN

D. OUTER LINK

OUTER LINK nie jest poprawną klauzulą SQL. W rzeczywistości poprawnym terminem jest OUTER JOIN, który jest używany do łączenia tabel w sposób, który pozwala na zwrócenie rekordów z jednej tabeli, nawet jeśli nie mają one powiązań w drugiej tabeli. Ponadto, termin INNER LINK także nie istnieje w standardzie SQL. Odpowiednim terminem w tym kontekście jest INNER JOIN, który zwraca tylko te rekordy, które mają odpowiadające wartości w obu tabelach. Ostatecznie, klauzula AND jest używana w SQL do dodawania warunków do zapytań, ale nie służy do łączenia tabel. Można ją stosować w klauzuli WHERE, aby określić dodatkowe filtry, jednakże nie jest to forma łączenia tabel. W rezultacie, ani OUTER LINK, ani INNER LINK, ani AND nie odpowiadają na pytanie o to, jak skutecznie łączyć tabele w celu wybrania korespondujących wartości, co czyni je błędnymi odpowiedziami.

Pytanie 22

Jedną z charakterystyk relacyjnej bazy danych jest

A. stosowanie kluczy głównych do identyfikacji rekordów w tabelach

B. obecność klas, obiektów i metod

C. używanie języka zapytań OQL

D. zdefiniowanie jej stanu według obiektowego modelu danych

Relacyjne bazy danych opierają się na koncepcji tabel, gdzie dane są przechowywane w wierszach i kolumnach. Klucze główne odgrywają kluczową rolę w zapewnieniu unikalności rekordów w tabelach i umożliwiają ich identyfikację. Klucz główny to kolumna (lub zestaw kolumn), której wartości są unikalne w obrębie tabeli i nie mogą być puste. Przykładem może być tabela 'Użytkownicy', w której identyfikatorem użytkownika (kluczem głównym) może być numer PESEL lub unikalny ID. Dzięki kluczom głównym, można łatwo odnaleźć konkretne rekordy, a także powiązać je z innymi tabelami przy pomocy kluczy obcych, co jest fundamentalne dla relacyjnej struktury bazy danych. Standardy takie jak SQL (Structured Query Language) dostarczają narzędzi do definiowania, modyfikowania i manipulowania danymi z wykorzystaniem kluczy głównych, co jest podstawą projektowania baz danych zgodnie z najlepszymi praktykami. Dobre praktyki projektowe sugerują również, aby klucze główne były proste, stabilne i unikalne, co ułatwia zarządzanie danymi w relacyjnych systemach zarządzania bazą danych (RDBMS).

Pytanie 23

Lokalny System Zarządzania Bazą Danych (SZBD) oferuje bazę danych

A. wyłącznie na jednym, wyznaczonym komputerze.

B. jako usługę serwerową w sieci.

C. w chmurze obliczeniowej.

D. w formie serwera w sieci.

Odpowiedzi sugerujące, że lokalny system zarządzania bazą danych może być udostępniany jako serwer w sieci, w chmurze komputerowej lub jako usługa sieciowa serwera, mogą prowadzić do pewnych nieporozumień dotyczących architektury baz danych. W kontekście lokalnych systemów, 'serwer w sieci' sugeruje, że baza danych jest dostępna dla wielu użytkowników przez internet lub sieć lokalną, co jest charakterystyczne dla systemów zdalnych. Z kolei chmura komputerowa odnosi się do zdalnych usług i zasobów, które są przechowywane i zarządzane przez dostawców usług chmurowych, co również jest sprzeczne z ideą lokalnych systemów. Usługi sieciowe serwera dodatkowo podkreślają potrzebę interakcji z systemem zdalnym, podczas gdy lokalny SZBD działa na pojedynczym urządzeniu. Często błędne wnioski wynikają z nieodróżniania lokalnych i zdalnych architektur baz danych. W praktyce, lokalne SZBD jest idealne do zastosowań, gdzie bezpieczeństwo danych oraz ich szybki dostęp są kluczowe, w przeciwieństwie do rozwiązań chmurowych, które mogą wprowadzać opóźnienia związane z latencją sieci. Aby lepiej zrozumieć te różnice, warto zaznajomić się z typowymi zastosowaniami dla różnych typów baz danych, co pomoże w podejmowaniu świadomych decyzji w przyszłości.

Pytanie 24

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

A. pobieranie danych z tabeli

B. tworzenie nowych tabel

C. zmianę danych w tabeli

D. usuwanie danych z tabeli

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

Pytanie 25

W SQL, aby zmienić dane w tabeli, wykorzystuje się instrukcję

A. JOIN

B. CREATE

C. UPDATE

D. SELECT

Odpowiedź 'UPDATE' jest poprawna, ponieważ w języku SQL polecenie to służy do modyfikacji danych w istniejących rekordach tabeli. Umożliwia aktualizację wartości w jednym lub więcej polach w wybranych wierszach, których identyfikacja może być dokonana poprzez zastosowanie klauzuli WHERE. Na przykład, aby zaktualizować nazwisko użytkownika w tabeli 'Użytkownicy', można użyć polecenia: 'UPDATE Użytkownicy SET nazwisko = 'NoweNazwisko' WHERE id = 1;'. Dobrą praktyką jest zawsze uwzględnienie klauzuli WHERE, aby uniknąć przypadkowego zaktualizowania wszystkich rekordów w tabeli. Polecenie UPDATE jest częścią standardu SQL i szeroko stosowane w codziennej pracy z bazami danych, co czyni je kluczowym narzędziem w zarządzaniu danymi. Warto również pamiętać, że przed wykonaniem aktualizacji zaleca się wykonanie kopii zapasowej danych, aby zabezpieczyć się przed niezamierzonymi zmianami.

Pytanie 26

W SQL, aby zaktualizować informacje w wierszach w tabeli, konieczne jest użycie polecenia

A. UPDATE

B. SELECT

C. INSERT INTO

D. ALTER TABLE

Odpowiedź "UPDATE" jest właściwa, bo w SQL to właśnie to polecenie używamy do zmiany danych w już istniejących wierszach tabeli. Żeby zaktualizować konkretne kolumny w danym wierszu, trzeba wpisać coś takiego: "UPDATE nazwa_tabeli SET kolumna1 = wartość1, kolumna2 = wartość2 WHERE warunek". Dzięki klauzuli WHERE możemy dokładnie wskazać, które wiersze chcemy zmienić, co jest naprawdę ważne, żeby wszystko działało sprawnie i bezpiecznie. Na przykład, jeśli chcemy zmienić nazwisko użytkownika o id równym 1, napiszemy: "UPDATE Użytkownicy SET nazwisko = 'NoweNazwisko' WHERE id = 1". Używanie tego polecenia to dobra praktyka w zarządzaniu bazami danych. Nie zapominajmy o transakcjach, żeby mieć pewność, że dane są bezpieczne. A jak korzystamy z przygotowanych zapytań, to zminimalizujemy ryzyko ataków SQL injection, co jest bardzo istotne w kontekście bezpieczeństwa aplikacji bazodanowych.

Pytanie 27

Które z poniższych twierdzeń na temat klucza głównego jest prawdziwe?

A. Może mieć tylko wartości liczbowe

B. Zawiera jedynie jedno pole

C. W przypadku tabeli z danymi osobowymi może to być pole nazwisko

D. Jest unikalny w ramach tabeli

Wszystkie niepoprawne odpowiedzi opierają się na nieporozumieniach dotyczących definicji i właściwości klucza podstawowego. Klucz podstawowy nie jest ograniczony do jednego pola; może być złożony z kilku atrybutów, co jest typowe w bardziej skomplikowanych modelach danych. Zastosowanie kilku pól jako klucza podstawowego jest często konieczne, aby zapewnić unikalność w sytuacjach, gdzie pojedyncze pole może nie wystarczyć. Odpowiedź wskazująca, że klucz podstawowy składa się tylko z jednego pola, prowadzi do myślenia, które nie odzwierciedla rzeczywistości projektowania baz danych. Ponadto, klucz podstawowy może przyjmować różne typy danych, w tym tekstowe, co jest niezgodne z twierdzeniem, że może on przyjmować jedynie wartości liczbowe. W rzeczywistości, wiele baz danych używa tekstowych wartości jako kluczy, zwłaszcza w kontekście identyfikatorów, które są bardziej zrozumiałe dla użytkowników. W przypadku danych osobowych, pole nazwisko nie jest odpowiednim kandydatem na klucz podstawowy, ponieważ nie jest unikalne - wielu użytkowników może mieć to samo nazwisko. Używanie nieunikalnych danych jako kluczy podstawowych narusza podstawowe zasady projektowania baz danych, co może prowadzić do błędów i problemów z integralnością danych. Rozumienie tych koncepcji jest kluczowe dla prawidłowego projektowania i administracji baz danych.

Pytanie 28

W języku SQL wydano polecenie

CREATE USER 'anna'@'localhost' IDENTIFIED BY '54RTu8';

Jednak operacja ta zakończyła się niepowodzeniem z powodu błędu: #1396 - Operation CREATE USER failed for 'anna'@'localhost'. Możliwą przyczyną tego problemu bazy danych może być:

A. nieznane polecenie CREATE USER

B. istnienie użytkownika anna w bazie danych

C. błędna składnia polecenia CREATE USER

D. niewystarczająca siła hasła dla konta anna

Wybrana przez Ciebie odpowiedź o zbyt słabym haśle dla konta 'anna' jest nietrafiona. Podczas tworzenia użytkownika w MySQL ustalasz nowego użytkownika i hasło, które jeszcze nie jest połączone z żadnym drugim kontem. Zasady bezpieczeństwa mówią, że hasła powinny być mocne, ale w tym przypadku słabe hasło nie wywołuje błędu #1396. Słabe hasło może być problemem przy późniejszej edycji konta, ale nie przy zakładaniu nowego. Co więcej, jeśli chodzi o składnię CREATE USER, to w twoim poleceniu nie masz błędu. To, że hasło jest słabe, to istotny temat, ale musi być zgodne z zasadami, które ustala firma. I pamiętaj, polecenie CREATE USER jest standardem w MySQL, więc jeśli nie znasz, to warto się z nim zapoznać. Większość błędów przy użytkownikach bierze się z braku zrozumienia, jak działa system autoryzacji w bazach danych. Warto znać zasady dotyczące uprawnień, żeby lepiej zarządzać dostępem do baz.

Pytanie 29

Podczas definiowania pola id w tabeli MySQL użyto AUTO_INCREMENT. Co to oznacza?

id int NOT NULL AUTO_INCREMENT

A. pole id może przyjmować takie wartości jak: NULL, 1, 2, 3, 4 i tak dalej

B. możliwe jest dodanie rekordu z dowolną wartością pola id

C. wartości dla tego pola będą generowane automatycznie przy dodawaniu nowego rekordu do bazy

D. wartość pola id zostanie nadana automatycznie przez bazę i będzie to losowo wygenerowana liczba całkowita

Wartości pola AUTO_INCREMENT nie są generowane losowo lecz według określonego schematu liczbowego zaczynającego się zwykle od jedynki i rosnącego z każdym nowym rekordem. Koncepcja losowego nadawania wartości jest błędna ponieważ główna cecha AUTO_INCREMENT polega na przewidywalnym wzroście wartości co jest kluczowe dla zachowania integralności danych przy użyciu kluczy głównych. Z kolei możliwość dodawania rekordu z dowolną wartością id jest ograniczona gdyż w przypadku AUTO_INCREMENT to baza narzuca wartość tego pola co zabezpiecza przed duplikacją i kolizjami identyfikatorów. Pole id w kontekście AUTO_INCREMENT nie może przyjmować wartości NULL a jedynie wartości liczbowych zaczynających się od jedynki lub innej wartości początkowej jeśli zostanie zdefiniowana na etapie tworzenia tabeli. Mylenie tych koncepcji wynika często z niezrozumienia mechanizmów generowania kluczy w bazach danych gdzie klucz główny musi być unikalny a AUTO_INCREMENT to jeden z najczęściej stosowanych sposobów osiągania tego celu zgodnie z dobrymi praktykami projektowania baz danych. Zrozumienie funkcji AUTO_INCREMENT pozwala na efektywne zarządzanie rekordami i utrzymanie spójności danych w aplikacjach wykorzystujących bazy danych.

Pytanie 30

Jakie działanie wykonuje polecenie DBCC CHECKDB("sklepAGD", Repair_fast) w MS SQL Server?

A. zweryfikuje spójność danej tabeli oraz naprawi uszkodzone rekordy

B. sprawdzi spójność bazy danych i utworzy kopię zapasową

C. zweryfikuje spójność danej tabeli

D. sprawdzi spójność bazy danych i naprawi uszkodzone indeksy

Wiele osób mylnie sądzi, że polecenie DBCC CHECKDB może być używane do sprawdzania spójności tylko określonych tabel, co jednak jest nieprawidłowe. DBCC CHECKDB działa na poziomie całej bazy danych, analizując wszystkie tabele, indeksy oraz inne obiekty. Dlatego odpowiedzi sugerujące, że narzędzie to sprawdza spójność tylko pojedynczej tabeli, są błędne. Dodatkowo, niektóre odpowiedzi wskazują, że DBCC CHECKDB może naprawiać uszkodzone rekordy, co jest również mylące. W rzeczywistości, podczas użycia opcji Repair_fast, narzędzie może naprawiać uszkodzone indeksy, ale nie ma możliwości naprawy uszkodzonych danych w samych rekordach. Istnieje ryzyko, że błędne zrozumienie funkcji DBCC CHECKDB może prowadzić do niewłaściwego podejścia do zarządzania bazą danych, w tym do nieadekwatnego planowania kopii zapasowych czy procedur odzyskiwania. Ważne jest, aby być świadomym, że regularne wykonywanie tego polecenia jest kluczowe, ale również, że nie zastępuje ono pełnej strategii zarządzania danymi. Standardy branżowe podkreślają znaczenie kompleksowego podejścia do ochrony danych, co obejmuje zarówno monitorowanie integralności, jak i odpowiednie zabezpieczenia przed utratą danych.

Pytanie 31

Aby wykonać kopię zapasową bazy danych w MySQL, jakie polecenie należy zastosować?

A. mysqlslap

B. mysqlreplicate

C. mysqlcheck

D. mysqldump

Wybór polecenia mysqlslap jako metody do tworzenia kopii zapasowych bazy danych jest nieuzasadniony, ponieważ funkcjonalność tego narzędzia jest całkowicie inna. Mysqlslap jest narzędziem do testowania wydajności MySQL, które symuluje obciążenie bazy danych i umożliwia ocenę jej reakcji na różne zapytania. Zamiast służyć do backupu, jest wykorzystywane do analizy i optymalizacji wydajności systemu, co może prowadzić do błędnych wniosków o jego zastosowaniu w kontekście bezpieczeństwa danych. Podobnie, mysqlcheck jest narzędziem używanym do sprawdzania i naprawy tabel w bazach danych MySQL, co oznacza, że nie ma on zastosowania w kontekście tworzenia kopii zapasowych. Jego główną rolą jest diagnostyka i konserwacja bazy danych, a nie zarządzanie danymi. Z kolei mysqlreplicate, jak sama nazwa wskazuje, odnosi się do replikacji bazy danych, co jest zupełnie inną procedurą, mającą na celu zapewnienie wysokiej dostępności i skalowalności poprzez tworzenie duplikatów danych na różnych serwerach. Typowym błędem jest mylenie narzędzi do zarządzania danymi z narzędziami do ich zabezpieczania. Aby skutecznie zarządzać bazą danych, konieczne jest zrozumienie różnicy między tymi funkcjami oraz właściwe dobieranie narzędzi do konkretnych zadań, co jest kluczowe dla zapewnienia spójności i bezpieczeństwa danych.

Pytanie 32

W języku SQL przedstawiony warunek jest równoważny warunkowi

liczba >= 10 AND liczba <= 100

A. NOT (liczba < 10 AND liczba > 100)

B. liczba BETWEEN 10 AND 100

C. liczba LIKE '10%'

D. liczba IN (10, 100)

Dobra robota! Twoja odpowiedź jest na pewno poprawna. Warunek 'liczba >= 10 AND liczba <= 100' w SQL oznacza, że musimy znaleźć liczbę, która jest większa lub równa 10 i mniejsza lub równa 100. Można to również zapisać jako 'liczba BETWEEN 10 AND 100', co po prostu definiuje zakres wartości od 10 do 100, łącznie z tymi granicami. Używanie operatorów takich jak BETWEEN jest naprawdę przydatne w SQL, bo ułatwia nam życie przy pisaniu zapytań i sprawia, że łatwiej jest zrozumieć, co ten kod właściwie robi. Fajnie umieć takie rzeczy, bo to naprawdę klucz do efektywnej pracy z bazami danych.

Pytanie 33

Podane w ramce polecenie SQL ma za zadanie

UPDATE Uczen SET id_klasy = id_klasy + 1;

A. ustawić wartość pola id_klasy na 1 dla wszystkich rekordów tabeli Uczen

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

C. zwiększyć o jeden wartość pola id_klasy w jednym rekordzie tabeli Uczen

D. ustawić wartość w kolumnie id_klasy na 1 dla wszystkich rekordów tabeli Uczen

Analizując to polecenie SQL, warto na spokojnie rozłożyć je na części, bo większość nieporozumień bierze się z mylenia stałej wartości z wyrażeniem oraz z niezauważenia braku klauzuli WHERE. W zapisie UPDATE Uczen SET id_klasy = id_klasy + 1; po lewej stronie znaku równości mamy kolumnę, którą aktualizujemy, a po prawej – wyrażenie, które określa nową wartość. To wyrażenie nie jest stałą liczbą 1, tylko operacją: bieżąca wartość id_klasy plus 1. Dlatego nie można tego interpretować jako „ustaw wartość na 1”. Gdyby celem było ustawienie identycznej wartości dla wszystkich uczniów, składnia wyglądałaby np. tak: UPDATE Uczen SET id_klasy = 1; i wtedy rzeczywiście każdemu rekordowi przypisano by dokładnie 1, bez użycia dotychczasowej wartości. Druga częsta pomyłka dotyczy zakresu działania UPDATE. W SQL to klauzula WHERE zawęża liczbę modyfikowanych rekordów. Jeśli WHERE nie ma, silnik bazy danych zgodnie ze standardem SQL przyjmuje, że operacja dotyczy wszystkich wierszy tabeli. Nie istnieje domyślne założenie „tylko jeden rekord”, chyba że jawnie wskażemy warunek, który zwróci pojedynczy wiersz, np. WHERE id_ucznia = 5. Dlatego interpretacja, że polecenie zmienia tylko jeden rekord, jest po prostu sprzeczna z tym, jak działa mechanizm UPDATE. Z mojego doświadczenia typowy błąd myślowy polega na tym, że ktoś patrzy na przykład z dokumentacji, gdzie często pojawia się WHERE, i podświadomie zakłada, że on tam „zawsze jest”. A tu go po prostu nie ma, więc działanie jest globalne. Drugi błąd to utożsamianie zapisu „+ 1” z „ustaw na 1”, co jest bardzo niebezpieczne w prawdziwych systemach, bo łatwo wtedy masowo popsuć dane. Dobre praktyki w pracy z SQL mówią jasno: zawsze dokładnie analizuj część SET oraz obecność lub brak WHERE, a przed wykonaniem złożonego UPDATE warto najpierw uruchomić SELECT z tym samym warunkiem, żeby zobaczyć, które rekordy zostaną zmienione. Taka systematyka pozwala uniknąć właśnie takich nieporozumień, jakie widać w błędnych odpowiedziach.

Pytanie 34

W systemie MySQL trzeba użyć polecenia REVOKE, aby użytkownikowi anna cofnąć możliwość wprowadzania zmian jedynie w definicji struktury bazy danych. Odpowiednia komenda do odebrania tych uprawnień ma postać

A. REVOKE ALL ON tabela1 FROM 'anna'@'locaihost'

B. REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost'

C. REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'

D. REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'

Polecenie REVOKE w MySQL jest używane do odbierania przydzielonych wcześniej uprawnień użytkownikom. W kontekście pytania, właściwa odpowiedź to 'REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost''. To polecenie wskazuje na odebranie użytkownikowi 'anna' możliwości tworzenia nowych obiektów w bazie danych (CREATE), zmiany struktury istniejących obiektów (ALTER) oraz usuwania obiektów (DROP) w tabeli 'tabela1'. Odbieranie tych praw jest kluczowe w zarządzaniu bezpieczeństwem bazy danych, ponieważ pozwala na precyzyjne kontrolowanie, kto ma dostęp do modyfikacji struktury bazy danych. W praktyce, administratorzy baz danych często muszą ograniczać uprawnienia użytkowników, aby zapobiec nieautoryzowanym zmianom, które mogą wpłynąć na integralność danych. Dobrą praktyką jest regularne przeglądanie i aktualizowanie uprawnień użytkowników, aby dostosować je do zmieniających się potrzeb organizacji oraz zwiększyć poziom bezpieczeństwa systemu.

Pytanie 35

Wynikiem realizacji kwerendy

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

na podstawie poniższej tabeli rezerwacje jest:

A. lato 3, zima 4

B. lato 20, zima 27

C. lato 10, zima 4, lato 5, zima 6, lato 5, zima 9, zima 8

D. lato 10, 5, 5; zima 4, 6, 9, 8

Analiza błędnych odpowiedzi wskazuje na niezrozumienie zasad działania kwerend SQL, szczególnie w kontekście zagregowanych wyników. Odpowiedź sugerująca lato 3, zima 4, 6, 9, 8 jest niepoprawna, ponieważ nie sumuje dni, a jedynie przedstawia liczby, które są w rzeczywistości liczbą dni w sezonach. Może to wynikać z błędnej interpretacji funkcji GROUP BY, która ma na celu zebranie wyników w grupy przed zastosowaniem funkcji agregujących. Kolejna odpowiedź myli pojęcie grupowania i agregacji, podając szczegółowe wartości bez ich sumowania, co nie jest zgodne z logiką kwerendy. W SQL, funkcja SUM nie jest używana do wyodrębnienia poszczególnych wartości, ale do obliczenia ich łącznej wartości w ramach grupy. Ostatnia niepoprawna odpowiedź, która z kolei podaje poszczególne dni rezerwacji dla obu sezonów, również nie spełnia wymogu zsumowania danych. Podobnie jak w poprzednich przypadkach, brak zrozumienia, jak działają agregacje w SQL, prowadzi do wniosków, które są niezgodne z pojęciem zorganizowanej analizy danych. Dlatego niezwykle ważne jest, aby przy pracy z danymi zrozumieć, jak funkcje agregujące wpływają na zbieranie informacji oraz w jaki sposób odpowiednie grupowanie i przetwarzanie danych może dostarczyć użytecznych informacji dla różnych analiz biznesowych.

Pytanie 36

W tabeli mieszkancy znajdują się dane o osobach z całego kraju. Aby ustalić, ile unikalnych miast występuje w tej tabeli, trzeba zapisać kwerendę

A. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;

B. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;

C. SELECT DISTINCT miasto FROM mieszkancy;

D. SELECT COUNT(miasto) FROM mieszkancy;

Wybór odpowiedzi, która polega na użyciu tylko funkcji COUNT, jak w "SELECT COUNT(miasto) FROM mieszkancy;" nie jest najlepszy. To zapytanie zlicza wszystkie wystąpienia miast, w tym duplikaty, więc dostajesz łączną liczbę wierszy w kolumnie 'miasto', a to nie pokazuje, ile tak naprawdę jest unikalnych miejscowości. Moim zdaniem, ta pomyłka może prowadzić do złych wniosków, bo nie uwzględniasz różnorodności danych. Użycie DISTINCT, na przykład w "SELECT DISTINCT miasto FROM mieszkancy;", też nie daje ci liczby unikalnych miast, tylko listę ich. Niektórzy mogą myśleć, że wystarczy wylistować unikalne wartości, żeby wiedzieć, ile ich jest, ale to błędne podejście do zliczania. A ta odpowiedź "SELECT COUNT(miasto) FROM mieszkancy DISTINCT;" jest też niepoprawna, bo nie możesz używać DISTINCT w takim kontekście. Z doświadczenia wiem, że zrozumienie zasad dotyczących funkcji agregujących i filtrujących w SQL jest naprawdę kluczowe, jeśli chcesz dobrze zarządzać danymi i prowadzić sensowne analizy. Dlatego warto zastanowić się nad tym, jak używasz tych funkcji, żeby uniknąć typowych błędów przy interpretacji wyników zapytań w bazach danych.

Pytanie 37

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 = pensja + 100;

B. UPDATE pracownicy SET 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 38

Klucz obcy w bazie danych jest tworzony w celu

A. umożliwienia jednoznacznej identyfikacji rekordu w bazie danych

B. określenia relacji 1..n łączącej go z kluczem głównym innej tabeli

C. łączenia go z innymi kluczami obcymi w tabeli

D. stworzenia formularza do wprowadzania danych do tabeli

Zrozumienie roli klucza obcego w tabeli wymaga głębszego spojrzenia na struktury relacyjnych baz danych. Klucz obcy definiuje relacje pomiędzy tabelami, co jest niezwiązane z jednoznaczną identyfikacją rekordu w tabeli. Ta koncepcja jest często mylona, ponieważ klucz główny, a nie klucz obcy, jest odpowiedzialny za zapewnienie unikalności każdego rekordu. Klucz obcy jest używany do wskazywania na klucz główny w innej tabeli, co tworzy powiązania, ale nie ma on na celu identyfikacji rekordu w swojej tabeli. Dodatkowo, klucz obcy nie ma związku z tworzeniem formularzy do wprowadzania danych. Formularze są narzędziem interfejsu użytkownika, które mogą wykorzystywać dane z tabel bazodanowych, ale nie są bezpośrednio związane z pojęciami klucza obcego i klucza głównego. Tworzenie formularzy nie zmienia struktury danych czy relacji między nimi. W kontekście łączenia kluczy obcych z innymi kluczami obcymi, również jest to niepoprawne, gdyż klucz obcy nie jest używany do tworzenia połączeń z innymi kluczami obcymi w tej samej tabeli. Klucz obcy ma na celu jedynie odniesienie do klucza głównego z innej tabeli, co ilustruje podstawowe zasady projektowania baz danych, w tym zapewnienie integralności referencyjnej i unikanie cyklicznych odniesień, które mogą prowadzić do błędów i niepoprawnych danych. Zrozumienie tych różnic jest kluczowe dla skutecznego projektowania relacyjnych baz danych.

Pytanie 39

Przed przystąpieniem do tworzenia kopii zapasowej bazy danych, aby była ona poprawna i zdatna do późniejszego przywrócenia, konieczne jest sprawdzenie

A. spójności bazy danych

B. poprawności składni zapytań

C. uprawnień dostępu do serwera bazy danych

D. opcji udostępnienia bazy danych

Prawa dostępu do serwera bazy danych, możliwość udostępnienia bazy danych oraz poprawność składni zapytań to aspekty, które są istotne w kontekście zarządzania bazami danych, jednak nie mają one bezpośredniego wpływu na możliwość wykonania poprawnej kopii bezpieczeństwa. Sprawdzanie praw dostępu jest kluczowe z punktu widzenia bezpieczeństwa, ale nawet przy odpowiednich uprawnieniach, kopia zapasowa będzie bezwartościowa, jeśli dane są niezgodne lub uszkodzone. Możliwość udostępnienia bazy danych odnosi się do tego, czy inni użytkownicy mogą z niej korzystać, co również nie ma wpływu na integralność danych, które kopiujemy. Z kolei poprawność składni zapytań dotyczy aspektu komunikacji z bazą danych, a nie stanu samych danych. Właściwie skonstruowane zapytania mogą z powodzeniem zwrócić wynik, ale nie gwarantują, że dane, które chcemy zarchiwizować, są zgodne i spójne. Często w praktyce pomija się te elementy, koncentrując się na bezpośrednich aspektach zarządzania danymi, co może prowadzić do poważnych problemów po przywróceniu bazy z kopii zapasowej. Najważniejsze jest, aby przed wykonaniem kopiowania danych, zapewnić ich spójność, co jest fundamentem operacji backupu.

Pytanie 40

Zastosowanie poniższej kwerendy SQL spowoduje usunięcie

DELETE FROM mieszkania WHERE status=1;

A. tabeli mieszkania z systemu baz danych

B. rekordów, dla których pole status ma wartość 1, z tabeli mieszkania

C. pola o nazwie status w tabeli mieszkania

D. tabel, w których pole status ma wartość 1, z bazy danych mieszkania

Odpowiedź, którą zaznaczyłeś, jest jak najbardziej trafna i dotyczy działania kwerendy SQL, szczególnie polecenia DELETE. W tym przypadku, to DELETE FROM mieszkania WHERE status=1 oznacza, że zamierzamy usunąć wszystkie rekordy z tabeli mieszkania, gdzie status jest równy 1. To jest ważne, bo w zarządzaniu bazami danych kluczowe jest precyzyjne ustalenie, które dane chcemy usunąć. Z mojej perspektywy, przed wykonaniem takiej operacji warto najpierw wykonać zapytanie SELECT z tymi samymi warunkami, żeby zobaczyć, co dokładnie usuniemy. Przykład? Możesz chcieć usunąć mieszkania, które są zarezerwowane lub niedostępne, co może być oznaczone statusem 1. To naprawdę dobra praktyka, bo pozwala na lepsze zarządzanie danymi i na utrzymanie porządku w bazie. A wiesz, co jeszcze? Zawsze warto zrobić kopię zapasową danych przed masowym usuwaniem, żeby nie stracić czegoś ważnego.

Rozpocznij nowy egzamin

Powrót do strony głównej