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 11:37
Data zakończenia: 27 kwietnia 2026 12:03

Egzamin zdany!

Wynik: 31/40 punktów (77,5%)

Wymagane minimum: 20 punktów (50%)

Nowe

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

Przebieg egzaminu

Pochwal się swoim wynikiem!

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

 SELECT model FROM samochody WHERE rocznik > 2017 AND marka = "opel";

Tabela samochody zawiera rekordy przedstawione na obrazie. Wydając przedstawione zapytanie SQL zostaną zwrócone dane:

id	klasa_id	marka	model	rocznik
1	1	ford	ka	2017
2	2	seat	toledo	2016
3	3	opel	zafira	2018
4	2	fiat	500X	2018
5	3	opel	insignia	2017

A. zafira

B. opel zafira

C. zafira; insignia

D. opel zafira; opel insignia

Gratulacje, twoja odpowiedź jest poprawna. Zapytanie SQL 'SELECT model FROM samochody WHERE rocznik > 2017 AND marka = 'opel';' ma na celu wyświetlenie modelu samochodu marki 'opel' z roku produkcji późniejszego niż 2017. Analizując dostępną tabelę, możemy zauważyć, że tylko model 'zafira' spełnia oba kryteria. W tym przypadku wykorzystaliśmy dwa kluczowe elementy języka SQL, tj. instrukcję SELECT i klauzulę WHERE. Instrukcja SELECT służy do zapytań o konkretne dane z bazy, a klauzula WHERE to powszechnie stosowane narzędzie do filtrowania wyników zapytania według określonych kryteriów. Jest to bardzo praktyczny aspekt SQL, który pozwala na wydobywanie tylko tych danych, które są potrzebne, co jest niezwykle przydatne przy dużych bazach danych.

Pytanie 2

Którą kwerendę należy wykonać, aby zaktualizować wszystkim rekordom z tabeli pracownicy wartość w kolumnie plec na K, przyjmując na potrzeby zadania, że każde imię żeńskie kończy się literą a?

A. UPDATE pracownicy SET plec='K' WHERE imie='%a';

B. UPDATE pracownicy SET plec='K' WHERE imie LIKE '%a';

C. ALTER TABLE pracownicy SET plec='K' WHERE imie LIKE '%a';

D. ALTER TABLE pracownicy SET plec='K' WHERE imie='%a';

Poprawna jest kwerenda: UPDATE pracownicy SET plec='K' WHERE imie LIKE '%a';. Po pierwsze użyty jest właściwy typ polecenia SQL do modyfikacji danych w tabeli. Do zmiany wartości w istniejących rekordach zawsze używamy instrukcji UPDATE, a nie ALTER TABLE. ALTER TABLE służy do zmiany struktury tabeli (np. dodanie kolumny, zmiana typu danych, usunięcie kolumny), a nie do operowania na danych w wierszach. To jest taki podstawowy podział: DDL (Data Definition Language) – np. ALTER TABLE, CREATE, DROP – do definicji struktury; DML (Data Manipulation Language) – np. SELECT, INSERT, UPDATE, DELETE – do pracy na rekordach. W tym zadaniu ewidentnie potrzebna jest operacja DML. Druga ważna rzecz to warunek WHERE imie LIKE '%a'. Operator LIKE służy do porównywania tekstów z wykorzystaniem wzorców. Symbol % oznacza „dowolny ciąg znaków (również pusty)”, więc wzorzec '%a' oznacza: dowolny ciąg znaków zakończony literą „a”. Dokładnie o to chodzi w zadaniu: przyjmujemy założenie, że każde imię żeńskie kończy się na „a”, więc chcemy zaktualizować wszystkie rekordy, gdzie kolumna imie kończy się na „a”. Gdybyśmy chcieli szukać imion zaczynających się na „A”, używalibyśmy 'A%'. Moim zdaniem warto zapamiętać ten schemat, bo w praktyce bardzo często stosuje się LIKE do prostych filtrów tekstowych: wyszukiwanie użytkowników po fragmencie loginu, znajdowanie produktów po części nazwy, filtrowanie adresów e-mail po domenie itp. Przykład: UPDATE klienci SET status='VIP' WHERE nazwisko LIKE 'Nowak%'; – zaktualizuje wszystkich Nowaków. Albo: UPDATE produkty SET promocja=1 WHERE nazwa LIKE '%kabel%'; – zaznaczy jako promocyjne wszystkie produkty, których nazwa zawiera słowo „kabel”. W dobrych praktykach zaleca się uważać z aktualizacjami bez WHERE, bo wtedy zmieniamy wszystkie rekordy w tabeli. Tutaj warunek LIKE '%a' pełni rolę bezpiecznego filtra. W wielu systemach bazodanowych warto też pamiętać, że domyślnie porównania tekstowe mogą być niewrażliwe na wielkość liter (collation), więc 'a' i 'A' mogą być traktowane tak samo, ale to już zależy od konfiguracji bazy. W kontekście egzaminów zawodowych i pracy z SQL-em takie zadanie to klasyk – łączy poprawne użycie UPDATE z właściwym użyciem LIKE i symbolu % jako wieloznakowego wildcarda.

Pytanie 3

Podaj polecenie SQL, które wprowadza kolumnę miesiacSiewu do istniejącej tabeli rosliny?

A. ALTER TABLE rosliny ADD miesiacSiewu int

B. INSERT INTO rosliny VALUES (miesiacSiewu int)

C. UPDATE rosliny ADD miesiacSiewu int

D. CREATE TABLE rosliny {miesiacSiewu int}

Poprawna odpowiedź to ALTER TABLE rosliny ADD miesiacSiewu int. To polecenie SQL jest używane do modyfikacji istniejącej tabeli w bazie danych. W tym przypadku, zmiana dotyczy dodania nowego pola 'miesiacSiewu', które określi miesiąc siewu roślin. Typ danych 'int' oznacza, że wartość tego pola będzie przechowywana jako liczba całkowita, co jest odpowiednie, jeśli miesiące będą reprezentowane jako liczby od 1 do 12. Przykład użycia polecenia w praktyce: po dodaniu tego pola można wprowadzać dane o miesiącu siewu dla różnych roślin, co może być przydatne w systemach zarządzania uprawami. Dobrą praktyką jest zawsze dokumentować zmiany w schemacie bazy danych, aby zapewnić spójność i przejrzystość w zarządzaniu danymi. Ważne jest również, aby przed modyfikacją tabeli upewnić się, że nie wprowadza to konfliktów z istniejącymi danymi lub strukturami.

Pytanie 4

Jakim słowem kluczowym można zestawić wyniki dwóch zapytań SELECT, które operują na różnych tabelach, aby utworzyć jeden zbiór danych?

A. DISTINCT

B. AS

C. JOIN

D. UNION

