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: 29 kwietnia 2026 09:12
  • Data zakończenia: 29 kwietnia 2026 09:18

Egzamin niezdany

Wynik: 12/40 punktów (30,0%)

Wymagane minimum: 20 punktów (50%)

Nowe
Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania
Udostępnij swój wynik
Facebook
X.com
LinkedIn
Szczegółowe wyniki:
Pytanie 1

W tabeli klienci znajduje się pole status, które może przyjmować wartości: Zwykły, Złoty, Platynowy. Z uwagi na to, że dane klientów o statusie Platynowy są przetwarzane najczęściej, konieczne jest utworzenie wirtualnej tabeli (widoku), która będzie zawierała wyłącznie te informacje. W tym celu można użyć kwerendy

A. CREATE VIEW KlienciPlatyna AS SELECT * FROM klienci WHERE status = "Platynowy"
B. CREATE VIEW KlienciPlatyna FROM klienci WHERE status = "Platynowy"
C. CREATE VIEW KlienciPlatyna AS SELECT status FROM klienci WHERE "Platynowy"
D. CREATE VIEW KlienciPlatyna AS klient WHERE status = "Platynowy"
Wszystkie inne odpowiedzi zawierają błędy w składni SQL lub koncepcjach dotyczących tworzenia widoków. Odpowiedź pierwsza, sugerując 'CREATE VIEW KlienciPlatyna AS klient WHERE status = "Platynowy";', jest niepoprawna, ponieważ nie podaje poprawnej struktury zapytania. W SQL nie używa się słowa kluczowego 'client' w takim kontekście. Odpowiedź druga, 'CREATE VIEW KlienciPlatyna FROM klienci WHERE status = "Platynowy";', wykorzystuje słowo kluczowe 'FROM', które nie jest obsługiwane w definicji widoków; zamiast tego powinno się używać 'AS SELECT'. Odpowiedź trzecia, 'CREATE VIEW KlienciPlatyna AS SELECT status FROM klienci WHERE "Platynowy";', także nie jest poprawna, ponieważ nie zawiera pełnej definicji warunku filtracji, a zamiast tego próbuję zastosować wartość bez kontekstu, co prowadzi do błędnych wyników. W SQL każdy element zapytania ma swoje miejsce i funkcje, a niepoprawna konstrukcja może skutkować błędami lub nieprzewidywalnymi rezultatami. W praktyce ważne jest, aby zrozumieć, jak budować zapytania w sposób zgodny z gramatyką języka SQL i jak optymalizować je dla lepszej wydajności. Prawidłowe zrozumienie struktury zapytań jest kluczowe w pracy z bazami danych.
Pytanie 2

Na rysunku została przedstawiona relacja jeden do wielu. Łączy ona

Ilustracja do pytania
A. klucz obcy reżyserzy_id tabeli filmy z kluczem obcym id tabeli reżyserzy.
B. klucz podstawowy id tabeli filmy z kluczem podstawowym id tabeli reżyserzy.
C. klucz obcy reżyserzy_id tabeli filmy z kluczem podstawowym id tabeli reżyserzy.
D. klucz podstawowy id tabeli filmy z kluczem obcym reżyserzy_id tabeli reżyserzy.
Wszystkie błędne odpowiedzi zawierają pewne mylące koncepcje związane z rolą kluczy obcych i podstawowych w relacyjnych bazach danych. Klucz podstawowy jest unikalnym identyfikatorem rekordu w tabeli, a klucz obcy wskazuje na klucz podstawowy w innej tabeli, tworząc w ten sposób relację między danymi. Błędne odpowiedzi sugerują, że klucz podstawowy z jednej tabeli może wskazywać na klucz podstawowy w innej tabeli lub że klucz obcy może wskazywać na inny klucz obcy. To są niepoprawne interpretacje, które mogą prowadzić do błędów w projektowaniu bazy danych, utrudniając efektywne zarządzanie danymi. Dobrze zrozumienie roli kluczy obcych i podstawowych jest kluczowe dla prawidłowego projektowania i zarządzania relacyjnymi bazami danych.
Pytanie 3

Jednoznacznym identyfikatorem rekordu w bazie danych jest pole

A. wyłącznie typu tekstowego.
B. klucza głównego.
C. wyłącznie typu logicznego.
D. klucza obcego.
W tym zagadnieniu łatwo pomylić różne typy pól i ich role w bazie danych, szczególnie gdy ktoś dopiero zaczyna przygodę z SQL i projektowaniem relacyjnych baz danych. Jednoznaczny identyfikator rekordu to takie pole, które pozwala bez żadnych wątpliwości wskazać dokładnie jeden wiersz w tabeli. W standardzie relacyjnych baz danych tę rolę pełni klucz główny, oznaczany jako PRIMARY KEY. Klucz obcy jest często mylony z kluczem głównym, bo też dotyczy identyfikatorów, ale jego zadanie jest inne. Foreign key służy do tworzenia powiązań między tabelami – przechowuje wartości klucza głównego z innej tabeli. Sam w sobie nie musi być unikalny, wręcz przeciwnie, w relacji 1:N zwykle powtarza się wiele razy. Dlatego nie może być uznany za jednoznaczny identyfikator rekordu w swojej tabeli. Gdybyśmy próbowali identyfikować rekordy po kluczu obcym, szybko okazałoby się, że wiele wierszy ma tę samą wartość i nie da się wskazać jednego, konkretnego. Kolejny typ błędnego rozumowania to przekonanie, że o byciu identyfikatorem decyduje typ danych, np. logiczny albo tekstowy. Typ logiczny (BOOLEAN, TINYINT(1) itp.) ma zwykle tylko dwie możliwe wartości: true/false, 0/1. Nietrudno zauważyć, że w dowolnej realnej tabeli więcej niż dwa rekordy nie będzie mogło mieć unikalnej wartości takiego pola, więc nie da się w ten sposób jednoznacznie identyfikować wierszy. Typ tekstowy też sam w sobie niczego nie gwarantuje. Można mieć kolumnę VARCHAR z e-mailem użytkownika, ale jeśli nie nałożymy ograniczenia unikalności i nie oznaczymy jej jako klucz główny, baza danych nie będzie pilnowała, by wartości się nie powtarzały. Częsty błąd myślowy polega na tym, że skoro w praktyce „zazwyczaj” coś jest unikalne (np. PESEL, e-mail), to ktoś zakłada, że to automatycznie jest klucz główny. Tymczasem dopiero formalne zadeklarowanie PRIMARY KEY (ewentualnie UNIQUE + NOT NULL, ale to już bardziej obejście) nadaje kolumnie rolę jednoznacznego identyfikatora w sensie technicznym. Dlatego nie typ danych, nie to czy pole wygląda na ważne, tylko jego definicja jako klucza głównego w strukturze tabeli decyduje o tym, że identyfikuje rekord jednoznacznie.
Pytanie 4

Polecenie SQL:

GRANT SELECT, INSERT, UPDATE, DELETE ON klienci TO adam@localhost
Przedstawione polecenie SQL nadaje użytkownikowi adam@localhost prawa:
A. do manipulowania danymi bazy danych klienci
B. do zarządzania strukturą bazy danych klienci
C. do zarządzania strukturą tabeli klienci
D. do manipulowania danymi w tabeli klienci
Polecenie SQL przedstawione w pytaniu to GRANT, które jest używane do nadawania uprawnień użytkownikom w systemach zarządzania bazami danych. W tym przypadku użytkownikowi adam@localhost przyznawane są prawa SELECT, INSERT, UPDATE oraz DELETE na tabeli klienci. Oznacza to, że adam ma pełne prawo do manipulowania danymi w tej tabeli, co obejmuje możliwość odczytu danych (SELECT), dodawania nowych rekordów (INSERT), aktualizacji istniejących danych (UPDATE) oraz usuwania danych (DELETE). W kontekście relacyjnych baz danych, te operacje są kluczowe dla zarządzania danymi. Przykładowo, jeśli adam chciałby dodać nowego klienta, użyłby polecenia INSERT. Jeśli natomiast chciałby zaktualizować dane istniejącego klienta, wykorzystałby polecenie UPDATE. Standardy SQL precyzują, że każde z tych uprawnień pozwala użytkownikowi na określone interakcje z danymi, co jest niezbędne dla efektywnego zarządzania informacjami w bazie danych, a także zapewnia bezpieczeństwo poprzez kontrolę dostępu do wrażliwych danych.
Pytanie 5

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

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

