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: 12 czerwca 2026 14:21
Data zakończenia: 12 czerwca 2026 14:26

Egzamin niezdany

Wynik: 9/40 punktów (22,5%)

Wymagane minimum: 20 punktów (50%)

Nowe

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

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Sklep online używa tabeli faktury. W trakcie generowania faktury pole dataPlatnosci nie zawsze zostaje uzupełnione. Aby to skorygować, na zakończenie dnia trzeba wpisać bieżącą datę do rekordów, w których to pole nie jest wypełnione. Można to osiągnąć za pomocą kwerendy

A. UPDATE faktury SET dataPlatnosci=CURTIME() WHERE dataPlatnosci IS NOT NULL;

B. UPDATE faktury SET dataPlatnosci=CURDATE() WHERE dataPlatnosci IS NULL;

C. UPDATE faktury SET dataPlatnosci=CURTIME() WHERE id = 3;

D. UPDATE faktury SET dataPlatnosci=CURDATE() WHERE dataplatnosci = '0000-00-00';

Wybór innych opcji jest nieco problematyczny. Kwerenda, która ustawia dataPlatnosci na CURTIME() w wierszach, gdzie id = 3, nie jest zbyt sensowna, bo odnosi się tylko do jednego rekordu. Poza tym, CURTIME() zwraca czas, a nie datę, a w kontekście faktur to nie ma sensu, bo powinny mieć datę płatności, a nie tylko czas. Kolejna sprawa to aktualizacja dat w wierszach, gdzie dataPlatnosci IS NOT NULL, co prowadzi do utraty ważnych informacji. Tego typu podejście jest sprzeczne z zasadami ochrony danych i może narobić bałaganu przy audytach. I ostatnia opcja, która ustawia datę na '0000-00-00', to kompletna katastrofa. Takie coś wprowadza błędne dane, które mogą wywołać problemy później. Użycie '0000-00-00' jako znacznika braku daty jest do bani i może prowadzić do nieporozumień. Lepiej używać NULL, bo to standard w SQL. Wybierając złe opcje, nie tylko ograniczasz funkcjonalność, ale także łamiesz zasady dobrego zarządzania danymi.

Pytanie 2

Które polecenie wydane w konsoli systemowej przywróci bazę danych z kopii kopia.sql?

mysql -u root -p baza > kopia.sql

mysql -u root -p baza < kopia.sql

mysqldump -u root -p baza < kopia.sql

mysqldump -u root -p baza > kopia.sql

Kopię bazy tworzy się narzędziem mysqldump, a PRZYWRACA klientem mysql, przekierowując zawartość pliku SQL na jego wejście: mysql -u root -p baza < kopia.sql. Operator < kieruje treść pliku „do” programu (import), a > - „z” programu do pliku (eksport). Plik kopia.sql zawiera polecenia odtwarzające strukturę i dane. Dlatego bazę przywróci mysql -u root -p baza < kopia.sql.

Pytanie 3

Źródłem danych dla raportu może być

A. inny raport

B. makropolecenie

C. zapytanie INSERT INTO

D. tabela

Inny raport, chociaż może zawierać dane, nie jest źródłem danych w sensie strukturalnym, lecz raczej wynikiem przetwarzania informacji zawartych w tabelach. Raporty są generowane na podstawie danych zgromadzonych w tabelach, a nie bezpośrednio z innych raportów, co ogranicza ich użyteczność jako źródła danych. Makropolecenie, będące zbiorem instrukcji do automatyzacji procesów, również nie stanowi źródła danych, lecz narzędzie do przetwarzania lub manipulacji danymi, które znajdują się w tabelach. Użycie makropolecenia może prowadzić do generowania raportów, jednak sama jego struktura nie zawiera danych, które mają być raportowane. Zapytanie INSERT INTO jest instrukcją SQL używaną do dodawania danych do tabeli, ale nie jest źródłem danych w kontekście raportowania. To polecenie umożliwia wprowadzenie nowych rekordów do tabeli, a więc odgrywa rolę w aktualizacji danych, a nie w ich źródłowym dostarczaniu. Każda z tych opcji nie spełnia wymogu bycia źródłem danych w kontekście tworzenia raportu, co czyni je niewłaściwymi odpowiedziami.

Pytanie 4

Jak nazywa się WYBRANY minimalny zestaw atrybutów jednoznacznie identyfikujący każdy rekord (wartości unikalne i niepuste)?

A. obcym

B. kandydującym

C. głównym

D. złożonym

Pozostałe pojęcia są inne. Klucz OBCY wiąże tabele i wskazuje klucz główny innej tabeli. Klucz KANDYDUJĄCY to każdy taki minimalny zestaw - klucz główny to ten WYBRANY spośród kandydujących. „Złożony” mówi tylko, że klucz ma wiele pól. Wybrany identyfikator rekordu to klucz główny.

Pytanie 5

Dostępna jest tabela zatytułowana wycieczki, zawierająca kolumny nazwa, cena oraz miejsca (jako liczba dostępnych miejsc). Aby wyświetlić jedynie nazwy wycieczek, których cena jest poniżej 2000 złotych oraz posiadają co najmniej cztery dostępne miejsca, należy zastosować zapytanie

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

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

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

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

Zapytania, które nie były prawidłowe, operują na istotnych nieporozumieniach związanych z użyciem operatorów logicznych oraz z określeniem liczby wolnych miejsc. Przykłady te często wykorzystują operator OR, co prowadzi do sytuacji, w której jeden z warunków może być spełniony, a drugi nie. W szczególności, użycie operatora OR w kontekście zadań, które wymagają spełnienia obu warunków, prowadzi do nieprawidłowych wyników. Na przykład, zapytanie z OR zwróci wszystkie wycieczki, które mają cenę poniżej 2000 zł, niezależnie od tego, ile mają wolnych miejsc, co może skutkować wyświetleniem wycieczek, które w ogóle nie spełniają kryteriów dostępności. Dodatkowo, w jednym z zapytań zastosowano niewłaściwą wartość dla ilości wolnych miejsc - 'miejsca > 3' zamiast 'miejsca > 4', co również prowadzi do nieścisłości. Zmiana wartości progowej nie uwzględnia wymogu, by wycieczki miały przynajmniej cztery wolne miejsca, tym samym zmieniając sens zapytania. Kluczowym błędem jest zatem zrozumienie, że w kontekście filtrowania danych w bazie, zarówno operator AND, jak i precyzyjne określenie wartości granicznych są niezbędne dla uzyskania poprawnych i użytecznych wyników.

Pytanie 6

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

A. SELECT

B. UPDATE

C. INSERT INTO

D. ALTER TABLE

Wybór innych poleceń SQL do aktualizacji danych w tabelach pokazuje pewne nieporozumienia co do funkcji tych komend. Polecenie ALTER TABLE jest do zmiany struktury tabeli, a nie do aktualizacji danych w wierszach. Używamy go do dodawania lub usuwania kolumn, zmiany typów danych, ale nie do zmiany informacji w istniejących rekordach. A INSERT INTO służy do dodawania nowych wierszy, a to także nie jest to, czego potrzebujemy w przypadku aktualizacji. Takie podejście często prowadzi do błędnych wniosków, bo nie każde polecenie SQL można stosować zamiennie, co jest błędne. SELECT natomiast służy do odczytywania danych, a nie do ich zmiany. Użytkownicy czasami mylą te komendy, zwłaszcza jak nie znają jeszcze dobrze podstaw SQL. Kluczowe jest, aby zrozumieć, jakie operacje są możliwe w SQL i do czego służą, bo to pozwoli unikać błędnych decyzji i poprawić efektywność pracy z bazami danych.

