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: 26 kwietnia 2026 17:08
  • Data zakończenia: 26 kwietnia 2026 17:22

Egzamin zdany!

Wynik: 29/40 punktów (72,5%)

Wymagane minimum: 20 punktów (50%)

Nowe
Analiza przebiegu egzaminu- sprawdź jak rozwiązywałeś pytania
Pochwal się swoim wynikiem!
Facebook
X.com
LinkedIn
Szczegółowe wyniki:
Pytanie 1

W systemie baz danych sklepu komputerowego znajduje się tabela o nazwie komputery. Aby stworzyć raport, który wyświetla dane z tabeli dla komputerów z co najmniej 8 GB pamięci oraz procesorem Intel, można użyć kwerendy

A. SELECT * FROM komputery WHERE procesor = "Intel" AND pamiec < 8
B. SELECT * FROM komputery WHERE procesor = "Intel" OR pamiec < 8
C. SELECT * FROM komputery WHERE procesor = "Intel" OR pamiec >= 8
D. SELECT * FROM komputery WHERE procesor = "Intel" AND pamiec >= 8
Niepoprawne odpowiedzi bazują na błędnych założeniach dotyczących użycia operatorów logicznych oraz porównania. W przypadku odpowiedzi, w której pamięć jest mniejsza niż 8 GB, zapytanie nie spełnia wymagań, ponieważ ogranicza zakres wyników do komputerów, które nie pasują do założonych kryteriów. Ponadto, zastosowanie operatora OR w kontekście, w którym zarówno procesor, jak i pamięć muszą spełniać konkretne warunki, prowadzi do uzyskania wyników, które nie odpowiadają założeniom raportu. Operator OR łączy wyniki, które spełniają przynajmniej jeden z warunków, co w tym przypadku prowadzi do wybierania komputerów, które mogą mieć mniejszą pamięć, a procesor wcale nie musi być Intel. Takie podejście często wynika z mylnego przekonania, że wystarczy spełnić jeden z warunków, aby uzyskać oczekiwane wyniki. W kontekście tworzenia kwerend, ważne jest, aby dokładnie rozumieć, jak działają różne operatory oraz jakie efekty wywołują w analizowanych danych. Zastosowanie operatorów logicznych musi być starannie przemyślane, aby zapewnić, że zapytania będą rzeczywiście zwracały tylko te dane, które są istotne oraz zgodne z wymaganiami użytkownika.
Pytanie 2

Pole insert_id zdefiniowane w bibliotece MySQLi w języku PHP może służyć do

A. pobrania pierwszego dostępnego indeksu w bazie, tak aby można było pod nim dodać nowe dane
B. pobrania najwyższego indeksu z bazy, aby po jego inkrementacji wstawić pod niego dane
C. uzyskania id ostatnio dodanego wiersza
D. pozyskania kodu błędu, jeśli proces dodawania wiersza się nie powiódł
Pole insert_id w bibliotece MySQLi w języku PHP jest kluczowym narzędziem do uzyskiwania identyfikatora (ID) ostatnio wstawionego rekordu w bazie danych. Jest to szczególnie przydatne w kontekście operacji wstawiania nowych danych, gdzie często chcemy wiedzieć, jaki identyfikator został przypisany do nowego rekordu, aby móc go później wykorzystać, na przykład w odniesieniach do powiązanych tabel. W praktyce, po wykonaniu zapytania INSERT, możemy od razu pobrać ID nowo wstawionego rekordu, co jest istotne w relacyjnych bazach danych, gdzie klucze główne są często generowane automatycznie. Przykładowe zastosowanie to sytuacja, gdy wstawiamy nowego użytkownika do tabeli 'users' i chcemy również dodać rekord do tabeli 'profiles', który będzie powiązany z tym użytkownikiem. Wówczas, po wstawieniu użytkownika, możemy użyć insert_id, aby uzyskać jego ID i użyć go do wstawienia do 'profiles'. Używanie insert_id jest zgodne z najlepszymi praktykami, które zalecają minimalizowanie liczby zapytań do bazy danych oraz zapewnienie spójności danych.
Pytanie 3

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

A. indeksem klucza
B. indeksem unikalnym
C. kluczem podstawowym
D. kluczem obcym
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 4

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

A. Klauzula CHARACTER SET utf8 jest wymagana
B. Rekord tabeli nie może mieć wartości 3 MAJA
C. IF NOT EXISTS używa się opcjonalnie, żeby potwierdzić, że taka tabela nie istnieje w bazie danych
D. Nie można dodawać do tabeli ulic, które zawierają polskie znaki w nazwie
Pierwsze stwierdzenie, że rekordem tabeli nie może być 3 MAJA, jest niepoprawne, ponieważ w SQL nie ma ograniczeń co do znaków w wartościach tekstowych poza ogólnymi zasadami dotyczącymi typów danych. Jeżeli kolumna była zdefiniowana jako VARCHAR, można wprowadzać dowolne ciągi znaków, w tym daty w formacie tekstowym, o ile są one zgodne z ograniczeniami zdefiniowanymi na poziomie bazy danych. Drugie stwierdzenie, że klauzula CHARACTER SET utf8 jest obowiązkowa, również jest błędne. Ustalanie zestawu znaków jest opcjonalne; jeśli nie zostanie określony, system domyślnie użyje zestawu znaków przypisanego do bazy danych. Zestaw znaków jest istotny dla poprawnego przechowywania i wyświetlania danych tekstowych, ale jego brak nie uniemożliwia stworzenia tabeli. Wreszcie, trzecie stwierdzenie, że do tabeli nie można wprowadzać ulic zawierających polskie znaki, jest nieprawdziwe. W przypadku użycia zestawu znaków utf8, baza danych jest w stanie poprawnie przechowywać i przetwarzać polskie znaki diakrytyczne, takie jak ą, ę, ó, czy ł. W związku z tym nie ma żadnych ograniczeń co do wprowadzania takich danych, co czyni wprowadzenie ulic z polskimi znakami jak najbardziej możliwym i prawidłowym.
Pytanie 5

Dostępna jest tabela pracownicy zawierająca pola id, nazwisko, imię oraz wynagrodzenie. Kolumnę wynagrodzenie można usunąć przy użyciu następującej instrukcji

A. DROP TABLE pracownicy DELETE COLUMN wynagrodzenie
B. ALTER TABLE pracownicy DELETE wynagrodzenie
C. ALTER TABLE pracownicy DROP COLUMN wynagrodzenie
D. ALTER TABLE pracownicy DELETE COLUMN wynagrodzenie
W prawidłowej odpowiedzi powinno być 'ALTER TABLE pracownicy DROP COLUMN wynagrodzenie;'. To polecenie ALTER TABLE to coś, co używamy, żeby zmodyfikować to, co już mamy w tabeli w bazie danych. Jak chcemy usunąć kolumnę, to kluczowe jest użycie DROP COLUMN, bo to dokładnie mówi, co chcemy zrobić – usunąć konkretną kolumnę. W praktyce często tak usuwamy zbędne dane, kiedy kolumna już nie jest potrzebna. Usunięcie kolumny upraszcza strukturę bazy danych i może zwiększyć wydajność, bo mamy mniej danych do przechowywania. Fajnie jest też pamiętać, żeby zanim coś zmienimy, zrobić kopię zapasową tabeli – nigdy nie wiadomo, kiedy mogą się przydać stare dane. No i jak pracujesz z dużą bazą danych, to najlepiej robić takie rzeczy w nocy czy w weekend, żeby nie wpływać na działanie systemu w godzinach szczytu.
Pytanie 6

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ł przeszukiwać dane w tabeli klienci.
D. Będzie mógł eliminować rekordy z tabeli klienci.
Odpowiedź "Będzie mógł zmienić strukturę tabeli klienci" jest prawidłowa, ponieważ użytkownik jan zyskał pełne uprawnienia do tabeli klienci za pomocą polecenia GRANT ALL PRIVILEGES. Oznacza to, że posiada on wszystkie dostępne uprawnienia w tym zakresie, w tym możliwość modyfikacji struktury tabeli, co obejmuje dodawanie lub usuwanie kolumn, zmienianie typów danych oraz wprowadzanie modyfikacji do indeksów. Jednakże, zastosowane polecenie REVOKE powoduje odebranie wybranych uprawnień, tj. SELECT, INSERT, UPDATE oraz DELETE. W związku z tym, mimo że jan może zmieniać strukturę tabeli, nie ma już możliwości wprowadzania, usuwania ani przeglądania danych. Praktycznie, na przykład, jeżeli jan chciałby dodać nową kolumnę do tabeli klienci, ma taką możliwość, jednak nie będzie mógł dodać nowych rekordów ani ich edytować. To podejście jest zgodne z najlepszymi praktykami zarządzania uprawnieniami w systemach baz danych, gdzie ważne jest precyzyjne określenie, jakie operacje mogą być realizowane przez różnych użytkowników.
Pytanie 7