W danej tabeli pracownicy, polecenie MySQL eliminujące wszystkie wpisy, dla których nie została wypełniona kolumna rodzaj_umowy, ma następującą formę

A. DROP pracownicy FROM rodzaj_umowy = 0;
B. DELETE FROM pracownicy WHERE rodzaj_umowy IS NULL;
C. DELETE pracownicy WHERE rodzaj_umowy = 'brak';
D. DROP pracownicy WHERE rodzaj_umowy IS NULL;
W odpowiedziach, które zostały uznane za błędne, można dostrzec kilka istotnych nieporozumień dotyczących użycia poleceń SQL. Przykładowo, polecenie "DELETE pracownicy WHERE rodzaj_umowy = 'brak';" sugeruje, że chcesz usunąć pracowników z tabeli, którzy mają zaznaczoną wartość 'brak'. Jednak, w kontekście baz danych, wartość NULL jest odmienna od wartości tekstowej. NULL oznacza brak jakiejkolwiek wartości, co nie jest tożsame z wartością 'brak'. W związku z tym to zapytanie nie zwróci żadnych rezultatów, ponieważ nie identyfikuje rekordów, których pole 'rodzaj_umowy' jest puste. Inna odpowiedź, "DROP pracownicy WHERE rodzaj_umowy IS NULL;" jest również niepoprawna, ponieważ komenda DROP służy do usuwania całej tabeli, a nie poszczególnych rekordów. Zastosowanie WHERE w tym kontekście jest niewłaściwe, co prowadzi do całkowitego usunięcia tabeli, a nie do usunięcia tylko określonych wierszy. Z kolei "DROP pracownicy FROM rodzaj_umowy = 0;" także wykazuje fundamentalne błędy, ponieważ DROP jest używane do usuwania obiektów bazy danych, a nie do operacji na danych. Użycie FROM jest również niepoprawne w kontekście DROP, co wskazuje na niewłaściwe zrozumienie składni SQL. Tego rodzaju pomyłki mogą prowadzić do poważnych konsekwencji, takich jak utrata danych czy zniszczenie struktury bazy danych, dlatego niezwykle istotne jest zrozumienie podstawowych różnic między poszczególnymi poleceniami oraz ich zastosowaniem w praktyce.
Pytanie 7

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

A. bezpośrednie połączenie kluczy obcych z obu tabel.
B. zaprojektowanie tabeli pomocniczej.
C. uporządkowanie przynajmniej jednej z tabel.
D. bezpośrednie połączenie kluczy podstawowych 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 8

Podaj dwa sposoby ochrony bazy danych Microsoft Access?

A. Ustalenie zabezpieczeń na poziomie użytkownika i sesji
B. Zaszyfrowanie pliku bazy danych oraz wiadomości SMS z kodem autoryzacyjnym
C. Funkcje anonimowe oraz ustawienie hasła do bazy danych
D. Ustalenie hasła do otwarcia bazy danych oraz zabezpieczeń na poziomie użytkownika
Zabezpieczenie bazy danych Microsoft Access jest kluczowym procesem, który ma na celu ochronę danych przed nieautoryzowanym dostępem oraz zapewnienie ich integralności. Ustalenie hasła do otwarcia bazy danych to pierwszy krok w kierunku zabezpieczenia. Pozwala to na ograniczenie dostępu tylko do osób, które znają hasło, co jest fundamentalnym środkiem ochrony informacji w systemach informatycznych. Dodatkowo, zabezpieczenia na poziomie użytkownika umożliwiają różnicowanie uprawnień dla poszczególnych użytkowników. Można przydzielać różne poziomy dostępu, co minimalizuje ryzyko, że niepowołane osoby będą mogły wprowadzać zmiany w bazie danych. Ważne jest również, aby stosować najlepsze praktyki związane z bezpieczeństwem, takie jak regularna aktualizacja haseł oraz audyty dostępu. Utrzymanie zgodności z międzynarodowymi standardami, takimi jak ISO/IEC 27001, może również pomóc w identyfikacji luk w zabezpieczeniach oraz w implementacji odpowiednich procedur ochrony danych. W codziennym użytkowaniu, skuteczne wdrożenie tych zabezpieczeń pozytywnie wpływa na bezpieczeństwo danych oraz ochronę prywatności użytkowników.
Pytanie 9

Tabela Pracownicy zawiera informacje na temat pracowników różnych działów, co jest zaznaczone przez pole liczbowe dzial. Z racji tego, że zazwyczaj kwerendy dotyczą tylko działu 2, można uprościć zapytania do tej tabeli, tworząc wirtualną tabelę o nazwie Prac_dzial2 przy użyciu zapytania

A. CREATE VIEW Prac_dzial2 AS SELECT * FROM Pracownicy WHERE dzial=2;
B. CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;
C. VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;
D. VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2;
Wybór odpowiedzi, która nie zawiera pełnej składni SQL, prowadzi do nieporozumień w zrozumieniu, jak działa tworzenie widoków w bazach danych. Odpowiedzi takie jak 'CREATE VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;' są błędne, ponieważ użycie słowa kluczowego 'FROM' jest niewłaściwe w kontekście definicji widoku. W standardowym SQL używa się 'AS' do określenia zapytania, które definiuje widok, co jest kluczowe dla poprawnego przetwarzania zapytania przez silnik bazy danych. Z kolei odpowiedzi, które zaczynają się od 'VIEW', takie jak 'VIEW Prac_dzial2 FROM Pracownicy WHERE dzial=2;' oraz 'VIEW Prac_dzial2 SELECT FROM Pracownicy WHERE dzial=2;', są całkowicie niepoprawne, ponieważ w SQL nie istnieje polecenie 'VIEW' jako samodzielne polecenie do tworzenia widoków. To może prowadzić do mylnego przekonania, że komendy SQL są bardziej elastyczne w kwestii składni, co nie jest zgodne z rzeczywistością. Użytkownicy powinni zawsze odnosić się do dokumentacji SQL oraz standardów, aby upewnić się, że struktura zapytań jest zgodna z wymaganiami danego systemu bazy danych. Rozumienie poprawnej składni i semantyki SQL jest podstawowym elementem efektywnego zarządzania bazami danych i kluczowym krokiem w procesie nauki oraz implementacji skutecznych rozwiązań bazodanowych.
Pytanie 10

Powszechnie stosowanym narzędziem SZBD do tworzenia zestawień danych, które można wydrukować, jest

A. kwerenda UPDATE
B. formularz
C. makro
D. raport
Kwerenda UPDATE jest używana do modyfikacji istniejących danych w bazie danych. Głównym celem kwerendy jest aktualizacja wartości pól w określonych rekordach, co jest zupełnie innym zadaniem niż generowanie zestawień danych. Użytkownicy, którzy mylnie uważają, że kwerenda UPDATE może służyć do tworzenia raportów, mogą nie rozumieć podstawowego podziału funkcji w systemach bazodanowych. Z kolei formularz jest interfejsem użytkownika, który umożliwia wprowadzanie danych do bazy, ale nie jest narzędziem do generowania zestawień, co sprawia, że jego zastosowanie jest także niewłaściwe w kontekście tego pytania. Makro, z drugiej strony, to zestaw instrukcji automatyzujących różne operacje w bazie danych, ale także nie jest dedykowane do tworzenia raportów. Kluczowym błędem myślowym jest utożsamianie narzędzi do modyfikacji lub wprowadzania danych z narzędziami do ich analizy i raportowania. Warto zrozumieć, że każdy z tych elementów ma swoje specyficzne zastosowanie w systemach zarządzania bazami danych, a ich pomylenie może prowadzić do nieskutecznego wykorzystania zasobów oraz obniżenia jakości analizy danych.
Pytanie 11

Aby wprowadzić dane do bazy przy użyciu polecenia PHP, konieczne jest przekazanie do jego parametrów