Pytanie 7

Po wykonaniu przedstawionego poniżej polecenia SQL użytkownik Ela będzie mógł

GRANT SELECT, INSERT, UPDATE, DELETE ON baza1.tab1 TO 'Ela'@'localhost';

A. wykonywania wszelkich działań na danych

B. wykonywania wszystkich operacji na strukturze danych

C. jedynie dodawania i edytowania danych

D. jedynie tworzenia i zmiany struktury tabel

Polecenie SQL GRANT SELECT INSERT UPDATE DELETE ON baza1.tab1 TO 'Ela'@'localhost' przyznaje użytkownikowi Ela pełny dostęp do danych w tabeli tab1 w bazie danych baza1. Oznacza to możliwość wykonywania wszystkich operacji związanych z zarządzaniem danymi w tej tabeli. Komenda GRANT jest używana do nadawania uprawnień użytkownikom bazy danych. W tym przypadku uprawnienia obejmują SELECT do odczytu danych INSERT do dodawania nowych rekordów UPDATE do modyfikacji istniejących danych oraz DELETE do usuwania rekordów. Uprawnienia te pokrywają pełne spektrum operacji związanych z manipulacją danymi co jest kluczowe w sytuacjach gdzie użytkownik musi mieć elastyczność w zarządzaniu zawartością tabeli. Dobrymi praktykami jest ograniczanie nadawania takich szerokich uprawnień tylko wtedy gdy jest to absolutnie konieczne w celu minimalizacji ryzyka nieautoryzowanej manipulacji danymi. Rozumienie i zarządzanie uprawnieniami użytkowników jest kluczowym elementem bezpieczeństwa bazy danych ponieważ pozwala na kontrolę dostępu i zapewnienie integralności danych. Tak szeroki dostęp jak w tym przypadku powinien być przyznawany z rozwagą i jedynie zaufanym użytkownikom w środowiskach produkcyjnych gdzie dane są szczególnie wrażliwe.

Pytanie 8

Tabele Klienci oraz Zgloszenia są związane relacją jeden do wielu. Jakie polecenie należy wydać, aby uzyskać tylko opis zgłoszenia oraz odpowiadające mu nazwisko klienta dla zgłoszenia numer 5?

A. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.Klienci_id WHERE Zgloszenia.id = 5

B. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.id WHERE Zgloszenia.id = 5

C. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci ON Klienci.id = Zgloszenia.Klienci_id WHERE Klienci.id = 5

D. SELECT opis, nazwisko FROM Zgloszenia JOIN Klienci WHERE Klienci.id = 5

W przypadku nieprawidłowych odpowiedzi często występuje błędne rozumienie relacji i składni SQL. W pierwszym przykładzie, klauzula WHERE Klienci.id = 5 próbuje filtrować według identyfikatora klienta zamiast zgłoszenia, co nie jest zgodne z celem zapytania. Taki zapis prowadzi do niepoprawnych wyników, ponieważ zamiarem jest uzyskanie danych dla konkretnego zgłoszenia, a nie wszystkich zgłoszeń danego klienta. Innym częstym błędem jest pominięcie klauzuli ON w zapytaniu, co widać w trzeciej odpowiedzi. Bez określenia warunku łączenia, SQL nie ma informacji, jak powiązać rekordy z dwóch tabel, co może skutkować błędem lub zwróceniem niepoprawnych danych. W czwartym przypadku, klauzula ON jest błędnie skonstruowana, używając Klienci.id = Zgloszenia.id, co nie odpowiada relacji klucz główny-klucz obcy. Takie błędy wynikają z niezrozumienia struktury bazy danych i jej modeli relacyjnych. W praktyce, takie niepoprawne zapytania mogą prowadzić do błędnych wniosków, utraty integralności danych i problemów z wydajnością systemu. Aby tego uniknąć, istotne jest zrozumienie logicznej struktury bazy danych oraz poprawne stosowanie składni SQL, co jest kluczowe w pracy z relacyjnymi bazami danych. W profesjonalnym środowisku, testowanie i walidacja zapytań pomogą zidentyfikować i poprawić takie błędy przed wdrożeniem w produkcji.

Pytanie 9

W języku SQL polecenie INSERT INTO

A. aktualizuje rekordy określoną wartością.

B. dodaje pola do tabeli.

C. dodaje tabelę.

D. wprowadza dane do tabeli.

W SQL bardzo łatwo pomylić polecenia, bo wszystkie wyglądają dość podobnie, ale każde ma swoje wyraźne zadanie. INSERT INTO jest komendą typowo do pracy na danych, nie na strukturze bazy. Jeżeli ktoś myśli, że tym poleceniem „dodaje tabelę”, to miesza dwa różne obszary: definicję struktury i operacje na rekordach. Tworzenie nowej tabeli wykonuje się za pomocą CREATE TABLE, gdzie określamy nazwy kolumn, typy danych, klucze główne itd. INSERT zakłada, że tabela już istnieje i jest gotowa na przyjmowanie rekordów.

Podobnie błędne jest kojarzenie INSERT z dodawaniem pól (kolumn) do tabeli. Modyfikacja struktury tabeli, czyli dokładanie nowych kolumn, zmiana typów, usuwanie kolumn, to domena polecenia ALTER TABLE. To jest tzw. DDL (Data Definition Language). Natomiast INSERT należy do DML (Data Manipulation Language), czyli tej części SQL, która operuje na danych: INSERT, UPDATE, DELETE, SELECT. Jeśli próbujemy INSERT-em „dodać pole”, to tak jakby śrubokrętem próbować wbijać gwóźdź – czasem coś się tam stanie, ale to w ogóle nie to narzędzie.

Częstym nieporozumieniem jest też mylenie INSERT i UPDATE. UPDATE służy do aktualizacji istniejących rekordów, czyli zmiany wartości w wierszach, które już są w tabeli. Wykorzystuje się przy tym klauzulę WHERE, żeby wskazać, które rekordy mają zostać zmodyfikowane. INSERT natomiast zawsze tworzy nowy wiersz. Jeśli ktoś uważa, że INSERT „aktualizuje rekordy określoną wartością”, to tak naprawdę opisuje działanie UPDATE. W praktyce prowadzi to do błędów typu duplikowanie danych zamiast ich poprawiania.

Moim zdaniem największy błąd myślowy polega na wrzucaniu wszystkiego, co „coś zmienia w bazie”, do jednego worka. Tymczasem w dobrze zaprojektowanym systemie bazodanowym wyraźnie rozdziela się operacje na schemacie (CREATE, ALTER, DROP) od operacji na danych (INSERT, UPDATE, DELETE). Zrozumienie tej różnicy jest kluczowe, żeby pisać poprawne i bezpieczne zapytania SQL. INSERT INTO zawsze oznacza: dodaj nowy rekord do istniejącej tabeli, z wartościami zgodnymi z jej strukturą i ograniczeniami.

Pytanie 10

Kod SELECT imie, pesel, wiek FROM dane WHERE wiek IN (18,30) spowoduje wybranie

A. imion, nazwisk i numerów PESEL osób młodszych niż 18 lat

B. imion, numerów PESEL i wieku osób, które mają 18 lub 30 lat

C. imion, numerów PESEL oraz wieku ludzi mających ponad 30 lat

D. imion, numerów PESEL oraz wieku osób w przedziale 18 do 30 lat