Wykonanie zapytania SQL: DELETE FROM mieszkania WHERE status=1; spowoduje usunięcie

A. tabel, w których pole status ma wartość 1, z bazy danych mieszkania
B. tabeli mieszkania w bazie danych
C. pola o nazwie status w tabeli mieszkania
D. rekordów, gdzie pole status ma wartość 1, z tabeli mieszkania
Użycie kwerendy SQL: DELETE FROM mieszkania WHERE status=1; jest poprawne, ponieważ polecenie DELETE ma na celu usunięcie rekordów z określonej tabeli, w tym przypadku z tabeli mieszkania. Klauzula WHERE filtruje te rekordy, które mają wartość pola status równą 1. To podejście jest zgodne z zasadami zarządzania danymi, które sugerują, że operacje usuwania powinny być przeprowadzane z użyciem odpowiednich filtrów, aby zminimalizować ryzyko przypadkowego usunięcia niezamierzonych danych. Na przykład, jeśli w tabeli mieszkania mamy 1000 rekordów, a tylko 150 z nich ma status równy 1, to po wykonaniu tej kwerendy usunięte zostaną dokładnie te 150 rekordów, a pozostałe pozostaną nienaruszone. Dobrą praktyką jest również tworzenie kopii zapasowych danych przed wykonaniem operacji usuwania, aby móc je przywrócić w razie potrzeby. Kwerendy DELETE są niezwykle przydatne w zarządzaniu bazami danych, zwłaszcza w sytuacjach, gdzie wymagana jest aktualizacja danych lub usunięcie nieaktualnych informacji.
Pytanie 8

Które z tabel będą poddane weryfikacji zgodnie z przedstawionym poleceniem? ```CHECK TABLE pracownicy CHANGED;```

A. Tabele, które zmieniły się w obecnej sesji
B. Tabele, które uległy zmianie od ostatniej kontroli lub nie zostały poprawnie zamknięte
C. Wyłącznie tabele odnoszące się do innych
D. Tylko te tabele, które nie mogły być poprawnie zakończone
Wybór odpowiedzi dotyczącej jedynie tabel, które nie zostały poprawnie zamknięte, nie uwzględnia pełnego zakresu zastosowania polecenia CHECK TABLE. To podejście ignoruje ważny aspekt, jakim jest monitorowanie wszelkich zmian, które miały miejsce od ostatniej inspekcji. Tabele mogą być zmieniane przez różne operacje, zarówno podczas aktualizacji, jak i w wyniku nieprawidłowego zakończenia sesji, co czyni istotnym ich kontrolowanie w szerszym ujęciu. Z kolei odpowiedź sugerująca, że tylko tabele referujące do innych powinny być sprawdzane, jest myląca, ponieważ takie ograniczenie do współzależności między tabelami nie odzwierciedla rzeczywistej natury problemów z integralnością danych. W praktyce, wszystkie tabele w bazie danych mogą wpływać na siebie nawzajem, a problemy w jednej tabeli mogą prowadzić do błędów w innych. Takie myślenie może prowadzić do zaniedbania, które naraża system na uszkodzenia, a nawet utratę danych. Właściwe podejście do zarządzania bazami danych powinno opierać się na całościowym przeglądzie stanu tabel, a nie na selektywnym podejściu, co może przyczynić się do nieefektywności i ryzyka utraty danych. Dlatego też skupienie się tylko na jednym aspekcie, takim jak niewłaściwe zamknięcie, jest niewystarczające dla zapewnienia integralności systemu.
Pytanie 9

Dodanie ograniczenia klucza obcego w taki sposób, aby kolumna Klasy_id z tabeli Uczniowie była powiązana z kolumną id w tabeli Klasy zostanie wykonane przy użyciu polecenia

Ilustracja do pytania
A. ALTER TABLE Uczniowie ADD FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);
B. ALTER TABLE Uczniowie DROP CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);
C. ALTER TABLE Uczniowie DROP FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);
D. ALTER TABLE Uczniowie ADD CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);
W poleceniach dotyczących kluczy obcych bardzo łatwo pomylić operacje `ADD` i `DROP` oraz prawidłową składnię dla poszczególnych dialektów SQL. W przedstawionych błędnych odpowiedziach pojawia się kilka typowych nieporozumień. Część z nich próbuje używać słowa kluczowego `DROP`, które służy do usuwania istniejącego ograniczenia, a nie do jego tworzenia. Jeżeli naszym celem jest dopiero dodanie relacji między tabelą `Uczniowie` a tabelą `Klasy`, to użycie `DROP CONSTRAINT` albo `DROP FOREIGN KEY` jest po prostu logicznie sprzeczne z zadaniem – takie polecenia mogłyby mieć sens tylko wtedy, gdy klucz obcy `FKKlasy` już istnieje i chcemy go zlikwidować. W praktyce takie pomyłki wynikają z mylenia dwóch kroków: projektowania schematu (gdzie klucze dopiero dodajemy) z refaktoryzacją istniejącej bazy (gdzie często coś usuwamy i tworzymy na nowo). Kolejna sprawa to składnia `ADD FOREIGN KEY FKKlasy FOREIGN KEY(...)`. W standardowych systemach zarządzania bazą danych najpierw podaje się `ADD CONSTRAINT nazwa`, a dopiero później słowo `FOREIGN KEY` wraz z listą kolumn. Wpychanie nazwy ograniczenia między `ADD FOREIGN KEY` a definicję kolumn nie jest zgodne z zasadami składni SQL i po prostu nie zadziała. Moim zdaniem to efekt mieszania różnych przykładów z internetu, gdzie w jednych pokazuje się nazwane ograniczenia (`ADD CONSTRAINT ...`), a w innych anonimowe (`ADD FOREIGN KEY (...) REFERENCES ...`), bez nazwy. Dodatkowo, używanie w jednym poleceniu jednocześnie `DROP` i całej definicji `FOREIGN KEY(Klasy_id) REFERENCES Klasy(id)` jest nielogiczne: przy usuwaniu ograniczenia podajemy wyłącznie jego nazwę, bo silnik bazy już zna szczegóły definicji i nie trzeba ich powtarzać. W poprawnym podejściu zawsze zadajemy sobie pytanie: czy ja chcę coś dodać, czy usunąć, i czy składnia, której używam, odpowiada dokumentacji konkretnego systemu (np. SQL Server, MySQL, PostgreSQL). Stosowanie czytelnej, udokumentowanej formy `ALTER TABLE ... ADD CONSTRAINT ... FOREIGN KEY ... REFERENCES ...` jest zgodne z dobrymi praktykami i oszczędza sporo nerwów przy późniejszej administracji oraz migracjach schematu.
Pytanie 10

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

A. klucz główny zawsze będzie liczbą całkowitą
B. każdy klucz główny będzie miał odpowiadający mu klucz obcy w innej tabeli
C. dla każdej tabeli zostanie ustanowiony klucz główny
D. każda kolumna otrzyma zdefiniowany typ danych
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 11