A. NULL w $zm1, aby baza mogła zapisać kod błędu i zapytanie SELECT w $zm2
B. identyfikator połączenia z bazą danych w $zm1 i zapytanie INSERT INTO w $zm2
C. id wiersza w $zm1 i zapytanie INSERT INTO w $zm2
D. identyfikator połączenia z bazą danych w $zm1 i zapytanie SELECT w $zm2
Wybór innych odpowiedzi wskazuje na pewne nieporozumienia dotyczące funkcji mysqli_query oraz sposobu operowania na bazach danych w PHP. Przykładowo, sugerowanie, że w $zm1 powinno być id wiersza, jest błędne, ponieważ w tym kontekście nie przekazujemy konkretnego rekordu, lecz identyfikator połączenia. Również pomysł, aby używać zapytania SELECT w $zm2, nie jest właściwy, ponieważ SELECT służy do odczytu danych, a nie do ich wstawiania. W kontekście baz danych, każde polecenie ma swoje przeznaczenie i powinno być używane zgodnie z intencją. Użycie NULL w miejscu identyfikatora połączenia jest także mylnym posunięciem, ponieważ nazwa ta odnosi się do zasobów, które muszą być zaawansowane do działania. Wszelkie próby wstawiania danych bez otwartego połączenia z bazą danych zakończą się błędem. Zrozumienie tych zasad jest kluczowe dla każdego programisty, aby móc poprawnie i efektywnie zarządzać bazami danych, co jest podstawą wielu aplikacji internetowych. Ignorowanie tej wiedzy może prowadzić nie tylko do błędów w działaniu aplikacji, ale również do poważnych luk bezpieczeństwa.
Pytanie 12

Przedstawiony kod PHP nawiązuje połączenie z serwerem bazy danych. Jakiego typu operacje powinny się znaleźć w instrukcji warunkowej w miejscu trzech kropek?
$db = mysqli_connect("localhost", "root", "qwerty", "baza1");
if (!$db) {
...
}

A. Obsługa błędu połączenia
B. Informacja o udanym połączeniu z bazą
C. Obsługa danych uzyskanych z bazy
D. Zamknięcie połączenia z bazą danych
Zamknięcie bazy danych w kontekście nieudanego połączenia jest koncepcją, która nie ma sensu. Jeśli połączenie się nie uda, to nie ma nawet nawiązanej sesji, która mogłaby być zamknięta. Połączenie z bazą danych powinno być zamykane tylko w momencie, gdy zostało nawiązane i jest już niepotrzebne, a nie w przypadku, gdy wystąpił błąd w trakcie łączenia. Komunikat o pomyślnym połączeniu także nie ma zastosowania w tej sytuacji, ponieważ, skoro połączenie się nie udało, nie ma podstaw do informowania użytkownika o jego powodzeniu. Obsługa danych pobranych z bazy również nie ma miejsca, jeśli połączenie nie zostało ustanowione, co czyni te odpowiedzi błędnymi. Właściwe podejście w takich sytuacjach to zawsze najpierw sprawdzenie, czy połączenie zostało nawiązane, a następnie działania w przypadku usunięcia błędu. Ignorowanie tej zasady może prowadzić do nieprzewidzianych zachowań aplikacji, a nawet do wycieków danych lub awarii serwerów.
Pytanie 13

Z tabel Klienci oraz Uslugi należy wyodrębnić tylko imiona klientów oraz odpowiadające im nazwy usług, które kosztują więcej niż 10 zł. Kwerenda uzyskująca te informacje ma formę

Ilustracja do pytania
A. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id
B. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = uslugi_id WHERE cena > 10
C. SELECT imie, nazwa FROM klienci, uslugi WHERE cena < 10
D. SELECT imie, nazwa FROM klienci JOIN uslugi ON uslugi.id = klienci.id
Pozostałe odpowiedzi zawierają istotne błędy w składni SQL oraz w interpretacji relacji między tabelami w bazie danych. Odpowiedź używająca WHERE cena < 10 jest błędna, ponieważ warunek ten wybiera usługi tańsze niż 10 zł, co jest sprzeczne z wymogami zadania. Innym błędem jest użycie niepoprawnego połączenia ON bez odpowiedniego dopasowania kluczy. Użycie klauzuli JOIN bez precyzyjnego określenia relacji, jak w przypadku ON uslugi.id = klienci.id, nie odzwierciedla rzeczywistego związku danych, co prowadzi do błędów logicznych w wynikach. Prawidłowe korzystanie z JOIN wymaga zrozumienia struktury bazy danych oraz relacji między tabelami. Właściwe połączanie tabel z wykorzystaniem klucza obcego jest kluczową praktyką, która zapewnia integralność danych i optymalizację zapytań. Ponadto, brak zastosowania warunków filtracyjnych lub nieodpowiednie ich użycie prowadzi do zwracania niekompletnych lub niepoprawnych danych. Wiedza o strukturze bazy danych oraz umiejętność stosowania poprawnych zapytań SQL są niezbędne dla osób zajmujących się projektowaniem i zarządzaniem bazami danych. Praktyczne doświadczenie w stosowaniu tych umiejętności jest kluczowe dla zapewnienia skuteczności oraz wydajności operacji w bazach danych. Poprawne zapytania są podstawą każdej operacji bazodanowej, zarówno w kontekście codziennych operacji, jak i skomplikowanych analiz danych.
Pytanie 14

Który typ danych SQL należy użyć, jako optymalny, do zapisania numeru PESEL?

A. FLOAT(11)
B. TINYINT
C. BLOB
D. CHAR(11)
Poprawny wybór to CHAR(11), ponieważ numer PESEL nie jest liczbą w sensie matematycznym, tylko identyfikatorem tekstowym złożonym z 11 znaków. W praktyce nigdy nie wykonujemy na PESEL‑u operacji arytmetycznych (dodawanie, odejmowanie, mnożenie), więc trzymanie go w typie numerycznym nie ma sensu i zwykle tylko komplikuje życie. Z punktu widzenia projektowania baz danych przyjmuje się dobrą praktykę: wszystkie identyfikatory, które mają stałą długość i mogą zaczynać się od zera, zapisujemy w typie znakowym o stałej długości, czyli właśnie CHAR(n). Dzięki CHAR(11) mamy gwarancję, że w każdej komórce kolumny PESEL będzie dokładnie 11 znaków. Silnik bazy danych może to łatwo sprawdzić, co pomaga w walidacji danych i porządku w tabeli. Nie zgubią się też zera wiodące, które przy typach liczbowych potrafią zniknąć. Moim zdaniem, szczególnie w systemach produkcyjnych (np. system kadrowy, rejestr pacjentów, e‑sklep z weryfikacją danych klienta), taki zapis jest po prostu najbezpieczniejszy i najbardziej przewidywalny. W wielu firmowych standardach programistycznych jest wręcz zapisane wprost: PESEL, NIP, REGON, numery dokumentów, numery kart, kody pocztowe – zawsze trzymamy jako CHAR/VARCHAR, a nie jako INT czy inne typy numeryczne. Dodatkowo CHAR(11) jest efektywny wydajnościowo dla stałej długości: porównywanie, indeksowanie, sortowanie takiej kolumny jest proste dla silnika SQL. W razie potrzeby możesz też na takim polu założyć indeks unikalny (UNIQUE), żeby baza nie dopuściła do wprowadzenia dwóch takich samych PESEL‑i. To jest właśnie praktyczne połączenie typów danych z zasadami integralności i jakości danych, których oczekuje się w prawidłowo zaprojektowanych bazach.
Pytanie 15

Baza danych zawiera tabelę artykuły z kolumnami: nazwa, typ, producent, cena. Aby wypisać wszystkie nazwy artykułów jedynie typu pralka, których cena mieści się w zakresie od 1000 PLN do 1500 PLN, należy użyć zapytania

A. SELECT nazwa FROM artykuly WHERE typ="pralka" OR cena BETWEEN 1000 OR 1500
B. SELECT nazwa FROM artykuly WHERE typ="pralka" OR cena BETWEEN 1000 AND 1500
C. SELECT nazwa FROM artykuly WHERE typ="pralka" AND cena BETWEEN 1000 AND 1500
D. SELECT nazwa FROM artykuly WHERE typ="pralka" AND cena FROM 1000 TO 1500
Błędne odpowiedzi opierają się na nieporozumieniach dotyczących składni SQL oraz logicznych błędach w użyciu operatorów. W pierwszym przypadku, użycie 'cena FROM 1000 TO 1500' jest niepoprawne, ponieważ składnia SQL nie wspiera takiego zapisu. Poprawne podejście wymagałoby użycia operatora 'BETWEEN'. Drugie podejście używa operatora 'OR', co skutkuje zwróceniem artykułów, które są typu 'pralka' lub mają cenę w podanym przedziale, a to jest niezgodne z wymaganiem, które wymaga obu warunków jednocześnie. Trzecia opcja z 'BETWEEN' jest bliska poprawnej, ale przez użycie operatora 'OR' dla ceny również nie spełnia wymagań. Ostatnia odpowiedź, która stosuje 'OR' w kontekście ceny, jest błędna, ponieważ nie można używać 'OR' w ten sposób przy definiowaniu zakresu. Typowe błędy myślowe, które mogą prowadzić do takich nieporozumień, obejmują mylenie operatorów logicznych oraz niewłaściwe rozumienie składni SQL. W rezultacie, kluczowe jest zrozumienie, że do filtrowania danych używamy 'AND' dla warunków, które muszą być spełnione jednocześnie oraz 'BETWEEN' do określenia zakresu wartości.
Pytanie 16