Odpowiedzi takie jak JOIN, DISTINCT i AS są niepoprawne w kontekście łączenia wyników kwerend SELECT z różnych tabel w jeden zbiór. JOIN jest używane do łączenia rekordów z dwóch tabel na podstawie powiązania między nimi, co oznacza, że wymaga istnienia relacji między danymi, co nie jest przypadkiem w każdym scenariuszu, w którym chcemy połączyć wyniki. INCLUDES, które może być naturalnym skojarzeniem z łączeniem danych, nie pasuje do sytuacji, gdy kwerendy SELECT są niezależne od siebie. DISTINCT natomiast jest używane do eliminowania duplikatów z wyników jednej kwerendy, ale nie służy do łączenia wyników z różnych źródeł. Wreszcie, AS jest używane głównie do nadawania aliasów kolumnom lub tabelom, co nie ma zastosowania w kontekście łączenia wyników kwerend. Typowym błędem myślowym jest zakładanie, że każde słowo kluczowe związane z SELECT może być użyte do łączenia wyników, podczas gdy każde z nich ma swoje specyficzne zastosowanie i ograniczenia. Zrozumienie tych różnic jest kluczowe dla prawidłowego stosowania SQL w praktyce i tworzenia efektywnych zapytań, które zwracają oczekiwane wyniki.

Pytanie 5

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

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

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

C. Jest unikalny w ramach tabeli

D. Zawiera jedynie jedno pole

Klucz podstawowy jest fundamentalnym elementem w projektowaniu baz danych. Jego główną funkcją jest zapewnienie unikalności każdego rekordu w tabeli, co oznacza, że nie mogą istnieć dwa identyczne wiersze z tym samym kluczem podstawowym. To jest kluczowe dla zachowania integralności danych i umożliwia efektywne zarządzanie informacjami. Na przykład, w tabeli z danymi klientów klucz podstawowy może stanowić unikalny identyfikator klienta (np. numer ID), który pozwala na szybkie i jednoznaczne zlokalizowanie rekordu. Dobrą praktyką jest używanie kluczy podstawowych, które są długoterminowo stabilne, co oznacza, że nie zmieniają się w czasie. Warto również stosować technologię baz danych, która wspiera mechanizmy zapewniające unikalność kluczy, takie jak indeksy unikalne. Ponadto, klucz podstawowy nie musi być wyłącznie pojedynczym polem; może składać się z kilku pól, co jest powszechnie stosowane w przypadku złożonych relacji między tabelami.

Pytanie 6

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

A. sieciowym

B. relacyjnym

C. hierarchicznym

D. jednorodnym

Model jednorodny to taka podstawowa struktura w bazach danych, gdzie wszystko trzymamy w jednej tabeli. To się fajnie sprawdza w prostych aplikacjach, bo wtedy relacje między danymi są dość oczywiste. Klasycznym przykładem może być baza kontaktów, gdzie każdy ma swoje info w jednym miejscu. Dzięki temu mamy łatwy dostęp do danych i prosto nimi zarządzać. Z mojego doświadczenia, to rozwiązanie jest super efektywne, ale jak system staje się większy i złożony, to zaczynają się schody. Wtedy inne modele, jak relacyjne, mogą mieć więcej sensu. W branży często korzysta się z modelu jednorodnego, zwłaszcza tam, gdzie szybki dostęp do danych jest kluczowy, a sztywne struktury tylko przeszkadzają. Na codzień to naprawdę przydatna rzecz, jak ktoś nie chce się męczyć z komplikacjami.

Pytanie 7

W poleceniu CREATE TABLE zastosowanie klauzuli PRIMARY KEY przy definiowaniu kolumny tabeli spowoduje, że ta kolumna stanie się

A. kluczem obcym

B. indeksem unikalnym

C. kluczem podstawowym

D. indeksem klucza

Użycie klauzuli PRIMARY KEY w instrukcji CREATE TABLE pozwala na zdefiniowanie unikalnego identyfikatora dla każdego rekordu w tabeli. Klucz podstawowy zapewnia, że żadne dwa wiersze nie mogą mieć tej samej wartości w kolumnie, co jest kluczowe dla zachowania integralności danych. Przykładem praktycznym może być stworzenie tabeli użytkowników, gdzie 'id_użytkownika' jest kluczem podstawowym. Taki klucz może być typu INTEGER z automatycznym inkrementowaniem, co oznacza, że dla każdego nowego użytkownika wartość 'id_użytkownika' wzrasta automatycznie. Standardy branżowe zalecają definiowanie klucza podstawowego dla każdej tabeli, aby upewnić się, że rekordy można w sposób jednoznaczny zidentyfikować, co jest niezbędne dla relacyjnych baz danych. Dodatkowo, klucz podstawowy automatycznie tworzy indeks na tej kolumnie, co przyspiesza operacje wyszukiwania. Ważne jest, aby klucz podstawowy był dobrze przemyślany, ponieważ jego zmiana w przyszłości może wiązać się z dużymi komplikacjami w bazie danych.

Pytanie 8

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

A. Otwarty mechanizm komunikacji bazy danych

B. Obiektowy System Zarządzania Bazą Danych

C. Klucz obcy

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

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

Pytanie 9

Jakie jest zastosowanie zapytania z klauzulą JOIN?

A. pozyskać dane z dwóch tabel, które są ze sobą powiązane

B. określić klucz obcy dla tabeli

C. uzyskać wynik tylko z jednej tabeli

D. wywołać funkcję agregującą

Zapytania z klauzulą JOIN są fundamentalnym narzędziem w relacyjnych bazach danych, umożliwiającym łączenie danych z różnych tabel na podstawie określonych warunków. Klauzula JOIN pozwala na uzyskanie wyników, które są wynikiem relacji między tabelami, co jest kluczowe w przypadku, gdy dane są rozproszone w różnych miejscach. Na przykład, w przypadku bazy danych e-commerce, możemy mieć jedną tabelę z informacjami o klientach i inną z zamówieniami. Używając JOIN, możemy połączyć te dwie tabele, aby uzyskać pełen obraz zamówień dokonanych przez konkretnego klienta. W praktyce, korzystanie z JOIN jest zgodne z zasadami normalizacji bazy danych, co przyczynia się do efektywnego zarządzania danymi i minimalizowania redundancji. Przy właściwym zastosowaniu, JOIN może również poprawić wydajność zapytań, limitując ilość danych do przesłania, kiedy to tylko niezbędne informacje są łączone w jeden wynik. To podejście jest zgodne z najlepszymi praktykami w inżynierii oprogramowania oraz zarządzaniu danymi.

Pytanie 10

Kwerenda

ALTER TABLE artykuly MODIFY cena float;

ma na celu dokonanie zmian w tabeli artykuly.

A. zmienić typ kolumny cena na float

B. dodać kolumnę o nazwie cena z typem float, jeżeli jeszcze nie istnieje

C. usunąć kolumnę o nazwie cena typu float

D. zmienić nazwę kolumny cena na float

Twoja odpowiedź o zmianie typu na float dla kolumny cena jest całkiem na miejscu! W pracy z bazami danych ważne jest, żeby odpowiednio zarządzać typami danych w tabelach. Typ float to coś, co często wykorzystuje się do przechowywania wartości liczbowych, które mają część dziesiętną. To istotne przy cenach, które często muszą być dokładnie przedstawione, na przykład do dwóch miejsc po przecinku. Wspomniana kwerenda ALTER TABLE to świetne narzędzie do zmiany struktury tabeli, i to jest zgodne z dobrymi praktykami zarządzania bazami, zwłaszcza z zasadą elastyczności. Dzięki temu można dostosować tabelę do zmieniających się potrzeb bez potrzeby przebudowy całej bazy. Wiesz, takie operacje są dość typowe, ale trzeba uważać, by nie stracić danych czy mieć jakieś niezgodności. Dlatego zawsze warto zrobić kopię zapasową i testować zmiany w środowisku testowym. Zrozumienie takich operacji pomoże ci w lepszym zarządzaniu bazami danych i ich optymalizacji.

