Wyniki egzaminu

Nowy egzamin
Informacje o egzaminie:
  • Zawód: Technik programista
  • Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
  • Data rozpoczęcia: 10 kwietnia 2026 09:50
  • Data zakończenia: 10 kwietnia 2026 09:50

Egzamin niezdany

Wynik: 6/40 punktów (15,0%)

Wymagane minimum: 20 punktów (50%)

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

W języku PHPnie ma możliwości

A. przetwarzanie danych z formularzy
B. obróbka informacji przechowywanych w bazie danych
C. tworzenie dynamicznej zawartości strony internetowej
D. zmienianie dynamiczne treści strony HTML w przeglądarce
Pomimo powszechnej wiedzy o zastosowaniach PHP, istnieje pewne nieporozumienie dotyczące jego funkcji w kontekście dynamicznych zmian na stronach internetowych. PHP jest używane do przetwarzania danych po stronie serwera, co oznacza, że jego zadaniem jest generowanie treści, które są następnie wysyłane do przeglądarki użytkownika. Pierwsza z niepoprawnych odpowiedzi sugeruje, że PHP może przetwarzać dane zgromadzone w bazie danych, co jest prawdą, jednak nie odnosi się do sedna pytania. PHP efektywnie współpracuje z bazami danych za pomocą zapytań SQL, ale to, co jest zwracane, to statyczny kod HTML. W kontekście generowania dynamicznej zawartości strony, PHP może być użyte do stworzenia HTML, ale nie do jego późniejszej modyfikacji w przeglądarce. Odpowiedź dotycząca generowania dynamicznej zawartości nie uwzględnia, że zmiany te są wynikiem działania PHP przed wysłaniem danych do klienta. Kolejna odpowiedź, sugerująca, że PHP może bezpośrednio zmieniać HTML w przeglądarkach, myli funkcjonalności języka. Nowoczesne aplikacje webowe często wykorzystują JavaScript do interakcji z użytkownikiem po załadowaniu strony, co pozwala na dynamiczne zmiany bez konieczności ponownego ładowania strony. Również przetwarzanie danych formularzy jest zadaniem, które PHP wykonuje, ale dotyczy to głównie zbierania i przesyłania danych do serwera, a nie modyfikacji treści na stronie po jej załadowaniu. Podsumowując, kluczowym aspektem jest zrozumienie, że PHP jest językiem po stronie serwera, a wszelkie dynamiczne interakcje w przeglądarkach powinny być zarządzane za pomocą technologii klienckich, takich jak JavaScript, co jest zgodne z aktualnymi standardami tworzenia aplikacji webowych.
Pytanie 2

Aby zapewnić integralność danych w bazie programu Microsoft Access, należy zastosować

A. więzy integralności
B. defragmentację bazy
C. archiwizację bazy
D. kwerendę aktualizującą
Kwerendy aktualizujące są narzędziem, które służą do modyfikacji istniejących danych w bazie, ale nie są one odpowiednie do zapewnienia spójności danych. Ich podstawowym celem jest wprowadzanie zmian, takich jak aktualizacja wartości w tabelach, co może prowadzić do niezamierzonych błędów, jeśli nie są stosowane ostrożnie i z pełną świadomością istniejących więzów integralności. Defragmentacja bazy to proces optymalizacji, który ma na celu poprawę wydajności dostępu do danych przez reorganizację zapisanych danych na dysku, ale nie wpływa na spójność samych danych. Chociaż defragmentacja jest istotna z perspektywy wydajności, nie ma bezpośredniego wpływu na to, czy dane są poprawne czy spójne. Archiwizacja bazy odnosi się do procesu przenoszenia danych do archiwum, co ma na celu zwolnienie miejsca w głównej bazie danych, ale także nie ma nic wspólnego z zapewnieniem integralności danych. Archiwizacja, choć pomocna w zarządzaniu dużymi zbiorami danych, nie eliminuje ryzyka wystąpienia błędów w danych, które mogą pozostać w aktywnej bazie. Wszystkie te podejścia mają swoje zastosowanie, ale nie są metodami zapewniającymi spójność danych na poziomie strukturalnym, jak to robią więzy integralności.
Pytanie 3

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

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

Klucz obcy w bazie danych jest tworzony w celu

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

W podanym fragmencie zapytania w języku SQL, komenda SELECT jest używana do zwrócenia SELECT COUNT(wartosc) FROM …

A. summy w kolumnie wartosc
B. średniej w kolumnie wartosc
C. ilości wierszy
D. średniej wartości z tabeli
No, trochę jest tu pomyłka. Ludzie często mylą to zapytanie SELECT COUNT(wartosc) z sumowaniem wartości, co nie jest do końca poprawne. Funkcja COUNT nie sumuje wartości, ona tylko liczy, ile jest niepustych wierszy. Więc jeżeli ktoś twierdzi, że to daje średnią, to wprowadza w błąd – średnią liczymy z pomocą funkcji AVG, a nie COUNT. W kolumnie 'wartosc' mogą być różne liczby, a suma wartości nie ma wiele wspólnego z tym, ile jest wierszy. Dobrze jest pamiętać, że średnia to coś innego niż liczba wierszy, co jest ważne do zrozumienia, jak działają zapytania w SQL. Jeśli ktoś myli te funkcje, to może się zgubić w analizie danych. Więc ogólnie mówiąc, warto wiedzieć, czym różnią się COUNT, AVG i inne funkcje agregujące, bo to kluczowe do ogarnięcia pracy z bazami danych.
Pytanie 6

Który typ relacji wymaga stworzenia tabeli pośredniczącej łączącej klucze główne obu tabel?

A. n..1
B. 1..1
C. 1..n
D. n..n
Wybór relacji 1..1 sugeruje, że jeden rekord w pierwszej tabeli jest powiązany z dokładnie jednym rekordem w drugiej tabeli, co nie wymaga tabeli pośredniej. Przykładem może być relacja między tabelą 'Pracownicy' a tabelą 'Działy', gdzie każdy pracownik jest przypisany do jednego działu, a każdy dział ma jednego pracownika. Relacje 1..n oraz n..1 również nie wymagają tabel pośrednich, ponieważ pozwalają na przypisania jednego rekordu do wielu rekordów, ale nie wymagają wzajemnych powiązań, co jest charakterystyczne dla relacji n..n. Relacja 1..n oznacza, że jeden rekord z tabeli A może być powiązany z wieloma rekordami z tabeli B, ale nie odwrotnie, natomiast w relacji n..1 wiele rekordów z tabeli A jest przypisanych do jednego rekordu w tabeli B. Te błędne podejścia wynikają z niepełnego zrozumienia struktury relacji danych oraz roli tabel pośrednich w zarządzaniu skomplikowanymi powiązaniami. Aby uniknąć mylnych interpretacji, ważne jest zrozumienie, że relacje 1..1, 1..n i n..1 nie wymagają tabel pośrednich, ponieważ nie łączą wielu rekordów z obu tabel, co jest kluczowym wymogiem dla relacji n..n.
Pytanie 7

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ż zapytanie, które zwróci te same dane:

A. SELECT nazwisko, imie FROM mieszkancy AS "Poznań" OR "Kraków"
B. SELECT nazwisko, imie FROM mieszkancy WHERE miasto="Poznań" OR miasto="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"
Zarówno druga, jak i trzecia odpowiedź zawierają błędne konstrukcje zapytań SQL, które nie są zgodne z syntaktyką SQL. W drugiej propozycji użycie aliasu 'AS' dla miast jest niepoprawne, ponieważ aliasowanie dotyczy głównie tabel i kolumn, a nie wartości w klauzuli WHERE. W konsekwencji zapytanie nie zwróci żadnych danych, gdyż nie jest w stanie poprawnie zinterpretować podanych warunków. Trzecia odpowiedź sugeruje użycie operatora BETWEEN w kontekście miast, co również jest niepoprawne. BETWEEN wymaga wartości liczbowych lub dat, a nie tekstowych. Dodatkowo, użycie operatora OR w kontekście BETWEEN jest błędne, ponieważ BETWEEN sam w sobie definiuje zakres wartości. Ostatnia odpowiedź jest również niepoprawna, ponieważ klauzula HAVING jest wykorzystywana w kontekście agregacji danych i nie jest przeznaczona do stosowania w prostych warunkach filtracji, jak w tym przypadku. Typowym błędem jest mylenie kontekstu użycia różnych klauzul w SQL oraz niewłaściwe stosowanie operatorów, co prowadzi do niepoprawnych wniosków o skutkach zapytań. Warto zrozumieć zasady rządzące składnią SQL, aby efektywnie tworzyć zapytania, które zwracają oczekiwane wyniki.
Pytanie 8

Poniższe zapytanie zwróci

SELECT COUNT(cena) FROM uslugi;
A. łączną wartość cen usług w tabeli
B. liczbę wszystkich cen usług w tabeli
C. wszystkie wartości cen usług w tabeli
D. średnią wartość cen usług w tabeli
Wszystkie pozostałe odpowiedzi wynikają z nieporozumienia dotyczącego funkcji COUNT oraz jej zastosowania w SQL. Przede wszystkim, odpowiedź sugerująca sumę cen usług jest błędna, ponieważ COUNT nie sumuje wartości, lecz zlicza ich ilość. W SQL do obliczenia sumy używa się funkcji SUM. W kontekście średniej ceny, podobnie, funkcja COUNT nie dostarcza takiej informacji; do obliczeń średnich wykorzystuje się funkcję AVG. Innym częstym błędem jest mylenie zliczania wszystkich rekordów z wyświetlaniem ich wartości. Użycie COUNT zawsze odnosi się do ilości, a nie do treści poszczególnych rekordów. Warto zrozumieć, że funkcje agregujące, takie jak COUNT, SUM, AVG, MAX czy MIN, mają różne zastosowania i dostarczają różnych informacji. Każda z tych funkcji ma swoje specyficzne zadanie i nie można ich stosować zamiennie. Na przykład, błędna interpretacja może prowadzić do sytuacji, w której analityk danych podejmuje decyzje na podstawie niewłaściwie zrozumianych wyników zapytania, co może skutkować poważnymi konsekwencjami biznesowymi. W związku z tym istotne jest nie tylko znajomość składni SQL, ale także zrozumienie logiki stojącej za funkcjami agregującymi, co jest kluczowe dla analizy danych.
Pytanie 9

W języku MySQL należy wykorzystać polecenie REVOKE, aby użytkownikowi anna cofnąć możliwość wprowadzania zmian wyłącznie w definicji struktury bazy danych. Polecenie, które służy do odebrania tych uprawnień, ma następującą formę

A. REVOKE CREATE ALTER DROP ON tabela1 FROM 'anna'@'localhost'
B. REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost'
C. REVOKE ALL ON tabela1 FROM 'anna'@'localhost'
D. REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'
Wybór innego podejścia do odbierania uprawnień użytkownikowi 'anna' jest niewłaściwy z kilku powodów. Po pierwsze, REVOKE ALL ON tabela1 FROM 'anna'@'localhost' jest zbyt ogólnie sformułowane, jako że odbiera wszystkie przydzielone uprawnienia, w tym te, które mogą być konieczne do wykonywania podstawowych operacji na danych. Taki ruch mógłby całkowicie zablokować użytkownika w interakcji z tabelą, co nie odzwierciedla zamierzonego celu, jakim jest jedynie ograniczenie możliwości modyfikacji struktury. Drugą nieodpowiednią propozycją jest REVOKE CREATE UPDATE DROP ON tabela1 FROM 'anna'@'localhost'. Ta komenda również jest błędna, ponieważ wprowadza uprawnienie UPDATE, które nie jest związane z zarządzaniem strukturą bazy danych. Odbieranie tego uprawnienia sprawiłoby, że użytkownik nie mógłby wprowadzać danych do tabeli, co jest sprzeczne z intencją ograniczenia jedynie modyfikacji struktury. Kolejną niewłaściwą odpowiedzią jest REVOKE CREATE INSERT DELETE ON tabela1 FROM 'anna'@'localhost', która również nie spełnia wymogów, ponieważ odbiera uprawnienia związane z wstawianiem i usuwaniem danych, co jest istotne dla pracy z danymi w tabeli. W kontekście zarządzania bazami danych, istotne jest, aby precyzyjnie określać, jakie uprawnienia są odbierane, a także dokładnie rozumieć ich zastosowanie oraz potencjalne konsekwencje ich odebrania.
Pytanie 10

Aby ułatwić wprowadzanie oraz modyfikację danych w tabeli, konieczne jest zdefiniowanie

A. raportu
B. formularza
C. kwerendy SELECT
D. filtra
Odpowiedzi, które nie obejmują formularza, wskazują na pewne nieporozumienia dotyczące sposobu, w jaki użytkownicy wchodzą w interakcje z danymi w bazie danych. Kwerenda SELECT, mimo że jest fundamentalnym narzędziem do pobierania informacji, nie jest odpowiednia do wprowadzania czy edytowania danych. Kwerendy są stosowane głównie do filtrowania i prezentowania danych istniejących, a nie do ich wprowadzania. W kontekście zarządzania danymi, kwerendy powinny być używane w celu analizy danych, a nie ich modyfikacji. Z kolei filtry są narzędziami, które umożliwiają użytkownikom przeszukiwanie i wyświetlanie określonych zestawów danych, ale również nie są przeznaczone do edytowania danych. Filtry są bardziej funkcjonalne w kontekście przeglądania już wprowadzonych informacji, co nie spełnia wymogu prostoty wprowadzania danych. Raporty natomiast są używane do generowania zestawień i podsumowań danych, co jest zupełnie innym procesem niż ich wprowadzanie. Powszechnym błędem jest zrozumienie tych narzędzi jako równoważnych formularzom, co jest mylne. Właściwe podejście do zarządzania danymi w bazach danych wymaga zrozumienia ról różnych narzędzi i ich zastosowań w praktyce, co jest kluczowe dla efektywnego zbierania i zarządzania informacjami.
Pytanie 11

Użytkownik Jan będzie mógł wykonywać

GRANT ALL PRIVILEGES ON dane.* TO 'Jan'@'localhost';
A. wszystkie operacje na tabelach bazy dane.
B. jedynie operacje CREATE, ALTER, DROP na tabelach bazy dane.
C. jedynie operacje manipulowania danymi i zmienić jedynie swoje prawa.
D. wszystkie operacje na tabelach bazy dane oraz nadawać prawa innym użytkownikom.
Wszystkie pozostałe odpowiedzi są niepoprawne z różnych powiedział. Druga odpowiedź sugeruje, że Jan może wykonywać tylko operacje CREATE, ALTER, DROP. Jest to nieprawidłowe, ponieważ otrzymał on pełne uprawnienia do bazy danych, co zdecydowanie wykracza poza te trzy operacje. Trzecia odpowiedź zawiera błędne przekonanie, że Jan może nadawać uprawnienia innym użytkownikom. Pomimo posiadania pełnych uprawnień do bazy danych, nie oznacza to, że ma on możliwość zarządzania uprawnieniami innych użytkowników. Czwarta odpowiedź jest również błędna, twierdząc, że Jan może manipulować danymi i zmieniać tylko swoje uprawnienia. W rzeczywistości, Jan nie ma uprawnień do zmiany swoich własnych uprawnień - to zadanie zazwyczaj spoczywa na administratorze bazy danych. Wszystkie te błędy wynikają z niewłaściwego zrozumienia zarządzania uprawnieniami w bazach danych i roli konstrukcji GRANT. W rzeczywistości, GRANT pozwala na precyzyjne i granularne zarządzanie uprawnieniami, a pełne uprawnienia oznaczają pełną kontrolę nad bazą danych, ale nie nad uprawnieniami innych użytkowników.
Pytanie 12