Wykonanie zapytania SQL spowoduje skasowanie

DELETE FROM mieszkania WHERE status = 1;
A. elementów o nazwie status z tabeli mieszkania
B. tabel, w których wartość pola status wynosi 1, z bazy danych mieszkania
C. rekordów, w których wartość pola status jest równa 1, z tabeli mieszkania
D. tabeli mieszkania znajdującej się w bazie danych
Odpowiedź wskazująca na usunięcie rekordów, w których pole status jest równe 1, z tabeli mieszkania jest poprawna ponieważ w zapytaniu SQL użyto składni DELETE, która jest odpowiedzialna za usuwanie danych z określonej tabeli. W kontekście tego zapytania, po słowie 'FROM' znajduje się nazwa tabeli, czyli 'mieszkania', a warunek 'WHERE status = 1' precyzuje, które rekordy mają zostać usunięte. Przykładowo, jeśli w tabeli mieszkania znajdują się mieszkania oznaczone jako dostępne (status = 1), to po wykonaniu tego zapytania wszystkie takie mieszkania zostaną trwale usunięte z bazy danych. Ważne jest, aby przed wykonaniem zapytania DELETE rozważyć konieczność wykonania kopii zapasowej danych, aby zapobiec ich nieodwracalnej utracie. Dobrą praktyką jest również stosowanie zapytania SELECT z tym samym warunkiem, aby najpierw zweryfikować, które rekordy zostaną usunięte. Tego rodzaju podejście umożliwia lepsze zarządzanie danymi oraz redukuje ryzyko pomyłek podczas operacji na bazach danych.
Pytanie 12

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

A. spójności bazy danych
B. poprawności składni zapytań
C. opcji udostępnienia bazy danych
D. uprawnień dostępu do serwera 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 13

Którą relację w projekcie bazy danych należy ustalić między tabelami widocznymi na ilustracji zakładając, że każdy klient sklepu internetowego dokona przynajmniej dwóch zamówień?

Ilustracja do pytania
A. n:n
B. 1:1
C. 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia
D. 1:n, gdzie 1 jest po stronie Zamówienia, a wiele po stronie Klienta
W tym zadaniu pułapka polega głównie na poprawnym zrozumieniu biznesowego sensu relacji. Opis mówi jasno, że mamy tabelę Klient i tabelę Zamówienie w sklepie internetowym oraz że każdy klient złoży co najmniej dwa zamówienia. To automatycznie sugeruje relację, w której pojedynczy klient jest powiązany z wieloma zamówieniami, ale każde konkretne zamówienie należy tylko do jednego klienta. Relacja 1:1 między Klientem a Zamówieniem byłaby sensowna wtedy, gdyby na jednego klienta przypadało dokładnie jedno zamówienie. W praktyce systemów sprzedażowych to bardzo rzadki przypadek i raczej zły model. Prowadziłby do sytuacji, że dla kolejnego zamówienia tego samego klienta trzeba by tworzyć nowy rekord klienta, czyli duplikować dane osobowe, adres, NIP itd. To łamie podstawowe zasady normalizacji (szczególnie pierwszą i trzecią postać normalną) i bardzo utrudnia późniejsze raportowanie. Relacja n:n sugeruje, że jedno zamówienie mogłoby należeć do wielu klientów, a jeden klient do wielu zamówień jednocześnie, przy czym do poprawnego odwzorowania takiej relacji trzeba by wprowadzić tabelę pośredniczącą, np. Klient_Zamówienie. W kontekście sklepu internetowego takie założenie jest nielogiczne: jedno zamówienie ma jednego właściciela, nie ma sensu aby ten sam koszyk zakupowy był przypisany do kilku różnych klientów. Relacja n:n jest typowa raczej dla powiązań typu Produkt–Zamówienie (wiele produktów w wielu zamówieniach), a nie Klient–Zamówienie. Z kolei relacja 1:n odwrócona, gdzie „1” jest po stronie Zamówienia, a „n” po stronie Klienta, oznaczałaby, że jedno zamówienie może być przypisane do wielu klientów. To dokładnie odwrócenie poprawnego modelu i w praktyce niewykonalne biznesowo – kto byłby płatnikiem, kto odbiorcą, jak liczyć historię zakupów? Taki projekt łamie też zasadę jednoznacznej odpowiedzialności rekordu: zamówienie powinno mieć jednego, jasno określonego właściciela. Typowym błędem myślowym przy takich pytaniach jest mylenie relacji Klient–Zamówienie z relacją Zamówienie–Produkt. Tam rzeczywiście często stosuje się n:n z tabelą pośrednią (pozycje zamówienia). Warto zawsze zatrzymać się i odpowiedzieć sobie na proste pytanie: czy ten obiekt może realnie „należeć” do więcej niż jednego innego obiektu? W przypadku zamówienia odpowiedź brzmi: nie, dlatego poprawnym podejściem jest właśnie relacja 1:n z jednym klientem i wieloma jego zamówieniami.
Pytanie 14

Który typ danych należy przypisać do atrybutu Telefon encji Student zakładając, że numer rozpoczyna się od znaku + i następującego po nim numeru kierunkowego kraju?

A. Liczbowy
B. Binarny
C. Tekstowy
D. Wyliczeniowy
Poprawny typ danych dla atrybutu Telefon w encji Student to typ tekstowy, ponieważ numer telefonu nie jest zwykłą liczbą, tylko ciągiem znaków o określonej strukturze. Mamy tam znak plus na początku, potem numer kierunkowy kraju, często spacje, czasem myślniki, nawiasy. System informatyczny nie powinien wykonywać na tym polu działań arytmetycznych, tylko przechowywać dokładnie to, co użytkownik wpisał. W bazach danych i w większości języków programowania przyjętym standardem jest traktowanie numerów telefonów jako stringów, właśnie po to, żeby nie tracić formatu i nie usuwać znaków specjalnych. Moim zdaniem to jedna z takich pułapek początkujących: skoro są cyfry, to kusi, żeby dać typ liczbowy. A potem wychodzą kwiatki, typu ucinanie zera na początku, problemy z numerami międzynarodowymi, brak możliwości zapisania +48 albo numeru wewnętrznego. W praktyce w modelu danych stosuje się typ tekstowy (np. VARCHAR o rozsądnej długości) i ewentualnie nakłada się walidację po stronie aplikacji lub bazy, np. wyrażeniem regularnym, żeby pilnować formatu zgodnego z E.164 (+48123456789 itd.). Dobre praktyki mówią też, żeby nie łączyć w jednym polu różnych znaczeń, więc jeśli oprócz numeru trzeba przechowywać np. opis typu telefonu (komórkowy, stacjonarny, służbowy), to lepiej dać osobny atrybut albo nawet osobną tabelę. Sam numer jednak zawsze jako tekst, bo jego „wartość” logiczna to identyfikator, a nie wielkość liczbowa.
Pytanie 15

Polecenie w języku SQL w formie

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

Jakie jest zadanie funkcji PHP o nazwie mysql_num_rows()?

A. zwrócić liczbę wierszy znajdujących się w wyniku zapytania
B. zwrócić rekord o numerze podanym jako parametr funkcji
C. zwrócić następny rekord z wynikami zapytania
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 17

Model, w którym wszystkie informacje są zgromadzone w jednej tabeli, określa się jako struktura prostych baz danych

A. hierarchicznym
B. relacyjnym
C. sieciowym
D. jednorodnym
Model jednorodny, znany też jako model płaskiej tabeli, to taka struktura bazy, w której trzymamy wszystkie dane w jednej tabeli. To najprostsza opcja do zrozumienia i wdrożenia, dlatego świetnie nadaje się do małych i prostych aplikacji. W tym modelu dane są poukładane w wiersze i kolumny – każdy wiersz to jakiś rekord, a kolumny to różne cechy lub atrybuty tego rekordu. Na przykład, wyobraź sobie tabelę z informacjami o książkach: każda książka to osobny wiersz, a kolumny mogą zawierać tytuł, autora, rok wydania czy ISBN. Oczywiście, ma to swoje ograniczenia, zwłaszcza jeśli chodzi o wydajność i zarządzanie dużymi zbiorami danych. Dlatego w praktyce często przechodzi się na bardziej zaawansowane modele, jak relacyjny. Mimo to, model jednorodny sprawdza się w prototypowaniu albo tam, gdzie liczy się prostota i szybki dostęp do danych. Warto też wiedzieć, że nie korzysta się tu do końca ze standardów typu SQL, bo nie ma relacji między danymi.
Pytanie 18