Pytanie 11

Określenie powiązań między tabelami w bazie danych MySQL realizuje klauzula

A. PRIMARY KEY

B. ORDER BY

C. INDEX

D. REFERENCES

Klauzula REFERENCES w systemie bazodanowym MySQL jest kluczowym elementem, który umożliwia ustanawianie relacji pomiędzy tabelami. Jej główną funkcją jest definiowanie kluczy obcych, które zapewniają referencyjną integralność danych. Klucz obcy wskazuje na kolumnę w innej tabeli, co pozwala na powiązanie dwóch zestawów danych. Na przykład, jeśli mamy tabelę 'Zamówienia', która zawiera kolumnę 'KlientID', możemy użyć klauzuli REFERENCES, aby wskazać, że ta kolumna odnosi się do kolumny 'ID' w tabeli 'Klienci'. Dzięki temu, przy dodawaniu lub aktualizowaniu rekordów w tabeli 'Zamówienia', system MySQL będzie sprawdzać, czy 'KlientID' ma odpowiadający mu rekord w tabeli 'Klienci'. Takie powiązanie zapobiega błędom związanym z nieistniejącymi danymi i umożliwia bardziej złożone zapytania, które łączą dane z różnych tabel. Klauzula REFERENCES jest częścią szerszych standardów SQL, które ułatwiają zarządzanie relacyjnymi bazami danych i są kluczowe w projektowaniu złożonych struktur danych.

Pytanie 12

W jaki sposób można ocenić normalizację przedstawionej tabeli?

FirmaAdres
Forbotul. Krótka 11, 22-222 Warszawa
Marbotul. Długa 5, 33-333 Warszawa

A. Tabela nie została znormalizowana

B. Tabela znajduje się w pierwszej postaci normalnej

C. Tabela znajduje się w drugiej postaci normalnej

D. Tabela jest w trzeciej postaci normalnej

Tabela nie jest znormalizowana ponieważ zawiera dane redundancyjne które mogą prowadzić do anomalii aktualizacji W tej tabeli adresy są przechowywane jako pojedyncze pola tekstowe co uniemożliwia ich efektywne wyszukiwanie i przetwarzanie Normalizacja bazy danych polega na usuwaniu redundancji danych poprzez ich dekompozycję na mniejsze tabele z zachowaniem integralności danych i minimalizacją utraty informacji W tym przypadku adresy powinny być rozbite na osobne pola takie jak ulica miasto i kod pocztowy co pozwoli na bardziej precyzyjną kontrolę i manipulację tymi danymi Dodatkowo należy zwrócić uwagę na potencjalne naruszenie zasad drugiej postaci normalnej gdzie klucz główny powinien jednoznacznie identyfikować wartości z nim powiązane Przy poprawnej normalizacji uzyskamy lepszą spójność danych i eliminację nieścisłości co jest kluczowe w przypadku aplikacji gdzie dane są często aktualizowane lub używane do różnorodnych analiz Ostatecznym celem normalizacji jest zwiększenie wydajności i dokładności operacji bazodanowych oraz ułatwienie zarządzania złożonymi strukturami danych

Pytanie 13

Zawarte polecenie SQL wykonuje

UPDATE Uczen SET id_klasy = id_klasy + 1;

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

B. ustalić wartość pola Uczen na 1

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

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

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

Pytanie 14

W SQL wykorzystywanym przez system baz danych MySQL atrybut UNIQUE w poleceniu CREATE TABLE

A. Jest stosowany wyłącznie w przypadku kolumn liczbowych

B. Jest używany, gdy wartości w kolumnie nie mogą się powtarzać

C. Wymusza unikalne nazwy kolumn w tabeli

D. Zabrania wprowadzenia wartości NULL

Istnieje kilka powszechnych nieporozumień dotyczących atrybutu UNIQUE w kontekście relacyjnych baz danych, które mogą prowadzić do błędnych wniosków. Przede wszystkim, twierdzenie, że atrybut UNIQUE wymusza unikatowe nazwy pól tabeli, jest nieprecyzyjne. UNIKATOWOŚĆ odnosi się do wartości przechowywanych w kolumnie, a nie do nazw kolumn. W rzeczywistości, nowa kolumna nie może mieć takiej samej nazwy jak istniejąca kolumna w tej samej tabeli, co jest regułą odzwierciedlającą strukturalne ograniczenia bazy danych, ale nie ma to związku z atrybutem UNIQUE. Ponadto, atrybut ten nie blokuje możliwości wpisania wartości NULL w kolumnach. W MySQL, kolumna z atrybutem UNIQUE może zawierać wiele wartości NULL, ponieważ NULL jest traktowane jako wartość nieokreślona i nie jest uważane za duplikat. Dlatego stwierdzenie, że UNIQUE blokuje możliwość wpisania wartości NULL, jest mylące. Co więcej, atrybut UNIQUE nie jest ograniczony tylko do pól liczbowych; może być zastosowany do dowolnego typu danych, w tym tekstowych czy datowych. Stosowanie UNIQUE w zbiorach danych, które nie wymagają unikalności, może prowadzić do zbędnych błędów i komplikacji podczas wprowadzania danych. Dlatego ważne jest, aby zrozumieć, że atrybut ten odnosi się do wartości w kolumnach, a nie do ich typów czy nazw, co jest kluczowe dla efektywnego projektowania baz danych.

Pytanie 15

Domyślny użytkownik, który posiada pełne uprawnienia do zarządzania bazą danych w systemie MySQL, to

A. admin

B. mysqld

C. root

D. sysadmin

Poprawna odpowiedź to „root”, ponieważ w domyślnej instalacji MySQL to właśnie użytkownik root ma pełne, administracyjne uprawnienia do całego serwera baz danych. Jest to odpowiednik konta administratora systemu operacyjnego, ale w kontekście samego MySQL. Użytkownik root może tworzyć i usuwać bazy danych, zakładać nowych użytkowników, nadawać i odbierać im uprawnienia, wykonywać kopie zapasowe, przywracać dane, a także zmieniać konfigurację na poziomie serwera SQL. Z mojego doświadczenia wynika, że w środowiskach produkcyjnych raczej unika się codziennej pracy na koncie root, mimo że technicznie jest to możliwe. Zgodnie z dobrymi praktykami bezpieczeństwa tworzy się osobne konta z ograniczonymi uprawnieniami, np. użytkownika, który ma dostęp tylko do jednej konkretnej bazy i tylko do odczytu albo do odczytu i zapisu. Konto root zostawia się wyłącznie do zadań administracyjnych, takich jak migracje, zmiana schematu bazy, naprawa tabel czy zarządzanie użytkownikami. W praktyce, podczas pierwszej instalacji MySQL albo MariaDB, instalator prosi o ustawienie hasła dla użytkownika root – i to hasło powinno być mocne, unikalne i dobrze zabezpieczone. W środowiskach serwerowych często dodatkowo ogranicza się możliwość logowania rootem z zewnątrz, np. tylko z localhost, aby utrudnić ewentualne ataki z sieci. Warto też pamiętać, że w MySQL użytkownik identyfikowany jest nie tylko nazwą, ale też hostem, więc „root@localhost” to inny użytkownik niż „root@%”. W pracy zawodowej spotyka się też sytuację, że root ma wyłączone logowanie hasłem i używa się uwierzytelniania systemowego lub pluginów, ale to już bardziej zaawansowane scenariusze. Kluczowe jest to, że root jest kontem nadrzędnym, z pełnią praw, i trzeba z nim obchodzić się ostrożnie, bo jedno nieuważne polecenie może usunąć całą bazę produkcyjną.

