Wyniki egzaminu

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

Egzamin zdany!

Wynik: 26/40 punktów (65,0%)

Wymagane minimum: 20 punktów (50%)

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

W bazie MySQL zdefiniowano podczas tworzenia tabeli pole

id int NOT NULL AUTO_INCREMENT
Wpis AUTO_INCREMENT oznacza, że
A. wartość kolumny id zostanie automatycznie przypisana przez system i będzie to przypadkowo wygenerowana liczba całkowita
B. możliwe jest wprowadzenie rekordu z dowolną wartością dla kolumny id
C. wartości tej kolumny będą automatycznie tworzone w trakcie dodawania nowego rekordu do bazy
D. kolumna id będzie mogła przyjmować wartości: NULL, 1, 2, 3, 4 i tak dalej
Wybór niepoprawnych odpowiedzi najczęściej wynika z niepełnego zrozumienia działania mechanizmu AUTO_INCREMENT w MySQL. Zgłoszenie, że dozwolone jest dodawanie rekordu z dowolną wartością pola id, jest błędne, ponieważ pole z AUTO_INCREMENT nie pozwala na wprowadzenie wartości ręcznie; to system bazy danych przydziela kolejne wartości. Ponadto, sugestia, że pole id może przyjmować wartość NULL jest również nieprawidłowa. W definicji pola 'id int NOT NULL AUTO_INCREMENT' zawiera się klauzula NOT NULL, co oznacza, że pole to nie może być puste - każdemu rekordowi musi być przypisana właściwa wartość. Inną mylną koncepcją jest stwierdzenie, że wartość pola id zostanie wygenerowana losowo. AUTO_INCREMENT nie generuje wartości losowych, lecz sekwencyjne, co oznacza, że wartości będą rosły o jeden w stosunku do ostatniego zarejestrowanego identyfikatora. Takie podejście zapewnia porządek i przewidywalność w bazie danych. Często zdarza się, że osoby korzystające z baz danych nie zdają sobie sprawy z tych mechanizmów, co prowadzi do mylnych wniosków. Zrozumienie zasad działania AUTO_INCREMENT jest kluczowe dla efektywnego projektowania baz danych oraz zapewnienia integralności danych.

Pytanie 2

W bazie danych znajduje się tabela uczniowie z kolumnami: imie, nazwisko, klasa. Jakie polecenie SQL należy wykorzystać, aby znaleźć imiona oraz nazwiska uczniów, których nazwiska zaczynają się na literę M?

A. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko LIKE 'M%';
B. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko = 'M%';
C. SELECT nazwisko, imie FROM uczniowie ORDER BY nazwisko IN 'M%';
D. SELECT nazwisko, imie FROM uczniowie WHERE nazwisko IN 'M%';
Wybrana odpowiedź jest poprawna, ponieważ używa operatora LIKE, który jest standardowym rozwiązaniem w SQL do wyszukiwania wzorców w danych. W tym przypadku 'M%' oznacza, że chcemy znaleźć wszystkie nazwiska, które zaczynają się na literę M. Operator LIKE jest szczególnie przydatny w sytuacjach, gdy potrzebujemy elastycznego wyszukiwania, umożliwiającego zastosowanie symboli wieloznacznych, takich jak '%' oznaczający dowolną liczbę znaków. Przykład zastosowania tego zapytania może obejmować generowanie listy uczniów dla nauczycieli, którzy chcą szybko zobaczyć wszystkich uczniów z nazwiskiem zaczynającym się na M, co może być przydatne przy organizowaniu wydarzeń czy klas. Dobrą praktyką jest także używanie odpowiednich indeksów w bazie danych, co może znacznie przyspieszyć wykonanie zapytań, zwłaszcza w dużych zbiorach danych. Znajomość operatorów SQL i ich zastosowań, jak również umiejętność formułowania zapytań, jest kluczowa w pracy z relacyjnymi bazami danych.

Pytanie 3

Wymień dwa sposoby na zabezpieczenie bazy danych w Microsoft Access.

A. Zaszyfrowanie pliku bazy danych oraz wysyłanie SMS-ów z kodem autoryzacyjnym
B. Używanie funkcji anonimowych oraz ustawienie hasła dostępu do bazy danych
C. Wprowadzenie zabezpieczeń na poziomie użytkownika oraz sesji
D. Określenie hasła do otwarcia bazy danych oraz wprowadzenie zabezpieczeń na poziomie użytkownika
Ustalanie hasła do otwarcia bazy danych oraz zabezpieczeń na poziomie użytkownika to kluczowe aspekty bezpieczeństwa w kontekście zarządzania bazą danych Microsoft Access. Ustalanie hasła do bazy danych jest podstawowym krokiem w ochronie danych przed nieautoryzowanym dostępem. Każda próba otwarcia bazy wymaga podania poprawnego hasła, co znacząco utrudnia dostęp osobom trzecim. Dodatkowo, zabezpieczenia na poziomie użytkownika pozwalają na przypisanie różnych ról i uprawnień do konkretnych użytkowników, co zapewnia, że tylko uprawnione osoby mogą edytować, przeglądać lub usuwać dane. Przykładowo, menedżer bazy danych może zdefiniować użytkowników, którzy mają jedynie dostęp do raportów, podczas gdy inni mogą modyfikować dane. Takie podejście jest zgodne z dobrymi praktykami w zakresie zarządzania danymi, gdzie stosuje się zasady minimalnych uprawnień oraz segmentacji obowiązków, co zwiększa ogólne bezpieczeństwo systemu.

Pytanie 4

Narzędzie phpMyAdmin służy do administrowania serwerem

A. FTP
B. baz danych
C. plików
D. WWW
Poprawnie – phpMyAdmin to narzędzie służące do administrowania serwerem baz danych, najczęściej MySQL lub MariaDB. Działa jako aplikacja webowa, czyli obsługujesz ją przez przeglądarkę, ale jej głównym zadaniem nie jest zarządzanie stroną WWW, tylko właśnie strukturą i danymi w bazie. Dzięki phpMyAdmin możesz tworzyć nowe bazy danych, zakładać i usuwać tabele, definiować typy kolumn, klucze główne i obce, indeksy, a także wykonywać zapytania SQL, eksportować i importować dane (np. do formatu SQL, CSV, czasem też JSON), robić backupy i przywracać je, zarządzać użytkownikami i ich uprawnieniami do konkretnych baz. W praktyce, gdy stawiasz stronę w PHP opartą na WordPressie, Joomla czy autorskim CMS-ie, to bardzo często pierwsze narzędzie, po które się sięga do ogarnięcia bazy, to właśnie phpMyAdmin. Z mojego doświadczenia to jest taki „szwajcarski scyzoryk” do MySQL – niby prosty interfejs, ale pod spodem pełna moc SQL-a. Warto też wiedzieć, że phpMyAdmin nie zastępuje poprawnie napisanego kodu aplikacji czy mechanizmów migracji baz danych, ale w codziennej pracy administratora i programisty webowego jest niesamowicie przydatny: do szybkiego podglądu rekordów, debugowania problemów z danymi, sprawdzania wydajności zapytań czy ręcznej korekty błędnie zapisanych wpisów. Dobrą praktyką jest ograniczanie dostępu do phpMyAdmina (np. przez hasło, IP, HTTPS), bo daje on bardzo szerokie możliwości ingerencji w dane – a więc jest newralgicznym punktem z punktu widzenia bezpieczeństwa.