W języku SQL wykonano przedstawione poniżej polecenia GRANT. Kto będzie miał prawo do przeglądania danych oraz ich zmiany?

GRANT ALL ON firmy TO 'adam'@'localhost';
GRANT ALTER, CREATE, DROP ON firmy TO 'anna'@localhost;
GRANT SELECT, INSERT, UPDATE ON firmy TO 'tomasz'@'localhost';
A. Jedynie Tomasz
B. Adam i Anna
C. Anna i Tomasz
D. Tomasz i Adam
Odpowiedź 'Tomasz i Adam' jest poprawna, ponieważ obaj użytkownicy mają przypisane odpowiednie uprawnienia do przeglądania oraz modyfikacji danych w bazie 'firmy'. Adam otrzymał pełne uprawnienia, co oznacza, że może przeglądać (SELECT) oraz modyfikować (INSERT, UPDATE, DELETE) dane, a także zmieniać strukturę tabel (ALTER, CREATE, DROP). Tomasz, z kolei, ma przydzielone szczegółowe uprawnienia do przeglądania danych (SELECT) oraz ich modyfikacji (INSERT, UPDATE). W praktyce, przydzielanie uprawnień w bazach danych odbywa się zgodnie z zasadą minimalnych uprawnień, co oznacza, że każdy użytkownik powinien mieć tylko te uprawnienia, które są mu niezbędne do realizacji przydzielonych zadań. Dobrą praktyką jest regularna weryfikacja przydzielonych uprawnień oraz ich dostosowywanie do zmieniających się potrzeb organizacji.
Pytanie 19

Jakie są nazwy standardowych instrukcji w języku SQL, które dotyczą wykonywania operacji na danych w SQL DML (np.: dodawanie danych do bazy, usuwanie, wprowadzanie zmian w danych)?

A. DENY, GRANT, REVOKE
B. SELECT, SELECT INTO
C. DELETE, INSERT, UPDATE
D. ALTER, CREATE, DROP
Odpowiedź DELETE, INSERT, UPDATE jest całkiem trafna, bo te polecenia są częścią DML, czyli Data Manipulation Language, w SQL-u. DML to zestaw komend do zarządzania danymi w bazach danych. Moim zdaniem, DELETE jest kluczowe, bo pozwala na usuwanie zbędnych rekordów, co pomaga utrzymać bazę w dobrym stanie. Z kolei INSERT to coś, co używamy do dodawania nowych wpisów do tabeli, co jest mega ważne, jeśli chodzi o zbieranie danych potrzebnych aplikacji. A UPDATE? No to już absolutnie istotna sprawa, bo z jego pomocą zmieniamy dane, które już są w bazie, co przydaje się na przykład przy aktualizacji informacji o użytkownikach czy produktach. Przykłady? Można użyć INSERT, żeby dodać nowego użytkownika do tabeli 'Users', DELETE, żeby pozbyć się nieaktywnych kont, a UPDATE, żeby zmienić e-mail jakiegoś użytkownika. Dobrym pomysłem jest też korzystanie z transakcji, bo zapewnia to lepszą integralność danych podczas operacji DML.
Pytanie 20

Wskaź na właściwą sekwencję tworzenia aplikacji?

A. Analiza potrzeb klienta, specyfikacja wymagań, tworzenie, testowanie, wdrażanie
B. Analiza potrzeb klienta, specyfikacja wymagań, tworzenie, wdrażanie, testowanie
C. Tworzenie, analiza potrzeb klienta, specyfikacja wymagań, wdrażanie, testowanie
D. Specyfikacja wymagań, analiza potrzeb klienta, tworzenie, wdrażanie, testowanie
Prawidłowa kolejność tworzenia aplikacji zaczyna się od analizy wymagań klienta, co jest kluczowym etapem, pozwalającym zrozumieć oczekiwania oraz potrzeby użytkowników. Następnie, na podstawie zebranych informacji, sporządzana jest specyfikacja wymagań, która dokładnie opisuje, jakie funkcjonalności i cechy powinna posiadać aplikacja. To dokument, który stanowi fundament dla dalszych prac programistycznych. W kolejnej fazie następuje etap tworzenia, w którym programiści przekształcają specyfikację w kod, implementując wszystkie wymagane funkcje. Po zakończeniu kodowania, aplikacja przechodzi testy, które mają na celu wykrycie błędów oraz weryfikację zgodności z wymaganiami. W końcowej fazie, po przeprowadzeniu testów i eliminacji ewentualnych problemów, aplikacja jest wdrażana, co oznacza jej udostępnienie użytkownikom. Cały proces powinien być zgodny z najlepszymi praktykami oraz standardami, takimi jak Agile czy Scrum, które kładą duży nacisk na iteracyjny rozwój oraz stałą komunikację z klientem, co zwiększa szansę na sukces projektu.
Pytanie 21

Jakie słowo kluczowe w języku SQL należy zastosować, aby usunąć powtarzające się rekordy?

A. GROUP BY
B. ORDER BY
C. LIKE
D. DISTINCT
Słowo DISTINCT w SQL to taki sprytny sposób na pozbycie się duplikatów w wynikach zapytań. Jak robisz zapytanie SELECT, które zwraca różne wiersze, to dzięki DISTINCT dostaniesz tylko unikalne wartości w kolumnach, które wybierzesz. Na przykład, mając tabelę 'pracownicy' z kolumną 'miasto', jak użyjesz zapytania 'SELECT DISTINCT miasto FROM pracownicy;', to dostaniesz listę wszystkich miast, w których są pracownicy, a powtórzenia polecą w odstawkę. Warto pamiętać, że DISTINCT działa na całej kombinacji kolumn, które zwracasz. Jak dodasz więcej kolumn w zapytaniu, to SQL wyciągnie unikalne zestawienia tych kolumn. To naprawdę przydatne, zwłaszcza przy dużych zbiorach danych, gdzie duplikaty mogą namieszać w analizach i raportach. DISTINCT jest standardowym elementem w SQL i działa praktycznie w każdym systemie zarządzania bazami danych, jak MySQL czy PostgreSQL, co czyni to narzędzie mega uniwersalnym w codziennym grzebaniu w danych.
Pytanie 22

W systemach baz danych, aby przedstawić dane spełniające określone kryteria, należy stworzyć

A. makropolecenie
B. relację
C. formularz
D. raport
Raport w bazach danych jest narzędziem, które pozwala na prezentację danych w formacie dostosowanym do konkretnych potrzeb użytkownika. Jego głównym celem jest przedstawienie informacji, które spełniają określone kryteria, co jest niezwykle istotne w kontekście analizy danych. Raporty mogą być generowane na podstawie różnych źródeł danych, a ich struktura może obejmować tabele, wykresy i podsumowania. W praktyce, raporty są często używane w procesach decyzyjnych, na przykład w raportowaniu wyników finansowych, analizie sprzedaży czy monitorowaniu wydajności operacyjnej. Wiele systemów zarządzania bazami danych (DBMS) oferuje funkcje do tworzenia raportów, co jest zgodne z najlepszymi praktykami w dziedzinie analizy i wizualizacji danych. Dobrze zbudowany raport nie tylko dostarcza kluczowych informacji, ale także umożliwia efektywniejsze podejmowanie decyzji poprzez dostarczenie kontekstu i analizy danych.
Pytanie 23