Pytanie 16

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

GRANT SELECT, INSERT, UPDATE ON klienci TO anna;

nada użytkownikowi anna uprawnienia wyłącznie do

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

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

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

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

Polecenie SQL 'GRANT SELECT, INSERT, UPDATE ON klienci TO anna;' przyznaje użytkownikowi 'anna' konkretne uprawnienia do tabeli 'klienci'. Oznacza to, że użytkownik ten będzie miał możliwość wybierania (SELECT), wstawiania (INSERT) oraz aktualizacji (UPDATE) danych w tej konkretnej tabeli. To podejście jest zgodne z zasadą minimalnych uprawnień, co oznacza, że użytkownik powinien mieć jedynie te prawa, które są niezbędne do wykonywania jego zadań. Na przykład, jeśli 'anna' jest pracownikiem działu sprzedaży, może być konieczne, aby miała dostęp do aktualizacji informacji o klientach, ale nie potrzebuje uprawnień do usuwania rekordów (DELETE) czy zmiany struktury tabeli (ALTER). Praktyczne zastosowanie takiego przydzielania uprawnień pomaga w zabezpieczeniu danych oraz minimalizuje ryzyko nieautoryzowanych zmian, co jest standardem w zarządzaniu bazami danych. Dodatkowo, stosowanie takich restrykcji w przydzielaniu ról jest zgodne z najlepszymi praktykami bezpieczeństwa w branży IT, aby zapobiegać potencjalnym nadużyciom.

Pytanie 17

Zidentyfikuj poprawnie zbudowany warunek w języku PHP, który sprawdza brak połączenia z bazą MySQL.

A. if {mysql_connect_errno()}{}

B. if (mysql_connect_error())()

C. if {mysqli_connect_error()}{}

D. if (mysqli_connect_errno()){}

No, odpowiedzi, które wybrałeś, mają sporo błędów. Na przykład, 'if (mysql_connect_error())()' jest źle napisane, bo masz tu podwójne nawiasy, a powinny być pojedyncze. 'if {mysql_connect_errno(){}}' i 'if {mysqli_connect_error()}' używają klamr, gdzie powinny być nawiasy okrągłe, bo w PHP warunki muszą być w nawiasach. Te stare funkcje, takie jak 'mysql_connect_error()' czy 'mysql_connect_errno()', to już przeżytek, zostały usunięte w PHP 7.0. Teraz, wybierając 'mysqli', zapewniasz sobie lepsze bezpieczeństwo i działanie aplikacji. To jest kluczowe, żeby zrozumieć, jak poprawnie pisać kod, bo bez tego ciężko osiągniesz sukces w programowaniu w PHP.

Pytanie 18

Jakie jest zadanie funkcji PHP o nazwie mysql_num_rows()?

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

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

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

D. ponumerować rekordy w bazie danych

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 19

W SQL klauzula DISTINCT w poleceniu SELECT zapewnia, że zwrócone wyniki

A. nie zawiera będą duplikatów.

B. będą spełniały dany warunek.

C. będą uporządkowane.

D. będą zgrupowane według wskazanego pola.

Klauzula DISTINCT w języku SQL jest używana w instrukcji SELECT do eliminacji duplikatów w zwracanych wynikach zapytania. Gdy zapytanie wykorzystuje DISTINCT, zwracane są tylko unikalne rekordy, co oznacza, że identyczne wiersze występujące w zestawie wyników są redukowane do jednego wystąpienia. Działa to poprzez porównywanie wszystkich kolumn wymienionych w SELECT, co oznacza, że różnice w jakiejkolwiek kolumnie będą skutkować zwróceniem oddzielnych wierszy. Przykładowe zapytanie: SELECT DISTINCT nazwisko FROM pracownicy; zwróci listę unikalnych nazwisk pracowników, eliminując wszelkie powtórzenia. Klauzula DISTINCT jest szczególnie przydatna w raportach i analizach danych, gdyż pozwala na zrozumienie częstotliwości występowania różnych wartości. Zgodnie z SQL ANSI, użycie DISTINCT jest standardem, co oznacza, że jest obsługiwane przez wszystkie główne systemy zarządzania bazami danych, takie jak MySQL, PostgreSQL czy Oracle. Warto jednak pamiętać, że dodanie DISTINCT do zapytania może wpływać na wydajność, zwłaszcza w przypadku dużych zbiorów danych, ponieważ wymaga dodatkowych operacji przetwarzania, aby zidentyfikować i usunąć duplikaty.

Pytanie 20

W zapytaniu SQL, umieszczonym w ramce, symbol gwiazdki wskazuje, że w wyniku tego zapytania

A. zostaną wyświetlone wszystkie wpisy z tabeli mieszkańcy

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

C. zostanie pokazane pole o nazwie "*" (gwiazdka)

D. zostanie pominięty warunek dotyczący imienia

W zapytaniach SQL użycie znaku gwiazdki (*) po klauzuli SELECT jest częstą praktyką, która wskazuje na potrzebę wyświetlenia wszystkich kolumn z tabeli wynikowej. W kontekście zapytania SELECT * FROM mieszkańcy WHERE imie = 'Anna'; oznacza to, że zostaną zwrócone wszystkie kolumny dla rekordów, które spełniają warunek imie='Anna'. Jest to szybki sposób na uzyskanie pełnych danych dla określonych kryteriów bez konieczności wyszczególniania nazw kolumn, co może być szczególnie przydatne w przypadku tabel o dużej liczbie kolumn. Ważnym aspektem jest tutaj optymalizacja zapytań; choć użycie * jest wygodne, w dużych zbiorach danych lepiej jest selekcjonować tylko te kolumny, które są rzeczywiście potrzebne do analizy, co zmniejsza obciążenie bazy danych i poprawia wydajność. W praktykach branżowych zaleca się również zwracanie uwagi na bezpieczeństwo danych i dostępność użytkowników do informacji, szczególnie w kontekście RODO i innych regulacji dotyczących ochrony danych osobowych.

Pytanie 21

Tabela o nazwie naprawy zawiera kolumny: klient, czyNaprawione. Jakie polecenie należy użyć, aby wykasować rekordy, w których pole czyNaprawione ma wartość prawdziwą?

A. DELETE klient FROM naprawy WHERE czyNaprawione = TRUE;

B. DELETE naprawy WHERE czyNaprawione = TRUE;

C. DELETE FROM naprawy WHERE czyNaprawione = TRUE;

D. DELETE FROM naprawy;