Pytanie 5

W języku SQL, w wyniku wykonania poniższego zapytania:

ALTER TABLE osoba DROP COLUMN grupa;
A. zostanie zmieniona nazwa kolumny na grupa
B. zostanie usunięta kolumna grupa
C. zostanie zmieniona nazwa tabeli na grupa
D. zostanie dodana kolumna grupa
Zapytanie SQL 'ALTER TABLE osoba DROP COLUMN grupa;' jest komendą, która służy do usunięcia kolumny o nazwie 'grupa' z tabeli 'osoba'. Komenda ta wykorzystuje instrukcję ALTER TABLE, która jest standardową konstrukcją SQL używaną do modyfikacji struktury istniejącej tabeli. W kontekście baz danych, usunięcie kolumny może być nieodwracalne, co oznacza, że wszystkie dane zawarte w tej kolumnie zostaną trwale usunięte. Przykładem zastosowania tej komendy może być sytuacja, w której kolumna 'grupa' nie jest już potrzebna, na przykład, po zmianie wymagań aplikacji lub po analogicznym przekształceniu modelu danych. Zgodnie z normami SQL, aby uniknąć błędów, przed wykonaniem takiej operacji warto wykonać kopię zapasową bazy danych. Warto również pamiętać, że niektóre systemy zarządzania bazami danych mogą wymagać dodatkowych opcji, aby zrealizować tę operację, na przykład, jeśli kolumna jest kluczem obcym lub jest związana z innymi strukturami. Podsumowując, użycie tej komendy skutkuje trwałym usunięciem kolumny 'grupa' z tabeli 'osoba'.

Pytanie 6

Jakiego języka można użyć do nawiązania połączenia z bazą MySQL w trakcie tworzenia aplikacji internetowej?

A. PHP
B. XHTML
C. CSS
D. HTML
PHP to naprawdę fajny język skryptowy, który świetnie sprawdza się w tworzeniu dynamicznych aplikacji internetowych. Jest super efektywny, kiedy trzeba połączyć się z bazami danych, takimi jak MySQL. Jako język serwerowy, daje programistom narzędzia do robienia różnych rzeczy z danymi, jak dodawanie, edytowanie czy usuwanie rekordów w bazie. Na przykład, gdy tworzysz aplikację do zarządzania użytkownikami, możesz użyć PHP do obsługi formularza rejestracyjnego, który zbiera dane od użytkowników i następnie łączy się z MySQL, by je zapisać. Do łączenia z bazą danych używa się funkcji, jak mysqli_connect() lub PDO (PHP Data Objects), co pozwala na bezpieczne i sprawne zarządzanie połączeniami oraz zapytaniami SQL. Co ważne, PHP zachęca do dobrych praktyk, jak stosowanie przygotowanych zapytań, co mocno zwiększa bezpieczeństwo aplikacji, chroniąc przed różnymi atakami, jak SQL injection.

Pytanie 7

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 WHERE status = 'zamknięte';
D. TRUNCATE TABLE zadania;
Odpowiedź DELETE FROM zadania WHERE status = 'zamknięte' jest poprawna, ponieważ wykorzystuje standardową składnię SQL do usuwania rekordów z tabeli na podstawie zadanych warunków. W tym przypadku, kwerenda ta usuwa tylko te wiersze, które mają wartość 'zamknięte' w polu status. Jest to podejście zgodne z dobrymi praktykami, ponieważ pozwala na precyzyjne określenie, które dane mają zostać usunięte, co minimalizuje ryzyko przypadkowego usunięcia innych rekordów. Na przykład, w systemie zarządzania projektami, możemy mieć wiele zadań z różnymi statusami, takimi jak 'otwarte', 'w trakcie', czy 'zamknięte'. Użycie tej kwerendy pozwala na oczyszczenie bazy danych z nieaktualnych zadań, co jest kluczowe dla utrzymania porządku i efektywności w zarządzaniu projektami. Ponadto, stosując tę metodę, możemy w przyszłości łatwo modyfikować warunki usuwania, na przykład zmieniając status na 'wstrzymane', zachowując elastyczność w zarządzaniu danymi.

Pytanie 8

W której notacji diagramów ER został zapisany model związków encji przedstawiony na ilustracji?

Ilustracja do pytania
A. Bachmana.
B. Martina.
C. Chena.
D. Min-Max.
Na diagramie przedstawiono model w notacji Martina, a nie w żadnej z pozostałych wymienionych. Warto zrozumieć, czym ta notacja różni się od innych, bo w praktyce projektowania baz danych bardzo łatwo je ze sobą pomylić. Notacja Chena to bardziej „akademickie” podejście do ERD. Encje są zwykle rysowane jako prostokąty, ale atrybuty pojawiają się w osobnych elipsach, połączonych liniami z encją. Klucz główny bywa podkreślony, a związki są reprezentowane przez romby z nazwą relacji. Na naszym diagramie nic takiego nie ma – atrybuty są w środku prostokąta, w formie listy, a nie jako osobne kształty, więc to już mocny sygnał, że to nie jest Chen. Z kolei notacja Bachmana historycznie kojarzy się z modelami sieciowymi i specyficznym sposobem prezentowania struktur danych, często z łamanymi liniami i strzałkami, raczej nie przypomina tabel z nagłówkiem i listą pól. W typowych podręcznikach do systemów baz danych Bachman jest pokazywany jako dość stary styl, dziś mało używany przy klasycznym relacyjnym ERD, więc mało prawdopodobne, by tak wyglądał nowoczesny diagram klient–zakup–towar. Odpowiedź Min-Max jest też myląca, bo Min-Max nie jest nazwiskiem autora notacji, tylko sposobem zapisu krotności relacji, np. (0,1), (1,n). Można taki zapis wykorzystać zarówno z notacją Chena, jak i z innymi, ale sam diagram z obrazka nie używa jawnego oznaczenia min/max przy relacjach – widzimy crow’s foot, czyli styl typowy dla Martina. Typowy błąd w tego typu pytaniach polega na tym, że ktoś kojarzy jeden detal, np. gdzieś widział oznaczenia min-max, i automatycznie zakłada, że każda notacja z relacjami i krotnościami to „Min-Max”. Tutaj jednak kluczowe są kształty encji i sposób zapisu atrybutów: prostokąt z nagłówkiem i lista pól jak w tabeli, bez elips i rombów, bez dodatkowych znaczników kluczy – to bardzo klasyczny, praktyczny styl używany przy projektowaniu relacyjnych baz danych, właśnie w notacji Martina. Dobrze jest więc patrzeć na diagram całościowo, a nie tylko na pojedynczy symbol, bo wtedy łatwiej uniknąć takich pomyłek.