Dana jest tabela studenci o polach id_albumu, ubezpieczenie. Modyfikacja w kolumnie ubezpieczenie polegająca na zmianie wierszy bez wartości (NULL) na ciąg znaków „brak” zostanie wykonana kwerendą

A. ALTER TABLE studenci ADD ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
B. ALTER TABLE studenci MODIFY COLUMN ubezpieczenie='brak' NOT NULL;
C. UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak';
D. UPDATE studenci SET ubezpieczenie='brak' WHERE ubezpieczenie IS NULL;
W tym zadaniu łatwo wpaść w kilka typowych pułapek związanych z rozumieniem różnicy między modyfikacją danych a modyfikacją struktury tabeli. W SQL mamy dwa zupełnie różne światy: polecenia typu UPDATE, DELETE, INSERT działają na rekordach, czyli na zawartości tabeli, natomiast ALTER TABLE służy do zmiany schematu – dodawania kolumn, zmiany typów, ustawiania ograniczeń. Próba użycia ALTER TABLE do modyfikowania konkretnych wartości w wybranych wierszach po prostu nie pasuje do logiki języka SQL. Jeśli w poleceniu pojawia się ALTER TABLE z klauzulą ADD i jednocześnie WHERE, to widać tu pomieszanie pojęć. ADD dodaje nową kolumnę lub ograniczenie do całej tabeli, nie ma możliwości, żeby ALTER TABLE działał tylko na wierszach spełniających jakiś warunek. Warunek WHERE jest typowy dla operacji na danych (SELECT, UPDATE, DELETE), a nie na strukturze. Podobnie MODIFY COLUMN w SQL służy do zmiany typu, rozmiaru lub właściwości kolumny (np. z NULL na NOT NULL, zmiana długości VARCHAR), ale nie do ustawiania konkretnej wartości tekstowej w wybranych rekordach. Ustawienie NOT NULL bez zrozumienia aktualnej zawartości kolumny jest zresztą ryzykowne – jeżeli w tabeli są jakieś wartości NULL, baza może w ogóle nie przyjąć takiej zmiany albo wymagać wartości domyślnej, ale to nadal nie oznacza, że te NULL-e zostaną zamienione na sensowny ciąg znaków. Czasem pojawia się też błąd składniowy polegający na pominięciu słowa SET przy UPDATE albo błędnym umieszczeniu warunku IS NULL. Standard SQL wymaga postaci: UPDATE nazwa_tabeli SET kolumna=wartość WHERE warunek;. Próba napisania UPDATE studenci ubezpieczenie IS NULL SET ubezpieczenie='brak'; łamie tę strukturę – parser SQL nie jest w stanie tego poprawnie zinterpretować, bo po nazwie tabeli nie może stać od razu warunek, tylko ewentualny alias, a potem musi być słowo SET. Z mojego doświadczenia wynika, że wiele osób myli kolejność elementów w zapytaniu, zwłaszcza gdy łączy warunki z modyfikacją danych. Podsumowując, żeby zamienić wartości NULL na ciąg znaków „brak” w konkretnej kolumnie, potrzebne jest czyste UPDATE z prawidłową składnią i z warunkiem WHERE ubezpieczenie IS NULL. ALTER TABLE nie nadaje się do takiej operacji, a pominięcie SET albo błędne użycie IS NULL skutkuje albo błędem składni, albo niepoprawnym działaniem. Dobra praktyka w pracy z bazami danych to wyraźne oddzielanie operacji na strukturze od operacji na danych i dokładne pilnowanie składni w tego typu poleceniach.
Pytanie 13

W PHP, aby połączyć się z bazą danych MySQL przy użyciu biblioteki mysqli, w zapisie zamieszczonym poniżej, w miejscu litery 'c' powinno się wpisać

Ilustracja do pytania
A. nazwę bazy danych
B. lokalizację serwera bazy danych
C. nazwę użytkownika
D. hasło użytkownika
Rozważając, co powinno znajdować się na miejscu oznaczonym literą 'c', należy zrozumieć, jak działa funkcja mysqli w PHP. Pierwszym argumentem jest lokalizacja serwera bazy danych, często jest to 'localhost' dla lokalnych połączeń, co może prowadzić do błędnego założenia, że to właśnie ten parametr znajduje się pod literą 'c'. Drugi parametr powinien być nazwą użytkownika bazy danych, co w kontekście bezpieczeństwa jest elementem, na który zawsze trzeba zwracać uwagę. Hasło użytkownika znajduje się na trzeciej pozycji i jest kluczowe dla zapewnienia, że tylko uprawnione osoby mogą uzyskać dostęp do bazy. Czwarty parametr to nazwa bazy danych, która jest niezbędna do określenia, z którą bazą chcemy pracować w ramach danego połączenia. Często błędnie przyjmuje się, że nazwa bazy powinna być na pierwszym miejscu, co wynika z zamieszania co do struktury danych wejściowych. Warto dodać, że lokalizacja serwera, choć czasem zaniedbywana, jest kluczowa w środowiskach rozproszonych, gdzie połączenia mogą być nawiązywane z różnych serwerów lub maszyn wirtualnych. Każdy z tych elementów jest istotny i musi być poprawnie zidentyfikowany, aby połączenie z bazą danych było skuteczne i bezpieczne. Praktyczne umiejętności w tej dziedzinie są kluczowe, zwłaszcza przy projektowaniu i wdrażaniu aplikacji działających w profesjonalnym środowisku produkcyjnym.
Pytanie 14

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

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

Jakie wyniki zostaną wyświetlone po wykonaniu podanej w ramce kwerendy SQL SELECT na tabeli pracownicy, która zawiera rekordy?

idimienazwiskopensja
1AnnaKowalska3400
2MonikaNowak1300
3EwelinaNowakowska2600
4AnnaPrzybylska4600
5MariaKowal2200
6EwaNowacka5400
SELECT SUM(pensja) FROM pracownicy WHERE pensja > 4000;
A. Kwota 19500, czyli suma wszystkich pensji zatrudnionych
B. Kwota 5400, co oznacza najwyższą pensję wśród pracowników
C. Dwie kwoty: 4600 oraz 5400, jako wynagrodzenia pracowników przekraczające 4000
D. Kwota 10000, co stanowi sumę pensji pracowników o id=4 i id=6
Błędne zrozumienie zapytania SQL może wynikać z pominięcia szczegółów w klauzuli WHERE. Funkcja SUM w połączeniu z WHERE służy do zliczania tylko tych wartości, które spełniają określony warunek. W tym przypadku analizujemy pensje większe niż 4000. Mylną interpretacją byłoby bezkrytyczne założenie, że funkcja SUM zlicza wszystkie wartości w kolumnie, co prowadzi do niepoprawnego wniosku o sumie wszystkich pensji. Innym typowym błędem jest zakładanie, że zwracane zostaną konkretne wartości pensji, co wskazuje na brak zrozumienia działania funkcji agregujących, które zwracają jedną wartość wynikową, jak suma czy średnia. Powszechnym błędem jest ignorowanie zastosowania klauzuli WHERE, co prowadzi do błędnych interpretacji danych. Wiedza o tym, jak filtrować dane przed ich agregacją, jest kluczowa w skutecznej analizie danych. Zrozumienie roli klauzuli WHERE oraz funkcji agregujących, jak SUM, MAX, MIN, pozwala na tworzenie bardziej precyzyjnych i efektywnych raportów, co jest niezbędne w praktykach biznesowych i IT. Prawidłowe rozumienie tych konceptów jest nieodzowne w pracy z dużymi zbiorami danych i przy podejmowaniu decyzji opartych na danych.
Pytanie 16