Pierwsza odpowiedź, która wskazuje na osoby poniżej 18 lat, jest błędna. To zapytanie SQL nie ma na celu wybrania młodszych; przecież filtruje tych, którzy mają 18 lub 30 lat. Co do drugiej odpowiedzi, to sugeruje, jakoby zapytanie wybierało osoby w przedziale od 18 do 30, co też jest pomyłką. Operator IN wskazuje konkretne liczby, a nie przedzial, dlatego w tym przypadku wiek pośredni nie ma miejsca. Trzecia odpowiedź, dotycząca osób powyżej 30 lat, kompletnie nie pasuje, bo nie dotyczy tego, co jest w zapytaniu. Właściwie to nie ma związku między tą składnią SQL a osobami, które mają więcej niż 30 lat. Każda z tych odpowiedzi wynika z niepoprawnego zrozumienia, jakie jest intencja zapytania, które jasno wybiera osoby tylko w dwóch podanych przedziałach. Myślę, że ważne jest, żeby dobrze rozumieć, jak działają operatory w SQL, żeby unikać takich pomyłek i nieporozumień.

Pytanie 11

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

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

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

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

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

Relacja jeden do wielu polega na tym że jedna wartość z jednej tabeli może być związana z wieloma wartościami w innej tabeli W tym przypadku jeden klient może mieć wiele zamówień co oznacza że musimy dodać pole klucza obcego w tabeli Zamowienia które będzie odnosiło się do Klientów Klucz obcy w bazach danych to pole które odwołuje się do klucza głównego w innej tabeli Dobre praktyki projektowania baz danych sugerują aby takie połączenia realizować za pomocą kluczy obcych co pozwala na utrzymanie integralności danych oraz łatwiejsze ich przetwarzanie W praktyce oznacza to że w tabeli Zamowienia dodajemy pole które przechowuje ID z tabeli Klienci Standardy branżowe jak SQL ANSI określają sposób tworzenia takich relacji co zapewnia kompatybilność z większością systemów zarządzania bazami danych Dzięki temu możemy łatwo uzyskać wszystkie zamówienia przypisane do konkretnego klienta co jest funkcjonalnością często wymaganą w aplikacjach biznesowych

Pytanie 12

Aby stworzyć relację jeden do wielu, w tabeli po stronie wiele, co należy zdefiniować?

A. klucz sztuczny odnoszący się do kluczy podstawowych obu tabel

B. klucz obcy wskazujący na klucz obcy tabeli po stronie jeden

C. klucz obcy wskazujący na klucz podstawowy tabeli po stronie jeden

D. klucz podstawowy wskazujący na klucz podstawowy tabeli po stronie jeden

W kontekście relacji jeden do wielu w bazach danych, każda z podanych niepoprawnych opcji wprowadza w błąd odnośnie do zasady funkcjonowania kluczy obcych i ich roli w modelowaniu danych. Klucz obcy wskazujący na klucz obcy tabeli po stronie jeden jest konceptualnie błędny, ponieważ klucz obcy zawsze odnosi się do klucza podstawowego innej tabeli, a nie do innego klucza obcego. Taki układ narusza zasady referencyjności i integralności danych, co może prowadzić do trudności w utrzymaniu spójności w bazie. Kolejną niepoprawną opcją jest klucz sztuczny odnoszący się do kluczy podstawowych obu tabel. Klucze sztuczne, choć mogą być użyteczne w pewnych kontekstach, nie powinny być używane jako sposób tworzenia relacji, ponieważ nie odzwierciedlają naturalnych powiązań między danymi. Klucz podstawowy wskazujący na klucz podstawowy tabeli po stronie jeden również jest mylny, ponieważ w relacji jeden do wielu klucz podstawowy tabeli 'jeden' musi być referencjonowany przez klucz obcy w tabeli 'wiele', a nie odwrotnie. Te nieporozumienia mogą prowadzić do błędów projektowych w bazach danych, co w efekcie utrudnia ich rozwój i zarządzanie, szczególnie w dużych systemach, gdzie spójność danych jest kluczowa dla funkcjonowania aplikacji.

Pytanie 13

Utworzono bazę danych z tabelą mieszkancy, która zawiera pola: nazwisko, imie, miasto. Następnie zrealizowano poniższe zapytanie do bazy:

SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Poznań' UNION ALL SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Kraków';

Wskaź, które zapytanie zwróci te same dane.

A. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto='Poznań' OR miasto='Kraków';```

B. ```SELECT nazwisko, imie FROM mieszkancy AS 'Poznań' OR 'Kraków';```

C. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto BETWEEN 'Poznań' OR 'Kraków';```

D. ```SELECT nazwisko, imie FROM mieszkancy WHERE miasto HAVING 'Poznań' OR 'Kraków';```

Wszystkie niepoprawne odpowiedzi zawierają błędy syntaktyczne lub logiczne, które uniemożliwiają prawidłowe wykonanie zapytania. W pierwszej odpowiedzi użycie aliasu 'AS' jest niewłaściwe w tym kontekście, ponieważ nie można zastosować aliasu dla warunku w klauzuli WHERE. SQL nie interpretuje 'OR' w ten sposób, co powoduje, że zapytanie nie zwróci żadnych wyników. Druga odpowiedź z zastosowaniem klauzuli HAVING jest także błędna, ponieważ HAVING służy do filtrowania wyników po agregacji, a nie do prostego filtrowania danych w kolumnach. W tym przypadku poprawne byłoby użycie WHERE, które jest dedykowane do tego celu. Ostatnia odpowiedź z użyciem 'BETWEEN' jest zupełnie nieprawidłowa, ponieważ operator BETWEEN oczekuje dwóch wartości do porównania oraz nie może być używany z wieloma wartościami za pomocą 'OR'. W przypadku miast, powinno się stosować warunek, który precyzyjnie zdefiniuje, które miasta mają być brane pod uwagę, co w tej sytuacji nie zostało spełnione. Te błędy wskazują na nieprawidłowe zrozumienie zasad działania SQL oraz różnic pomiędzy operatorami logicznymi.

Pytanie 14

W tabeli zadania znajduje się pole tekstowe status. Jakie zapytanie należy użyć, aby usunąć te zadania, które mają status 'zamknięte'?

A. DELETE FROM zadania;

B. DELETE FROM zadania WHERE status = 'zamknięte';

C. TRUNCATE TABLE zadania;

D. TRUNCATE TABLE zadania WHERE status = 'zamknięte';

W przypadku pierwszej odpowiedzi, zastosowanie kwerendy TRUNCATE TABLE zadania jest niewłaściwe, ponieważ ta komenda usuwa wszystkie rekordy z tabeli bez możliwości określenia warunków. TRUNCATE jest bardziej efektywne w kontekście usuwania wszystkich danych, ale nie spełnia wymogu eliminacji jedynie tych z określonym statusem. Usunięcie wszystkich danych z tabeli mogłoby prowadzić do utraty cennych informacji, które mogą być potrzebne do analizy czy raportowania. W odniesieniu do kolejnej opcji, DELETE FROM zadania nie zawiera żadnego warunku, co również skutkuje usunięciem wszystkich wierszy. Brak warunku WHERE w tym kontekście wprowadza ryzyko nieodwracalnej utraty danych. Zastosowanie TRUNCATE TABLE zadania WHERE status = 'zamknięte' jest błędne, ponieważ TRUNCATE nie akceptuje klauzuli WHERE. Warto zwrócić uwagę, że TRUNCATE jest szybsze niż DELETE, ale użycie go bez warunków na pewno będzie prowadziło do nieefektywnego zarządzania danymi. Typowym błędem myślowym jest przekonanie, że TRUNCATE można stosować w taki sam sposób jak DELETE, co prowadzi do dużych konsekwencji w pracy z bazami danych. Ważne jest, aby przed wykonaniem operacji usuwania dokładnie rozważyć, które dane są istotne i uniknąć operacji, które mogą być nieodwracalne.