Pytanie 9

Które z poleceń przyznaje użytkownikowi uczen najniższe uprawnienia w kontekście modyfikacji danych oraz struktury tabeli?

A. GRANT ALTER, SELECT ON szkola.przedmioty TO uczen;
B. GRANT SELECT ON szkola.przedmioty TO uczen;
C. GRANT INSERT, DROP ON szkola.przedmioty TO uczen;
D. GRANT DROP ON szkola.przedmioty TO uczen;
Odpowiedź GRANT SELECT ON szkola.przedmioty TO uczen jest całkiem niezła. Daje użytkownikowi 'uczen' tylko możliwość przeglądania danych z tabeli 'przedmioty' w bazie danych 'szkola'. To znaczy, że nie może on nic zmieniać ani modyfikować struktury tabeli, co jest spoko, bo zapewnia to większe bezpieczeństwo. Z własnego doświadczenia mogę powiedzieć, że dobrze jest przydzielać uprawnienia w taki sposób, żeby użytkownicy mieli tylko to, co im naprawdę potrzebne do pracy. W przypadku ucznia, który tylko chce się uczyć i patrzeć na przedmioty, dostęp do operacji takich jak INSERT, UPDATE czy DROP nie ma sensu, bo tylko stwarza ryzyko niekontrolowanych zmian w danych. W edukacji warto ograniczyć dostęp, żeby zachować porządek i uniknąć błędów oraz nadużyć. Więc dobrze, że wybrałeś tę odpowiedź.

Pytanie 10

Obiekt bazy danych, którego głównym przeznaczeniem jest drukowanie lub wyświetlanie zestawień danych, to

A. moduł.
B. formularz.
C. makro.
D. raport.
Poprawna odpowiedź to „raport”, bo właśnie ten obiekt bazy danych jest przeznaczony typowo do estetycznego drukowania lub wyświetlania gotowych zestawień danych. W typowych systemach bazodanowych, takich jak Microsoft Access czy różne narzędzia klasy RAD, formularze służą głównie do wprowadzania i edycji danych, kwerendy do ich wyszukiwania i filtrowania, a raporty do prezentacji wyników w uporządkowanej, czytelnej formie. Raport ma własny projekt układu: nagłówki, stopki, grupowanie po polach (np. po kliencie, dacie, dziale), sumy częściowe i końcowe, numerację stron, a często także pola obliczeniowe. To jest dokładnie to, czego potrzebujemy, gdy chcemy przygotować np. wydruk faktur, miesięczne zestawienie sprzedaży, raport obecności pracowników albo raport kasowy do działu księgowości. Z mojego doświadczenia raport traktuje się jako końcowy produkt pracy z danymi – użytkownika końcowego zwykle nie interesują tabele czy relacje, tylko czy dostanie przejrzysty wydruk lub PDF, który można wysłać dalej. Dobre praktyki mówią, żeby w raportach nie upychać logiki biznesowej ani skomplikowanych obliczeń, tylko oprzeć je na dobrze przygotowanych kwerendach. Raport powinien być możliwie prosty, czytelny i stabilny – tak, żeby zmiana sposobu liczenia odbywała się w warstwie zapytań, a nie w każdym raporcie osobno. W narzędziach BI (np. Power BI, Tableau, ale też klasyczne Crystal Reports) idea jest podobna: raport to warstwa prezentacji, która korzysta z danych z bazy, modelu analitycznego albo widoków SQL. W praktyce w firmach raporty są podstawą podejmowania decyzji, więc poprawne zrozumienie ich roli w bazie danych jest naprawdę kluczowe.

Pytanie 11

Przy użyciu komendy ALTER TABLE można

A. usunąć dane z rekordu
B. zmodyfikować strukturę tabeli
C. skasować tabelę
D. zmienić dane w rekordach
Kiedy mówimy o poleceniu ALTER TABLE w SQL, to jest to naprawdę ważne narzędzie, które pozwala na zmianę struktury tabeli w bazie danych. Możemy dzięki niemu dodać nowe kolumny, zmienić rodzaj danych w istniejących czy nawet usunąć niepotrzebne kolumny. Na przykład, gdybyśmy chcieli dodać kolumnę 'data_urodzenia' do tabeli 'pracownicy', to musielibyśmy użyć takiego polecenia: ALTER TABLE pracownicy ADD data_urodzenia DATE;. To wszystko jest kluczowe, żeby nasze aplikacje mogły się rozwijać i żeby baza danych spełniała coraz to nowe wymagania. Z mojego doświadczenia wynika, że najlepiej jest zawsze robić kopię zapasową danych przed wprowadzeniem jakichkolwiek zmian. Dobrze by też było testować zmiany w środowisku, które nie jest produkcyjne, zanim coś popsujemy. Warto pamiętać, że niektóre operacje mogą wymagać zablokowania tabeli, co może skutkować tym, że użytkownicy nie będą mogli korzystać z systemu, więc trzeba to mieć na uwadze.

Pytanie 12

W relacyjnym modelu danych, krotki definiuje się jako

A. wiersze tabeli wyłączając wiersz nagłówkowy, w którym znajdują się nazwy kolumn
B. wszystkie kolumny tabeli, które reprezentują atrybuty obiektu
C. liczbę rekordów w tabeli
D. wszystkie wiersze w tabeli łącznie z wierszem nagłówkowym
Krotka to taki ważny element w relacyjnych bazach danych, który odnosi się do konkretnych rekordów w tabeli. Każda krotka to jakby zestaw informacji, który dotyczy jednej jednostki, na przykład pojedynczego użytkownika w tabeli 'Użytkownicy'. Zawiera wartości atrybutów, które są przypisane do kolumn w tabeli. Te wartości są przechowywane w wierszach, a nagłówek z nazwami kolumn nie wchodzi w grę, jeśli chodzi o definicję krotek. Na przykład, w tabeli dotyczącej studentów, każdy wiersz mógłby zawierać dane jednego studenta, takie jak imię, nazwisko, wiek czy kierunek studiów. Myślę, że zrozumienie, czym jest krotka, jest kluczowe, żeby dobrze projektować bazy danych i używać SQL, bo w nim operacje na krotkach to podstawa większości zapytań. W praktyce, krotki pomagają również tworzyć relacje między tabelami w bazie danych, gdzie można je wykorzystać do przedstawiania powiązań między różnymi obiektami, na przykład 'Studenci' i 'Kursy'.

Pytanie 13

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

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

Pytanie 14

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