W języku SOL komenda INSERT INTO

A. wprowadza pola do tabeli
B. tworzy tabelę
C. wprowadza dane do tabeli
D. modyfikuje rekordy ustaloną wartością
W odpowiedziach, które nie są poprawne, można zaobserwować pewne powszechne nieporozumienia dotyczące funkcji polecenia INSERT INTO. Odpowiedź sugerująca, że to polecenie aktualizuje rekordy, myli funkcje INSERT i UPDATE, które mają zupełnie różne cele. INSERT INTO służy do dodawania nowych danych, podczas gdy UPDATE jest używane do modyfikacji istniejących rekordów. Z kolei stwierdzenie, że polecenie dodaje pola do tabeli, odnosi się do innej komendy, jaką jest ALTER TABLE. Ta komenda służy do zmiany struktury tabeli, a nie do wprowadzania danych. Wreszcie, odpowiedź mówiąca o dodawaniu tabeli dotyczy również ALTER TABLE, a nie INSERT INTO. Te nieporozumienia mogą wynikać z braku zrozumienia podstawowej architektury baz danych oraz różnorodności poleceń SQL, które są zaprojektowane do realizacji różnych zadań. Dlatego ważne jest, aby przed przystąpieniem do pracy z bazami danych zrozumieć, jak różne polecenia wpływają na strukturę i zawartość bazy danych oraz jakie są ich zastosowania w praktyce. Zrozumienie tych różnic jest kluczowe dla efektywnego zarządzania danymi i unikania błędów w codziennej pracy z bazami danych.
Pytanie 17

Zdefiniowano bazę danych z tabelą sklepy, zawierającą pola: nazwa, ulica, miasto, branża. Aby odnaleźć wszystkie nazwy sklepów spożywczych znajdujących się wyłącznie we Wrocławiu, należy użyć kwerendy:

A. SELECT sklepy FROM branza='spożywczy' WHERE miasto='Wrocław';
B. SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND miasto='Wrocław';
C. SELECT sklepy FROM nazwa WHERE branza='spożywczy' BETWEEN miasto='Wrocław';
D. SELECT nazwa FROM sklepy WHERE branza='spożywczy' OR miasto='Wrocław';
Żeby znaleźć wszystkie sklepy spożywcze tylko we Wrocławiu, stosujemy kwerendę SQL: SELECT nazwa FROM sklepy WHERE branza='spożywczy' AND miasto='Wrocław'; Ta kwerenda jest OK, bo używa klauzuli WHERE, żeby zawęzić wyniki. Klauzula AND jest bardzo ważna, bo tak naprawdę pozwala na spełnienie obu warunków naraz. Jeśli mamy tabelę 'sklepy', gdzie są różne dane o sklepach, to ta kwerenda zwróci tylko te, które pasują do obu kryteriów. Myślę, że to dobrze pokazuje, jak działa normalizacja baz danych, która mówi, żeby unikać duplikatów przez dokładne filtrowanie. Użycie AND gwarantuje, że dostaniemy wyniki, które są naprawdę zgodne z naszym zapytaniem. Na przykład jeśli w tabeli mamy 'Sklep A, ul. X, Wrocław, spożywczy' i 'Sklep B, ul. Y, Poznań, spożywczy', to nasza kwerenda odda tylko 'Sklep A'.
Pytanie 18

Jakim poleceniem SQL można zlikwidować z tabeli artykuly wiersze, które zawierają słowo "sto" w dowolnej lokalizacji pola tresc?

A. DELETE FROM artykuly WHERE tresc LIKE "%sto%"
B. DELETE * FROM artykuly WHERE tresc LIKE "%sto%"
C. DELETE * FROM artykuly WHERE tresc = "%sto%"
D. DELETE FROM artykuly WHERE tresc = "%sto%"
Wybór odpowiedzi "DELETE * FROM artykuly WHERE tresc = '%sto%';" jest po prostu zły z paru powodów. Po pierwsze, w SQL nie używamy znaku '*' przy DELETE. Jak chcemy usunąć wiersze, to piszemy tylko "DELETE FROM nazwa_tabeli". To '*' sugeruje, że chcesz usunąć jakieś konkretne kolumny, a to w SQL się nie sprawdzi. Druga sprawa to operator '=' zamiast 'LIKE'. '=' używamy do porównania wartości, nie do wyszukiwania wzorców, a tu właśnie szukamy wystąpienia słowa 'sto' w dłuższym tekście. Dlatego operator LIKE z wildcardami jest tu konieczny, by znaleźć i usunąć te wiersze, które mają 'sto' gdziekolwiek. Często ludzie mylą te operatory w SQL, co prowadzi do problemów i nieefektywnego wyszukiwania.
Pytanie 19

Na podstawie jakiego parametru oraz z ilu tabel będą zwrócone wiersze w wyniku podanego zapytania?

SELECT * FROM producent, hurtownia, sklep, serwis WHERE
producent.nr_id = hurtownia.nr_id AND
producent.wyrob_id = serwis.wyrob_id AND
hurtownia.nr_id = sklep.nr_id AND
sklep.nr_id = serwis.nr_id AND
producent.nr_id = 1;
A. Na podstawie parametru wyrob_id tylko dla trzech tabel
B. Na podstawie parametru wyrob_id tylko dla trzech tabel
C. Na podstawie parametru nr_id tylko dla trzech tabel
D. Na podstawie parametru nr_id dla wszystkich tabel
Zapytanie SQL w poleceniu jest skonstruowane tak by pobierać dane z czterech tabel: producent hurtownia sklep i serwis W warunku WHERE użyto klauzuli dotyczącej parametru nr_id co powoduje że połączenia między tabelami są realizowane na podstawie tego właśnie parametru Jest to typowe podejście w relacyjnych bazach danych gdzie klucz główny jednej tabeli jest kluczem obcym w innej umożliwiając łączenie danych Parametr nr_id pojawia się wielokrotnie w klauzuli WHERE jako kryterium dla różnych połączeń między tabelami To pozwala na uzyskanie spójnej listy wierszy które spełniają wszystkie zdefiniowane warunki Dzięki temu zapytanie zwraca wiersze dla wszystkich czterech tabel co jest zgodne z odpowiedzią numer 1 Takie podejście umożliwia tworzenie złożonych raportów i analiz danych branżowych Warto także zauważyć że użycie JOIN w taki sposób często optymalizuje wydajność zapytań co jest dobrą praktyką w zarządzaniu bazami danych SQL
Pytanie 20

W bazie danych znajduje się tabela ksiazki, która zawiera pola: tytul, id_autora, data_wypoz oraz id_czytelnika. Co dzień generowany jest raport dotyczący książek wypożyczonych w danym dniu, który prezentuje tylko tytuły książek. Która z poniższych kwerend SQL będzie odpowiednia do utworzenia tego raportu?