Mamy tabelę firm, która zawiera takie kolumny jak: nazwa, adres, NIP, obrot (obrót w ostatnim miesiącu), rozliczenie, status. Wykonanie zapytania SQL SELECT spowoduje wyświetlenie

SELECT nazwa, NIP FROM firmy WHERE obrot < 4000;
A. wszystkie dane o firmach, które w ostatnim miesiącu miały obrót na poziomie co najmniej 4000 zł
B. tylko nazwę i numer NIP przedsiębiorstw, które w poprzednim miesiącu miały obrót wynoszący przynajmniej 4000 zł
C. wszystkie informacje o firmach, które w minionym miesiącu osiągnęły obrót poniżej 4000 zł
D. tylko nazwę i numer NIP przedsiębiorstw, które w ostatnim miesiącu miały obrót mniejszy niż 4000 zł
Prawidłowa odpowiedź odwołuje się do kwerendy SQL SELECT która wybiera jedynie kolumny nazwa oraz NIP z tabeli firmy pod warunkiem że kolumna obrot jest mniejsza niż 4000 Kwerenda ta jest przykład zastosowania filtracji danych w celu wyodrębnienia specyficznych informacji z bazy danych co jest kluczowe w analizie biznesowej Dzięki tej operacji można uzyskać listę firm które w ostatnim miesiącu osiągnęły niski obrót co może być istotne dla działów finansowych i marketingowych w celu identyfikacji klientów wymagających dodatkowego wsparcia Tego rodzaju selektywne przetwarzanie danych jest częścią codziennej pracy analityków danych oraz specjalistów od zarządzania relacjami z klientami W praktyce w infrastrukturze bazodanowej tego typu zapytania mogą być stosowane do generowania raportów okresowych lub alertów biznesowych Przy projektowaniu kwerend SQL ważne jest aby precyzyjnie określać które kolumny i wiersze danych są interesujące co nie tylko zwiększa efektywność zapytań ale także pozwala na lepsze zarządzanie zasobami serwera Dobra praktyka polega na optymalizacji zapytań w celu minimalizacji czasów odpowiedzi oraz obciążenia systemów bazodanowych co jest kluczowe dla utrzymania wydajności i niezawodności w dużych systemach informatycznych
Pytanie 24

Funkcja pg_connect w PHP pozwala na nawiązanie połączenia z bazą danych

A. MS ACCESS
B. PostgreSQL
C. mySQL
D. MS SQL
Polecenie pg_connect w języku PHP jest używane do nawiązywania połączenia z bazą danych PostgreSQL. PostgreSQL to zaawansowany system zarządzania relacyjnymi bazami danych, który obsługuje wiele zaawansowanych funkcji, takich jak transakcje, złożone zapytania czy wsparcie dla różnych typów danych. Funkcja pg_connect przyjmuje jako argumenty łańcuch połączenia, w którym określamy host, port, nazwę bazy danych, użytkownika oraz hasło. Przykładowe użycie polecenia to: $conn = pg_connect("host=localhost dbname=mydb user=myuser password=mypass");. Przy prawidłowym połączeniu, zmienna $conn będzie zawierała uchwyt do bazy danych, który można używać w dalszych operacjach, takich jak wykonywanie zapytań SQL. PostgreSQL jest często wybierany ze względu na swoje możliwości dostosowywania, silne wsparcie dla standardów SQL oraz szeroką społeczność. Warto zauważyć, że pg_connect jest częścią rozszerzenia PHP o nazwie pgsql, które musi być włączone, aby umożliwić korzystanie z tej funkcji.
Pytanie 25

W celu zmiany struktury tabeli w systemie MySQL trzeba wykonać polecenie

A. GRANT
B. INSERT INTO
C. UPDATE
D. ALTER TABLE
Odpowiedź 'ALTER TABLE' to strzał w dziesiątkę, bo to właśnie to polecenie w MySQL pozwala na zmiany w strukturze tabeli w bazach danych. Gdy używamy 'ALTER TABLE', możemy dodawać nowe kolumny, usuwać te, które już nie są potrzebne, albo zmieniać typ danych w kolumnach. Przykładowo, jeśli chcemy dodać kolumnę 'wiek' do tabeli 'pracownicy', używamy: ALTER TABLE pracownicy ADD COLUMN wiek INT;. A żeby usunąć kolumnę 'adres', wystarczy: ALTER TABLE pracownicy DROP COLUMN adres;. Pamiętaj przy tym, żeby zawsze sprawdzić, czy te zmiany nie będą miały negatywnego wpływu na dane oraz czy mamy odpowiednie uprawnienia. Osobiście uważam, że warto robić kopie zapasowe przed większymi zmianami, bo to może uratować skórę, gdy coś pójdzie nie tak. Dobry sposób na to, by być pewnym siebie w pracy z bazami danych, to dobrze poznać 'ALTER TABLE' i jego możliwości.
Pytanie 26

Baza danych szkoły podstawowej dla dzieci w wieku 6 lat obejmuje tabelę szkoła, która zawiera kolumny: imie, nazwisko, klasa. Wszyscy uczniowie w klasach od 1 do 5 przeszli do wyższej klasy. W celu zwiększenia wartości w kolumnie klasa o 1, należy wykonać następujące polecenie

A. UPDATE nazwisko, imie SET klasa = klasa + 1 WHERE klasa>l OR klasa < 5
B. SELECT szkoła FROM klasa = klasa + 1 WHERE klasa >=1 AND klasa <= 5
C. UPDATE szkoła SET klasa = klasa + 1 WHERE klasa >=1 AND klasa <= 5
D. SELECT nazwisko, imie FROM klasa = klasa + 1 WHERE klasa>l OR klasa < 5
Poprawne polecenie to 'UPDATE szkoła SET klasa = klasa + 1 WHERE klasa >=1 AND klasa <= 5;'. To zapytanie aktualizuje wartość w kolumnie 'klasa' dla wszystkich uczniów w tabeli 'szkoła', których aktualny poziom klasy mieści się w zakresie od 1 do 5. Kluczowym elementem jest użycie polecenia UPDATE, które jest standardowym sposobem na modyfikowanie danych w bazach danych SQL. Oznaczenie 'SET klasa = klasa + 1' wskazuje, że chcemy zwiększyć obecną wartość w kolumnie 'klasa' o 1. Warto zwrócić uwagę na warunek WHERE, który filtruje rekordy tak, aby aktualizacja dotyczyła tylko tych uczniów, którzy są w klasach 1-5. Tego rodzaju operacje są powszechnie stosowane w zarządzaniu danymi w aplikacjach edukacyjnych i są zgodne z praktykami bezpieczeństwa i integralności danych, zapewniając, że tylko odpowiednie rekordy są aktualizowane. Przykładem praktycznego zastosowania może być coroczna aktualizacja klas uczniów po zakończeniu roku szkolnego.
Pytanie 27

W systemie baz danych zdefiniowano tabelę Mieszkancy, która zawiera dane. W celu usunięcia tej tabeli oraz jej zawartości, należy użyć polecenia

A. DELETE FROM Mieszkancy;
B. ALTER TABLE Mieszkancy;
C. TRUNCATE TABLE Mieszkancy;
D. DROP TABLE Mieszkancy;
Polecenie 'DROP TABLE Mieszkancy;' jest odpowiednie do usunięcia tabeli z bazy danych, wraz ze wszystkimi jej danymi i strukturą. W przeciwieństwie do innych poleceń, takich jak 'DELETE' czy 'TRUNCATE', które modyfikują zawartość tabeli, 'DROP TABLE' usuwa całą tabelę z systemu. Użycie tego polecenia jest nieodwracalne, dlatego przed jego zastosowaniem warto upewnić się, że posiadamy kopię zapasową danych, jeśli będą one w przyszłości potrzebne. W praktyce, jeśli jesteś administratorem bazy danych i chcesz usunąć zbędną tabelę, polecenie to jest niezwykle efektywne i pozwala na zwolnienie zasobów. Zgodnie z najlepszymi praktykami, przed wykonaniem operacji na bazie danych, zawsze warto przeprowadzić analizę wpływu na inne powiązane obiekty, takie jak relacje między tabelami. Dobrą praktyką jest również włączenie kontroli dostępu, aby nieuprawnione osoby nie mogły wykonywać takich operacji.
Pytanie 28