W programie Microsoft Access metodą zabezpieczającą dostęp do danych związanych z tabelą oraz kwerendą jest

A. ustalanie przestrzeni tabel
B. przydzielenie uprawnień
C. użycie makr
D. nałożenie limitów przestrzeni dyskowej
Stosowanie makr w Microsoft Access to funkcjonalność, która umożliwia automatyzację procesów, ale nie stanowi bezpośredniego mechanizmu zabezpieczeń dostępu do danych. Makra pozwalają na tworzenie sekwencji działań, które ułatwiają użytkownikom interakcję z bazą danych, lecz ich użycie nie ma na celu ograniczenia dostępu do określonych zasobów. Z kolei określanie przestrzeni tabel dotyczy zarządzania strukturą bazy danych, a nie zabezpieczeń. Przestrzeń tabel odnosi się do alokacji pamięci dla danych i nie wpływa na kontrolę dostępu, co czyni tę odpowiedź nieadekwatną w kontekście pytania. Wprowadzenie limitów przestrzeni dyskowej również nie jest metodą zabezpieczającą dostęp do danych, ale raczej sposobem na zarządzanie zasobami serwera bazy danych. Limity te mogą mieć znaczenie w kontekście zarządzania kosztami operacyjnymi, jednak nie mają zastosowania w ochronie danych przed nieautoryzowanym dostępem. Dlatego przypisanie uprawnień stanowi istotny element polityki bezpieczeństwa, podczas gdy pozostałe odpowiedzi są mniej związane z tematem zabezpieczenia dostępu do danych.
Pytanie 17

Tabela samochody zawiera dane przedstawione poniżej:

idklasa_idmarkamodelrocznik
11fordka2017
22seattoledo2016
33opelzafira2018
42fiat500X2018
53opelinsignia2017
Wydając zamieszczone zapytanie SQL, jakie dane zostaną zwrócone:
SELECT model FROM samochody WHERE rocznik > 2017 AND marka = "opel";
A. zafira; insignia
B. zafira
C. opel zafira; opel insignia
D. opel zafira
Poprawna odpowiedź to 'zafira', ponieważ zapytanie SQL odnosi się do modelu samochodu marki 'opel', którego rocznik jest większy niż 2017. Z analizy danych w tabeli wynika, że tylko model 'opel zafira' (z rocznika 2018) spełnia te warunki. Odpowiedzi 'opel zafira', 'zafira; insignia', 'opel zafira; opel insignia' zawierają dodatkowe informacje, które nie są zgodne z wymaganiami zapytania. Dobrym przykładem zastosowania takiej analizy jest filtrowanie danych w bazach danych, co jest kluczowym procesem w zarządzaniu informacjami. Efektywne posługiwanie się zapytaniami SQL to umiejętność istotna w pracy każdego analityka danych, programisty, czy specjalisty w zakresie baz danych, ponieważ pozwala na wyciąganie precyzyjnych informacji zgodnych z wymaganiami biznesowymi.
Pytanie 18

Podczas tworzenia tabeli, do pola, które ma automatycznie przyjmować następne liczby całkowite, należy wprowadzić atrybut

A. NOT NULL
B. AUTO_INCREMENT
C. PRIMARY KEY
D. NULL
Właściwość AUTO_INCREMENT w bazach danych, takich jak MySQL, jest kluczowym elementem, który umożliwia automatyczne zwiększanie wartości liczbowej w polu, co jest szczególnie przydatne przy tworzeniu identyfikatorów dla rekordów. Gdy pole jest oznaczone jako AUTO_INCREMENT, każda nowa wartość wstawiana do tego pola jest automatycznie zwiększana o jeden w porównaniu do ostatniej wprowadzonej wartości. Na przykład, jeśli ostatni rekord miał identyfikator 5, to nowy rekord otrzyma identyfikator 6. Umożliwia to uniknięcie ręcznego zarządzania numeracją identyfikatorów i minimalizuje ryzyko ich powtórzenia, co jest kluczowe dla zachowania integralności danych. Praktycznie, stosowanie AUTO_INCREMENT w tabelach, które przechowują dane o użytkownikach, zamówieniach czy transakcjach, zapewnia wydajność oraz spójność w zarządzaniu unikalnymi identyfikatorami. Dobrą praktyką jest również łączenie AUTO_INCREMENT z PRIMARY KEY, aby zapewnić, że każdy rekord w tabeli jest unikalny i łatwy do identyfikacji.
Pytanie 19

Integralność encji w systemie baz danych będzie zapewniona, jeśli między innymi

A. dla każdej tabeli zostanie ustanowiony klucz główny
B. każda kolumna otrzyma zdefiniowany typ danych
C. każdy klucz główny będzie miał odpowiadający mu klucz obcy w innej tabeli
D. klucz główny zawsze będzie liczbą całkowitą
Inne odpowiedzi na to pytanie wskazują na powszechnie występujące błędne przekonania dotyczące integralności encji. Twierdzenie, że klucz główny musi być zawsze liczbą całkowitą, jest błędne, ponieważ klucz główny może przyjmować różne typy danych, takie jak ciągi znaków, co może być użyteczne w przypadku identyfikatorów alfanumerycznych. Przypisanie typu danych dla każdej kolumny jest ważne, ale samo w sobie nie gwarantuje integralności encji, ponieważ nie eliminuje problemu duplikacji wartości, co jest kluczowe dla kluczy głównych. Ponadto, sugerowanie, że każdy klucz główny powinien mieć odpowiadający klucz obcy w innej tabeli, prowadzi do nieporozumienia, ponieważ klucz główny nie musi być powiązany z kluczem obcym, jeśli tabela nie jest częścią relacji. Klucze obce są używane do tworzenia relacji między tabelami, ale nie są wymogiem dla każdej tabeli. W praktyce, klucz główny jest podstawowym wymogiem dla spójności danych w tabelach, natomiast inne aspekty, takie jak typ danych czy relacje między tabelami, są uzupełniające i nie mogą być traktowane jako równorzędne do roli klucza głównego w zapewnieniu integralności encji.
Pytanie 20

W relacyjnych bazach danych dane zapisywane są w

A. listach.
B. wektorach.
C. kolejkach.
D. tabelach.
W modelu relacyjnych baz danych kluczowe jest zrozumienie, że podstawową strukturą przechowywania danych jest tabela, a nie ogólne pojęcia typu lista, kolejka czy wektor. Te inne struktury występują częściej w programowaniu, w kodzie aplikacji, a nie jako główny element fizycznej organizacji danych w systemach takich jak MySQL czy PostgreSQL. Lista kojarzy się z prostym zbiorem elementów zapisanych jeden po drugim, bez sztywnych kolumn i typów danych. W kodzie możemy mieć listę obiektów użytkowników, ale kiedy te dane trafiają do relacyjnej bazy, lądują w tabeli z jasno zdefiniowanymi kolumnami. Baza danych musi zapewnić integralność, indeksy, klucze, możliwość złożonych zapytań SQL – zwykła lista tego nie ogarnia. Kolejka z kolei to struktura typu FIFO, używana np. w systemach kolejkowania zadań, komunikatach między serwisami, przetwarzaniu asynchronicznym. W bazach danych można co najwyżej zaimplementować logikę działania kolejki na tabeli (np. kolumna status, czas dodania, pobieranie najstarszego zadania), ale fizycznie to dalej jest tabela, a nie specjalny typ „kolejka” w sensie modelu relacyjnego. Wektor natomiast to pojęcie bardziej z matematyki i programowania niskopoziomowego, czasem używane jako tablica dynamiczna. W silnikach baz danych oczywiście istnieją wewnętrzne struktury w pamięci, jakieś tablice, strony danych, indeksy, ale użytkownik pracuje z tabelami, relacjami, widokami. Typowym błędem myślowym jest przenoszenie pojęć z programowania obiektowego czy struktur danych 1:1 do świata relacyjnych baz. W praktyce, niezależnie od tego, czy obsługujesz system CRM, sklep internetowy czy prosty blog, zawsze kończysz z tabelami: użytkownicy, posty, komentarze, produkty itd. Reszta struktur, takich jak listy czy kolejki, to bardziej narzędzia w warstwie aplikacji, nie fundament modelu relacyjnego. Dlatego przy pytaniach o relacyjne bazy danych warto automatycznie myśleć o tabelach, kolumnach, wierszach i kluczach, bo to jest absolutna podstawa pracy z SQL.
Pytanie 21