A. SELECT * FROM ksiazki
B. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E()
C. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()
D. SELECT tytul FROM ksiazki
Wybór innych kwerend nie spełnia wymagania, by uzyskać tylko tytuły wypożyczonych książek z konkretnego dnia. Kwerenda 'SELECT tytul FROM ksiazki;' zwraca wszystkie tytuły książek z tabeli, nie uwzględniając daty wypożyczenia. Takie podejście mogłoby prowadzić do nieefektywnego przetwarzania danych oraz przeciążenia systemu, ze względu na duże ilości danych. W kontekście baz danych, selekcja zbyt ogólnych danych jest niezalecana, ponieważ nie dostarcza istotnych informacji i nie spełnia wymagań użytkowników, prowadząc do frustracji. Kwerenda 'SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E();' zawiera błąd w nazwie funkcji, jako że 'CURRDATE_NT_E()' nie jest standardową funkcją SQL, co skutkuje błędem wykonania zapytania. Dodatkowo, nawet gdyby była poprawna, ta kwerenda zwracałaby więcej danych niż potrzebne, co znowu nie jest praktyką zgodną z efektywnym zarządzaniem danymi. Ostatnia propozycja, 'SELECT * FROM ksiazki;', również nie jest odpowiednia, ponieważ zwraca wszystkie kolumny z tabeli, a nie tylko tytuły książek, co skutkuje nieoptymalnym przetwarzaniem i brakiem precyzyjnych informacji. Kluczową lekcją jest to, że kwerendy w SQL powinny być precyzyjnie dopasowane do potrzeb użytkowników, aby minimalizować obciążenie bazy danych oraz maksymalizować użyteczność raportów.
Pytanie 21

Wskaż zapytanie, w którym dane są uporządkowane.

A. SELECT DISTINCT produkt, cena FROM artykuly;
B. SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek;
C. SELECT nazwisko FROM firma WHERE pensja > 2000 LIMIT 10;
D. SELECT AVG(ocena) FROM uczniowie WHERE klasa = 2;
Odpowiedź wskazująca na zapytanie "SELECT imie, nazwisko FROM mieszkancy WHERE wiek > 18 ORDER BY wiek;" jest prawidłowa, ponieważ zawiera klauzulę ORDER BY, która służy do sortowania rekordów w wynikach zapytania. W tym przypadku dane są sortowane według kolumny 'wiek', co pozwala na uzyskanie uporządkowanej listy mieszkańców, którzy mają więcej niż 18 lat. Sortowanie danych jest kluczowym aspektem w zarządzaniu bazami danych, umożliwiającym łatwiejsze wyszukiwanie oraz analizę informacji. Przykładem zastosowania może być generowanie raportów, gdzie istotne jest uporządkowanie danych, na przykład według wieku, aby zobaczyć, jak rozkłada się wiek mieszkańców w danej grupie. Dodatkowo, stosowanie sortowania zgodnie z przyjętymi standardami SQL zwiększa czytelność oraz efektywność zapytań, a także ułatwia rozwiązywanie problemów związanych z przetwarzaniem danych.
Pytanie 22

Do czego służy funkcja PHP o nazwie mysql_num_rows?

A. przyporządkować numery rekordom w bazie danych
B. zwracać rekord, którego numer został przekazany jako parametr funkcji
C. podawać liczbę wierszy, które są w wynikach zapytania
D. oddawać następny rekord z wyników zapytania
Wszystkie pozostałe odpowiedzi są niepoprawne z kilku kluczowych powodów. Pierwsza z niepoprawnych odpowiedzi sugeruje, że funkcja mysql_num_rows ma na celu ponumerowanie rekordów w bazie danych. Takie podejście jest mylące, ponieważ mysql_num_rows nie modyfikuje ani nie przechowuje żadnych danych w bazie, a jedynie zwraca informację o liczbie wierszy w zestawie wyników, co w żaden sposób nie wiąże się z ich numerowaniem. Kolejna błędna odpowiedź wskazuje, że funkcja miałaby zwracać kolejny rekord z wynikami zapytania. W rzeczywistości, mysql_num_rows nie zwraca danych samych w sobie, lecz jedynie informację o ich liczbie, co czyni tę odpowiedź zupełnie nietrafioną. Ostatnia niepoprawna odpowiedź sugeruje, że funkcja zwraca rekord na podstawie numeru podanego w jej parametrze. Znowu, taka interpretacja jest nieprawidłowa, ponieważ mysql_num_rows nie przyjmuje parametrów odnoszących się do konkretnych rekordów, a jedynie do zmiennej wynikowej, która zawiera efekty zapytania SQL. W związku z tym, każde z tych stwierdzeń nieodzwierciedla rzeczywistej funkcji mysql_num_rows i jej zastosowania w kontekście zarządzania i przetwarzania danych w PHP.
Pytanie 23

Co uzyskujemy po wykonaniu zapytania SQL?

Ilustracja do pytania
A. suma ocen uczniów, których średnia ocen wynosi 5
B. liczbę uczniów, których średnia ocen wynosi 5
C. całkowitą liczbę uczniów
D. średnią wszystkich ocen uczniów
Analizując błędne koncepcje w tym pytaniu warto zwrócić uwagę na mechanizmy działania zapytań SQL które często są mylnie interpretowane. Zapytanie SELECT count(*) nie zwraca liczby wszystkich uczniów lecz tylko tych którzy spełniają określone warunki tutaj średnia ocen wynosi 5. Wybór SELECT count(*) jest kluczowy ponieważ w odróżnieniu od funkcji takich jak AVG() czy SUM() nastawiony jest na zliczanie wierszy a nie na obliczanie wartości średnich czy sum. Mylnym przekonaniem może być że tak skonstruowane zapytanie zwraca średnią ocen wszystkich uczniów; do tego celu służyłaby funkcja AVG(). Podobnie błędne byłoby oczekiwanie że zwróci sumę ocen studentów z daną średnią. Suma wymagałaby użycia funkcji SUM() i odpowiednich modyfikacji zapytania. Często popełnianym błędem jest także niedostrzeżenie że zapytanie z klauzulą WHERE ogranicza wyniki do podzbioru danych co jest kluczowe dla jego poprawnej interpretacji. Zrozumienie tych różnic jest istotne dla efektywnego wykorzystania SQL w praktyce zawodowej i unikania błędów analitycznych.
Pytanie 24

Jaki typ danych w MySQL należy zastosować, aby w jednym polu zapisać zarówno datę, jak i czas?

A. DATE
B. YEAR
C. TIMESTAMP
D. BOOLEAN
Typ danych TIMESTAMP w MySQL jest przeznaczony do przechowywania zarówno daty, jak i czasu w jednym polu. Jest szczególnie przydatny w sytuacjach, gdy potrzebne jest śledzenie zdarzeń w czasie, takich jak rejestracja daty i godziny utworzenia lub modyfikacji rekordów w bazie danych. TIMESTAMP przechowuje dane w formacie 'YYYY-MM-DD HH:MM:SS', co pozwala na precyzyjne określenie momentu w czasie. Wartością dodaną tego typu danych jest automatyczne aktualizowanie znacznika czasu przy każdej zmianie rekordu (jeśli ustawimy odpowiednie opcje), co jest zgodne z najlepszymi praktykami w zakresie audytu danych. Przykładem zastosowania może być rejestracja logów aktywności użytkowników w aplikacji internetowej lub monitorowanie transakcji w systemach finansowych, gdzie dokładny czas zdarzenia jest kluczowy. Dodatkowo, TIMESTAMP obsługuje różnice stref czasowych, co czyni go idealnym wyborem w aplikacjach działających w różnych lokalizacjach geograficznych.
Pytanie 25