W systemie baz danych stworzono tabelę Mieszkancy zawierającą informacje. Aby usunąć tę tabelę wraz z danymi, należy użyć komendy

A. ALTER TABLE Mieszkancy;
B. DELETE FROM Mieszkancy;
C. DROP TABLE Mieszkancy;
D. TRUNCATE TABLE Mieszkancy;
Polecenie 'DROP TABLE Mieszkancy;' jest właściwym sposobem na usunięcie tabeli wraz z jej zawartością w bazie danych. To polecenie nie tylko usuwa tabelę, ale również wszystkie dane, które w niej się znajdują oraz wszelkie powiązania, takie jak klucze obce. W praktyce, gdy programista chce całkowicie wyeliminować strukturę tabeli oraz jej dane, wykorzystuje 'DROP TABLE'. Jest to szczególnie przydatne w sytuacjach, gdy tabela nie jest już potrzebna w systemie, a jej usunięcie pozwala na zwolnienie zasobów oraz uproszczenie struktury bazy danych. Warto również pamiętać, że przed wykonaniem tego polecenia warto stworzyć kopię zapasową danych, jeśli są one istotne, ponieważ operacja ta jest nieodwracalna. Ponadto, zgodnie z zasadami dobrych praktyk, przed usunięciem tabeli należy upewnić się, że nie ma na nią żadnych zależności w innych częściach bazy danych, aby uniknąć potencjalnych problemów z integralnością danych.
Pytanie 29

W bibliotece mysqli w PHP, aby uzyskać najbardziej aktualny komunikat o błędzie, można użyć funkcji

A. mysqli_errno()
B. mysqli_error()
C. mysqli_error_list()
D. mysqli_use_result()
Funkcja mysqli_error() w bibliotece mysqli języka PHP jest sposobem na uzyskanie ostatniego komunikatu o błędzie związanym z połączeniem lub zapytaniem SQL. Zwraca ona łańcuch znaków, który opisuje ostatni błąd związany z danym połączeniem. Jest to niezwykle przydatne narzędzie w procesie debugowania, ponieważ pozwala programiście szybko zidentyfikować źródło problemu. Na przykład, jeśli napotkasz błąd podczas wykonywania zapytania, możesz użyć mysqli_error($connection) po funkcji wykonującej zapytanie, aby uzyskać szczegółowy opis błędu. W kontekście dobrych praktyk programistycznych, zawsze należy obsługiwać błędy i nie ignorować ich, aby uniknąć trudności w przyszłości. Warto również pamiętać, że funkcja ta działa tylko w kontekście aktualnego połączenia bazodanowego, co oznacza, że przed jej użyciem musisz mieć aktywne połączenie. Przykład użycia: $result = mysqli_query($connection, $query); if (!$result) { echo mysqli_error($connection); }
Pytanie 30

W bazie danych istnieje tabela ksiazki, która posiada pola: tytul, id_autora, data_wypoz, id_czytelnika. Codziennie tworzony jest raport dotyczący książek wypożyczonych w danym dniu, który wyświetla jedynie tytuły książek. Która kwerenda SQL jest odpowiednia do generowania tego raportu?

A. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATENT_E()
B. SELECT tytul FROM ksiazki
C. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()
D. SELECT * FROM ksiazki
Wybór innych kwerend związany jest z różnymi nieprawidłowymi założeniami. Kwerenda SELECT tytul FROM ksiazki; nie uwzględnia żadnego filtrowania daty wypożyczenia, przez co generowany raport zawierałby wszystkie tytuły książek, niezależnie od daty ich wypożyczenia. Takie podejście jest nieefektywne, ponieważ nie spełnia założonego celu raportu, jakim jest prezentacja książek wypożyczonych jedynie w danym dniu. Z kolei SELECT * FROM ksiazki; zwraca wszystkie kolumny z tabeli książek, co prowadzi do nadmiaru danych i utrudnia analizę wyników. Raport powinien być zwięzły i dostarczać tylko istotnych informacji. Kwerenda SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATENT_E(); zawiera literówkę i jest niepoprawna syntaktycznie. Warto zwrócić uwagę na typowe błędy, takie jak błędne użycie funkcji i brak filtracji danych, które mogą prowadzić do nieefektywnych i nieczytelnych raportów. Dobrą praktyką jest zawsze dokładne zrozumienie celu zapytania oraz odpowiednie stosowanie klauzul WHERE, aby uniknąć zbędnych danych i skupić się na analizie konkretnych przypadków.
Pytanie 31

Zamieszczone zapytanie SQL przyznaje prawo SELECT:

GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost';
A. dla użytkownika root na serwerze sprzedawca
B. dla użytkownika root na serwerze localhost
C. do wszystkich tabel w bazie hurtownia
D. do wszystkich kolumn w tabeli hurtownia
Polecenie GRANT SELECT ON hurtownia.* TO sprzedawca@localhost; jest często źle interpretowane co prowadzi do błędnego przypisania uprawnień. Częstym problemem jest mylne przekonanie, że przyznanie uprawnień do wszystkich pól w tabeli oznacza to samo co do wszystkich tabel. Symbol * w poleceniu odnosi się do wszystkich tabel w bazie hurtownia a nie do wszystkich pól pojedynczej tabeli. To ważne rozróżnienie wpływa na sposób przyznawania i zarządzania uprawnieniami w kontekście bezpieczeństwa i dostępu do danych. Błędna interpretacja że uprawnienie dotyczy użytkownika root jest wynikiem niezrozumienia konwencji dotyczącej składni SQL gdzie specyficzna definicja użytkownika pojawia się po słowie TO w naszym przypadku jest to sprzedawca@localhost. To wyklucza użytkownika root z opcji możliwych odbiorców tego uprawnienia. Warto zwrócić uwagę że identyfikacja użytkownika sprzedawca@localhost jednoznacznie określa użytkownika działającego z lokalnego serwera a nie z dowolnego hosta co jest istotne z punktu widzenia bezpieczeństwa systemu. Zrozumienie tych niuansów jest kluczowe dla efektywnego zarządzania bazami danych i ochrony przed nieautoryzowanym dostępem. W praktyce przyznanie uprawnień powinno być starannie rozważone i dostosowane do potrzeb zgodnie z zasadą najmniejszych uprawnień co minimalizuje ryzyko błędów i nadużyć systemowych.
Pytanie 32

Zdefiniowanie klucza obcego jest niezbędne do utworzenia

A. klucza podstawowego.
B. relacji 1..1.
C. transakcji.
D. relacji 1..n.
Poprawnie – klucz obcy definiujemy właśnie po to, żeby utworzyć i wymusić relację między tabelami, najczęściej relację 1..n. W praktyce wygląda to tak, że w tabeli „dziecko” (np. ZAMOWIENIA) umieszczamy kolumnę, która odwołuje się do klucza głównego w tabeli „rodzic” (np. KLIENCI). Ta kolumna jest właśnie kluczem obcym. Dzięki temu każde zamówienie musi być powiązane z istniejącym klientem. To jest klasyczny przykład relacji 1 klient – wiele zamówień (1..n). Moim zdaniem to jest jeden z fundamentów relacyjnych baz danych: klucze obce pilnują integralności referencyjnej. Silnik bazy (MySQL, PostgreSQL, SQL Server itd.) sprawdza, czy wartość w kolumnie z kluczem obcym faktycznie istnieje w tabeli nadrzędnej. Jeżeli spróbujesz wstawić zamówienie z nieistniejącym id_klienta, dostaniesz błąd. To jest dokładnie to, co chcemy w dobrze zaprojektowanym systemie – brak „osieroconych” rekordów. W relacjach 1..n stosuje się standardowo schemat: tabela nadrzędna ma klucz podstawowy (PRIMARY KEY), a tabela podrzędna ma kolumnę z kluczem obcym (FOREIGN KEY), który wskazuje na ten klucz podstawowy. W SQL zapisuje się to np.: `FOREIGN KEY (id_klienta) REFERENCES klienci(id_klienta)`. Dobre praktyki mówią też, żeby na kolumnach kluczy obcych zakładać indeksy, bo to przyspiesza złączenia (JOIN) i operacje kasowania/aktualizacji. Warto też wiedzieć, że klucz obcy może być używany z dodatkowymi opcjami, np. `ON DELETE CASCADE` lub `ON UPDATE RESTRICT`, żeby automatycznie usuwać powiązane rekordy lub blokować operacje łamiące spójność danych. W realnych aplikacjach webowych (np. systemy sklepów internetowych, CRM-y, systemy magazynowe) poprawne zdefiniowanie relacji 1..n przez klucze obce to podstawa stabilności całej bazy – bez tego bardzo szybko robi się bałagan, duplikaty i niespójne dane.
Pytanie 33