Pytanie 15

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. Tomasz i Adam

B. Anna i Tomasz

C. Jedynie Tomasz

D. Adam i Anna

Analizując inne odpowiedzi, można zauważyć, że niektóre z nich nie spełniają podstawowych wymogów związanych z przydzielaniem uprawnień w bazach danych. Na przykład, stwierdzenie, że tylko Anna ma prawo do przeglądania i modyfikowania danych, jest błędne, ponieważ w przydzielonych jej uprawnieniach nie ma komendy SELECT, która jest niezbędna do przeglądania danych. Uprawnienia ALTER, CREATE i DROP, które otrzymała, dotyczą jedynie zmiany struktury bazy, a nie samego przeglądania danych, co jest kluczowe dla jej roli w systemie. Warto także zwrócić uwagę na odpowiedź mówiącą o Tomaszu i Annie. Tomasz rzeczywiście ma przydzielone uprawnienia do przeglądania i modyfikacji danych, jednak Anna nie ma uprawnienia SELECT, więc nie może przeglądać danych. Analogicznie, odpowiedź wskazująca na Tomasza i Adama również pomija fakt, że Anna nie ma dostępu do przeglądania danych, co czyni ją nieprawidłową. W kontekście przydzielania uprawnień, istotne jest zrozumienie, że dostęp do danych powinien być zgodny z rolą użytkownika oraz zadaniami, jakie ma do wykonania. Właściwe przydzielenie uprawnień jest fundamentalne w zapewnieniu bezpieczeństwa danych i ich integralności.

Pytanie 16

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

A. INSERT INTO

B. UPDATE

C. ALTER TABLE

D. GRANT

Patrząc na Twoje odpowiedzi, inne opcje nie nadają się do modyfikacji struktury tabel w MySQL. Na przykład, 'INSERT INTO' służy do dodawania nowych wierszy do tabeli. To zupełnie coś innego niż zmiana samej struktury tabeli. Używanie 'INSERT INTO' może wprowadzić w błąd, jeśli ktoś myśli, że dodaje dane, a nie zmienia ich układ. 'UPDATE' z kolei zmienia dane, które już są w tabeli, ale nie zmienia struktury. Wiem, że sporo osób myli 'UPDATE' z dodawaniem kolumn, co jest kompletnie mylne. Natomiast 'GRANT' dotyczy zarządzania uprawnieniami użytkowników, więc też nie ma nic wspólnego z modyfikacją tabel. Warto zwracać uwagę na te różnice, bo pomyłki mogą prowadzić do problemów z aplikacjami i utraty danych. Zrozumienie, kiedy używać 'ALTER TABLE', a nie innego polecenia, to klucz do sukcesu w pracy z bazami danych.

Pytanie 17

Aby przy usunięciu rekordu nadrzędnego automatycznie usunęły się powiązane z nim rekordy podrzędne, w definicji klucza obcego dodaje się klauzulę:

ON DELETE SET NULL

ON DELETE CASCADE

ON DELETE RESTRICT

ON UPDATE CASCADE

ON DELETE CASCADE to opcja klucza obcego, która sprawia, że usunięcie rekordu w tabeli nadrzędnej automatycznie usuwa wszystkie powiązane z nim rekordy w tabeli podrzędnej. Zapobiega to pozostawieniu „osieroconych” wierszy wskazujących na nieistniejący rekord. Dodaje się ją w definicji klucza obcego, np. FOREIGN KEY(klient_id) REFERENCES klienci(id) ON DELETE CASCADE. Dlatego poprawna jest klauzula ON DELETE CASCADE.

Pytanie 18

Kwerenda pozwalająca zmienić wiele rekordów lub przenieść wiele rekordów w jednej operacji nosi nazwę kwerendy

A. krzyżowej

B. parametrycznej

C. wybierającej

D. funkcjonalnej

Pozostałe kwerendy nie modyfikują masowo danych. Wybierająca tylko odczytuje (SELECT), parametryczna pyta o wartość przed uruchomieniem, a krzyżowa podsumowuje dane w układzie tabelarycznym. Masowej zmiany rekordów dokonuje kwerenda funkcjonalna.

Pytanie 19

W instrukcji CREATE TABLE w SQL atrybut wskazujący, która kolumna w tabeli pełni rolę klucza podstawowego, to

A. MAIN KEY

B. PRIMARY KEY

C. UNIQUE

D. IDENTITY FIELD

Odpowiedzi takie jak 'UNIQUE', 'MAIN KEY' oraz 'IDENTITY FIELD' są niepoprawne z różnych powodów. Rozpoczynając od 'UNIQUE', warto zaznaczyć, że choć atrybut ten jest używany do zapewnienia unikalności wartości w kolumnie, nie definiuje on klucza podstawowego. Klucz podstawowy automatycznie implikuje unikalność, ale atrybut UNIQUE może być użyty w innych kontekstach, gdzie nie jest on kluczem podstawowym. Przechodząc do 'MAIN KEY', istotne jest, aby zauważyć, że nie istnieje taki standardowy termin w SQL; poprawnym terminem jest 'PRIMARY KEY', co może prowadzić do nieporozumień w zrozumieniu struktury bazy danych. Wreszcie, 'IDENTITY FIELD' odnosi się do konkretnej cechy kolumny w bazach danych, która automatycznie inkrementuje wartość (typowe dla kolumn klucza podstawowego), ale nie jest terminem używanym do definiowania klucza podstawowego jako takiego. Łatwo jest pomylić te koncepcje, zwłaszcza dla osób początkujących w SQL, dlatego ważne jest, aby zrozumieć specyfikę każdego z atrybutów oraz ich zastosowanie. Klucz podstawowy pełni fundamentalną rolę w zarządzaniu danymi i jego poprawna definicja jest kluczowa dla efektywności oraz integralności całej bazy.

Pytanie 20

W SQL, aby dokonać zmiany w strukturze tabeli, na przykład dodać lub usunąć kolumnę, powinno się użyć polecenia

A. UPDATE

B. TRUNCATE

C. DROP TABLE

D. ALTER TABLE

Wybór poleceń takich jak 'UPDATE', 'TRUNCATE' czy 'DROP TABLE' wskazuje na nieporozumienia dotyczące ich zastosowania w kontekście zmiany struktury tabeli. 'UPDATE' jest używane do modyfikacji danych już istniejących w tabeli, a nie do zmiany jej struktury. Umożliwia aktualizację wartości w kolumnach, jednak nie wpływa na same kolumny czy ich definicje. 'TRUNCATE' służy do szybkiego usuwania wszystkich rekordów z tabeli, ale nie można go używać do zmiany struktury tabeli ani do usunięcia kolumn. Tego typu operacja nie tylko nie jest możliwa, ale także wymaga innego podejścia niż modyfikacja struktury. Z kolei 'DROP TABLE' całkowicie usuwa tabelę i wszystkie jej dane, co jest drastycznym krokiem, gdyż skutkuje utratą wszystkich informacji w niej zawartych. Wybór tych poleceń wskazuje na typowe błędy myślowe związane z zamianą operacji na danych z operacjami na strukturze bazy danych. W praktyce, modyfikacje struktury tabel powinny być zawsze przemyślane i zaplanowane, aby zachować integralność danych oraz zgodność z wymaganiami aplikacyjnymi.

Pytanie 21

Tabela Pacjenci ma pola: imie, nazwisko, wiek, lekarz_id. Aby zestawić raport zawierający wyłącznie imiona i nazwiska pacjentów poniżej 18 roku życia, którzy zapisani są do lekarza o id równym 6, można posłużyć się kwerendą SQL