Aby dodać nowy rekord do tabeli Pracownicy, konieczne jest zastosowanie polecenia SQL

A. INSERT VALUES (Jan, Kowalski) INTO Pracownicy
B. INSERT INTO Pracownicy VALUES ('Jan',' Kowalski')
C. INSERT (Jan, Kowalski) INTO Pracownicy
D. INSERT VALUES Pracownicy INTO (Jan, Kowalski)
Wszystkie niepoprawne odpowiedzi zawierają błędy składniowe oraz nieprawidłowe użycie konstrukcji SQL. W przypadku pierwszej błędnej odpowiedzi, brak jest kluczowego słowa 'INTO' przed nazwą tabeli, co czyni jej zapis niepoprawnym oraz niezgodnym z wymaganiami SQL. Dodatkowo, wartości 'Jan' oraz 'Kowalski' nie zostały otoczone apostrofami, co jest konieczne dla prawidłowego zdefiniowania danych typu tekstowego. Kolejna odpowiedź nie tylko niepoprawnie organizuje słowa kluczowe, ale także umieszcza 'VALUES' przed wartościami, co jest niezgodne z odpowiednią składnią SQL. Poprawna konstrukcja wymaga najpierw wskazania tabeli, a dopiero potem podania wartości. W ostatnim przypadku, brak jest również użycia słowa 'INTO', a wartości są podane w niewłaściwej kolejności i bez prawidłowego otoczenia apostrofami. W każdej z tych odpowiedzi istotnym błędem jest brak zgodności ze standardami SQL, co prowadzi do nieudanych prób wstawienia danych do tabeli.
Pytanie 26

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

A. truncate
B. mysqlcheck
C. mysqldump
D. create
Zarówno mysqldump, truncate, jak i create stanowią istotne polecenia w zarządzaniu bazami danych, ale nie mają one zdolności do naprawy uszkodzonych tabel. Mysqldump to narzędzie służące do eksportowania danych z bazy do pliku, co jest przydatne w kontekście tworzenia kopii zapasowych, ale nie oferuje funkcji naprawy uszkodzonych tabel. Funkcjonalność mysqldump koncentruje się na zabezpieczaniu danych, a nie na ich naprawie. Truncate, z kolei, to polecenie, które służy do usuwania wszystkich rekordów z tabeli bez rejestrowania pojedynczych operacji usunięcia w dzienniku transakcji, co sprawia, że jest to szybki sposób na opróżnienie tabeli, lecz nie ma zastosowania w kontekście naprawy uszkodzonych danych. Create to polecenie wykorzystywane do tworzenia nowych baz danych lub tabel, co jest podstawową operacją w zarządzaniu bazami danych, ale nie ma związku z naprawą istniejących struktur danych. Dlatego te narzędzia pełnią różne role w ekosystemie MySQL, ale nie są odpowiednie do rozwiązywania problemów z uszkodzonymi tabelami, co czyni mysqlcheck jedynym właściwym rozwiązaniem w tej sytuacji.
Pytanie 27

Jakie polecenie należy zastosować, aby naprawić bazę danych w MySQL?

A. REPAIR
B. CHANGE
C. FIX
D. UPDATE
Wybór FIX jako metody naprawy bazy danych w MySQL jest błędny, ponieważ to polecenie nie istnieje w składni MySQL. Użytkownicy mogą czasami mylić terminologię w kontekście innych systemów baz danych, jednak w MySQL nie ma komendy o nazwie FIX, co czyni ją nieodpowiednią w tym przypadku. Oprócz tego, UPDATE to polecenie służące do modyfikacji istniejących danych w tabelach, a nie do naprawy struktury bazy danych. Funkcja ta umożliwia użytkownikom aktualizację wartości w określonych kolumnach, ale nie ma związku z naprawą uszkodzonych tabel czy indeksów. Z kolei CHANGE, choć może być używane w kontekście zmiany struktury tabeli, również nie odnosi się do aspektu naprawy bazy danych. To polecenie jest używane w zmienianiu typu kolumny lub jej nazwy i nie ma zastosowania w kontekście naprawy błędów w tabelach. Dlatego, aby poprawnie naprawić bazę danych w MySQL, jedyną właściwą metodą pozostaje użycie polecenia REPAIR.
Pytanie 28

W SQL, aby usunąć wszystkie rekordy z tabeli, ale zachować jej strukturę, należy użyć polecenia:

A. DROP TABLE
B. REMOVE
C. DELETE FROM
D. TRUNCATE
W SQL, aby usunąć wszystkie rekordy z tabeli, ale zachować jej strukturę, używamy polecenia <code>DELETE FROM</code>. To polecenie jest częścią języka manipulacji danymi (DML) i pozwala na usunięcie danych bez usuwania samej tabeli. Warto zwrócić uwagę, że <code>DELETE FROM</code> może być użyte z klauzulą <code>WHERE</code>, aby usunąć tylko wybrane rekordy, ale bez tej klauzuli usunie wszystkie wiersze z tabeli. Zaletą tego podejścia jest to, że struktura tabeli, jej indeksy i inne atrybuty pozostają nienaruszone. Ponadto, polecenie <code>DELETE FROM</code> jest transakcyjne, co oznacza, że można je wycofać w ramach sesji transakcyjnej, co może być przydatne w przypadku błędów lub zmian w decyzji. Użycie tego polecenia jest zgodne z dobrymi praktykami zarządzania danymi, szczególnie w sytuacjach, gdy chcemy jedynie zresetować zawartość tabeli bez jej usuwania z bazy danych.
Pytanie 29

Jakie prawa: CREATE, ALTER, DROP zostały użyte w poleceniu GRANT?

A. pobierania danych z bazy
B. pracy z danymi
C. pracy ze strukturą
D. przyznawania uprawnień innym użytkownikom
Analiza pozostałych odpowiedzi prowadzi do nieporozumień związanych z różnymi rodzajami uprawnień w systemach baz danych. Manipulowanie danymi odnosi się głównie do operacji takich jak SELECT, INSERT, UPDATE i DELETE, które są używane do odczytywania i zmieniania danych przechowywanych w tabelach. Zestaw praw użyty w poleceniu GRANT nie obejmuje tych operacji, co czyni tę odpowiedź niewłaściwą. W przypadku wybierania informacji z bazy danych, odpowiednie prawa to SELECT, które nie mają związku z manipulowaniem strukturą. Ponadto, nadawanie praw innym użytkownikom jest związane z używaniem polecenia GRANT, ale nie odnosi się bezpośrednio do zestawu praw CREATE, ALTER i DROP. To ważne, aby zrozumieć, że każdy z tych typów uprawnień ma swoje specyficzne zastosowanie i nie mogą być mylone. W praktyce, administratorzy baz danych muszą wiedzieć, które uprawnienia są niezbędne dla użytkowników, aby zrealizować konkretne zadania, a błędne przypisanie uprawnień może prowadzić do poważnych problemów bezpieczeństwa i integralności danych. Takie myślenie o uprawnieniach wymaga zrozumienia ich różnorodności i kontekstu ich zastosowania w architekturze bazy danych.
Pytanie 30

W PHP, aby poprawnie zakończyć połączenie z bazą danych MySQL, ostatnim krokiem powinno być użycie polecenia