GRANT ALL PRIVILEGES ON klienci TO jan;
REVOKE SELECT, INSERT, UPDATE, DELETE ON klienci FROM jan;
A. Będzie mógł dodawać rekordy do tabeli klienci
B. Będzie mógł usuwać rekordy z tabeli klienci
C. Będzie mógł przeszukiwać dane w tabeli klienci
D. Będzie mógł zmieniać strukturę tabeli klienci
Rozważając inne opcje dostępne w pytaniu warto zwrócić uwagę na zakres uprawnień jakie są zazwyczaj przyznawane użytkownikom baz danych. Uprawnienia takie jak INSERT pozwalają na dodawanie nowych rekordów do tabeli co jest istotne w aplikacjach wymagających częstego aktualizowania danych użytkowników. Jednak w przedstawionym scenariuszu uprawnienia te zostały usunięte poleceniem REVOKE co oznacza że jan nie może wstawiać nowych rekordów do tabeli klienci co zdaje się być częstym nieporozumieniem w interpretacji uprawnień. Podobnie DELETE pozwala na usuwanie rekordów co jest kluczowe w zarządzaniu przestrzenią i utrzymywaniu danych aktualnymi. Jednakże po ponownym rozważeniu zaproponowanego scenariusza widzimy że jan nie ma już tych uprawnień. SELECT z kolei służy do przeszukiwania i wyświetlania danych co jest podstawowym działaniem w analizie danych. Brak tego uprawnienia oznacza brak możliwości przeglądania danych co może być ograniczeniem w pracy z bazą danych. Często mylnie zakłada się że użytkownik posiada wszystkie podstawowe uprawnienia co wynika z niewłaściwego zrozumienia poleceń GRANT i REVOKE. W praktyce administratorzy baz danych muszą precyzyjnie zarządzać uprawnieniami aby zapewnić bezpieczeństwo integralność i wydajność danych co oznacza dokładne zrozumienie i stosowanie poleceń DCL (Data Control Language).

Pytanie 15

Zgodnie z zasadami ACID, odnoszącymi się do przeprowadzania transakcji, wymóg trwałości (ang. durability) wskazuje, że

A. transakcja może w pewnych okolicznościach być rozdzielona na dwa niezależne etapy
B. dane zatwierdzone przez transakcję powinny być dostępne niezależnie od tego, co się wydarzy po jej zakończeniu
C. w trakcie realizacji transakcji dane mogą być zmieniane przez inne transakcje
D. w sytuacji naruszenia spójności bazy danych transakcja eliminuje tabele z kluczami obcymi
Wymóg trwałości (durability) w kontekście właściwości ACID oznacza, że po zatwierdzeniu transakcji, wszystkie zmiany dokonane na danych muszą być utrwalone w trwałym magazynie danych, a ich dostępność nie może być zagrożona przez awarie systemu, takie jak utrata zasilania czy awarie oprogramowania. Przykładem może być system bankowy, gdzie po wykonaniu operacji przelewu, saldo konta musi być natychmiastowo zaktualizowane i dostępne w systemie, niezależnie od tego, co wydarzy się później. W praktyce, wiele systemów zarządzania bazami danych, takich jak PostgreSQL czy MySQL, wykorzystuje mechanizmy logowania transakcji oraz techniki replikacji, aby zapewnić, że dane pozostaną spójne i dostępne nawet w obliczu kryzysów. Zgodność z zasadą trwałości jest kluczowa dla utrzymania zaufania użytkowników i stabilności operacyjnej systemów informacyjnych, co jest wspierane przez standardy takie jak ISO/IEC 27001 dotyczące zarządzania bezpieczeństwem informacji.

Pytanie 16

Baza danych zawiera tabelę pod nazwą pracownicy, która ma pola: nazwisko, imię, pensja oraz wiek. Jak brzmi składnia zapytania, aby obliczyć średnią pensję pracowników?

A. select VAR(pracownicy) into pensja
B. select AVG(nazwisko) into pensja
C. select VAR(pensja) from nazwisko
D. select AVG(pensja) from pracownicy
Aby obliczyć średnią pensję pracowników w tabeli 'pracownicy', używamy funkcji agregującej AVG, która zwraca średnią wartość dla podanego pola. W kontekście SQL, składnia polecenia 'select AVG(pensja) from pracownicy' jest poprawna, ponieważ wskazuje, że chcemy obliczyć średnią z kolumny 'pensja' w tabeli 'pracownicy'. Funkcje agregujące, takie jak AVG, SUM, COUNT, MIN i MAX, są fundamentalne w analizie danych, ponieważ umożliwiają zestawienie wyników w sposób zrozumiały i zwięzły. Przydatność funkcji AVG można zauważyć w praktyce, gdy potrzebujemy ocenić wynagrodzenia w firmie, co może wpłynąć na decyzje dotyczące polityki płacowej. Przykładowo, w przypadku tabeli z danymi o wynagrodzeniach, takie zapytanie zwraca pojedynczą wartość – średnią pensję, co pozwala na szybkie zrozumienie sytuacji finansowej firmy. Zgodnie z standardami SQL, polecenia muszą być formułowane w sposób, który jasno określa zarówno źródło danych, jak i sposób ich agregacji, co zostało spełnione w tej odpowiedzi.

Pytanie 17

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

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

Pytanie 18

Formularz główny używany do poruszania się w bazie danych pomiędzy formularzami i kwerendami dostępnymi w systemie określany jest jako formularz

A. zagnieżdżonym
B. sterującym
C. pierwotnym
D. głównym
Formularz sterujący jest kluczowym elementem w systemach baz danych, pełniącym funkcję nawigacyjną pomiędzy różnymi formularzami i kwerendami. Jego głównym zadaniem jest umożliwienie użytkownikowi łatwego dostępu do różnych części aplikacji, co zwiększa efektywność i intuicyjność pracy. Dobre praktyki w projektowaniu interfejsów użytkownika sugerują, aby formularze sterujące były przejrzyste i estetyczne, co ułatwia orientację w systemie. Przykładem zastosowania formularza sterującego może być aplikacja zarządzająca danymi klientów, gdzie użytkownik może za pomocą jednego formularza przeskakiwać pomiędzy zleceniami, danymi kontaktowymi oraz fakturami. Takie podejście nie tylko oszczędza czas, ale także redukuje ryzyko pomyłek. Warto również pamiętać, że formularze sterujące powinny być zgodne z zasadami użyteczności i dostępności, aby były dostępne dla jak najszerszej grupy użytkowników, w tym osób z niepełnosprawnościami.

Pytanie 19

Zdefiniowanie klucza obcego jest niezbędne do utworzenia

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

Pytanie 20

Podczas tworzenia tabeli w SQL, dla jednej z kolumn ustalono klucz główny. Jakie atrybuty należy zastosować, aby uniemożliwić wprowadzenie wartości pustej?