Przedstawione zapytanie MySQL ma za zadanie

ALTER TABLE ksiazki MODIFY tytul VARCHAR(100) NOT NULL;
A. dodać do tabeli ksiazki kolumnę tytul.
B. usunąć kolumnę tytul z tabeli ksiazki.
C. zmienić nazwę kolumny w tabeli ksiazki.
D. zmienić typ kolumny tytul w tabeli ksiazki.
Twoja odpowiedź dobrze odczytuje składnię polecenia ALTER TABLE w MySQL. Instrukcja: ALTER TABLE ksiazki MODIFY tytul VARCHAR(100) NOT NULL; służy do zmiany definicji już istniejącej kolumny tytul w tabeli ksiazki. Słowo kluczowe MODIFY w MySQL oznacza właśnie modyfikację typu danych i atrybutów kolumny, bez zmiany jej nazwy. W tym przykładzie kolumna tytul zostaje ustawiona jako typ VARCHAR o długości 100 znaków oraz z ograniczeniem NOT NULL, czyli pole nie może przyjmować wartości pustej. Moim zdaniem to jedno z częstszych poleceń przy rozwijaniu aplikacji, bo schemat bazy prawie nigdy nie jest idealny od początku. W praktyce takie polecenie stosuje się np. gdy początkowo założyliśmy zbyt krótki tytuł, np. VARCHAR(50), i po czasie okazuje się, że część danych się nie mieści. Zamiast tworzyć nową kolumnę, zmieniamy typ i parametry istniejącej. Dobra praktyka przy pracy z ALTER TABLE to zawsze sprawdzić, czy modyfikacja nie spowoduje utraty danych, np. przy skracaniu długości VARCHAR. W środowiskach produkcyjnych często robi się to najpierw na kopii bazy lub w środowisku testowym, bo zmiany w strukturze tabel potrafią blokować tabelę i wpływać na wydajność. Warto też wiedzieć, że w MySQL do zmiany nazwy kolumny używa się ALTER TABLE ... CHANGE stara_nazwa nowa_nazwa typ, a do dodania nowej kolumny słowa kluczowego ADD. Dzięki rozróżnieniu MODIFY/CHANGE/ADD/ DROP łatwiej czyta się skrypty migracyjne i utrzymuje spójny model danych. Dobrą praktyką jest też trzymanie wszystkich takich zmian w repozytorium razem z kodem aplikacji, żeby zawsze było wiadomo, jaka wersja schematu jest aktualna.
Pytanie 22

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

A. utworzenie użytkownika
B. pokazanie danych o istniejącym użytkowniku
C. stworznie nowego użytkownika oraz przydzielenie mu uprawnień do bazy
D. zmianę hasła dla już istniejącego użytkownika
Odpowiedzi sugerujące utworzenie użytkownika i nadanie mu praw do bazy lub wyświetlenie informacji o istniejącym użytkowniku nie są poprawne, ponieważ CREATE USER służy jedynie do definicji konta użytkownika, a nie do przypisywania mu uprawnień. W rzeczywistości, aby przyznać dostęp do bazy danych, należy użyć osobnego polecenia GRANT, które zarządza uprawnieniami dla już istniejących użytkowników. Z tego powodu pomylenie tych dwóch poleceń może prowadzić do nieefektywnego zarządzania użytkownikami w systemie bazy danych. Innym błędnym podejściem jest przypisanie funkcji wyświetlania informacji o użytkownikach do CREATE USER. W MySQL do uzyskania takich informacji wykorzystuje się zapytania do systemowych tabel informacyjnych lub polecenie SHOW GRANTS, które pozwala na przeglądanie przyznanych uprawnień dla konkretnego użytkownika. Z kolei zmiana hasła istniejącego użytkownika z wykorzystaniem CREATE USER jest również pomyłką, gdyż do takiej operacji należy używać polecenia ALTER USER, co pozwala na aktualizację danych logowania bez konieczności usuwania i ponownego tworzenia konta. Błędy te wynikają często z niepełnego zrozumienia funkcji poszczególnych poleceń SQL, co może prowadzić do nieefektywnego zarządzania bazą danych oraz zwiększonego ryzyka bezpieczeństwa.
Pytanie 23

W zaprezentowanym fragmencie zapytania SQL, instrukcja SELECT ma za zadanie zwrócić

SELECT COUNT(wartosc) FROM ...
A. liczby rekordów
B. suma w kolumnie wartosc
C. średniej wartości tabeli
D. średniej w kolumnie wartosc
Komenda SELECT COUNT w języku SQL jest używana do zwracania liczby wierszy w rezultacie zapytania. Użycie funkcji COUNT z nazwą kolumny, jak w przykładzie SELECT COUNT(wartosc), pozwala policzyć wszystkie niepuste wartości w danej kolumnie wartosc w tabeli. Jest to przydatne w przypadkach, gdy chcemy zrozumieć, ile danych spełnia określone kryteria, lub gdy interesuje nas liczba wierszy zawierających wartości w konkretnej kolumnie. Funkcja COUNT jest jedną z podstawowych funkcji agregujących w SQL, co oznacza, że podsumowuje dane w określony sposób. Stosowanie tej funkcji jest zgodne z najlepszymi praktykami w projektowaniu baz danych, gdzie często potrzebujemy analizować dane w sposób ilościowy. Przykładowo, jeśli prowadzimy bazę danych klientów, możemy użyć SELECT COUNT(id) FROM klienci, aby dowiedzieć się, ilu mamy zarejestrowanych klientów. Ta funkcja jest także kluczowym elementem w optymalizacji zapytań, ponieważ pozwala na szybkie uzyskanie informacji o liczbie rekordów bez konieczności przetwarzania wszystkich danych z tabeli. Zrozumienie działania COUNT i jego zastosowań jest kluczowe dla efektywnego przetwarzania danych i tworzenia wydajnych zapytań w języku SQL.
Pytanie 24

Wartość atrybutu w tabeli, który pełni rolę klucza głównego

A. jest używana do szyfrowania zawartości tabeli
B. może przyjmować wartość null (NULL)
C. nigdy nie jest innego typu niż numeryczny
D. musi być unikalna
Rozumienie, co to jest klucz podstawowy, jest mega istotne, zwłaszcza gdy projektujesz bazy danych. Klucz podstawowy nie ma nic wspólnego z tym, jak szyfrujesz dane w tabeli. Szyfrowanie dotyczy bardziej bezpieczeństwa informacji, a klucz podstawowy to sposób na identyfikację rekordów. Warto też wiedzieć, że klucz podstawowy nie musi być zawsze numeryczny. Może być tekstowy czy alfanumeryczny, w zależności od tego, jak go użyjesz. Na przykład, w niektórych systemach identyfikatory mogą być ciągami znaków, co jest ważne, kiedy integrujesz różne systemy. Tak czy siak, klucz podstawowy nigdy nie może mieć wartości pustej (NULL), bo to by wszystko zrujnowało. Jeśli ktoś myśli, że klucz podstawowy może być pusty, to może się narazić na spore kłopoty. Klucz podstawowy to nie tylko identyfikacja, ale też ważny element, który pomaga w normalizacji danych, co z kolei wpływa na ich spójność. Dlatego warto znać te zasady, bo mają duży wpływ na to, jak działają bazy danych.
Pytanie 25

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. błędna składnia polecenia CREATE USER
C. istnienie użytkownika anna w bazie danych
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 26

Każde informacje, które odnoszą się do innych informacji, określane są jako