A. mysql_exit
B. mysqli_close
C. exit
D. die
Wybór poleceń mysql_exit, exit oraz die jako sposobu na zamknięcie połączenia z bazą danych jest niewłaściwy z kilku powodów. mysql_exit to nieistniejąca funkcja w PHP. Nie ma takiego polecenia w dokumentacji PHP, co sugeruje, że użytkownik może być nieświadomy alternatywnych metod zarządzania połączeniami z bazą danych. exit i die, mimo że są często używane do zatrzymywania skryptu, mają zupełnie inne zastosowanie. Obie te komendy kończą wykonanie skryptu PHP, co może prowadzić do niezamierzonego przerywania całej aplikacji, zamiast zamknięcia jedynie połączenia z bazą danych. Używanie ich w kontekście zamykania połączenia z bazą danych jest nieefektywne i może prowadzić do błędów w logice aplikacji. Funkcje te nie zwalniają zasobów związanych z połączeniem, co może prowadzić do wycieków pamięci oraz nieoptymalnego działania bazy danych. Z tego względu, stosowanie tych poleceń w kontekście obsługi połączeń MySQL jest niewłaściwe i powinno być unikane w profesjonalnym kodzie PHP.
Pytanie 31

Określ rodzaj powiązania pomiędzy tabelami: Tabela1 oraz Tabela3

Ilustracja do pytania
A. Jeden do jednego
B. Wiele do jednego
C. Jeden do wielu
D. Wiele do wielu
Zrozumienie typów relacji w bazach danych jest kluczowym aspektem projektowania efektywnych i zrównoważonych systemów informatycznych. Jednym z najczęstszych błędów jest mylenie relacji wiele do wielu z innymi rodzajami relacji, takimi jak jeden do wielu lub jeden do jednego. Relacja jeden do wielu oznacza, że jeden rekord w jednej tabeli jest powiązany z wieloma rekordami w innej tabeli, co w przypadku Tabela1 i Tabela3 nie jest stosowne, ponieważ wymagałoby to bezpośredniego połączenia między tymi tabelami bez użycia tabeli pośredniej. Z kolei relacja jeden do jednego implikuje, że każdy rekord w jednej tabeli odpowiada dokładnie jednemu rekordowi w drugiej tabeli, co ogranicza elastyczność danych i nie pasuje do struktur gdzie występuje wiele powiązań, jak w przypadku szkół, gdzie wielu uczniów może mieć zajęcia z tym samym nauczycielem. Wreszcie, relacja wiele do jednego jest odwrotnością relacji jeden do wielu, gdzie wiele rekordów w jednej tabeli odpowiada jednemu rekordowi w drugiej tabeli, co również nie znajduje odzwierciedlenia w przedstawionym schemacie, jako że nie opisuje wzajemnych powiązań uczniów i nauczycieli. Zrozumienie i prawidłowe zastosowanie relacji wiele do wielu eliminuje redundancję danych i umożliwia efektywne przechowywanie oraz przetwarzanie informacji w systemach zarządzania bazami danych. Kluczem do sukcesu jest tutaj wykorzystanie tabel pośrednich do prawidłowego mapowania powiązań między tabelami, co jest standardem w dobrych praktykach projektowania baz danych.
Pytanie 32

DELETE FROM Pracownicy ORDER BY rok_urodzenia LIMIT 1;
W wyniku wykonania powyższego zapytania SQL zostanie:
A. usunięta tabela Pracownicy.
B. usunięta kolumna rok_urodzenia z tabeli Pracownicy.
C. usunięty rekord z danymi pracownika, który miał wpisaną datę urodzenia.
D. usunięty rekord najstarszego pracownika.
To polecenie SQL nie modyfikuje struktury tabeli, tylko usuwa konkretny wiersz danych. W SQL istnieje wyraźny podział między poleceniami do pracy na danych, a poleceniami do pracy na strukturze bazy. DELETE należy do grupy DML (Data Manipulation Language) i służy do usuwania rekordów, czyli pojedynczych wierszy w tabeli. Natomiast operacje typu usunięcie całej tabeli lub kolumny realizuje się za pomocą poleceń DDL (Data Definition Language), takich jak DROP czy ALTER. Jeżeli ktoś kojarzy usunięcie tabeli z DELETE FROM, to jest to typowy błąd: do usunięcia tabeli używamy DROP TABLE Pracownicy; i po takim poleceniu struktura tabeli znika całkowicie z bazy. DELETE FROM Pracownicy bez warunku WHERE usunęłoby wszystkie rekordy, ale sama tabela – jej kolumny, indeksy, definicja – nadal by istniała. To bardzo ważne rozróżnienie, bo w praktyce administracji bazą przypadkowe DROP TABLE bywa katastrofalne, a DELETE da się jeszcze często cofnąć z backupu danych. Podobnie mylne jest myślenie, że DELETE FROM zadziała na kolumnie, np. usunie rok_urodzenia. Do modyfikacji struktury kolumn używamy ALTER TABLE, np. ALTER TABLE Pracownicy DROP COLUMN rok_urodzenia;. To jest zupełnie inny typ operacji niż usuwanie wiersza. W przedstawionym zapytaniu kolumna rok_urodzenia jest tylko kryterium sortowania w klauzuli ORDER BY, które decyduje, który rekord zostanie wybrany do usunięcia. Kolejna pułapka myślowa polega na tym, że ktoś widzi ORDER BY rok_urodzenia i myśli: „usunie się jakiś rekord, w którym ta wartość jest w ogóle wpisana”. To też nie jest prawidłowe. Baza nie usuwa „pierwszego lepszego” rekordu z niepustą datą urodzenia, tylko ten, który po posortowaniu według rok_urodzenia znajdzie się na pierwszej pozycji. Dzięki LIMIT 1 usuwany jest dokładnie jeden wiersz, nie więcej. W praktyce to bardzo precyzyjna operacja: jeśli rok_urodzenia oznacza rok urodzenia pracownika, to najmniejsza wartość w tej kolumnie odpowiada najstarszemu pracownikowi. To właśnie jego rekord zostaje skasowany. Z mojego doświadczenia wiele nieporozumień bierze się z pomieszania pojęć „rekord”, „kolumna” i „tabela”. Dobra praktyka jest taka, żeby zawsze czytać zapytanie fragmentami: DELETE – co robi? FROM Pracownicy – na jakiej tabeli? ORDER BY rok_urodzenia – według czego sortuje wiersze? LIMIT 1 – ile wierszy usunie? Taki sposób analizy bardzo pomaga unikać błędnych wniosków i jest standardem przy pracy z SQL w profesjonalnych projektach.
Pytanie 33

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

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

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. ALTER TABLE pracownicy DROP COLUMN wynagrodzenie
B. DROP TABLE pracownicy DELETE COLUMN wynagrodzenie
C. ALTER TABLE pracownicy DELETE wynagrodzenie
D. ALTER TABLE pracownicy DELETE COLUMN wynagrodzenie
W niepoprawnych odpowiedziach pojawiają się błędy związane z użyciem SQL i polecenia ALTER TABLE. Na przykład w pierwszej odpowiedzi ktoś użył kombinacji DROP TABLE i DELETE COLUMN, co jest totalnie pomyłką, bo DROP TABLE usuwa całą tabelę, a nie tylko kolumnę. Może to wynikać z pomylenia usuwania tabeli z usuwaniem kolumny. W następnej odpowiedzi, ALTER TABLE pracownicy DELETE COLUMN, mamy do czynienia z błędem, bo w SQL nie ma czegoś takiego jak DELETE COLUMN. Ludzie mogą to mylić z instrukcją DELETE, która dotyczy usuwania wierszy, a nie kolumn. Ostatnia odpowiedź, czyli ALTER TABLE pracownicy DELETE wynagrodzenie, też jest błędna, bo nie zaznacza, że chodzi o kolumnę, a użycie słowa DELETE w tym kontekście jest mylące. Takie błędy mogą wynikać z niepełnego zrozumienia podstawowych konceptów związanych z bazami danych i SQL. Żeby tego uniknąć, dobrze jest regularnie przeglądać dokumentację oraz ćwiczyć pisanie zapytań, bo to naprawdę pomaga w lepszym rozumieniu tego, co się robi.
Pytanie 35