A. NULL
B. DEFAULT
C. NOT NULL
D. UNIQUE
Atrybut NOT NULL jest kluczowym elementem w definiowaniu struktury tabeli w języku SQL, który zabezpiecza kolumnę przed wstawianiem wartości pustych (NULL). W kontekście klucza głównego, który ma zapewnić unikalność i identyfikowalność każdego rekordu w tabeli, użycie NOT NULL jest niezbędne, aby zagwarantować, że każda wartość w tej kolumnie jest zawsze obecna. Dla przykładu, w stworzonej tabeli `Pracownicy`, jeśli kolumna `ID_Pracownika` jest kluczem głównym, atrybut NOT NULL wymusi, że każde wstawienie rekordu będzie wymagało podania unikalnej wartości dla `ID_Pracownika`, co uniemożliwia dodanie rekordu bez tej wartości. Standard SQL definiuje NOT NULL jako jeden z podstawowych atrybutów, które mogą być używane w deklaracji kolumn, a jego stosowanie jest kluczowe dla integracji danych oraz zapewnienia spójności bazy danych. W praktyce, w przypadku prób dodania rekordu z pustą wartością w takiej kolumnie, system generuje błąd, co eliminuje ryzyko powstawania niekompletnych danych.

Pytanie 21

Związek między tabelami, osiągany przez bezpośrednie połączenie kluczy głównych obu tabel, nazywamy relacją

A. n..1
B. 1..1
C. n..m
D. 1..n
Zdecydowanie, tu coś poszło nie tak. Wybierając zły wariant, mogłeś nie do końca zrozumieć, jak działają te relacje między danymi. Odpowiedzi 1..n i n..1 to świetne przykłady na to, jak można się pogubić. W relacji 1..n, jeden rekord z tabeli A może mieć wiele rekordów w tabeli B, co już wprowadza zamieszanie, bo w pytaniu mowa była o unikalnych połączeniach. Z kolei n..1 to jakby odwrotność, gdzie wiele rekordów w A jest powiązanych z jednym w B – również nie to, czego szukamy. I jeszcze ta odpowiedź n..m, która dotyczy relacji wiele do wielu – tu to w ogóle wymaga dodatkowych tabel, a to już może skomplikować wszystko. Takie błędy mogą wynikać z braku zrozumienia, jak zbudowane są bazy danych i zasady ich normalizacji. Fajnie byłoby pamiętać, że każda tabela powinna skupiać się na jednym typie encji, bo to naprawdę ułatwia sprawę i unika nieporozumień.

Pytanie 22

Jaką relację w projekcie bazy danych powinno się ustalić pomiędzy tabelami przedstawionymi na rysunku, przy założeniu, że każdy klient sklepu internetowego złoży co najmniej dwa zamówienia?

Ilustracja do pytania
A. 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia
B. n:n
C. 1:1
D. 1:n, gdzie 1 znajduje się po stronie Zamówienia, a wiele po stronie Klienta
Relacja 1:n, gdzie 1 jest po stronie Klienta, a wiele po stronie Zamówienia, oznacza, że każdy klient może mieć wiele zamówień, ale każde zamówienie jest powiązane dokładnie z jednym klientem. To podejście odpowiada rzeczywistości większości sklepów internetowych, gdzie klienci wielokrotnie dokonują zamówień. Projektując bazę danych zgodnie z tą relacją, stosujemy klucz obcy w tabeli Zamówienia, który odwołuje się do klucza głównego w tabeli Klient. Jest to zgodne z dobrymi praktykami w projektowaniu baz danych, które zalecają minimalizowanie redundancji i zapewnienie integralności danych. Praktyczne zastosowanie tego modelu umożliwia łatwe śledzenie historii zamówień klientów, co jest kluczowe dla analizy sprzedaży i zarządzania relacjami z klientami. Relacja 1:n jest jedną z najczęściej stosowanych w modelowaniu danych, co potwierdza jej uniwersalność i skuteczność w różnych systemach informatycznych, od sklepów internetowych po systemy zarządzania zasobami ludzkimi.

Pytanie 23

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

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

Pytanie 24

W tabeli mieszkancy znajdują się różne dane. Aby przefiltrować jedynie mieszkańców, którzy mają przypisaną dzielnicę = 1, stworzono dla uproszczenia działania wirtualną tabelę (widok) poprzez zastosowanie kwerendy

A. CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy WHERE dzielnica = 1
B. CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy
C. CREATE VIEW mieszkancy WHERE dzielnica = 1
D. CREATE VIEW mieszkancy FROM mieszkancy WHERE dzielnica = 1
Odpowiedzi, które nie pasują do definicji widoków w SQL, mają kilka kluczowych błędów. W pierwszej z nich, 'CREATE VIEW mieszkancy WHERE dzielnica = 1;', brakuje ważnych elementów do zdefiniowania widoku. Przede wszystkim, nie ma słowa 'AS', które powinno być tam, żeby określić kwerendę, z której widok się tworzy. SQL wymaga, żeby definicja widoku miała zapytanie, czego tutaj brakuje. W drugiej odpowiedzi, 'CREATE VIEW mieszkancy FROM mieszkancy WHERE dzielnica = 1;', również jest niepoprawna, bo nie ma 'AS' i jest zła składnia, bo 'FROM' nie może być używane w tworzeniu widoku bez odpowiedniej struktury. Ostatnia odpowiedź, 'CREATE VIEW mieszkancySrodmiescie AS SELECT * FROM mieszkancy;', choć składnia jest okej, nie filtruje danych do mieszkańców z dzielnicy nr 1. To błędne myślenie, bo często zapominamy o używaniu filtrów, co prowadzi do tego, że mamy za dużo danych do analizy. Tworząc widoki, warto zawsze mieć na uwadze, po co je robimy i zadbać o to, żeby zawierały tylko te dane, które są nam naprawdę potrzebne.

Pytanie 25

Jakie obiekty w bazie danych służą do podsumowywania, prezentacji oraz drukowania danych?

A. raport
B. formularz
C. zapytanie
D. zestawienie
Zapytanie, formularz i zestawienie również są ważnymi elementami pracy z bazami danych, jednak żaden z tych obiektów nie spełnia wszystkich funkcji przypisywanych raportom. Zapytanie to instrukcja w języku zapytań, najczęściej SQL, która służy do pobierania danych z bazy danych. Choć zapytania mogą generować dane do późniejszego wykorzystania w raportach, same w sobie nie są narzędziem służącym do ich prezentacji ani podsumowywania. Formularz natomiast to struktura, która umożliwia użytkownikom wprowadzanie danych do bazy danych. Używa się go głównie do zbierania informacji, ale nie do ich analizy czy podsumowywania w formie raportów. Zestawienie to termin, który odnosi się do ogólnego podsumowania danych, ale również nie oferuje tak zaawansowanej i zorganizowanej prezentacji jak raport. Typowym błędem myślowym jest mylenie tych terminów, co może prowadzić do nieporozumień przy projektowaniu systemów informacyjnych. Ważne jest, aby zrozumieć, że każdy z tych elementów pełni inną rolę w zarządzaniu danymi. Aby poprawnie wykorzystać potencjał baz danych, należy umiejętnie dobierać narzędzia do konkretnego zadania.