W bazie danych sklepu internetowego, w tabeli klienci znajdują się m.in. pola całkowite: punkty, liczbaZakupow oraz pole ostatnieZakupy o typie DATE. Klauzula WHERE dla zapytania wybierającego klientów, którzy mają ponad 3000 punktów lub dokonali zakupów więcej niż 100 razy, a ich ostatnie zakupy miały miejsce co najmniej w roku 2022, przyjmuje postać

A. WHERE punkty > 3000 OR liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'
B. WHERE punkty > 3000 AND liczbaZakupow > 100 AND ostatnieZakupy >= '2022-01-01'
C. WHERE (punkty > 3000 OR liczbaZakupow > 100) AND ostatnieZakupy >= '2022-01'
D. WHERE punkty > 3000 AND liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'
Odpowiedź ta jest poprawna, ponieważ zastosowano w niej właściwą logikę warunków w klauzuli WHERE. Aby wybrać klientów, którzy spełniają co najmniej jeden z dwóch pierwszych warunków (posiadają więcej niż 3000 punktów lub wykonali więcej niż 100 zakupów), używamy operatora OR. Z kolei ostatni warunek, dotyczący daty ostatnich zakupów, musi łączyć się z poprzednimi za pomocą operatora AND. Oznacza to, że aby klient został uwzględniony w wynikach, musi spełniać przynajmniej jeden z warunków dotyczących punktów lub liczby zakupów, a równocześnie musi mieć ostatnie zakupy dokonane w roku 2022 lub później. Takie podejście jest zgodne z dobrymi praktykami w SQL, w których operator OR jest wykorzystywany do łączenia warunków alternatywnych, a AND do warunków koniecznych. Na przykład, jeśli chcemy analizować dane klientów w kontekście programów lojalnościowych, takie zapytanie pozwoliłoby nam na wyodrębnienie najbardziej aktywnych klientów, co może być przydatne przy planowaniu kampanii marketingowych.
Pytanie 34

W bazie danych wykonano następujące polecenia dotyczące uprawnień użytkownika adam. Po ich realizacji użytkownik adam uzyska uprawnienia do

GRANT ALL PRIVILEGES ON klienci TO adam
REVOKE SELECT, INSERT, UPDATE ON klienci FROM adam
A. modyfikowania danych i przeglądania tabeli klienci
B. usuwania tabeli lub jej rekordów
C. tworzenia tabeli klienci oraz modyfikowania w niej danych
D. przeglądania tabeli klienci oraz dodawania do niej sektorów
Analizując dostarczone polecenia SQL kluczowe jest zrozumienie jakie uprawnienia zostały przyznane użytkownikowi adam. Polecenie GRANT ALL PRIVILEGES przyznaje pełen zakres uprawnień do tabeli klienci co obejmuje operacje takie jak SELECT INSERT UPDATE DELETE oraz DROP. Jednakże w następnym kroku za pomocą polecenia REVOKE ograniczono specyficzne uprawnienia takie jak SELECT INSERT i UPDATE pozostawiając jedynie te które nie zostały wymienione co w tym przypadku oznacza usunięcie rekordów DELETE oraz całej tabeli DROP. Niezrozumienie znaczenia poszczególnych poleceń SQL oraz ich interakcji prowadzi do błędnych wniosków dotyczących zakresu możliwości użytkownika. Warto zwrócić uwagę że uprawnienia takie jak SELECT umożliwiają jedynie przeglądanie danych co nie jest zgodne z usunięciem danych ani tabeli. Podobnie INSERT pozwala na dodawanie nowych rekordów a nie ich usuwanie. UPDATE z kolei umożliwia modyfikację istniejących danych bez ich usunięcia. W kontekście zarządzania bazą danych ważne jest precyzyjne rozumienie jakie prawa są przyznawane i jakie konsekwencje to niesie dla bezpieczeństwa i operacyjności systemu bazodanowego. Niewłaściwe przypisanie uprawnień może prowadzić do nieautoryzowanego dostępu lub modyfikacji danych co stanowi poważne zagrożenie dla integralności danych oraz stabilności systemu. Zrozumienie różnic między poszczególnymi uprawnieniami jest fundamentalne dla zarządzania bazą danych zgodnie z najlepszymi praktykami branżowymi i standardami bezpieczeństwa informatycznego. Poprawna interpretacja poleceń SQL jest kluczowa dla zapewnienia odpowiedniego poziomu kontroli dostępu i ochrony danych w systemach bazodanowych.
Pytanie 35

Wskaż właściwą sekwencję kroków w procesie projektowania relacyjnej bazy danych?

A. Określenie kluczy głównych tabel, Określenie zbioru danych, Selekcja, Określenie relacji
B. Selekcja, Określenie relacji, Określenie kluczy głównych tabel, Określenie zbioru danych
C. Określenie zbioru danych, Selekcja, Określenie kluczy głównych tabel, Określenie relacji
D. Określenie relacji, Określenie kluczy głównych tabel, Selekcja, Określenie zbioru danych
Wybranie błędnej odpowiedzi sugeruje, że nie do końca rozumiesz, jak działa proces projektowania relacyjnej bazy danych. Kiedy kolejność kroków jest pomijana, mogą się pojawić problemy. Czasem widziałem, że klucze podstawowe są określane jeszcze przed zdefiniowaniem zbioru danych. To może prowadzić do błędnego przypisania kluczy do tabel. Klucz podstawowy powinien być oparty na wcześniej zdefiniowanych danych, żeby wszystko było unikalne i wartościowe. Jak się nie rozumie, jakie dane mają być w bazie, to ustalanie relacji na wyrost nie ma sensu. W praktyce, jeśli źle podchodzimy do projektowania bazy danych, to później mogą być kłopoty z zarządzaniem danymi, co wpłynie na efektywność naszej aplikacji. Dlatego warto skupić się na dobrze przemyślanym zbiorze danych zanim zaczniemy myśleć o kluczach i relacjach.
Pytanie 36

Istnieje tabela programisci z polami: id, nick, ilosc_kodu, ocena. Wartość w polu ilosc_kodu przedstawia liczbę linii kodu, które dany programista stworzył w określonym miesiącu. Aby obliczyć całkowitą liczbę linii kodu napisanych przez wszystkich programistów, należy zastosować następujące polecenie