A. SELECT imie, nazwisko FROM Pacjenci WHERE wiek < 18 AND lekarz_id = 6;

B. SELECT imie, nazwisko WHERE wiek < 18 AND lekarz_id = 6;

C. SELECT imie, nazwisko WHERE wiek < 18 OR lekarz_id = 6;

D. SELECT imie, nazwisko FROM Pacjenci WHERE wiek < 18 OR lekarz_id = 6;

W tym zadaniu kluczowe są dwie rzeczy: poprawna składnia SQL i właściwe zrozumienie logiki warunków w klauzuli WHERE. Wiele osób intuicyjnie skupia się tylko na treści pytania i trochę pomija formalne wymagania języka, a to potem mści się w realnych systemach.
Pierwszy typ błędu to pomijanie klauzuli FROM. Instrukcje w stylu SELECT imie, nazwisko WHERE wiek < 18 ... wyglądają na pierwszy rzut oka sensownie, bo jest wybór kolumn i jest warunek, ale w SQL standardowo nie da się filtrować rekordów bez wskazania źródła danych. Serwer bazodanowy musi wiedzieć, z której tabeli pobrać kolumny imie, nazwisko, wiek i lekarz_id. Brak FROM Pacjenci powoduje po prostu błąd składni, a nie „prawie działającą” kwerendę. Z mojego doświadczenia to bardzo typowy błąd osób zaczynających przygodę z SQL: mieszanie logiki „co chcę” z tym „jak to ma być zapisane w języku”.
Drugi, bardziej podstępny problem to mylenie operatorów logicznych AND i OR. W zadaniu chodzi o pacjentów poniżej 18 roku życia, którzy jednocześnie są przypisani do lekarza o id = 6. To jest klasyczny przypadek koniunkcji – oba warunki muszą być spełnione. Użycie OR zamiast AND powoduje zupełnie inne działanie: zapytanie zwróci wszystkich pacjentów młodszych niż 18 lat niezależnie od lekarza, a dodatkowo wszystkich pacjentów lekarza nr 6 w każdym wieku. W praktyce taki raport byłby kompletnie niezgodny z założeniem, a co gorsza, na pierwszy rzut oka mógłby wyglądać „prawie dobrze”, bo część wyników się zgadza.
Warto też zwrócić uwagę na to, że przy prostych warunkach AND/OR bez nawiasów kolejność oceny może być myląca, dlatego dobrą praktyką w bardziej złożonych zapytaniach jest stosowanie nawiasów, np. WHERE (wiek < 18 AND lekarz_id = 6) OR ... itd. Tutaj warunek jest prosty, ale nawyk myślenia o logice boole’owskiej bardzo się przydaje.
Podsumowując, poprawne zapytanie musi mieć: wskazaną tabelę w klauzuli FROM, właściwie dobrane kolumny w SELECT oraz warunek z użyciem AND, który zawęża wynik do rekordów spełniających oba kryteria jednocześnie. Pomyłki w którymkolwiek z tych elementów prowadzą albo do błędu składni, albo – co gorsza – do logicznie błędnych raportów, których użytkownik nie zauważy od razu, a to w systemach produkcyjnych bywa naprawdę groźne.

Pytanie 22

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

A. CREATE

B. UPDATE

C. JOIN

D. SELECT

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

Pytanie 23

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(ilosc_kodu) FROM programisci;

B. SELECT MAX(ilosc_kodu) FROM programisci;

C. SELECT COUNT(programisci) FROM ilosc_kodu;

D. SELECT SUM(ocena) FROM ilosc_kodu;

Pierwsza z błędnych odpowiedzi, "SELECT COUNT(programisci) FROM ilosc_kodu;" zawiera fundamentalny błąd, gdyż funkcja COUNT() nie jest odpowiednia, gdy chcemy zsumować wartości liczby linii kodu. Funkcja COUNT() zlicza wiersze, ale nie sumuje wartości w kolumnach. Użycie jej w tym kontekście prowadzi do nieprawidłowych wyników i jest sprzeczne z zamiarem analizy danych. Z kolei odpowiedź "SELECT SUM(ocena) FROM ilosc_kodu;" łączy nieadekwatne elementy; pole "ocena" nie ma związku z analizowaną sumą linii kodu, co skutkuje brakiem sensu w kontekście zapytania. Warto zauważyć, że w SQL każda kolumna musi być właściwie zdefiniowana w kontekście używanych funkcji, a mieszanie danych z różnych pól bez logicznego uzasadnienia to typowy błąd myślowy. Ostatnia odpowiedź, "SELECT MAX(ilosc_kodu) FROM programisci;" także nie spełnia wymagań, ponieważ funkcja MAX() zwraca maksymalną wartość, a nie sumę. W praktyce, takie błędy mogą prowadzić do mylnych wniosków na temat produktywności zespołu, szczególnie gdy zapytania są używane do podejmowania decyzji biznesowych. Kluczowe jest, aby zrozumieć semantykę każdej funkcji SQL oraz zastosować je w odpowiednich kontekstach, co jest istotne dla skutecznej analizy danych w każdej organizacji.

Pytanie 24

Co PRZYSPIESZA wyszukiwanie danych, ale może spowolnić operacje zapisu (INSERT/UPDATE)?

A. indeksy

B. reguły

C. wartości domyślne

D. klucze podstawowe

Pozostałe elementy nie mają takiego kompromisu. Reguły i wartości domyślne dotyczą poprawności i wypełniania danych, a klucze podstawowe identyfikują rekordy (same w sobie nie są mechanizmem przyspieszania wyszukiwań po dowolnych polach). Przyspieszają odczyt kosztem zapisu indeksy.

Pytanie 25

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

NO REPEAT

UNIQUE

NOT NULL

SINGLE

Ograniczenie UNIQUE wymusza, że wartości w kolumnie nie mogą się powtarzać - baza odrzuci próbę wstawienia duplikatu. Stosuje się je np. do adresów e-mail, numerów PESEL czy loginów, gdzie każda wartość musi być niepowtarzalna, ale (w odróżnieniu od klucza głównego) kolumna może dopuszczać NULL. Definiuje się je przy kolumnie, np. email VARCHAR(100) UNIQUE. Dlatego brak powtórzeń zapewnia UNIQUE.

Pytanie 26

Do czego służy funkcja CONCAT() w SQL?

A. do przycinania tekstu

B. do usuwania wskazanego tekstu

C. do łączenia tekstów (konkatenacji)

D. do wyciągania podłańcucha

Pozostałe operacje wykonują inne funkcje. Usuwanie lub zamianę fragmentu robi REPLACE(), przycinanie - TRIM(), a wycinanie podłańcucha - SUBSTRING(). Łączeniem tekstów zajmuje się CONCAT().

Pytanie 27

Jakie informacje można uzyskać na temat normalizacji tej tabeli?

A. Tabela znajduje się w pierwszej postaci normalnej

B. Tabela znajduje się w trzeciej postaci normalnej

C. Tabela nie jest znormalizowana

D. Tabela jest w drugiej postaci normalnej