Pytanie 26

Aby zwiększyć wydajność operacji w bazie danych, należy skupić się na polach, które są często wyszukiwane lub sortowane

A. dodać klucz obcy
B. dodać więzy integralności
C. stworzyć oddzielną tabelę przechowującą wyłącznie te pola
D. utworzyć indeks
Dodawanie kluczy obcych nie jest bezpośrednią metodą na przyspieszenie operacji na bazie danych. Klucze obce są używane do zapewnienia integralności referencyjnej, co oznacza, że ich celem jest zapewnienie spójności danych w relacjach pomiędzy tabelami. Choć klucze obce mogą wpłynąć na wydajność w kontekście zapytań, nie przyspieszają one ani nie optymalizują wyszukiwania w obrębie pojedynczych tabel. Tworzenie osobnych tabel przechowujących tylko te pola również nie jest metodą optymalizacji efektywności wyszukiwania. Tego rodzaju podejście może prowadzić do komplikacji w zarządzaniu danymi oraz zmniejszenia wydajności przy łączeniu tabel w zapytaniach. Dodanie więzów integralności, które zapewniają, że dane w tabelach są poprawne i zgodne z określonymi zasadami, jest również istotne, ale nie wpływa bezpośrednio na szybkość operacji na bazie danych. Takie podejścia mogą prowadzić do błędnych przekonań, że poprawa wydajności bazy danych można osiągnąć poprzez wprowadzenie dodatkowych ograniczeń lub zmian w strukturze danych, co w rzeczywistości może generować dodatkowe koszty obliczeniowe przy wykonywaniu podstawowych operacji. Kluczowe jest stosowanie odpowiednich technik indeksacji, które są powszechnie uznawane za najlepszą praktykę w kontekście optymalizacji zasobów bazy danych.

Pytanie 27

W instrukcji CREATE TABLE zastosowanie klauzuli PRIMARY KEY przy definiowaniu pola tabeli spowoduje, że to pole stanie się

A. indeksem unikalnym
B. kluczem podstawowym
C. kluczem obcym
D. indeksem klucza
Wybór klucza obcego jako odpowiedzi jest błędny, ponieważ klucz obcy to inny typ atrybutu, który służy do tworzenia powiązań między tabelami. Klucz obcy odnosi się do klucza podstawowego w innej tabeli, co pozwala na utrzymanie relacyjnych danych. Nie jest to struktura, która jednoznacznie identyfikuje rekord w swojej tabeli, lecz odnosi się do rekordów w innej tabeli. Z kolei indeks klucza to struktura danych, która przyspiesza operacje wyszukiwania na kolumnach tabeli, ale nie pełni funkcji zapewnienia unikalności danych, co jest kluczowe dla klucza podstawowego. Indeks unikalny także różni się od klucza podstawowego; chociaż zapewnia unikalność wartości, może zawierać wartości NULL, podczas gdy klucz podstawowy ich nie dopuszcza. Typowym błędem myślowym jest mylenie tych pojęć, co prowadzi do nieporozumień w projektowaniu baz danych. Kluczowe jest zrozumienie ról, jakie poszczególne elementy struktury bazy danych odgrywają, aby efektywnie zarządzać danymi oraz zapewniać ich integralność. Właściwe zrozumienie tych koncepcji jest niezbędne do tworzenia prawidłowo działających systemów baz danych.

Pytanie 28

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

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

Pytanie 29

Jakie wartości powinny mieć zmienne w funkcji z biblioteki mysqli, by ustanowić połączenie z serwerem i bazą danych?

mysqli_connect($a, $b, $c, $d) or die('Brak połączenia z serwerem MySQL.');
A. adres serwera - $c, nazwa bazy danych - $d, login - $a, hasło - $b
B. adres serwera - $a, nazwa bazy danych - $d, login - $b, hasło - $c
C. adres serwera - $a, nazwa bazy danych - $b, login - $c, hasło - $d
D. adres serwera - $c, nazwa bazy danych - $d, login - $b, hasło - $a
Wybór złych odpowiedzi pewnie wynika z tego, że nie do końca zrozumiałeś, jak ważna jest prawidłowa kolejność argumentów w funkcji mysqli_connect. Często zdarza się pomylić kolejność argumentów przy połączeniu z bazą danych. Rozumienie tej logiki jest naprawdę istotne: pierwszy argument to adres serwera, np. localhost, a drugi to nazwa użytkownika. Trzeci to hasło do bazy, a czwarty to nazwa bazy, z którą chcesz się połączyć. Jak zmienisz kolejność tych zmiennych, to nie uda się nawiązać połączenia, bo serwer nie będzie wiedział, jak uwierzytelnić użytkownika ani znaleźć bazy. Użytkownikom, którzy nie czują się pewnie w tym temacie, może to być frustrujące. Z mojego doświadczenia, kluczem jest dobrze poznać specyfikację funkcji oraz myśleć logicznie, żeby przypisać zmienne do odpowiednich argumentów. Jak to ogarniesz, to unikniesz wielu błędów i lepiej sobie poradzisz z bazami danych w przyszłości.

Pytanie 30

W tabeli mieszkancy znajdują się dane o osobach z całej Polski. Aby zliczyć, ile różnych miast jest zawartych w tej tabeli, należy wykonać kwerendę

A. SELECT COUNT(DISTINCT miasto) FROM mieszkancy;
B. SELECT COUNT(miasto) FROM mieszkancy DISTINCT;
C. SELECT COUNT(miasto) FROM mieszkancy;
D. SELECT DISTINCT miasto FROM mieszkancy;
Wybór niewłaściwych kwerend może prowadzić do błędnych wyników i nieefektywnego przetwarzania danych. Kwerenda SELECT COUNT(miasto) FROM mieszkancy; zlicza wszystkie rekordy w kolumnie miasto, ale nie eliminuje duplikatów. Zatem, jeśli w tabeli występuje wiele osób z tego samego miasta, wynik będzie zawyżony. Na przykład, przy danych o 100 mieszkańcach z Warszawy, kwerenda ta zwróci liczbę 100, co nie odpowiada liczbie unikalnych miast. Wykorzystywanie SELECT DISTINCT miasto FROM mieszkancy; również nie przyniesie pożądanych rezultatów, ponieważ nie dostarcza ich liczby, a jedynie listę unikalnych miast. To podejście może być przydatne, gdy chcemy zobaczyć wszystkie miasta, ale nie odpowiada na pytanie o ich liczbę. Wybór kwerendy SELECT COUNT(miasto) FROM mieszkancy DISTINCT; jest syntaktycznie niepoprawny, ponieważ DISTINCT nie może być użyty w ten sposób w kontekście COUNT. Typowe błędy myślowe prowadzące do takich wniosków to brak uwzględnienia roli DISTINCT w eliminacji duplikatów oraz nieznajomość właściwej składni SQL. Dlatego kluczowe jest zrozumienie funkcji agregujących oraz ich zastosowania w kontekście analizy danych, co jest niezbędne do skutecznego zarządzania bazami danych i wyciągania właściwych wniosków.