A. databus.
B. metadata.
C. metalanguage.
D. markup language.
Odpowiedzi takie jak 'databus', 'metalanguage' oraz 'markup language' nie są odpowiednie w kontekście pytania o dane opisujące inne dane. Termin 'databus' odnosi się do architektury komunikacyjnej, która umożliwia przesyłanie danych pomiędzy różnymi aplikacjami lub systemami, ale nie odnosi się do opisu danych. 'Metalanguage' z kolei to język używany do opisu innego języka, co również nie pasuje do definicji metadanych. Użycie metalanguage może być przydatne w kontekście analizy języków programowania czy gramatyk formalnych, jednak nie wiąże się bezpośrednio z przekazywaniem informacji o danych. Z kolei 'markup language' odnosi się do języków znaczników, takich jak HTML czy XML, które służą do formatowania tekstu i strukturyzacji dokumentów, a nie do opisywania danych. Chociaż te języki mogą wykorzystywać metadane do opisu swojej struktury, same w sobie nie spełniają funkcji metadanych. Często mylnie uważa się, że wszystkie te terminy są ze sobą związane, jednak kluczowa różnica polega na tym, że metadane to informacje o danych, podczas gdy pozostałe odpowiedzi dotyczą różnych aspektów technologii informacyjnej i komunikacyjnej. Prawidłowe zrozumienie tych terminów jest kluczowe dla efektywnego zarządzania danymi oraz ich analizy w kontekście nowoczesnych rozwiązań IT.
Pytanie 27

W relacyjnych bazach danych, gdy dwie tabele są ze sobą powiązane przez ich klucze główne, mamy do czynienia z relacją

A. 1 .. 1
B. n .. n
C. 1 .. n
D. n .. 1
Relacje 1 .. n, n .. 1 oraz n .. n wskazują na bardziej złożone powiązania między tabelami w relacyjnych bazach danych, które nie są adekwatne w kontekście kluczy głównych. W przypadku relacji 1 .. n, jeden rekord w tabeli A może mieć wiele odpowiadających mu rekordów w tabeli B, co prowadzi do sytuacji, w której dane są powielane w tabeli B. Typowym błędem jest mylenie sytuacji, w której każdy rekord w tabeli A jest powiązany z wieloma rekordami w tabeli B, co prowadzi do wniosku o relacji 1 .. n. Z kolei relacja n .. 1 oznacza, że wiele rekordów w tabeli A odpowiada jednemu rekordowi w tabeli B, co również nie jest zgodne z definicją relacji 1 .. 1. Co więcej, relacja n .. n sugeruje, że wiele rekordów w tabeli A może być powiązanych z wieloma rekordami w tabeli B, co prowadzi do dużej złożoności i trudności w utrzymaniu integralności danych w bazie. Zrozumienie tych konceptów jest kluczowe dla modelowania danych, dlatego ważne jest, aby unikać nadmiernego uproszczenia lub generalizacji relacji, co często prowadzi do błędnych wniosków w projektowaniu bazy danych.
Pytanie 28

Integralność referencyjna w relacyjnych bazach danych oznacza, że

A. wartość klucza głównego oraz klucza obcego nie może być pusta
B. wartość klucza obcego w danej tabeli musi być albo równa wartości klucza głównego w związanej z nią tabeli albo równa wartości NULL
C. klucz główny lub klucz obcy nie mogą zawierać wartości NULL
D. każdemu kluczowi głównemu przyporządkowany jest dokładnie jeden klucz obcy w powiązanych tabelach
Integralność referencyjna jest kluczowym pojęciem w modelu relacyjnych baz danych, które zapewnia spójność i wiarygodność danych. Odpowiedź dotycząca wartości klucza obcego w danej tabeli, która musi być równa wartości klucza głównego w powiązanej tabeli lub NULL, jest zgodna z zasadami projektowania baz danych. Klucz obcy stanowi odniesienie do klucza głównego w innej tabeli, co umożliwia utrzymanie relacji między danymi. Na przykład, w bazie danych dotyczącej szkoły, tabela 'Uczniowie' może mieć kolumnę 'KlasaID', która jest kluczem obcym odnoszącym się do 'KlasaID' w tabeli 'Klasy'. Integralność referencyjna zapewnia, że każdy uczeń jest przypisany do istniejącej klasy, a jeśli uczeń nie jest przypisany do żadnej klasy, wartość ta może być NULL. Praktyczne zastosowanie tej zasady pozwala uniknąć błędów, takich jak pozostawienie ucznia bez przypisania do klasy, co mogłoby prowadzić do nieporozumień w analizach danych. Zgodnie z dobrymi praktykami, integralność referencyjna powinna być implementowana na poziomie bazy danych, aby automatycznie wymuszać te zasady, co zwiększa jakość i spójność gromadzonych danych.
Pytanie 29

Przedstawiony fragment kodu ilustruje działanie

Ilustracja do pytania
A. wykorzystania zdefiniowanej procedury lub funkcji
B. prezentacji danych
C. pozyskiwania danych
D. podjęcia decyzji
Blok przedstawiony na rysunku to romb, który w diagramach przepływu danych reprezentuje punkt decyzyjny. W kontekście programowania i modelowania procesów biznesowych, zastosowanie takich punktów jest kluczowe dla podejmowania decyzji na podstawie warunków logicznych. Na przykład, w algorytmach komputerowych romb służy do określenia, którą ścieżką proces powinien się dalej przemieszczać, zależnie od spełnienia określonych warunków. W praktyce, może to być na przykład wybór między dwiema różnymi akcjami, jak wysłanie e-maila lub zapis do bazy danych w zależności od wartości wprowadzonej przez użytkownika. Zastosowanie rombu zgodnie z zasadami BPMN (Business Process Model and Notation) oraz UML (Unified Modeling Language) pozwala na precyzyjne i czytelne modelowanie złożonych procesów, co jest kluczowe w projektowaniu systemów informatycznych i optymalizacji procesów biznesowych.
Pytanie 30

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

A. formularz
B. makropolecenie
C. raport
D. relację
Raport w kontekście baz danych to coś, co naprawdę pomaga w uporządkowanej prezentacji danych. Dzięki niemu możemy pokazać informacje w taki sposób, żeby było to zrozumiałe i zgodne z tym, czego potrzebujemy. Raporty to świetne narzędzie do zbierania danych, ich analizy i wizualizacji, co jest bardzo ważne w biznesie. Na przykład, można za ich pomocą stworzyć zestawienie sprzedaży za dany okres, porównać finanse różnych działów firmy albo sprawdzić, jak skuteczne były kampanie marketingowe. W praktyce często korzysta się z takich raportów w programach jak Microsoft Access, gdzie można wybrać źródło danych, odpowiednie pola i ustawić filtry. To wszystko po to, żeby stworzyć dokument, który jasno przedstawia wyniki analizy. Warto pamiętać, że tworzenie raportów powinno opierać się na dobrych zasadach, takich jak czytelność i estetyka, a także dostosowanie do potrzeb użytkownika, bo to naprawdę się liczy, jeśli chodzi o UX.
Pytanie 31

Do tabeli pracownicy wpisano rekordy. Co zostanie wyświetlone po uruchomieniu kwerendy SQL SELECT podanej poniżej?

SELECT SUM(pensja) FROM pracownicy WHERE pensja > 4000;
idimienazwiskopensja
1AnnaKowalska3400
2MonikaNowak1300
3EwelinaNowakowska2600
4AnnaPrzybylska4600
5MariaKowal2200
6EwaNowacka5400
A. Wartość 5400, czyli najwyższa pensja pracownika.
B. Wartość 10000, czyli suma pensji pracownika o id=4 oraz o id=6.
C. Dwie wartości: 4600 i 5400, jako pensje pracowników wyższe niż 4000.
D. Wartość 19500, czyli suma wszystkich pensji pracowników.
Niestety, twoja odpowiedź nie jest poprawna. W przypadku tej konkretnej kwerendy, została użyta funkcja agregująca SUM(), która zwraca sumę wartości dla określonego zestawu wierszy, nie jednak wartości indywidualne. Dlatego odpowiedź mówiąca o wyświetleniu dwóch wartości jako pensje pracowników wyższych niż 4000 jest niepoprawna - kwerenda agregująca nie zwróci wartości indywidualnych. Odpowiedź mówiąca o wyświetleniu sumy wszystkich pensji pracowników jest również błędna, ponieważ w kwerendzie jest zastosowany warunek WHERE, który ogranicza zestaw danych do tych, gdzie pensja przekracza 4000. Wyświetlenie najwyższej pensji pracownika również nie jest poprawne, ponieważ nie została użyta funkcja MAX, która zwraca najwyższą wartość w zestawie. Kluczowe jest zrozumienie, jak działają różne operatory i funkcje w SQL i kiedy ich używać. W tym przypadku funkcja SUM() zastosowana do kolumny 'pensja' zwraca sumę pensji dla pracowników, którzy zarabiają więcej niż 4000.
Pytanie 32