Tabela przedstawiona w pytaniu nie spełnia wymogów żadnej z trzech podstawowych postaci normalnych co oznacza że nie jest znormalizowana. Pierwsza postać normalna wymaga aby wszystkie wartości w tabeli były atomowe co oznacza że kolumna Adres powinna być podzielona na kilka kolumn takich jak ulica miasto i kod pocztowy. Druga postać normalna wymaga że wszystkie atrybuty niekluczowe muszą być deterministycznie zależne od całego klucza głównego co w tym przypadku nie ma zastosowania ponieważ tabela zawiera tylko dwa atrybuty i brak jest klucza złożonego. Trzecia postać normalna eliminuje wszelkie przejściowe zależności funkcyjne pomiędzy atrybutami niekluczowymi co również nie ma zastosowania w tej prostej strukturze. Typowe błędy myślowe prowadzące do niewłaściwych wniosków mogą obejmować niepełne zrozumienie zasad atomowości danych oraz błędne założenie że nieskomplikowana struktura tabeli automatycznie spełnia zasady normalizacji. Dlatego kluczowe jest aby dokładnie rozumieć i identyfikować zależności między danymi oraz jak te zależności wpływają na integralność i efektywność bazy danych co jest szczególnie istotne w dużych systemach gdzie dane są intensywnie modyfikowane i wykorzystywane przez wiele aplikacji jednocześnie. Właściwa normalizacja pozwala na optymalizację czasu dostępu do danych oraz minimalizację redundancji co jest uznawane za dobrą praktykę w branży projektowania baz danych. W kontekście projektowania systemów informatycznych poprawna normalizacja jest nieodłącznym elementem cyklu życia projektu zapewniającym że struktura danych jest odporna na zmiany w wymaganiach użytkowników oraz skalowalna w przypadku wzrostu ilości danych do obsługi przez system. Dlatego zrozumienie i prawidłowe stosowanie zasad normalizacji jest kluczowe dla przyszłych profesjonalistów w dziedzinie IT którzy będą odpowiedzialni za projektowanie i utrzymanie złożonych systemów bazodanowych.

Pytanie 28

Podane zapytanie SQL przyznaje użytkownikowi adam@localhost uprawnienia:

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

A. do manipulowania danymi bazy danych klienci

B. do zarządzania strukturą bazy danych klienci

C. do manipulowania danymi w tabeli klienci

D. do zarządzania strukturą tabeli klienci

Pozostałe opcje wskazują na zarządzanie strukturą bazy danych lub tabeli co w kontekście podanego polecenia SQL nie jest prawidłowe Zarządzanie strukturą bazy danych odnosi się do operacji takich jak tworzenie usuwanie lub modyfikowanie tabel indeksów i innych obiektów bazy danych Przykłady takich operacji to polecenia CREATE ALTER i DROP które zmieniają definicję strukturalną tabel lub innych obiektów bazodanowych W przypadku zarządzania strukturą tabeli moglibyśmy mówić o dodawaniu nowych kolumn zmienianiu typu danych istniejących kolumn czy zmianach w kluczach indeksach Tego typu zmiany nie są objęte poleceniem GRANT SELECT INSERT UPDATE DELETE które koncentruje się wyłącznie na manipulacji danymi w istniejącej strukturze Dlatego też typowym błędem myślowym jest utożsamianie operacji na danych z operacjami modyfikującymi strukturę bazy danych takimi jak dodawanie tabel czy kolumn Operatorzy SQL są precyzyjnie zdefiniowani i rozdzieleni na kategorie manipulacji danymi DML oraz definicji danych DDL co jest kluczowym rozróżnieniem w pracy z bazami danych

Pytanie 29

Dzięki poleceniu ALTER TABLE można

A. usunąć rekord

B. zmieniać wartości rekordów

C. skasować tabelę

D. zmieniać strukturę tabeli

Niektóre odpowiedzi mogą wydawać się na pierwszy rzut oka sensowne, jednak po głębszej analizie widać, że są one błędne. Zmiana wartości rekordów nie jest możliwa przy użyciu polecenia ALTER TABLE. To zadanie realizuje się za pomocą polecenia UPDATE, które umożliwia modyfikację danych istniejących w tabeli. Tabela jest strukturą danych, która przechowuje rekordy, więc usunięcie tabeli odbywa się przy użyciu polecenia DROP TABLE, a nie ALTER TABLE. Podobnie, usunięcie pojedynczego rekordu w tabeli to operacja, którą wykonujemy przy pomocy polecenia DELETE. Zrozumienie różnic między tymi poleceniami jest kluczowe dla efektywnego zarządzania bazami danych. Często popełnianym błędem jest mylenie poleceń, co może prowadzić do niezamierzonych skutków, takich jak utrata danych czy naruszenie integralności bazy. Na przykład, użycie ALTER TABLE w kontekście dodawania kolumny, a następnie nieprzemyślane usunięcie kolumny za pomocą DELETE spowoduje, że nie tylko stracimy całą kolumnę, ale również naruszymy relacje w bazie danych. Dlatego ważne jest, aby znać właściwe komendy oraz ich zastosowania, aby unikać nieporozumień i błędów w przyszłości.

Pytanie 30

W relacyjnym modelu danych, krotki definiuje się jako

A. wszystkie kolumny tabeli, które reprezentują atrybuty obiektu

B. wiersze tabeli wyłączając wiersz nagłówkowy, w którym znajdują się nazwy kolumn

C. wszystkie wiersze w tabeli łącznie z wierszem nagłówkowym

D. liczbę rekordów w tabeli

W relacyjnych bazach danych ważne jest, żeby wiedzieć, czym różnią się wiersze od kolumn. Jak ktoś twierdzi, że krotkami są wszystkie wiersze tabeli razem z nagłówkiem, to nie do końca tak jest. Wiersz nagłówkowy ma znaczenie, bo pokazuje strukturę danych, ale nie wchodzi w skład krotek. Z kolei określanie krotek jako liczby rekordów w tabeli jest mało precyzyjne, bo to nie oddaje tego, co naprawdę oznaczają krotki. Kolejna błędna odpowiedź, która mówi, że krotkami są wszystkie kolumny, może wprowadzać w błąd, bo kolumny definiują atrybuty, ale same w sobie nie przechowują danych. W kontekście baz danych, krotki są kluczowe dla zrozumienia, jak te dane są poukładane, a ich dobre zdefiniowanie sprawia, że zarządzanie informacjami staje się łatwiejsze. Żeby unikać błędów przy projektowaniu baz danych, trzeba pamiętać, że krotki to zestawy wartości atrybutów, które można porównywać i obrabiać w SQL. Takie podejście jest ważne, żeby poprawnie tworzyć zapytania i zarządzać danymi w różnych systemach baz danych.

Pytanie 31

W języku SQL dodanie nowej kolumny z nazwą miejscowości do istniejącej tabeli pracownicy umożliwia kwerenda

A. ALTER TABLE pracownicy DROP COLUMN miejscowosc;

B. ALTER TABLE pracownicy ADD miejscowosc FLOAT(2);

C. CREATE TABLE pracownicy ADD miejscowosc FLOAT(2);

D. ALTER TABLE pracownicy ADD miejscowosc VARCHAR(100);

Żeby dobrze zrozumieć to zadanie, trzeba rozdzielić trzy różne obszary: modyfikację istniejącej tabeli, tworzenie nowej tabeli oraz usuwanie elementów z tabeli. W pytaniu chodzi konkretnie o dodanie nowej kolumny do już istniejącej tabeli pracownicy. To od razu sugeruje użycie instrukcji ALTER TABLE z klauzulą ADD, bo właśnie ta kombinacja jest standardowym sposobem modyfikowania struktury tabeli w SQL.

Jednym z częstych nieporozumień jest użycie nieodpowiedniego typu danych. W niektórych odpowiedziach pojawia się typ FLOAT(2) dla nazwy miejscowości. FLOAT jest typem liczbowym zmiennoprzecinkowym, używanym do przechowywania wartości numerycznych, np. cen, pomiarów czy wyników obliczeń. Nazwa miasta to typowe dane tekstowe, czyli powinna być przechowywana w typie znakowym, takim jak VARCHAR czy ewentualnie CHAR. Próba użycia typu liczbowego do przechowywania tekstu jest po prostu sprzeczna z logiką projektowania baz danych i dobrymi praktykami normalizacji, bo utrudnia walidację i późniejsze operacje na danych.