Pytanie 31

Zapytanie przedstawione poniżej zwróci wynik:

SELECT COUNT(cena) FROM uslugi;
A. średnią wartość cen usług w tabeli
B. wszystkie wartości cen usług w tabeli
C. sumę wartości cen usług w tabeli
D. liczbę wszystkich cen usług w tabeli
Pojawiające się nieporozumienia związane z interpretacją zapytania mogą prowadzić do błędnych wniosków. Wybór odpowiedzi, która zakłada, że zapytanie zwróci wszystkie ceny usług, jest nieprecyzyjny, ponieważ funkcja COUNT() nie wyświetla wszystkich wartości, a jedynie ich ilość. Z kolei odpowiedź sugerująca, że zapytanie oblicza średnią cenę usług, również jest błędna, ponieważ do obliczenia średniej stosuje się funkcję AVG(), a nie COUNT(). Dodatkowo, wybór opcji dotyczącej sumy cen usług jest mylący, gdyż do tego celu używa się funkcji SUM(). Zrozumienie, jak działają te funkcje, jest kluczowe w pracy z bazami danych. Funkcja COUNT() wykonuje zadanie zliczenia, co różni się od zadań agregacyjnych takich jak SUM() czy AVG(), które operują na wartościach liczbowych. Typowym błędem jest mylenie zadań zliczania z zadaniami obliczeniowymi, co może prowadzić do nieprawidłowych analiz danych. Dlatego ważne jest, aby przed sformułowaniem zapytania dobrze zrozumieć, jakie operacje są wykonywane na danych i jakie funkcje są do tego odpowiednie.

Pytanie 32

Kiedy należy użyć kwerendy SELECT DISTINCT, aby wybrać rekordy?

A. obecne w bazie tylko raz.
B. pogrupowane.
C. uporządkowane w kolejności malejącej lub rosnącej.
D. tak, aby w wskazanej kolumnie nie powtarzały się wartości.
Kwerenda SELECT DISTINCT jest używana w SQL do zwracania unikalnych rekordów z określonej kolumny lub kolumn. Głównym celem tej kwerendy jest eliminacja duplikatów z wyników zapytania, co jest szczególnie przydatne w sytuacjach, gdy interesuje nas uzyskanie listy unikalnych wartości, na przykład nazwisk pracowników w firmie, których można znaleźć w tabeli „Pracownicy”. Dzięki zastosowaniu DISTINCT, wynik zapytania dostarczy tylko różne nazwiska, eliminując powtarzające się wystąpienia. W kontekście dobrych praktyk w projektowaniu baz danych, korzystanie z DISTINCT pozwala na efektywniejsze analizowanie danych oraz lepsze zrozumienie struktury informacji w tabelach. Użycie SELECT DISTINCT może również pomóc w optymalizacji zapytań, szczególnie w rozbudowanych bazach danych, gdzie występowanie duplikatów może prowadzić do zafałszowania wyników analiz. Przykład praktyczny to zapytanie: SELECT DISTINCT kraj FROM Klienci, które zwróci wszystkie różne kraje, w których znajdują się klienci, co jest kluczowe w analizach geolokalizacyjnych.

Pytanie 33

Utworzono bazę danych zawierającą tabelę podzespoły, która składa się z pól: model, producent, typ, cena. Aby uzyskać listę wszystkich modeli pamięci RAM od firmy Kingston uporządkowaną według ceny, zaczynając od najniższej, należy wykorzystać zapytanie:

A. SELECT model FROM podzespoly WHERE typ="RAM" OR producent="Kingston" ORDER BY cena DESC
B. SELECT model FROM podzespoly WHERE typ="RAM" AND producent="Kingston" ORDER BY cena DESC
C. SELECT model FROM podzespoly WHERE typ="RAM" AND producent="Kingston" ORDER BY cena ASC
D. SELECT model FROM producent WHERE typ="RAM" OR producent="Kingston" ORDER BY podzespoly ASC
Wybór tej odpowiedzi jest prawidłowy, ponieważ kwerenda wykorzystuje poprawną składnię SQL do wyboru modeli pamięci RAM od producenta Kingston. Klauzula WHERE filtruje rekordy, aby uwzględnić tylko te, które mają typ 'RAM' oraz producenta 'Kingston', co jest kluczowe dla uzyskania właściwych wyników. Użycie operatora AND w tym kontekście zapewnia, że obie te cechy muszą być spełnione, co jest zgodne z zamiarem wyświetlenia wszystkich modeli pamięci RAM tego producenta. Dodatkowo, klauzula ORDER BY cena ASC sortuje wyniki w kolejności rosnącej według ceny, co jest wymagane do poprawnego przedstawienia danych od najtańszej do najdroższej pamięci. Takie podejście jest zgodne z dobrymi praktykami SQL, gdzie precyzyjne filtrowanie danych i porządkowanie wyników są kluczowe dla efektywności i dokładności zapytań. W praktyce, takie kwerendy mogą być używane w aplikacjach do zarządzania produktami czy bazach danych e-commerce, aby pomóc użytkownikom w szybkim odnajdywaniu pożądanych produktów w oparciu o konkretne kryteria.

Pytanie 34

Który z elementów relacyjnej bazy danych, będący kodem w języku SQL, może być użyty w zapytaniach zmieniających kolumny danych przedstawiane w formie tabeli, niezależnie od tego, czy jest tworzony ręcznie, czy też dynamicznie?

A. Wyzwalacz
B. Funkcja zdefiniowana
C. Procedura składowa
D. Reguła
Funkcja zdefiniowana, znana również jako funkcja skalarna, jest obiektem relacyjnej bazy danych, który może być wywoływany w zapytaniach SQL, w tym w zapytaniach modyfikujących dane. Oferuje ona możliwość przetwarzania i zwracania wartości na podstawie określonego zestawu wejściowych. Funkcje zdefiniowane przez użytkownika są szczególnie przydatne, gdy potrzebujemy skomplikowanej logiki przetwarzania danych, która nie jest dostępna w standardowych funkcjach SQL. Przykładem może być funkcja obliczająca VAT na podstawie podanej kwoty, która może być użyta w zapytaniach INSERT lub UPDATE, aby dynamicznie obliczyć wartość i wprowadzić ją do bazy danych. W standardzie SQL, funkcje zdefiniowane są zgodne z normą SQL-92 i są kluczowym elementem w budowie bardziej zaawansowanych aplikacji bazodanowych. Umożliwiają one encapsulację logiki biznesowej, co pozwala na wielokrotne ich wykorzystanie, a także zwiększa czytelność kodu SQL.

Pytanie 35

Instrukcja SQL przedstawiona w formie graficznej