A. SELECT SUM(ocena) FROM ilosc_kodu;
B. SELECT SUM(ilosc_kodu) FROM programisci;
C. SELECT MAX(ilosc_kodu) FROM programisci;
D. SELECT COUNT(programisci) FROM ilosc_kodu;
Poprawna odpowiedź to "SELECT SUM(ilosc_kodu) FROM programisci;" ponieważ to zapytanie dokładnie ilustruje, jak można obliczyć sumę wszystkich linii kodu napisanych przez programistów. Funkcja agregująca SUM() służy do sumowania wartości w podanym polu, które w tym przypadku jest polem "ilosc_kodu". W kontekście relacyjnych baz danych, stosowanie funkcji agregujących jest kluczowe do analizy danych w sposób statystyczny. W praktyce, takie zapytanie może być przydatne w raportach dotyczących wydajności zespołu programistycznego, gdzie analiza sumy napisanych linii kodu pozwala na ocenę produktywności oraz identyfikację programistów, którzy mogą potrzebować wsparcia w realizacji zadań. Ponadto, zgodnie z najlepszymi praktykami SQL, warto być świadomym kontekstu zapytań, a dobór odpowiednich funkcji agregujących, takich jak SUM(), COUNT(), AVG() itp., jest niezbędny do efektywnego przetwarzania danych.
Pytanie 37

Który z komponentów dokumentacji aplikacji powinien być zawarty w dokumentacji dla użytkownika?

A. Wyjaśnienie zastosowanych technologii oraz bibliotek
B. Opis algorytmów użytych w kodzie
C. Szczegółowy opis kodu źródłowego
D. Instrukcja obsługi funkcji systemu
Opis obsługi funkcji systemu jest kluczowym elementem dokumentacji użytkownika, ponieważ ma na celu dostarczenie końcowemu użytkownikowi informacji o tym, jak efektywnie korzystać z aplikacji. W dokumentacji tej powinny znajdować się instrukcje krok po kroku, przykłady zastosowań oraz wyjaśnienia dotyczące funkcji i interfejsu użytkownika. Przykładowo, jeśli aplikacja jest systemem zarządzania projektami, dokumentacja użytkownika powinna zawierać szczegółowe opisy, jak tworzyć nowe projekty, przypisywać zadania, zarządzać kalendarzem oraz generować raporty. Zgodnie z wytycznymi standardów dokumentacji, takich jak ISO/IEC/IEEE 26511, dokumentacja użytkownika powinna być pisana w sposób zrozumiały i przystępny, aby umożliwić użytkownikom szybkie przyswojenie informacji i skuteczne wykorzystanie aplikacji. Kluczowym celem takiej dokumentacji jest zminimalizowanie potrzeby wsparcia technicznego oraz zwiększenie satysfakcji użytkowników z korzystania z systemu.
Pytanie 38

Poleceniem SQL służącym do wstawiania nowego rekordu z danymi jest

A. CREATE
B. ADD
C. UPDATE
D. INSERT INTO
Poprawna odpowiedź to `INSERT INTO`, bo właśnie tym poleceniem w SQL dodajemy nowe rekordy (wiersze) do tabeli w bazie danych. W praktyce wygląda to najczęściej tak: `INSERT INTO klienci (imie, nazwisko, email) VALUES ('Jan', 'Kowalski', '[email protected]');`. Silnik bazy danych (np. MySQL, PostgreSQL, SQL Server) odczytuje listę kolumn, dopasowuje do nich wartości z sekcji `VALUES` i tworzy nowy wiersz. To jest podstawowa operacja DML (Data Manipulation Language), obok `UPDATE`, `DELETE` i `SELECT`. W dobrych praktykach zawsze warto jawnie podawać listę kolumn po `INSERT INTO`, zamiast polegać na kolejności kolumn w tabeli. Dzięki temu, gdy ktoś doda nową kolumnę do tabeli albo zmieni ich kolejność, nasze zapytania się nie „wysypią” albo – co gorsza – nie wstawią danych w złe pola. Moim zdaniem to jest jedna z tych rzeczy, które odróżniają kod „na szybko” od kodu, który można utrzymywać latami. Warto też pamiętać o kwestii typów danych: wartości podawane w `VALUES` muszą pasować do typów kolumn (np. tekst w `VARCHAR`, liczba w `INT`, data w `DATE`). W aplikacjach webowych zapytania `INSERT` bardzo często pojawiają się przy obsłudze formularzy – np. rejestracja użytkownika, zapis zamówienia, dodawanie komentarza. Dobrą praktyką jest również używanie parametrów zapytań (prepared statements), a nie sklejanie stringów, żeby uniknąć podatności na SQL Injection. Podsumowując: jeśli chcesz dodać nowy rekord do istniejącej tabeli, standard SQL przewiduje właśnie `INSERT INTO` jako właściwe i jedyne poprawne polecenie do tego celu.
Pytanie 39

W języku SQL do grupy operacji DCL (ang. Data Control Language) należą polecenia:

A. CREATE i DROP
B. SELECT i INSERT
C. DELETE i UPDATE
D. GRANT i REVOKE
W SQL rozróżnienie między DDL, DML i DCL jest kluczowe, bo każdy z tych zestawów poleceń odpowiada za inny obszar pracy z bazą danych. Wiele osób intuicyjnie wrzuca wszystkie komendy „do jednego worka”, a potem trudno jest im zrozumieć, gdzie kończy się manipulacja danymi, a zaczyna zarządzanie uprawnieniami. Data Control Language, czyli DCL, to bardzo wąska, ale ważna grupa poleceń, służąca wyłącznie do kontroli dostępu. W standardowym SQL do DCL zaliczamy praktycznie tylko GRANT i REVOKE. Odpowiedzi typu CREATE i DROP są kuszące, bo też brzmią „administracyjnie”, ale to już inna kategoria – DDL (Data Definition Language). CREATE, ALTER, DROP czy TRUNCATE służą do definiowania i modyfikowania struktury bazy: tworzą tabele, widoki, indeksy, usuwają obiekty. One nie zarządzają prawami użytkowników, tylko tym, jakie obiekty w ogóle istnieją. To, że często wykonuje je administrator, nie znaczy jeszcze, że należą do DCL. Z kolei SELECT, INSERT, UPDATE, DELETE to klasyczne DML (Data Manipulation Language). Te polecenia działają na rekordach: odczytują dane, dodają nowe wiersze, modyfikują istniejące, usuwają je. Typowy błąd myślowy polega na tym, że ktoś myśli: skoro DELETE usuwa dane, to trochę jak „kontrola”, więc może DCL. Niestety nie – DELETE w ogóle nie dotyka uprawnień, ono po prostu kasuje rekordy, o ile użytkownik już ma odpowiednie prawa. Dopiero DCL decyduje, czy użytkownik może wykonać DELETE na danej tabeli. To subtelne, ale bardzo ważne rozróżnienie. Moim zdaniem warto zapamiętać prosty schemat: DDL – struktura, DML – dane, DCL – uprawnienia. Wtedy łatwiej od razu skojarzyć, że tylko GRANT i REVOKE pasują do kategorii Data Control Language, a reszta odpowiedzi dotyczy zupełnie innych warstw pracy z bazą.
Pytanie 40

Jakie polecenie wydane z terminala systemu operacyjnego, które zawiera opcję --repair, pozwala na naprawę bazy danych?

A. create
B. mysqldump
C. truncate
D. mysqlcheck
Polecenie mysqlcheck jest narzędziem dostarczanym przez system zarządzania bazami danych MySQL, które służy do sprawdzania, naprawiania i optymalizowania tabel w bazach danych. Opcja --repair w tym kontekście umożliwia automatyczne naprawienie uszkodzonych tabel, co jest istotne dla zachowania integralności danych. Użytkownicy mogą zastosować to polecenie w sytuacjach, gdy występują problemy z danymi, na przykład po awarii systemu lub nieprawidłowym zamknięciu serwera. Przykład użycia to: 'mysqlcheck --repair --databases nazwa_bazy', co sprawia, że narzędzie automatycznie przeszuka wszystkie tabele w danej bazie i podejmie próby ich naprawy. Warto również zauważyć, że mysqlcheck pozwala na optymalizację tabel, co może przyspieszyć działanie bazy danych. W kontekście standardów, MySQL jako jeden z najpopularniejszych systemów bazodanowych jest szeroko stosowany w różnych aplikacjach, co czyni to narzędzie niezbędnym dla administratorów baz danych.
Rozpocznij nowy egzamin
Powrót do strony głównej