Jakie uprawnienia będzie miał użytkownik jan po wykonaniu poniższych poleceń na bazie danych?

GRANT ALL PRIVILEGES ON klienci TO jan;
REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;
A. Będzie mógł zmieniać strukturę tabeli klienci.
B. Będzie mógł dodawać rekordy do tabeli klienci.
C. Będzie mógł eliminować rekordy z tabeli klienci.
D. Będzie mógł przeszukiwać dane w tabeli klienci.
Wybór odpowiedzi, że jan będzie mógł usuwać rekordy z tabeli klienci, jest błędny. Polecenie REVOKE SELECT, INSERT, UPDATE, DELETE nałożone na użytkownika jan oznacza, że pozbawiono go możliwości wykonywania operacji, które są kluczowe dla zarządzania danymi w tej tabeli. W praktyce, zasady przyznawania uprawnień w bazach danych wymagają, aby użytkownicy mieli określone uprawnienia do przeprowadzenia operacji na danych. Usuwanie rekordów jest operacją, która wymaga posiadania odpowiednich uprawnień, a ponieważ jan został pozbawiony uprawnienia DELETE, nie może on już usuwać żadnych danych z tabeli klienci. Podobnie, stwierdzenie, że jan będzie mógł wyszukiwać dane, również jest błędne, ponieważ uprawnienie SELECT zostało odjęte. W kontekście administracji bazą danych, kluczowe jest zrozumienie, że przyznawanie lub odbieranie uprawnień powinno być zgodne z zasadą najmniejszych uprawnień, co oznacza, że użytkownicy powinni mieć tylko te uprawnienia, które są niezbędne do wykonywania ich pracy. W tym przypadku jan ma pełne uprawnienia do zmiany struktury tabeli, ale nie ma żadnej możliwości interakcji z danymi. Zatem, odpowiedzi dotyczące możliwości wstawiania rekordów również są błędne, ponieważ uprawnienie INSERT zostało zabrane, co uniemożliwia janowi dodawanie nowych danych do tabeli. W związku z powyższym, wybór odpowiedzi na pytanie egzaminacyjne powinien opierać się na dokładnej analizie przyznanych uprawnień oraz ich wpływu na możliwości działania użytkowników w systemie baz danych.
Pytanie 33

Zastosowanie atrybutu NOT NULL dla kolumny jest konieczne w sytuacji, gdy

A. mamy do czynienia z kluczem podstawowym
B. definiujemy wszystkie pola o typie numerycznym
C. tworzymy definicję wszystkich pól tabeli
D. korzystamy z atrybutu DEFAULT
Nieprawidłowe odpowiedzi odzwierciedlają typowe błędne rozumienie działania atrybutu NOT NULL w kontekście tabel baz danych. W przypadku klucza podstawowego, jest to niezbędny warunek, aby zapewnić, że każdy wiersz w tabeli jest jednoznacznie identyfikowalny. Odpowiedzi sugerujące, że atrybut NOT NULL jest wymagany przy użyciu atrybutu DEFAULT, są mylące, ponieważ atrybut DEFAULT służy do ustalania wartości domyślnych dla kolumn, które mogą przyjmować wartość NULL. Użycie atrybutu DEFAULT wcale nie implikuje, że kolumna musi być oznaczona jako NOT NULL. Kolejna niepoprawna koncepcja dotyczy definicji wszystkich pól tabeli. Nie ma wymogu, aby wszystkie kolumny w tabeli były oznaczone jako NOT NULL; zależy to od specyficznych wymagań dotyczących danych w danej aplikacji. Ponadto, definicja wszystkich pól typu numerycznego jako NOT NULL również jest fałszywa, ponieważ pola numeryczne mogą być używane do reprezentacji wartości, które mogą być nieznane lub nieprzydzielone, co prowadziłoby do sytuacji, w której wartość NULL jest jak najbardziej uzasadniona. Zrozumienie tych różnic jest kluczowe dla efektywnego projektowania baz danych oraz zarządzania danymi w aplikacjach, co jest zgodne z najlepszymi praktykami w branży.
Pytanie 34

W języku SQL, dla dowolnych zbiorów danych w tabeli Uczniowie, aby uzyskać rekordy zawierające tylko uczennice o imieniu "Aleksandra", które urodziły się po roku "1998", należy sformułować zapytanie

A. SELECT * FROM Uczniowie WHERE imie ="Aleksandra" OR rok_urodzenia < "1998"
B. SELECT * FROM Uczniowie WHERE imie="Aleksandra" OR rok_urodzenia > "1998"
C. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia > "1998"
D. SELECT * FROM Uczniowie WHERE imie="Aleksandra" AND rok_urodzenia < "1998"
Pozostałe odpowiedzi niestety mają błędy w logice, co prowadzi do złych wyników. Jak używasz operatora OR, to istnieje szansa, że wyniki obejmą rekordy, które spełniają tylko jeden warunek, co nie pasuje do tego, co chciałeś uzyskać. Na przykład, zapytanie 'SELECT * FROM Uczniowie WHERE imie="Aleksandra" OR rok_urodzenia < "1998";' pokaże wszystkie Aleksandry, jak też wszystkie osoby urodzone przed 1998 rokiem, co jest kompletnie nie na miejscu, bo szukasz tylko tych urodzonych po 1998. Podobnie z użyciem operatora AND z warunkiem 'rok_urodzenia < "1998"', to także jest błędne, bo nie spełnia wymagań dotyczących urodzin po 1998 roku. Ważne jest, by operatorzy logiczni byli używani przemyślanie, żeby uniknąć niechcianych wyników. Często ludzie mylą AND z OR, co prowadzi do wniosków, które są dalekie od prawdy. W SQL musisz być precyzyjny w definiowaniu warunków, żeby wyniki pasowały do tego, co chcesz uzyskać.
Pytanie 35

Dana jest tabela ksiazki z polami: tytul, autor, cena (typu liczbowego). Aby kwerenda SELECT wybrała tylko tytuły, dla których cena jest mniejsza od 50 zł, należy zapisać

A. SELECT * FROM ksiazki WHERE cena < 50;
B. SELECT tytul FROM ksiazki WHERE cena < 50;
C. SELECT ksiazki FROM tytul WHERE cena < '50 zł';
D. SELECT tytul FROM ksiazki WHERE cena > '50 zł';
Prawidłowa odpowiedź wybiera dokładnie to, o co chodzi w treści zadania: tylko kolumnę tytul z tabeli ksiazki, ale tylko dla tych rekordów, gdzie cena jest mniejsza niż 50. Składnia SELECT tytul FROM ksiazki WHERE cena < 50; jest zgodna ze standardowym SQL i pokazuje dobrą praktykę – pobieramy tylko te dane, które są nam potrzebne, zamiast używać SELECT *. Dzięki temu zapytanie jest lżejsze, szybsze i czytelniejsze, co w większych projektach ma naprawdę duże znaczenie. Moim zdaniem warto zwrócić uwagę na kilka elementów. Po pierwsze, w klauzuli SELECT podajemy konkretne nazwy kolumn (tu: tytul), nie nazwę tabeli. Po drugie, w FROM podajemy dokładnie nazwę tabeli, z której korzystamy (ksiazki). Po trzecie, warunek WHERE cena < 50 poprawnie porównuje wartość liczbową, bo kolumna cena ma typ liczbowy, więc nie używamy tu cudzysłowów ani żadnych „zł” w środku. W praktyce podobny wzorzec stosuje się cały czas, np.: SELECT tytul, autor FROM ksiazki WHERE cena <= 30; żeby dostać tańsze książki, albo SELECT tytul FROM ksiazki WHERE cena BETWEEN 20 AND 40; gdy interesuje nas konkretny przedział. W profesjonalnych aplikacjach webowych taka precyzja w definiowaniu zapytań SQL jest podstawą: ułatwia optymalizację, indeksowanie kolumn (np. indeks na kolumnie cena przyspiesza filtrowanie w WHERE) i minimalizuje przesyłanie niepotrzebnych danych między bazą a aplikacją. Dobra praktyka jest też taka, żeby dostosowywać typy danych: skoro cena jest liczbą, to porównujemy ją z liczbą, bez jednostek, a formatowanie typu „50 zł” robimy później w warstwie prezentacji, np. w PHP, JavaScript albo w szablonach widoków.
Pytanie 36