ALTER TABLE 'miasta'
ADD 'kod' text;
A. wprowadza do tabeli dwie kolumny o nazwach: kod i text
B. dodaje do tabeli kolumnę o nazwie kod typu text
C. zmienia nazwę tabeli miasta na nazwę kod
D. w tabeli miasta zmienia nazwę kolumny kod na nazwę text
Polecenie ALTER TABLE w SQL to naprawdę przydatne narzędzie, które pozwala na modyfikowanie struktury tabeli w bazie danych. W Twoim przypadku dodajesz nową kolumnę o nazwie 'kod' typu text do tabeli 'miasta'. To słowo kluczowe ADD oznacza, że chcemy coś dorzucić do tej tabeli. Typ text jest fajny, bo jest używany do przechowywania różnych dłuższych tekstów, co sprawia, że idealnie nadaje się do takich danych jak opisy czy kody pocztowe. Pamiętaj, że przed robieniem zmian w tabelach warto pomyśleć, jak to wpłynie na całe działanie aplikacji i procesów w firmie. Na przykład, jeśli musisz przechować dodatkowe info o miastach, jak właśnie kody pocztowe, to dodanie tego jest super pomysłem. Znajomość ALTER TABLE jest mega przydatna w zarządzaniu bazami danych, bo pozwala na elastyczne dostosowanie tabel do zmieniających się potrzeb. To naprawdę może zwiększyć efektywność systemu, jeśli dobrze to ogarniesz.

Pytanie 36

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

Ilustracja do pytania
A. Wprowadzić pole klucza obcego do tabeli Klienci i połączyć je z ID tabeli Zamowienia
B. Utworzyć trzecią tabelę z dwoma kluczami obcymi. Jeden klucz połączyć z ID tabeli Klienci, a drugi z ID tabeli Zamowienia
C. Połączyć relacją pola ID z obu tych tabel
D. Wprowadzić pole klucza obcego do tabeli Zamowienia i połączyć je z ID tabeli Klienci
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 37

Atrybut autor w tabeli ksiazka oznacza

CREATE TABLE ksiazka (
  id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
  tytul VARCHAR(200),
  autor SMALLINT UNSIGNED NOT NULL,
  CONSTRAINT `dane` FOREIGN KEY (autor) REFERENCES autorzy(id)
);
A. atrybut typu tekstowego zawierający informacje o autorze
B. kluczem podstawowym tabeli ksiazka
C. atrybut używany w relacji z tabelą dane
D. kluczem obcym powiązanym z tabelą autorzy
Pole autor w tabeli ksiazka jest zdefiniowane jako klucz obcy co oznacza że tworzy relację z inną tabelą w bazie danych w tym przypadku z tabelą autorzy która zawiera id autorów W relacyjnych bazach danych klucz obcy jest mechanizmem który pozwala na utrzymanie integralności danych pomiędzy powiązanymi tabelami Jest to szczególnie ważne w kontekście modelowania rzeczywistości gdzie różne encje takie jak książki i autorzy są zależne od siebie W powyższym przykładzie pole autor odwołuje się do pola id w tabeli autorzy umożliwiając przypisanie konkretnego autora do danej książki Taka konstrukcja bazy danych jest zgodna z zasadami normalizacji które dążą do minimalizacji redundancji danych i zapewnienia ich spójności Klucze obce są powszechnie stosowaną praktyką w projektowaniu baz danych dzięki której złożone relacje mogą być reprezentowane i zarządzane w sposób efektywny Umożliwiają one implementację mechanizmu kaskadowego aktualizowania lub usuwania danych co pomaga w zachowaniu spójności w całej bazie danych

Pytanie 38

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 tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()
B. SELECT * FROM ksiazki
C. SELECT tytul FROM ksiazki
D. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATE_NT_E()
Wybrana kwerenda SQL, czyli 'SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE();', jest poprawna, ponieważ precyzyjnie spełnia wymagania zadania. Kwerenda ta wybiera jedynie tytuły książek z tabeli 'ksiazki', które zostały wypożyczone w dniu, który odpowiada bieżącej dacie. Funkcja 'CURRENT_DATE()' zwraca datę systemową w formacie YYYY-MM-DD, co pozwala na prawidłowe porównanie z polem 'data_wypoz'. Takie podejście jest zgodne z dobrymi praktykami w zakresie analizy baz danych, gdzie minimalizowanie liczby zwracanych danych do niezbędnego minimum znacząco poprawia wydajność zapytań. W praktyce, taka kwerenda może być przydatna w systemach bibliotek, które generują codzienne raporty wypożyczeń, umożliwiając bibliotekarzom szybki dostęp do informacji o książkach, które były popularne danego dnia. Warto także pamiętać o możliwości używania dodatkowych filtrów, na przykład według konkretnego czytelnika, co zwiększa funkcjonalność raportu.

Pytanie 39

W bazie danych dotyczącej sklepu znajduje się tabela artykuły, która posiada pole o nazwie nowy. Jak można zaktualizować to pole, aby dla każdego rekordu wprowadzić wartość TRUE, stosując odpowiednią kwerendę?

A. INSERT INTO artykuły VALUE nowy=TRUE
B. INSERT INTO nowy FROM artykuły SET TRUE
C. UPDATE artykuły SET nowy=TRUE
D. UPDATE nowy FROM artykuły VALUE TRUE
Zastosowane w niepoprawnych odpowiedziach metody są błędne z kilku powodów, które warto przeanalizować. W pierwszym przypadku, INSERT INTO artykuły VALUE nowy=TRUE; próbuje wykorzystać instrukcję INSERT do wstawienia nowych danych, co jest nieodpowiednie w kontekście aktualizacji istniejących rekordów. INSERT służy do dodawania nowych wierszy, a nie do modyfikacji istniejących, co skutkuje nieadekwatnością do przedstawionego problemu. W drugim przykładzie, UPDATE nowy FROM artykuły VALUE TRUE; nie ma poprawnej składni SQL. Konstrukcja ta nie uwzględnia prawidłowego użycia klauzuli SET, co powoduje, że kwerenda byłaby nieefektywna. Trzeci wariant, INSERT INTO nowy FROM artykuły SET TRUE;, nie ma też sensu, ponieważ pole 'nowy' nie powinno być wstawiane jako nowy rekord. Tego typu błędy często wynikają z nieznajomości i źle zrozumianej składni SQL. Ponadto, nieodpowiednie użycie instrukcji INSERT oraz błędne koncepcje dotyczące aktualizacji danych w bazie mogą prowadzić do poważnych zniekształceń danych. W kontekście dobrych praktyk, kluczowe jest zrozumienie różnicy między operacjami INSERT i UPDATE oraz ich właściwym zastosowaniem w praktyce dla zapewnienia spójności oraz prawidłowego zarządzania danymi.

Pytanie 40

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. jedynie tworzenia i zmiany struktury tabel
B. jedynie dodawania i edytowania danych
C. wykonywania wszystkich operacji na strukturze danych
D. wykonywania wszelkich działań na danych
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.