Inny błąd to sięganie po instrukcję DROP COLUMN. DROP w kontekście ALTER TABLE oznacza usunięcie kolumny z tabeli, a nie jej dodanie. Jeśli ktoś nieuważnie czyta polecenie lub myli słowa kluczowe, może mu się wydawać, że DROP „coś zmienia w strukturze”, ale kierunek jest dokładnie odwrotny do wymaganego – kolumna miejscowosc zostałaby usunięta (o ile w ogóle istnieje), a nie dodana. W praktyce administracji bazą jest to bardzo niebezpieczna pomyłka, bo DROP COLUMN usuwa dane bezpowrotnie.

Zdarza się też pomylenie CREATE TABLE z ALTER TABLE. CREATE TABLE służy do zakładania całkowicie nowej tabeli, a nie do modyfikacji istniejącej. Składnia CREATE TABLE nie przewiduje klauzuli ADD w środku, tylko od razu listę kolumn w nawiasach. Próba napisania czegoś w stylu CREATE TABLE pracownicy ADD ... jest po prostu składniowo błędna w SQL i żadna sensowna baza nie przyjmie takiego polecenia. To typowy błąd osób, które pamiętają, że „ADD dodaje kolumnę”, ale nie łączą tego poprawnie z kontekstem ALTER TABLE.

Z mojego doświadczenia dobrą praktyką jest zawsze zadanie sobie dwóch pytań: czy tabela już istnieje, oraz czy chcę coś dodać, usunąć czy zmienić. Jeśli tabela istnieje i coś dokładamy – używamy ALTER TABLE ... ADD ..., dobierając typ danych zgodny z charakterem informacji. W tym zadaniu wszystkie błędne odpowiedzi łamią jedną z tych zasad: albo używają złego typu (FLOAT zamiast tekstu), albo złego słowa kluczowego (DROP zamiast ADD), albo złej instrukcji (CREATE TABLE zamiast ALTER TABLE).

Pytanie 32

Które polecenie MySQL aktualizuje statystyki tabeli wykorzystywane przez optymalizator zapytań?

RESTORE TABLE

BACKUP TABLE

REPAIR TABLE

ANALYZE TABLE

Pozostałe polecenia robią co innego. REPAIR TABLE próbuje naprawić fizycznie uszkodzoną tabelę - to operacja ratunkowa, nie strojenie wydajności. Polecenia w stylu RESTORE TABLE czy BACKUP TABLE kojarzą się z kopiami zapasowymi i odtwarzaniem danych, a nie ze statystykami optymalizatora (kopie w MySQL robi się raczej narzędziami typu mysqldump). Przeliczenie statystyk rozkładu danych dla planera zapytań wykonuje ANALYZE TABLE, dlatego to ono jest poprawne.

Pytanie 33

Na przedstawionej tabeli samochody wykonano zapytanie SQL SELECT

SELECT model FROM samochody WHERE rocznik = 2016;

id	marka	model	rocznik	kolor	stan
1	Fiat	Punto	2016	czerwony	bardzo dobry
2	Fiat	Punto	2002	czerwony	dobry
3	Fiat	Punto	2007	niebieski	bardzo dobry
4	Opel	Corsa	2016	grafitowy	bardzo dobry
5	Opel	Astra	2003	niebieski	porysowany lakier
6	Toyota	Corolla	2016	czerwony	bardzo dobry
7	Toyota	Corolla	2014	szary	dobry
8	Toyota	Yaris	2004	granatowy	dobry

A. Czerwony, grafitowy.

B. Punto, Corsa, Astra, Corolla, Yaris.

C. Fiat, Opel, Toyota.

D. Punto, Corsa, Corolla.

Niepoprawne odpowiedzi pokazują częste błędy w interpretacji zapytań SQL. Pierwszy z nich to pomylenie kolumny - zapytanie 'SELECT model FROM samochody WHERE rocznik = 2016' odnosi się do kolumny 'model', a nie 'kolor', co wyklucza odpowiedź 'Czerwony, grafitowy'. Drugi błąd to niewłaściwe zrozumienie klauzuli WHERE - jest ona używana do filtrowania rekordów na podstawie konkretnych warunków. W tym przypadku, zapytanie dotyczyło modeli samochodów z rocznika 2016, co wyklucza odpowiedź 'Punto, Corsa, Astra, Corolla, Yaris', ponieważ zawiera modele z innymi rocznikami. Trzeci błąd to pomylenie kolumn - zapytanie odnosiło się do 'model', a nie 'marka', co oznacza, że odpowiedź 'Fiat, Opel, Toyota' jest nieprawidłowa. Ważne jest, aby dokładnie zrozumieć strukturę tabeli i zapytania SQL przed próbą interpretacji wyników.

Pytanie 34

Jakie mechanizmy przydzielania zabezpieczeń, umożliwiające przeprowadzanie operacji na bazie danych, są powiązane z zagadnieniami dotyczącymi zarządzania kontami, użytkownikami oraz uprawnieniami?

A. Z atrybutami

B. Z przywilejami systemowymi

C. Z regułami

D. Z przywilejami obiektowymi

Przywileje systemowe odnoszą się do uprawnień, które są nadawane użytkownikom w kontekście zarządzania kontami i dostępem do zasobów w systemach baz danych. Te mechanizmy są kluczowe dla zapewnienia bezpieczeństwa oraz integralności danych. Przykładem przywilejów systemowych mogą być uprawnienia do tworzenia i usuwania innych kont użytkowników, a także do modyfikacji struktur danych, co jest fundamentalne w operacjach administracyjnych. W praktyce, administratorzy baz danych wykorzystują te przywileje do określenia, które konta mają dostęp do określonych funkcji systemu. W standardach takich jak SQL standard, zarządzanie uprawnieniami jest ściśle zdefiniowane, co pozwala na audyt i kontrolę dostępu. Aby stosować dobre praktyki, warto wdrożyć zasadę najmniejszych uprawnień, co oznacza, że użytkownicy powinni otrzymywać tylko te uprawnienia, które są niezbędne do wykonywania ich zadań. Dzięki temu minimalizujemy ryzyko nieautoryzowanego dostępu oraz potencjalnych naruszeń bezpieczeństwa.

Pytanie 35

Na zakończenie dnia w systemie zarządzania magazynem sklepu spożywczego generowany jest raport, który przedstawia produkty oraz ich dostawców, dla których ilość na stanie jest mniejsza niż 10 sztuk. Do stworzenia tego raportu zastosowano kwerendę

A. UPDATE

B. SELECT

C. CHECK TABLE

D. INSERT INTO

Odpowiedź 'SELECT' jest poprawna, ponieważ to polecenie służy do pobierania danych z bazy danych. Kwerenda SELECT umożliwia zdefiniowanie, jakie kolumny oraz z jakich tabel chcemy wyświetlić. W kontekście raportu dla sklepu spożywczego, który wyświetla produkty z ich dostawcami, gdzie stan magazynowy jest mniejszy niż 10 sztuk, kwerenda SELECT pozwoli na precyzyjne określenie kryteriów wyszukiwania, takich jak nazwa produktu, nazwa dostawcy oraz warunek dotyczący stanu magazynowego. Przykładowa kwerenda mogłaby wyglądać następująco: 'SELECT product_name, supplier_name FROM inventory WHERE stock < 10'. W praktyce, stosowanie kwerend SELECT w raportach umożliwia monitorowanie stanów magazynowych, co jest kluczowe dla efektywnego zarządzania zapasami oraz podejmowania decyzji o zamówieniach. Takie podejście jest zgodne z dobrymi praktykami w zarządzaniu danymi w sklepach detalicznych, gdzie ciągłe monitorowanie stanu magazynowego jest kluczowe dla utrzymania płynności sprzedaży i zadowolenia klientów.