Zamieszczone zapytanie SQL przyznaje prawo SELECT:

GRANT SELECT ON hurtownia.* TO 'sprzedawca'@'localhost';
A. dla użytkownika root na serwerze localhost
B. dla użytkownika root na serwerze sprzedawca
C. do wszystkich kolumn w tabeli hurtownia
D. do wszystkich tabel w bazie 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 36

Aby cofnąć uprawnienia danemu użytkownikowi, należy użyć polecenia

A. REVOKE
B. GRANT NO PRIVILEGES
C. DELETE
D. DELETE PRIVILEGES
Wybór 'DELETE' do odbierania uprawnień to zły ruch, bo to polecenie służy do usuwania rekordów z tabel, a nie do zarządzania uprawnieniami. Ludzie często się mylą co do tego, a 'DELETE PRIVILEGES' brzmi trochę sensownie, ale w rzeczywistości to nie jest standardowa komenda w żadnym systemie baz danych. Można sobie to pomylić z 'REVOKE', co prowadzi do błędnych wniosków. Dodatkowo, 'GRANT NO PRIVILEGES' nie ma racji bytu, bo nie funkcjonuje jako polecenie w SQL. Zamiast tego, trzeba sięgać po 'REVOKE', żeby cofnąć konkretne uprawnienia. To typowy błąd, jakim jest mieszanie operacji na danych z operacjami na uprawnieniach, co może skutkować nieefektywnym zarządzaniem dostępem i zagrożeniami bezpieczeństwa. Ważne jest, żeby zrozumieć, że operacje na danych i zarządzanie uprawnieniami to zupełnie różne sprawy, co jest kluczowe do odpowiedniego administrowania bazą danych.
Pytanie 37

Tworząc raport w systemie zarządzania relacyjnymi bazami danych, umożliwia się

A. dodawanie danych do tabel
B. usuwanie danych z tabel
C. analizę wybranych danych
D. aktualizowanie danych w tabelach
Wykonywanie raportów w systemie obsługi relacyjnych baz danych nie polega na usuwaniu, dodawaniu ani aktualizowaniu danych. Usuwanie danych w tabelach jest operacją destrukcyjną, która trwale eliminuje informacje i nie sprzyja przechowywaniu ich do późniejszej analizy. Dodawanie danych to proces, który zwiększa objętość bazy danych, a nie koncentruje się na analizie już istniejących informacji. Z kolei aktualizacja danych polega na modyfikacji istniejących rekordów, co również nie ma bezpośredniego związku z tworzeniem raportów. Właściwe zrozumienie celu raportowania jest kluczowe dla efektywnego wykorzystania systemów bazodanowych. Często użytkownicy mylą procesy związane z utrzymywaniem baz danych z ich analizą. Dobrą praktyką jest oddzielanie operacji DML (Data Manipulation Language) od DQL (Data Query Language), które służy do analizy danych przy użyciu odpowiednich zapytań. Zastosowanie raportowania w systemach baz danych powinno być skupione na zrozumieniu i interpretacji danych, co pozwala na lepsze podejmowanie decyzji, zamiast na manipulacji danymi. Kluczowym aspektem jest umiejętność wyciągania wniosków z danych, które zostały już zgromadzone, a nie ich modyfikacja.
Pytanie 38

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 znajduje się w pierwszej postaci normalnej
B. Tabela jest w trzeciej 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 39

Jakie cechy powinien posiadać klucz główny?

A. Reprezentowany jest przez jedno pole tabeli, jego wartość nie może ulegać zmianie
B. Jest unikatowy, nie może zawierać pustych wartości
C. Nie może przybierać wartości, reprezentowany jest przez dokładnie jedno pole tabeli
D. Jest unikatowy, może mieć tylko wartości całkowite
Wszystkie błędne odpowiedzi zawierają nieprecyzyjne lub mylące stwierdzenia dotyczące kluczy głównych. Na przykład, twierdzenie, że klucz główny może przyjmować tylko wartości całkowite, nie jest zgodne z rzeczywistością. Klucz główny może być reprezentowany przez różne typy danych, w tym tekst, daty, a nawet złożone obiekty, co czyni tę koncepcję zbyt ograniczoną. Kolejne stwierdzenie, że klucz główny jest reprezentowany przez dokładnie jedno pole tabeli, również nie oddaje pełnego obrazu. Możliwe jest tworzenie kluczy głównych z kilku kolumn, znanych jako klucze złożone, co jest przydatne w sytuacjach, gdy pojedyncza kolumna nie może zapewnić unikalności. Ponadto, stwierdzenie, że wartości klucza głównego nie mogą się zmieniać, wprowadza w błąd. Chociaż zmiana wartości klucza głównego może wprowadzić komplikacje, zwłaszcza w relacjach z innymi tabelami, technicznie jest to możliwe. Właściwe podejście do zarządzania kluczami głównymi obejmuje zrozumienie konsekwencji takich zmian oraz odpowiednie aktualizacje w powiązanych tabelach. Wreszcie, nieznajomość tych aspektów może prowadzić do typowych błędów w projektowaniu baz danych, takich jak brak unikalności lub trudności w zarządzaniu relacjami, co z kolei może wpłynąć na wydajność oraz integralność aplikacji bazodanowych. Zrozumienie roli kluczy głównych jest zatem fundamentalne dla każdego, kto chce skutecznie projektować i zarządzać bazami danych.
Pytanie 40

Na przedstawionym obrazie zobrazowano wybór formatu pliku do zaimportowania bazy danych. Który z formatów należy wybrać, jeśli dane zostały wyeksportowane z programu Excel i zapisane w formie tekstowej z użyciem przecinka do oddzielania wartości pól?

Ilustracja do pytania
A. SQL
B. XML
C. CSV
D. ESRI
Format SQL jest używany do zapisywania i przenoszenia poleceń bazodanowych które pozwalają na operacje takie jak tworzenie modyfikowanie i pobieranie danych SQL to język zapytań a nie format przechowywania danych co sprawia że nie nadaje się do prostego importu danych wyeksportowanych z Excela bezpośrednio w formie tekstowej XML z kolei jest formatem tekstowym używanym do przechowywania danych w strukturze hierarchicznej z możliwością definiowania złożonych relacji między danymi Choć elastyczny i potężny XML jest często zbyt skomplikowany dla prostych tabelarycznych danych jakie można znaleźć w plikach Excel Wymaga tworzenia struktur znaczników co może być niepotrzebne zwłaszcza dla prostych zestawów danych ESRI czyli format plików kształtu jest specyficzny dla danych geograficznych i przestrzennych i nie jest używany do przenoszenia danych tabelarycznych Excel MediaWiki tabela jest rozwiązaniem specyficznym które umożliwia eksport i import danych w formacie wiki przydatnym jedynie w kontekście platform wiki Zastosowanie tych formatów w kontekście importu prostych danych tabelarycznych z Excela które są zapisane przy użyciu przecinków jako separatorów wydaje się niepraktyczne Odpowiednim i efektywnym rozwiązaniem jest zatem użycie CSV który zapewnia łatwość importu i szeroką kompatybilność z różnymi systemami i oprogramowaniem
Rozpocznij nowy egzamin
Powrót do strony głównej