Poprawna odpowiedź to 'DELETE FROM naprawy WHERE czyNaprawione = TRUE;'. To polecenie SQL jest zgodne z syntaksą używaną do usuwania rekordów z tabeli, gdzie spełniony jest określony warunek. W tym przypadku, usuwamy wszystkie rekordy z tabeli 'naprawy', dla których pole 'czyNaprawione' ma wartość TRUE. Użycie słowa kluczowego 'FROM' jest niezbędne, aby wskazać, z której tabeli chcemy usunąć dane. Przykładowo, jeśli w tabeli 'naprawy' mamy wielu klientów, z którymi nie zostały jeszcze dokonane naprawy, a chcemy zachować tylko te, które zostały zakończone, takie polecenie jest idealne. W praktyce, stosowanie takich zapytań jest istotne, aby utrzymywać bazę danych w porządku i eliminować nieaktualne informacje. Ponadto, zgodnie z dobrymi praktykami, przed wykonaniem polecenia DELETE warto wykonać zapytanie SELECT z tym samym warunkiem, aby zobaczyć, które rekordy zostaną usunięte.

Pytanie 22

W języku SQL, aby usunąć tabelę należy zastosować polecenie

A. TRUNCATE TABLE

B. UNIQUE

C. DELETE

D. DROP TABLE

Poprawne polecenie do usunięcia całej tabeli w SQL to „DROP TABLE”. To polecenie działa na poziomie struktury bazy danych, a nie tylko na danych. Innymi słowy: nie usuwasz rekordów z tabeli, tylko samą tabelę jako obiekt – razem z jej definicją, indeksami, constraintami (klucze obce, klucze główne, unikalne, check) itp. Przykładowo, jeśli masz tabelę użytkownicy, to jej usunięcie wygląda tak: DROP TABLE uzytkownicy; Po wykonaniu tej komendy tabela przestaje istnieć w schemacie bazy. Próba SELECT * FROM uzytkownicy po takim DROP-ie zakończy się błędem typu „table does not exist”. Moim zdaniem warto zapamiętać, że DROP to operacja DDL (Data Definition Language), czyli zmienia definicję bazy, w odróżnieniu od DELETE, który jest DML (Data Manipulation Language) i modyfikuje tylko zawartość. W praktyce w projektach produkcyjnych polecenia DROP TABLE stosuje się ostrożnie, zwykle po wykonaniu kopii zapasowej lub na środowiskach deweloperskich/testowych, bo operacja jest destrukcyjna i w wielu silnikach baz danych nieodwracalna bez backupu. Dobrą praktyką jest też sprawdzenie zależności, np. kluczy obcych z innych tabel, bo DROP TABLE może się nie udać, jeśli inne tabele się do niej odwołują. W wielu systemach stosuje się wariant: DROP TABLE IF EXISTS nazwa_tabeli; co pozwala uniknąć błędu, gdy tabela już została wcześniej usunięta. Warto też mieć świadomość, że w normalnych projektach zmiany struktury bazy (w tym DROP TABLE) wykonuje się przez migracje lub skrypty wersjonujące, a nie „z palca” na produkcji, co po prostu zwiększa bezpieczeństwo i porządek w bazie.

Pytanie 23

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

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

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

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

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

W podejściu zawartym w niepoprawnych odpowiedziach występuje kilka kluczowych nieporozumień dotyczących interpretacji zapytań SQL i zasad działania operatora `IN`. Wybór danych na podstawie wieku poniżej 18 lat jest błędny, ponieważ zapytanie nie uwzględnia wieku poniżej tej granicy, a zatem nie może zwracać rekordów dla tej grupy wiekowej. Takie wnioski mogą wynikać z mylnej interpretacji operatora `IN`, który nie działa na zasadzie zakresu, lecz na precyzyjnych wartościach. Przyjmowanie, że zapytanie obejmuje osoby powyżej 30 lat jest również niepoprawne, ponieważ zapytanie nie zawiera takich warunków, co dowodzi braku zrozumienia filtracji danych. Kolejny typowy błąd poznawczy to mylenie pojęcia 'przedziału' z konkretnymi wartościami. W SQL, kiedy chcemy odwołać się do przedziału, stosuje się operator `BETWEEN`, co różni się od zastosowania `IN`. Zrozumienie tych podstawowych różnic jest kluczowe w pracy z bazami danych. Aby skutecznie budować zapytania SQL, ważne jest zrozumienie, jakie operatory są odpowiednie do konkretnych zadań oraz jakie są ich ograniczenia. Niewłaściwe interpretowanie wyników zapytań może prowadzić do błędnych wniosków i decyzji, co podkreśla znaczenie staranności w analizie danych.

Pytanie 24

W relacyjnych bazach danych encja jest przedstawiana przez

A. kwerendę.

B. tabelę.

C. relację.

D. rekord.

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

Pytanie 25

SELECT ocena FROM oceny WHERE ocena>2 ORDER BY ocena;

Dana jest tabela oceny o polach id, nazwisko, imie, ocena. Przedstawione zapytanie jest przykładem:

A. sumowania

B. łączenia

C. selekcji

D. projekcji

Zapytanie SQL, które przedstawiłeś, jest naprawdę świetnym przykładem selekcji. Dzięki niemu można wyciągnąć konkretne dane z tabeli 'oceny'. Selekcja to nic innego jak filtracja danych według ustalonych kryteriów, a w tym przypadku chodzi o to, że 'ocena' musi być większa niż 2. Użycie klauzuli WHERE w SQL pozwala na efektywne wyodrębnienie danych spełniających te wymagania. A jak dodasz do tego klauzulę ORDER BY, to możesz posortować wyniki według wybranej kolejności, co jest naprawdę przydatne w różnych analizach. Takie operacje są kluczowe w pracy z bazami danych, bo dzięki nim zdobywasz konkretną wiedzę bez przeszukiwania całej bazy. W praktyce widać to w raportach, gdzie często potrzebne są tylko konkretne dane, przykładowo żeby sprawdzić, którzy studenci osiągnęli określony poziom ocen. Selekcja daje ci możliwość efektywnego zarządzania danymi, a to według mnie bardzo ważne, zwłaszcza w analizach.

Pytanie 26

Wskaż poprawne zdanie dotyczące poniższego polecenia. ```CREATE TABLE IF NOT EXISTS ADRES (ulica VARCHAR(70)) CHARACTER SET utf8); ```

A. Rekord tabeli nie może mieć wartości 3 MAJA

B. Klauzula CHARACTER SET utf8 jest wymagana

C. Nie można dodawać do tabeli ulic, które zawierają polskie znaki w nazwie

D. IF NOT EXISTS używa się opcjonalnie, żeby potwierdzić, że taka tabela nie istnieje w bazie danych

Klauzula IF NOT EXISTS w poleceniu CREATE TABLE jest używana do zapobiegania błędom, które mogą wystąpić, gdy próbujesz stworzyć tabelę, która już istnieje w danej bazie danych. Dzięki temu operatorowi, jeśli tabela o podanej nazwie już istnieje, polecenie nie zostanie wykonane, co pozwala na uniknięcie konfliktów oraz zbędnych błędów w aplikacji. Jest to szczególnie przydatne w sytuacjach, gdy skrypty są uruchamiane wielokrotnie, na przykład podczas aktualizacji lub migracji bazy danych. Użycie IF NOT EXISTS jest opcjonalne, ale zalecane dla poprawności i stabilności kodu SQL. Przykład praktyczny: można stworzyć tabelę 'klienci' z poleceniem 'CREATE TABLE IF NOT EXISTS klienci (id INT PRIMARY KEY, imie VARCHAR(100));', co zapobiega próbie utworzenia tabeli, która już istnieje. Zgodnie z standardami SQL, operator ten jest powszechnie akceptowany w większości systemów zarządzania bazami danych, takich jak MySQL, PostgreSQL czy SQLite, co czyni go uniwersalnym rozwiązaniem w projektach opartych na bazach danych.