Pytanie 36

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

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

A. Tabela jest w trzeciej postaci normalnej

B. Tabela znajduje się w pierwszej postaci normalnej

C. Tabela znajduje się w drugiej postaci normalnej

D. Tabela nie została znormalizowana

Pierwsza postać normalna wymaga aby wszystkie wartości atrybutów w rekordzie były atomowe czyli nieredukowalne Tabela przedstawiona w zadaniu nie spełnia tego wymogu ponieważ adresy nie są rozbite na osobne elementy takie jak ulica miasto i kod pocztowy co uniemożliwia bardziej złożoną manipulację danymi oraz precyzyjne wyszukiwanie Druga postać normalna wymaga aby wszystkie atrybuty nie będące częścią klucza głównego były w pełni funkcjonalnie zależne od całego klucza Tabela z pytania nie spełnia tych kryteriów ponieważ istnieje redundancja i brak wyraźnej struktury Klucz główny w dobrze zaprojektowanej tabeli bazy danych powinien jednoznacznie identyfikować każdy wiersz co nie jest widoczne w tej strukturze Trzecia postać normalna idzie krok dalej eliminując zależności przechodnie między atrybutami co w przypadku tej tabeli również nie ma zastosowania Problemem tutaj jest brak rozdzielenia danych na mniejsze tabele co prowadzi do redundancji i potencjalnych błędów przy aktualizacji danych często określanych jako anomaly W dobrze znormalizowanej bazie danych oddzielenie informacji takich jak dane adresowe umożliwia lepszą organizację danych ich spójność oraz zwiększa efektywność operacji na bazie danych

Pytanie 37

Zaproponowana baza danych składa się z trzech tabel oraz dwóch relacji. Żeby uzyskać listę wszystkich lekarzy przypisanych do danego pacjenta, konieczne jest porównanie kluczy

A. Lekarze.id = Pacjenci.Recepty_id

B. Lekarze.id = Pacjenci.Lekarze_id

C. Lekarze.id = Pacjenci.id

D. Lekarze.id = Recepty.id

Wybór niepoprawnych odpowiedzi często wynika z błędnego zrozumienia relacji między tabelami w bazie danych. Pierwsza opcja Lekarze.id = Pacjenci.id sugeruje mylne podejście że lekarz i pacjent mogą być tym samym podmiotem co jest sprzeczne z zasadą separacji encji w relacyjnych bazach danych. Taka relacja nie ma logicznego sensu w kontekście medycznym gdzie lekarz to osoba świadcząca usługi zdrowotne a pacjent to osoba je otrzymująca. Podobnie opcja Lekarze.id = Pacjenci.Recepty_id nie jest poprawna gdyż sugeruje bezpośrednią relację między lekarzami a lekami przepisanymi pacjentowi co ignoruje fakt że recepty są osobnymi dokumentami generowanymi w procesie leczenia. Recepty są przypisane do pacjentów ale to lekarze zlecają je poprzez interakcję z pacjentem nie bezpośrednio z receptą. Ostatnia opcja Lekarze.id = Recepty.id sugeruje relację bezpośrednią między lekarzami a receptami z pominięciem pacjentów co jest błędnym uproszczeniem procesu przepisywania leków. W rzeczywistości każda recepta jest wynikiem interakcji między lekarzem a pacjentem i nie istnieje bezpośrednia zależność między lekarzem a receptą. Takie myślenie prowadzi do błędów w projektowaniu struktury bazy danych co może skutkować trudnościami w zarządzaniu danymi i utrzymaniu ich spójności. Zrozumienie prawidłowych relacji między tabelami w bazie danych jest kluczowe dla efektywnego zarządzania informacją i eliminacji błędów w aplikacjach biznesowych.

Pytanie 38

Jaką wiadomość należy umieścić w przedstawionym fragmencie kodu PHP zamiast znaków zapytania? $a=mysql_connect('localhost','adam','mojeHasło'); if(!$a) echo "?????????????????????????";

A. Wybrana baza danych nie istnieje

B. Błąd połączenia z serwerem SQL

C. Błąd w przetwarzaniu zapytania SQL

D. Rekord został pomyślnie dodany do bazy

Wybranie innej opcji niż 'Błąd połączenia z serwerem SQL' jest mylne, ponieważ każda z tych odpowiedzi nie odnosi się do kontekstu błędu połączenia z bazą danych. Stwierdzenie 'Wybrana baza nie istnieje' sugeruje, że połączenie z serwerem SQL zostało nawiązane, ale nie udało się znaleźć konkretnej bazy danych. W rzeczywistości jednak błąd przy próbie połączenia z serwerem SQL jest czymś innym, ponieważ w momencie, gdy połączenie się nie udaje, nie można jeszcze mówić o istnieniu czy nieistnieniu bazy. Kolejna opcja, 'Pomyślnie dodano rekord do bazy', jest oczywiście błędna, ponieważ w przypadku braku połączenia nie ma możliwości dodania jakiegokolwiek rekordu. Ta odpowiedź myli koncepcję pomyślnego wykonania operacji z brakiem połączenia z bazą danych. Ostatecznie, 'Błąd przetwarzania zapytania SQL' również jest niepoprawny w tym kontekście, ponieważ odnosi się do sytuacji, w której połączenie z bazą danych zostało nawiązane, ale zapytanie SQL nie mogło zostać przetworzone z powodu błędów składniowych, braku uprawnień lub innych problemów. Jednak w przypadku problemu z połączeniem nie dochodzi nawet do etapu przetwarzania zapytania, co czyni tę odpowiedź nieadekwatną.

Pytanie 39

W tabeli produkt znajdują się artykuły wyprodukowane po roku 2000, posiadające pola nazwa oraz rok_produkcji. Jakie zapytanie SQL pokaże listę artykułów wyprodukowanych?

A. przed rokiem 2017

B. po roku 2017

C. w latach innych niż 2017

D. w roku 2017

Klauzula SQL wykorzystuje funkcję SUBSTR aby wyekstrahować dwie cyfry z roku produkcji zaczynając od trzeciej pozycji. To oznacza że bierze dwie cyfry odpowiadające końcówce roku. W ten sposób SELECT * FROM produkt WHERE SUBSTR(rok_produkcji3 2)=17; wyszukuje przedmioty których rok produkcji kończy się na 17 co wskazuje że zostały wyprodukowane w 2017 roku. Jest to efektywna metoda pod warunkiem że dane w kolumnie rok_produkcji są przechowywane jako ciągi znaków i spełniają wymagany format YYYY. Praktyczne zastosowanie tego podejścia jest szczególnie przydatne w bazach danych gdzie mogą występować różne formaty zapisu dat. Ważne jest aby zawsze upewnić się że dane są odpowiednio ujednolicone. Korzystanie z funkcji jak SUBSTR jest standardową praktyką w SQL umożliwiającą dynamiczne manipulowanie tekstem co czyni zapytania bardziej elastycznymi. Zrozumienie tego mechanizmu jest kluczowe dla efektywnego zarządzania bazami danych w kontekście filtrowania danych na podstawie ich struktur tekstowych.

Pytanie 40

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

A. ustalanie limitów przestrzeni na dysku

B. określanie zakresu tabel

C. wykorzystanie makr

D. przypisanie uprawnień

Brak odpowiedzi na to pytanie.

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

Rozpocznij nowy egzamin

Powrót do strony głównej