Tabela filmy zawiera klucz główny id oraz klucz obcy rezyserID. Tabela reżyserzy posiada klucz główny id. Obie tabele są powiązane relacją jeden do wielu, gdzie strona reżyserzy jest po stronie jeden, a filmy po stronie wiele. Aby wykonać kwerendę SELECT łączącą tabele filmy i reżyserzy, należy użyć zapisu

A. ... filmy JOIN rezyserzy ON filmy.rezyserID=rezyserzy.filmyID ...
B. ... filmy JOIN rezyserzy ON filmy.id=rezyserzy.filmyID ...
C. ... filmy JOIN rezyserzy ON filmy.rezyserzyID=rezyserzy.id ...
D. ... filmy JOIN rezyserzy ON filmy.id=rezyserzy.id ...
Wybór niepoprawnej odpowiedzi może wynikać z nieporozumienia co do relacji między tabelami i ich kluczami. W pierwszej opcji, warunek łączenia jest błędny, ponieważ użyto 'filmy.id' zamiast 'filmy.rezyserID'. Klucz główny 'id' w tabeli 'filmy' nie jest powiązany z kluczem głównym w tabeli 'rezyserzy', co prowadzi do nieprawidłowego łączenia. W drugiej opcji, podobnie jak w pierwszej, jest błędne odniesienie, ponieważ 'filmy.filmyID' nie istnieje jako klucz w tabeli 'filmy', co skutkuje niezgodnością, ponieważ 'filmy' nie powinny mieć klucza o takiej nazwie. Rozważając kolejną odpowiedź, zauważamy, że 'filmy.rezyserzyID' również jest niewłaściwe, ponieważ nie jest zgodne z definicją kluczy obcych, które powinny odnosić się do 'rezyserID'. Każda z tych niepoprawnych odpowiedzi nie tylko prowadzi do błędnych wyników, ale także narusza zasady normalizacji bazy danych, co może skutkować problemami z integralnością oraz błędami w analizach danych.
Pytanie 37

Czym jest proces normalizacji tabel w kontekście baz danych?

A. wizualizacja struktury bazy danych
B. wprowadzenie nowych rekordów do bazy
C. wyłącznie stworzenie tabel oraz relacji w bazie
D. analiza i optymalizacja bazy danych
Podczas analizy niepoprawnych odpowiedzi, istotne jest zrozumienie, dlaczego niektóre koncepcje są mylone z procesem normalizacji. Odpowiedzi sugerujące dodawanie rekordów do bazy oraz graficzne przedstawienie bazy nie mają związku z normalizacją, która koncentruje się na organizacji istniejących danych w sposób redukujący ich duplikację. Proces dodawania rekordów odnosi się do operacji DML (Data Manipulation Language) w SQL, podczas gdy normalizacja jest bardziej związana z teorią projektowania baz danych. Odpowiedź sugerująca, że normalizacja dotyczy jedynie tworzenia tabel i relacji, ignoruje złożoność tego procesu. Tworzenie tabel to tylko jeden z kroków w procesie normalizacji, który obejmuje również identyfikację zależności między danymi oraz eliminację niepożądanych redundancji. Niezrozumienie tego może prowadzić do nieefektywnej struktury bazy danych, co w perspektywie czasu skutkuje trudnościami w zarządzaniu danymi. Natomiast stwierdzenie, że normalizacja odnosi się jedynie do optymalizacji bazy danych, pomija jej fundamentalne założenia dotyczące integralności danych oraz eliminacji anomalii, które są kluczowe dla prawidłowego funkcjonowania systemów bazodanowych. W ten sposób można zauważyć, że mylenie tych pojęć prowadzi do błędnych wniosków na temat podstawowych zasad projektowania baz danych.
Pytanie 38

W języku SQL, aby usunąć wszystkie rekordy z tabeli, nie eliminując jej samej, można skorzystać z polecenia

A. ALTER
B. DROP
C. TRUNCATE
D. UPDATE
Wybór polecenia DROP do usunięcia danych z tabeli prowadzi do całkowitego usunięcia zarówno tabeli, jak i jej definicji ze struktury bazy danych. DROP jest stosowane, gdy chcemy usunąć obiekt w całości, co może być nie tylko nieodwracalne, ale także niepożądane w sytuacjach, gdy potrzebujemy zachować strukturę tabeli dla przyszłych operacji. Użycie ALTER w kontekście usuwania danych jest również błędne, ponieważ to polecenie służy do modyfikacji struktury tabeli, takiej jak dodawanie lub usuwanie kolumn, a nie do zarządzania danymi w tabeli. Kolejnym błędem myślowym jest zastosowanie polecenia UPDATE, które jest używane do modyfikacji istniejących danych w tabeli, a nie do ich usuwania. Często mylnie przyjmuje się, że UPDATE można wykorzystać do 'czyszczenia' tabeli, co jednak nie jest zgodne z rzeczywistym działaniem tego polecenia. Poprawne podejście polega na zrozumieniu, że usuwanie danych w SQL wymaga zastosowania odpowiednich poleceń w zależności od celu – czy chcemy usunąć dane, czy całą tabelę. Dlatego kluczowe jest odpowiednie zrozumienie różnicy między tymi poleceniami oraz ich zastosowaniem w praktycznych sytuacjach, aby uniknąć nieodwracalnych błędów w zarządzaniu danymi.
Pytanie 39

Kiedy zestawi się relacją kluczy głównych dwie tabele, uzyskuje się relację o typie

A. jeden do wielu
B. wiele do jednego
C. wiele do wielu
D. jeden do jednego
Relacja typu jeden do jednego występuje, gdy dla każdego rekordu w jednej tabeli istnieje dokładnie jeden odpowiadający rekord w drugiej tabeli. Taki związek jest szczególnie przydatny w sytuacjach, gdy chcemy podzielić dane na różne kategorie, ale zachować ścisłą zależność między rekordami. Na przykład, możemy mieć tabelę z informacjami o użytkownikach, a w drugiej tabeli przechowywać szczegółowe dane dotyczące ich profili, gdzie każdy użytkownik ma tylko jeden profil. Takie połączenie nie tylko organizuje dane, ale również zwiększa wydajność zapytań i umożliwia lepszą kontrolę nad danymi. W praktyce, stosowanie relacji jeden do jednego pozwala na implementację złożonych systemów baz danych, które są zgodne z zasadami normalizacji, co jest kluczowe w projektowaniu baz zgodnych z najlepszymi praktykami, takimi jak minimalizacja redundancji i zapewnienie integralności danych.
Pytanie 40

Kwerenda umożliwiająca modyfikację wielu rekordów lub przeniesienie ich przy pomocy jednego działania, określana jest jako kwerenda

A. krzyżowej
B. funkcjonalnej
C. wybierająca
D. parametrycznej
Odpowiedzi takie jak kwerenda wybierająca, parametryczna czy krzyżowa nie są właściwe w tym kontekście pytania, bo nie są do wprowadzania zmian w wielu rekordach. Kwerenda wybierająca filtruje i zwraca dane z bazy, ale nie zmienia ich. Często ludzie mylą to z masowym przetwarzaniem, co prowadzi do błędnych wniosków. Kwerenda parametryczna za to pozwala na dynamiczne dodawanie zmiennych podczas wykonywania zapytania, ale również nie działa na masowej aktualizacji. Jest bardziej o elastycznym pobieraniu danych według jakichś kryteriów. Kwerenda krzyżowa z kolei służy do analizy danych w formie tabeli przestawnej, co jest zupełnie inną bajką, bo tu chodzi bardziej o zestawianie niż o modyfikacje. Często myli się różne typy kwerend i ich funkcje w bazach danych, co może prowadzić do zamieszania i błędów. Ważne jest, żeby zrozumieć, że te różne kwerendy mają swoje konkretne zastosowania i są projektowane do różnych zadań w ramach baz danych.
Rozpocznij nowy egzamin
Powrót do strony głównej