Pytanie 27

Aby skutecznie stworzyć relację typu m…n, która będzie wolna od redundancji danych, konieczne jest

A. zaprojektowanie tabeli pomocniczej.

B. bezpośrednie połączenie kluczy podstawowych obu tabel.

C. uporządkowanie przynajmniej jednej z tabel.

D. bezpośrednie połączenie kluczy obcych z obu tabel.

Bezpośrednie połączenie kluczy obcych obu tabel w relacji m:n nie jest wystarczające, aby uniknąć redundancji danych. W rzeczywistości, klucze obce mają swoje zastosowanie w relacjach jeden do wielu, gdzie jedna z tabel zawiera odniesienia do drugiej. W przypadku relacji m:n, takie podejście prowadziłoby do powstania złożonych i nieczytelnych struktur, w których dane byłyby przetrzymywane wielokrotnie, co naruszałoby zasady normalizacji. Na przykład, gdybyśmy spróbowali bezpośrednio połączyć klucze obce studentów i kursów, każda kombinacja studenta i kursu byłaby wprowadzana do tej samej tabeli, co prowadziłoby do powielania informacji i wzrostu rozmiaru bazy danych bez rzeczywistej wartości. Ponadto, sortowanie jednej z tabel nie ma wpływu na strukturę relacji m:n; sortowanie jest operacją na poziomie zapytań, a nie na poziomie architektury bazy danych. Łączenie kluczy podstawowych także nie rozwiązuje problemu redundancji, ponieważ nie tworzy połączenia, które umożliwiłoby wielokrotne przypisanie tych samych elementów między tabelami. Właściwe podejście wymaga utworzenia tabeli pomocniczej, co jest powszechną praktyką w projektowaniu baz danych i zapewnia przejrzystość oraz efektywność operacyjną.

Pytanie 28

W SQL, aby utworzyć tabelę, konieczne jest użycie polecenia

A. INSERT TABLE

B. ADD TABLE

C. ALTER TABLE

D. CREATE TABLE

Żeby stworzyć tabelę w SQL, musisz użyć polecenia CREATE TABLE. To jest coś jak fundament, bo dzięki temu mówisz systemowi, jak ma wyglądać Twoja tabela. Możesz określić nazwę tabeli i jakie kolumny będą przechowywać dane. Wchodzą tu nie tylko nazwy kolumn, ale też ich typy, co jest ważne, żeby dane były dobrze zapisane. Na przykład, chcesz zrobić tabelę 'Użytkownicy', która ma ID, imię i nazwisko? Wtedy używasz takiego zapisu: CREATE TABLE Użytkownicy (ID INT PRIMARY KEY, Imię VARCHAR(50), Nazwisko VARCHAR(50)). Poza tym, to polecenie działa w różnych systemach, jak MySQL czy PostgreSQL, co czyni je naprawdę uniwersalnym. Z mojego doświadczenia, znajomość tego polecenia jest mega ważna, jeśli chcesz dobrze pracować z bazami danych, bo to w końcu ich podstawy!

Pytanie 29

W hurtowni utworzono tabelę sprzedaż, która zawiera pola: id, kontrahent, grupa_cenowa oraz obrot. Jakie polecenie należy wykorzystać, aby znaleźć tylko kontrahentów z drugiej grupy cenowej, których obrót przekracza 4000 zł?

A. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa=2 OR obrot>4000

B. SELECT sprzedaz FROM kontrahent WHERE grupa_cenowa=2 AND obrot>4000

C. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa=2 AND obrot>4000

D. SELECT sprzedaz FROM kontrahent WHERE obrot>4000

W analizowanych odpowiedziach znajdują się elementy, które nie spełniają wymogów stawianych przez zapytanie o kontrahentów z drugiej grupy cenowej i obrotem powyżej 4000 zł. W pierwszym przypadku, zapytanie używa niewłaściwej konstrukcji, ponieważ polecenie 'SELECT sprzedaz FROM kontrahent WHERE obrot>4000;' odnosi się do błędnych tabel i kolumn, wprowadzając zamieszanie. Użycie 'FROM kontrahent' zamiast 'FROM sprzedaz' wskazuje na nieprawidłowe zrozumienie struktury bazy danych. Kolejny błąd polega na zastosowaniu operatora OR w jednym z zapytań, co prowadzi do zwrócenia wszystkich kontrahentów, którzy mają obrót większy niż 4000 zł, niezależnie od grupy cenowej. W kontekście wymagań pytania, taki zabieg nie jest wystarczający, ponieważ nie segreguje wyników według grupy cenowej, co może skutkować uzyskaniem niepożądanych danych. W ostatniej niepoprawnej odpowiedzi także występuje mylna konstrukcja, ponieważ 'SELECT sprzedaz FROM kontrahent WHERE grupa_cenowa=2 AND obrot>4000;' błędnie wskazuje na tabele i kolumny, co jest niezgodne z zasadami normalizacji baz danych. Zastosowanie niewłaściwych aliasów i odniesień do tabel uniemożliwia skuteczne wykonanie zapytania i analizę danych.

Pytanie 30

Na podstawie tabeli Towar zrealizowano poniższe zapytanie SQL: ```SELECT nazwa_towaru FROM `Towar` WHERE cena_katalogowa < 65 ORDER BY waga DESC``` Jaki będzie rezultat tej operacji?

A. Zeszyt A5 w linie, Zeszyt A5, Kredki 24 kolory, Papier ksero A4

B. Zeszyt A5, Zeszyt A5 w linie, Kredki 24 kolory, Papier ksero A4

C. Papier ksero A4, Kredki 24 kolory, Zeszyt A5, Zeszyt A5 w linie

D. Papier ksero A4, Kredki 24 kolory, Zeszyt A5 w linie, Zeszyt A5

Zapytanie SQL selekcjonuje towary z tabeli Towar, których cena katalogowa jest mniejsza niż 65, a następnie sortuje wyniki malejąco według wagi. Dzięki temu otrzymujemy listę towarów uporządkowaną od najcięższego do najlżejszego, a jednocześnie wykluczamy towary, które nie spełniają kryterium ceny. W podanym zestawie danych znajdują się cztery towary spełniające warunek cenowy: Papier ksero A4, Zeszyt A5, Zeszyt A5 w linie i Kredki 24 kolory. Spośród tych towarów najcięższy jest Papier ksero A4 (2.3), następnie Kredki 24 kolory (0.3), Zeszyt A5 (0.13), a najlżejszy jest Zeszyt A5 w linie (0.12). Kolejność wyników odpowiada zatem prawidłowej odpowiedzi numer 3. W praktyce umiejętność tworzenia zapytań SQL z warunkami filtrowania i sortowania jest niezwykle istotna w analizie danych, umożliwiając precyzyjne wyodrębnienie potrzebnych informacji z dużych zbiorów danych. Dobrym standardem jest zawsze testowanie zapytań na przykładowych danych, aby potwierdzić poprawność wyników przed ich zastosowaniem w środowisku produkcyjnym.

Pytanie 31

Kto z wymienionych zajmuje się stałym przygotowaniem systemu bazy danych do działania w produkcji, zarządzaniem kontami użytkowników oraz instalowaniem nowych wersji systemu bazodanowego?

A. Administratorzy systemu bazy danych

B. Administratorzy serwerów oraz sieci komputerowych

C. Twórcy narzędzi programistycznych

D. Projektanci i programiści Systemu Zarządzania Bazą Danych

Administratorzy systemu bazy danych (DBA) odgrywają kluczową rolę w zarządzaniu bazami danych w organizacji. Ich głównym zadaniem jest zapewnienie ciągłej dostępności systemu bazy danych, co obejmuje zarówno przygotowanie środowiska do pracy produkcyjnej, jak i monitorowanie jego wydajności. DBA są odpowiedzialni za zarządzanie użytkownikami, co oznacza, że tworzą i usuwają konta użytkowników oraz przydzielają odpowiednie uprawnienia dostępu, co jest istotne dla bezpieczeństwa danych. Dodatkowo, DBA instalują nowe wersje systemu bazodanowego, co wiąże się z aktualizacjami oprogramowania, które często zawierają poprawki błędów oraz nowe funkcje. Przykładem takiej praktyki jest regularne tworzenie kopii zapasowych danych oraz ich przywracanie w przypadku awarii. DBA muszą także znać standardy i dobre praktyki branżowe, takie jak modelowanie danych czy optymalizacja zapytań SQL, co wpływa na efektywność działania bazy danych. Współpraca z innymi działami IT, takimi jak programiści czy inżynierowie systemowi, jest również niezbędna dla sprawnego funkcjonowania systemów opartych na bazach danych.

Pytanie 32

Jednoznacznym identyfikatorem rekordu w bazie danych jest pole

A. wyłącznie typu tekstowego.

B. klucza głównego.

C. klucza obcego.

D. wyłącznie typu logicznego.

Poprawna jest odpowiedź dotycząca klucza głównego, bo to właśnie pole (lub zestaw pól) oznaczone jako PRIMARY KEY w tabeli pełni rolę jednoznacznego identyfikatora rekordu. W praktyce oznacza to, że dla każdej krotki (wiersza) w tabeli wartość klucza głównego musi być unikalna i nie może być pusta (NULL). Systemy baz danych, takie jak MySQL, PostgreSQL, SQL Server czy Oracle, egzekwują te zasady automatycznie – jeśli spróbujesz wstawić drugi rekord z tą samą wartością klucza głównego, dostaniesz błąd naruszenia unikalności. Moim zdaniem to jedna z kluczowych zasad normalnego projektowania baz danych: zawsze projektujemy tabelę zaczynając od przemyślania klucza głównego. W aplikacjach webowych bardzo często używa się prostego klucza głównego typu liczbowego (np. INT AUTO_INCREMENT lub SERIAL), który jest technicznym identyfikatorem rekordu. Dzięki temu łatwo się odwołać do konkretnego użytkownika, zamówienia czy produktu po jego ID. Klucz główny jest też podstawą do definiowania kluczy obcych w innych tabelach – relacje typu 1:N czy N:M opierają się właśnie na odwołaniach do wartości PRIMARY KEY. Z mojego doświadczenia wynika, że stosowanie sztucznych (surrogate) kluczy głównych, zamiast kombinowania z wieloma polami naturalnymi, upraszcza później zapytania SQL, modyfikacje struktury i integrację z kodem w PHP czy JavaScript. W dobrze zaprojektowanej bazie danych każda tabela relacyjna powinna mieć jasno zdefiniowany klucz główny, bo bez tego trudno mówić o porządnym zarządzaniu danymi, spójności referencyjnej i wydajnym indeksowaniu.

Pytanie 33

Która funkcja PHP obsługi bazy danych służy do kodowania polskich znaków?

A. mysqli_query()

B. mysqli_fetch_assoc()

C. mysqli_set_charset()

D. mysqli_connect()

Prawidłowa odpowiedź to mysqli_set_charset(), bo właśnie ta funkcja ustawia zestaw znaków (charset) dla połączenia z bazą danych w rozszerzeniu mysqli. W praktyce oznacza to, że dzięki niej PHP i serwer bazy danych (np. MySQL) „dogadują się”, w jakim kodowaniu mają być przesyłane i zapisywane teksty – w tym polskie znaki typu ą, ę, ł, ś itd. Bez poprawnie ustawionego charsetu bardzo łatwo o krzaczki, znaki zapytania zamiast liter albo problemy z sortowaniem tekstu. Moim zdaniem dobrą praktyką jest zawsze po nawiązaniu połączenia mysqli_connect natychmiast wywołać mysqli_set_charset($conn, 'utf8mb4'). Ten konkretny charset (utf8mb4) jest obecnie standardem de facto: obsługuje pełne Unicode, w tym emotikony, różne alfabety, a przy okazji bez problemu radzi sobie z polskimi znakami. Przykładowy, poprawny fragment kodu może wyglądać tak: $conn = mysqli_connect('localhost', 'user', 'haslo', 'baza'); mysqli_set_charset($conn, 'utf8mb4'); Dzięki temu każda instrukcja mysqli_query, każde pobieranie danych mysqli_fetch_assoc będzie już działać w odpowiednim kodowaniu. Warto pamiętać, że ustawienie charsetu powinno być spójne na wszystkich poziomach: konfiguracja bazy (collation i charset tabel), ustawienia połączenia (właśnie mysqli_set_charset) oraz nagłówki HTTP/HTML (meta charset="utf-8"). Dopiero takie podejście zgodne z dobrymi praktykami branżowymi zmniejsza ryzyko błędów związanych z kodowaniem tekstu, zwłaszcza w większych aplikacjach webowych. Jeśli robi się projekty komercyjne, to ignorowanie tej funkcji bardzo szybko mści się przy migracjach danych czy integracjach z innymi systemami.

Pytanie 34

W tabeli mieszkancy, która zawiera pola id, imie, nazwisko, ulica, numer oraz czynsz (kwota całkowita), należy uzyskać informacje o osobach zamieszkujących ulicę Mickiewicza pod numerami 71, 72, 80, których czynsz nie przekracza 1000 zł. Klauzula WHERE w zapytaniu powinna wyglądać następująco

A. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) AND czynsz < 1000

B. WHERE ulica = 'Mickiewicza' OR numer IN (71, 72, 80) OR czynsz < 1000

C. WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) OR czynsz < 1000

D. WHERE ulica = 'Mickiewicza' AND numer > 70 AND numer < 81 OR czynsz < 1000

Kiedy piszemy zapytanie SQL, klauzula WHERE powinna wyglądać tak: 'WHERE ulica = 'Mickiewicza' AND numer IN (71, 72, 80) AND czynsz < 1000'. Dlaczego to działa? Bo ta klauzula jasno określa, że interesują nas tylko mieszkańcy z ulicy Mickiewicza, mający numery 71, 72 lub 80, i którzy płacą czynsz mniejszy niż 1000 zł. Użycie AND sprawia, że wszystkie te warunki muszą być spełnione naraz, co jest naprawdę ważne. Możemy to sobie wyobrazić w kontekście zarządzania nieruchomościami, gdzie chcemy pokazać tylko wybraną grupę mieszkańców, na przykład do analizy ich sytuacji finansowej. I tak na marginesie – w SQL lepiej unikać OR, gdy chcemy dostąpić do jasno określonych danych, ponieważ może to dać nam za dużo wyników lub takie, których nie chcemy.

Pytanie 35

W programie Microsoft Access mechanizmem ochrony danych związanym z tabelą i kwerendą jest

A. określanie zakresu tabel

B. wykorzystanie makr

C. przypisanie uprawnień

D. ustalanie limitów przestrzeni na dysku

Przypisanie uprawnień jest kluczowym elementem zarządzania bezpieczeństwem w Microsoft Access, ponieważ pozwala na kontrolowanie, kto ma dostęp do danych w tabelach i kwerendach. W praktyce, administratorzy baz danych mogą definiować, które grupy użytkowników mogą przeglądać, edytować lub usuwać dane. To podejście jest zgodne z zasadą najmniejszych uprawnień, co oznacza, że użytkownicy otrzymują tylko te uprawnienia, które są im niezbędne do wykonywania swoich zadań. Na przykład, jeśli pracownik potrzebuje jedynie przeglądać dane w konkretnej tabeli, administrator może przyznać mu jedynie uprawnienia do odczytu, co minimalizuje ryzyko nieautoryzowanych zmian. Warto także wspomnieć, że przypisanie uprawnień nie ogranicza się tylko do tabel, ale dotyczy również kwerend, formularzy i raportów, co pozwala na szczegółowe zarządzanie dostępem do różnych zasobów systemu. Dobre praktyki w zakresie bezpieczeństwa baz danych zalecają regularne audyty uprawnień, aby upewnić się, że są one nadal odpowiednie do zmieniających się potrzeb organizacji oraz roli użytkowników.

Pytanie 36

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

A. REPAIR TABLE

B. mysqldump

C. mysql

D. CHECK TABLE

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

Pytanie 37

W systemach bazodanowych, aby przedstawić dane, które spełniają określone kryteria, należy stworzyć

A. raport

B. makropolecenie

C. formularz

D. relację

Formularze, makropolecenia i relacje to różne rzeczy, które używamy w bazach danych, ale nie nadają się do tworzenia raportów. Formularz to narzędzie do wprowadzania danych, jego głównym celem jest to, żeby użytkownik mógł dodawać lub edytować informacje w bazie. Choć są przydatne do zbierania danych, to już do ich analizy czy prezentacji się nie nadają. Makropolecenia to z kolei instrukcje, które pomagają w automatyzacji powtarzalnych zadań, ale znowu – nie są do raportów. Użytkownicy mogą myśleć, że makropolecenia zastąpią raporty, ale to zupełnie inne rzeczy. Relacje dotyczą sposobu łączenia tabel w bazie danych, co jest ważne dla struktury, ale też nie ma to nic wspólnego z prezentacją danych. Warto wiedzieć, jakie są różnice między tymi pojęciami, bo to może pomóc w lepszym zarządzaniu danymi i uniknięciu nieporozumień.

Pytanie 38

Poziom izolacji transakcji Repeatable Read (tryb powtarzalnego odczytu) używany przez MS SQL jest związany z problemem

A. utraty aktualizacji

B. brudnych odczytów

C. niepowtarzalnych odczytów

D. odczytów widm

Wybór odpowiedzi 'niepowtarzalnych odczytów', 'brudnych odczytów' lub 'utraty aktualizacji' wskazuje na brak zrozumienia, jak działają różne poziomy izolacji transakcji w kontekście baz danych. Odczyty niepowtarzalne polegają na tym, że transakcja może odczytać różne wartości w kolejnych odczytach tego samego wiersza, co jest problemem rozwiązywanym przez poziom Repeatable Read. Oznacza to, że dane odczytane w jednym kroku transakcji pozostają spójne do końca tej transakcji, a zatem nie są one narażone na zmiany poprzez inne transakcje w tym samym czasie. Brudne odczyty występują, gdy jedna transakcja odczytuje dane zapisane przez inną, jeszcze niezakończoną transakcję, co jest problemem z kolei eliminowanym przez poziomy izolacji takie jak Read Committed. Utrata aktualizacji to inny problem, który polega na tym, że dwie transakcje odczytują tę samą wartość i zapisują zmodyfikowane wartości, przy czym ostatnia zapisuje nadpisując wcześniejszą, co także nie jest bezpośrednim problemem w kontekście Repeatable Read. W praktyce, zrozumienie różnicy między tymi problemami jest kluczowe dla zapewnienia spójności transakcji. Warto zatem studiować dokumentację i standardy, aby właściwie dobierać poziomy izolacji w zależności od wymagań konkretnej aplikacji.

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. poprawności składni zapytań

B. spójności bazy danych

C. uprawnień dostępu do serwera bazy danych

D. opcji udostępnienia bazy danych

Spójność bazy danych to kluczowy aspekt, który należy sprawdzić przed wykonaniem kopii bezpieczeństwa. Oznacza to, że wszystkie dane w bazie muszą być zgodne z ustalonymi regułami i zapewniać prawidłowe relacje między różnymi tabelami oraz rekordami. Na przykład, jeżeli w bazie danych znajdują się relacje między tabelami, to każda referencja musi wskazywać na istniejący rekord. W praktyce, przed wykonaniem kopii zapasowej, administratorzy często przeprowadzają operacje takie jak walidacja danych, aby upewnić się, że nie ma błędów, które mogłyby prowadzić do nieprawidłowych wyników po przywróceniu danych. Dobre praktyki w zarządzaniu bazami danych, takie jak regularne wykonywanie kontroli spójności oraz audytów danych, pomagają zminimalizować ryzyko problemów z danymi. Warto również korzystać z narzędzi automatyzacyjnych, które mogą wykrywać niezgodności w danych, co znacznie ułatwia proces przed wykonaniem kopii zapasowej.

Pytanie 40

Zastosowanie klauzuli PRIMARY KEY w poleceniu CREATE TABLE sprawi, że dane pole stanie się

A. kluczem obcym

B. kluczem podstawowym

C. indeksem unikalnym

D. indeksem klucza

Klauzula PRIMARY KEY w instrukcji CREATE TABLE definiuje unikalny identyfikator dla każdej rekord w tabeli, co oznacza, że pole oznaczone jako klucz podstawowy musi mieć unikalne wartości i nie może zawierać wartości NULL. Klucz podstawowy jest fundamentalnym elementem w relacyjnych bazach danych, ponieważ umożliwia tworzenie relacji między tabelami oraz zapewnia integralność danych. Na przykład, jeśli mamy tabelę 'Użytkownicy' z kolumną 'ID', która jest kluczem podstawowym, to każda wartość w tej kolumnie będzie unikalna, co pozwala na jednoznaczne identyfikowanie użytkowników. Zgodnie z normami SQL, klucz podstawowy może składać się z jednej lub wielu kolumn, a w przypadku złożonego klucza podstawowego, wszystkie kolumny muszą spełniać warunki unikalności oraz nie mogą mieć wartości NULL. W praktyce, użycie klucza podstawowego jest kluczowe dla organizacji danych i optymalizacji zapytań, ponieważ bazy danych mogą tworzyć indeksy na tych polach, co przyspiesza operacje wyszukiwania i sortowania.

Rozpocznij nowy egzamin

Powrót do strony głównej