Wyniki egzaminu

Nowy egzamin

Informacje o egzaminie:

Zawód: Technik informatyk
Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych
Data rozpoczęcia: 15 czerwca 2026 10:51
Data zakończenia: 15 czerwca 2026 11:09

Egzamin niezdany

Wynik: 18/40 punktów (45,0%)

Wymagane minimum: 20 punktów (50%)

Nowe

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

Przebieg egzaminu

Udostępnij swój wynik

Facebook

X.com

Szczegółowe wyniki:

Pytanie 1

Który typ relacji wymaga utworzenia tabeli POŚREDNIEJ łączącej klucze główne obu tabel?

A. n..m (wiele-do-wielu)

B. 1..n (jeden-do-wielu)

C. n..1 (wiele-do-jednego)

D. 1..1 (jeden-do-jednego)

Pozostałe relacje obywają się bez tabeli pośredniej. 1..n (oraz ta sama relacja widziana jako n..1) realizuje klucz OBCY po stronie „wielu”. 1..1 to także klucz obcy z ograniczeniem unikalności. Tabela pośrednia konieczna jest dopiero przy n..m.

Pytanie 2

Do czego służy w MS SQL Server polecenie RESTORE DATABASE?

A. do usunięcia bazy z serwera

B. do przywrócenia bazy danych z kopii zapasowej

C. do aktualizacji bazy z weryfikacją więzów integralności

D. do rekonstrukcji bazy z danych buforowanych

Pozostałe opisy nie pasują do RESTORE. Aktualizacja danych z weryfikacją więzów to zwykłe operacje DML i ograniczenia, a nie przywracanie. „Rekonstrukcja z danych buforowanych” nie jest funkcją tego polecenia. Usunięcie bazy to DROP DATABASE. RESTORE DATABASE przywraca bazę z kopii zapasowej.

Pytanie 3

Aby wybrać z bazy danych rekordy spełniające określone kryteria, należy utworzyć:

A. kwerendę (zapytanie)

B. raport

C. formularz

D. makro

Kwerenda (zapytanie) to obiekt bazy danych, który wybiera rekordy spełniające zadane warunki - odpowiada zapytaniu SELECT ... WHERE w SQL. Można w niej wskazać kolumny, kryteria filtrowania i sortowanie, a wynik wykorzystać dalej w formularzu czy raporcie. Dlatego do wybrania danych wg kryteriów tworzy się kwerendę.

Pytanie 4

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 nowy FROM artykuły VALUE TRUE

D. UPDATE artykuły SET nowy=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 5

Co chce osiągnąć poniższe zapytanie MySQL?

ALTER TABLE ksiazki
MODIFY tytul VARCHAR(100) NOT NULL;

A. Usunąć kolumnę tytul z tabeli ksiazki

B. Zmienić nazwę kolumny w tabeli ksiazki

C. Zmienić typ kolumny w tabeli ksiazki

D. Dodać do tabeli ksiazki kolumnę tytul

Polecenie SQL ALTER TABLE ksiazki MODIFY tytul VARCHAR(100) NOT NULL; służy do zmiany typu kolumny tytul w tabeli ksiazki. W tym przypadku typ kolumny jest zmieniany na VARCHAR(100), co oznacza, że będzie przechowywać łańcuchy znaków o maksymalnej długości 100 znaków, a dodatkowo kolumna ta nie może przyjmować wartości NULL. Użycie ALTER TABLE i MODIFY pozwala na dynamiczną modyfikację struktury tabeli bez konieczności jej usuwania i ponownego tworzenia, co jest korzystne w dużych systemach bazodanowych, gdzie minimalizacja czasu przestoju jest kluczowa. Praktyczne zastosowanie polecenia MODIFY jest szerokie i obejmuje sytuacje, w których wymagane są zmiany w przechowalności danych, na przykład aby dostosować się do nowych wymagań biznesowych lub normatywnych. Warto pamiętać o dopasowaniu zmian do istniejących danych i zapewnieniu spójności bazy danych, co jest dobrą praktyką w zarządzaniu bazami danych.

Pytanie 6

Dodanie do tabeli Produkty kolumny data_produkcji zostanie wykonane kwerendą SQL

A. ALTER TABLE Produkty ADD data_produkcji DATE;

B. ALTER TABLE Produkty ADD DATE data_produkcji;

C. ALTER TABLE Produkty DROP data_produkcji DATE;

D. ALTER TABLE Produkty DROP COLUMN data_produkcji DATE;

W poleceniu dotyczącym modyfikacji struktury tabeli bardzo łatwo pomylić składnię, zwłaszcza gdy w grę wchodzą słowa kluczowe ADD, DROP i typy danych. Podstawowa zasada jest taka: jeśli chcemy dodać nową kolumnę, używamy słowa kluczowego `ADD` wraz z nazwą kolumny i jej typem danych. Jeśli chcemy coś usuwać, korzystamy z `DROP` (czasem z dopiskiem `COLUMN`, zależnie od dialektu SQL). Mieszanie tych operacji albo zmiana kolejności elementów sprawia, że zapytanie staje się niepoprawne składniowo albo semantycznie.
Częsty błąd polega na tym, że ktoś próbuje użyć `DROP` tam, gdzie w treści zadania wyraźnie jest mowa o dodaniu kolumny. `DROP` służy do usuwania kolumn lub całych tabel, a nie do ich tworzenia. Jeżeli w instrukcji pojawia się `DROP data_produkcji DATE`, to po pierwsze logika jest odwrotna do wymaganej (bo usuwamy, zamiast dodawać), a po drugie większość systemów nie akceptuje podawania typu danych przy usuwaniu kolumny. W standardowych implementacjach SQL wystarczy `ALTER TABLE Produkty DROP COLUMN data_produkcji;` bez żadnego `DATE` na końcu. Dodawanie typu przy DROP jest po prostu niezgodne ze składnią.
Inny typ nieporozumienia polega na pomyleniu kolejności typu danych i nazwy kolumny. W definicji kolumny po słowie kluczowym `ADD` najpierw podajemy nazwę kolumny, a dopiero potem typ, czyli `ADD nazwa_kolumny TYP`. Konstrukcja w stylu `ADD DATE data_produkcji` wygląda, jakby ktoś traktował `DATE` jak nazwę kolumny, a `data_produkcji` jak typ. Jest to niezgodne zarówno ze składnią SQL, jak i z intuicją czytania definicji tabeli. Z mojego doświadczenia wynika, że ten błąd wynika z przenoszenia nawyków z języków programowania, gdzie czasem typ pisze się przed nazwą zmiennej (np. w C czy Javie), ale w SQL jest odwrotnie.
Dobra praktyka jest taka, żeby zapamiętać prosty wzór: przy dodawaniu kolumny zawsze używamy schematu `ALTER TABLE <tabela> ADD <kolumna> <typ>;`. Bez żadnych dodatkowych słów kluczowych w środku, bez mieszania DROP, bez odwracania kolejności. Warto też mieć w głowie, że przy DROP w większości dialektów nie podajemy typu, tylko samą nazwę kolumny, czasem z dopiskiem `COLUMN`. Takie drobne szczegóły często decydują, czy skrypt migracji bazy zadziała poprawnie, czy wysypie się na błędzie składni, dlatego dobrze jest wyrobić sobie nawyk dokładnego czytania treści zadania i rozumienia, czy w danym momencie coś dodajemy, czy usuwamy.

Pytanie 7

Która zasada dotyczy integralności danych w bazie?

A. w relacji 1..n klucz obcy łączy się z kluczem obcym innej tabeli

B. pole klucza obcego nie może być puste

C. klucz podstawowy musi mieć osobny indeks

D. pole klucza podstawowego nie może być puste

Jedną z zasad integralności jest to, że pole klucza PODSTAWOWEGO nie może być puste (NULL) - skoro identyfikuje rekord, musi mieć wartość w każdym wierszu. Dlatego klucz podstawowy nie może być pusty.

Pytanie 8

Na tabeli Pracownicy, której wiersze są przedstawione na załączonym obrazie, została zrealizowana podana kwerenda SELECT. Jakie dane zostaną zwrócone?

SELECT imie FROM pracownicy WHERE nazwisko = 'Kowal' OR stanowisko > 2;

id	imie	nazwisko	stanowisko
1	Anna	Kowalska	1
2	Monika	Nowak	2
3	Ewelina	Nowakowska	2
4	Anna	Przybylska	3
5	Maria	Kowal	3
6	Ewa	Nowacka	4

A. Anna, Maria, Ewa

B. Wyłącznie Anna

C. Monika, Ewelina, Maria

D. Wyłącznie Maria

Ważne jest zrozumienie działania klauzuli WHERE w SQL, zwłaszcza gdy stosujemy w niej operator OR. Częstym błędem przy analizie takich zapytań jest traktowanie operatora OR jak operatora AND co prowadzi do błędnych wniosków. W zapytaniu SELECT imie FROM pracownicy WHERE nazwisko = 'Kowal' OR stanowisko > 2 celem jest wybór imion pracowników spełniających przynajmniej jedno z podanych kryteriów. Można błędnie założyć że wybierane są tylko osoby z nazwiskiem Kowal i stanowiskiem większym od 2 lub odwrotnie co prowadzi do niepoprawnej interpretacji danych. Imiona takie jak Monika czy Ewelina nie pojawiają się w wyniku ponieważ ich stanowiska wynoszą dokładnie 2 co nie spełnia wymagań stanowisko > 2. Natomiast imię Maria jest wynikowe ponieważ nazwisko Kowal spełnia pierwszy warunek a Anna i Ewa są wybierane przez drugi warunek dotyczący stanowiska. Zrozumienie różnicy między operatorami AND i OR jest kluczowe dla poprawnego tworzenia zapytań SQL oraz unikania błędów logicznych przy przetwarzaniu danych. Operator OR wymaga aby przynajmniej jeden z warunków był prawdziwy co zwiększa elastyczność filtrowania danych ale także wymaga ostrożności aby nie uzyskać wyników niezgodnych z intencjami analizy. Znajomość i umiejętność wykorzystania różnych operatorów logicznych pozwala na efektywne zarządzanie danymi i ich analizę co jest niezbędne w pracy z bazami danych.

Pytanie 9

W języku PHP, podczas pracy z bazą danych MySQL, aby zakończyć sesję z bazą, powinno się użyć

A. mysqli_rollback()

B. mysqli_commit()

C. mysqli_close()

D. mysqli_exit( )

Wybór odpowiedzi 'mysqli_exit()' pojawia się często wśród programistów, którzy mylą koncepcje związane z obsługą połączeń w PHP. Należy zaznaczyć, że taka funkcja nie istnieje w kontekście baz danych MySQL, co może prowadzić do frustracji i nieporozumień. Niektórzy mogą sądzić, że 'mysqli_exit()' jest funkcją kończącą pracę z bazą, jednak w rzeczywistości nie ma żadnej dokumentacji ani zastosowania dla tej funkcji w standardowej bibliotece PHP. W programowaniu ważne jest, aby stosować się do oficjalnych dokumentacji oraz standardów, co zapewnia nie tylko poprawność kodu, ale także jego bezpieczeństwo i stabilność. Kolejne propozycje, takie jak 'mysqli_rollback()' i 'mysqli_commit()', dotyczą transakcji w bazie danych, a nie zakończenia połączenia. 'mysqli_rollback()' cofa zmiany wprowadzone w bieżącej transakcji, a 'mysqli_commit()' zatwierdza te zmiany. Oznacza to, że obie funkcje mają na celu zarządzanie transakcjami, a nie zamykanie połączeń. Wybierając niewłaściwą funkcję, programista może napotkać problemy z zarządzaniem stanem aplikacji i bazy danych, co jest szczególnie istotne w kontekście aplikacji wielowątkowych lub o dużym natężeniu ruchu. Aby uniknąć takich błędów, warto regularnie przeglądać i aktualizować swoją wiedzę oraz korzystać z zaufanych źródeł informacji.

Pytanie 10

W zamieszczonym kodzie PHP, zamiast znaków zapytania powinien być wyświetlony komunikat:

$x = mysql_query('SELECT * FROM mieszkancy');
if (!$x)
    echo '??????????????????????';

A. Błąd w trakcie przetwarzania zapytania

B. Niepoprawne hasło do bazy danych

C. Zapytanie zostało poprawnie przetworzone

D. Niepoprawna nazwa bazy danych

W przedstawionym kodzie PHP, komunikat "??????????????????????" powinien wskazywać na błąd przetwarzania zapytania SQL. Kiedy wynik funkcji mysql_query() jest równy fałszowi (false), oznacza to, że zapytanie nie mogło zostać poprawnie wykonane. Może to być spowodowane różnymi czynnikami, takimi jak błędy w składni zapytania, problemy z połączeniem z bazą danych, lub nieprawidłowe tabele. W tym przypadku, dobrym podejściem jest użycie funkcji mysql_error() w celu uzyskania bardziej szczegółowych informacji na temat natury błędu. Przykład poprawnego kodu mógłby wyglądać tak: $x = mysql_query('SELECT * FROM mieszkancy'); If (!$x) { echo mysql_error(); } Używanie tej metody pomaga w diagnostyce problemu i pozwala na szybsze jego rozwiązanie. Znalezienie i naprawienie błędów w zapytaniach SQL jest kluczowe w pracy z bazami danych, szczególnie w kontekście aplikacji internetowych, które muszą być niezawodne i efektywne.

Pytanie 11

Uprawnienia obiektowe nadawane użytkownikom bazy danych mogą zezwalać lub zabraniać:

A. wykonywania operacji na danych, np. wstawiania lub modyfikowania

B. dziedziczenia uprawnień

C. wykonywania instrukcji typu tworzenie kopii zapasowej

D. zmiany ról i kont użytkowników

Uprawnienia OBIEKTOWE odnoszą się do operacji na danych w konkretnych obiektach (np. tabelach) - pozwalają lub zabraniają m.in. SELECT, INSERT, UPDATE czy DELETE. Dlatego dotyczą wykonywania operacji na danych, jak wstawianie czy modyfikowanie.

Pytanie 12

Podczas przechowywania hasła użytkownika serwisu internetowego (np. bankowości online), aby chronić je przed ujawnieniem, zazwyczaj stosuje się funkcję

A. klucza.

B. cyklometrycznych.

C. mieszających.

D. abstrakcyjnych.

Użycie klucza do zabezpieczenia haseł użytkowników w systemach takich jak bankowość internetowa jest kluczowym elementem zapewnienia prywatności i bezpieczeństwa danych. Funkcje klucza, takie jak szyfrowanie, pozwalają na przekształcenie haseł w nieczytelne ciągi znaków, które są niemożliwe do odtworzenia bez odpowiedniego klucza. Przykładem jest zastosowanie algorytmów takich jak AES (Advanced Encryption Standard), które są szeroko uznawane i stosowane w branży. Dobre praktyki w zakresie zabezpieczania danych sugerują używanie silnych, losowych kluczy oraz regularne ich aktualizowanie. Ponadto, najnowsze standardy, takie jak NIST (National Institute of Standards and Technology), rekomendują stosowanie dodatkowych technik, takich jak solenie haseł, co zwiększa ich odporność na ataki. Dzięki temu, nawet w przypadku wycieku bazy danych, potencjalny atakujący napotyka na trudności w odzyskaniu oryginalnych haseł. Zrozumienie i wdrożenie funkcji klucza jest niezbędne dla każdej organizacji, która pragnie skutecznie chronić wrażliwe dane swoich użytkowników.

Pytanie 13

W tabeli artykuly znajduje się pole o nazwie nowy. Aby pole to wypełnić wartościami TRUE dla każdego rekordu, należy zastosować kwerendę

A. UPDATE nowy FROM artykuly VALUE TRUE;

B. UPDATE artykuly SET nowy = TRUE;

C. INSERT INTO nowy FROM artykuly SET TRUE;

D. INSERT INTO artykuly VALUE nowy = TRUE;

W tym zadaniu kluczowe jest zrozumienie różnicy między poleceniami UPDATE i INSERT w SQL oraz poprawnej składni tych instrukcji. Chodzi o modyfikację istniejących rekordów w tabeli artykuly, a nie o dodawanie nowych wierszy. To jest taki typowy błąd początkujących: pomieszanie operacji wstawiania danych z operacją ich aktualizacji. Jeśli tabela już zawiera dane i chcemy zmienić wartość w konkretnej kolumnie dla wszystkich wierszy, zawsze sięgamy po UPDATE.
Instrukcje wykorzystujące INSERT, typu INSERT INTO artykuly VALUE nowy = TRUE; czy INSERT INTO nowy FROM artykuly SET TRUE;, są niepoprawne składniowo i logicznie. INSERT służy do dodawania nowych rekordów, czyli tworzenia kolejnych wierszy w tabeli. Poprawny wzorzec wygląda mniej więcej tak: INSERT INTO artykuly (kolumna1, kolumna2) VALUES (wartość1, wartość2);. Nie aktualizuje on istniejących pól, tylko dokłada nowe rekordy. Gdybyśmy próbowali użyć INSERT do „ustawienia” kolumny nowy, to w rzeczywistości tworzyliśmy nowe wiersze, a stare rekordy pozostałyby nietknięte, co jest sprzeczne z treścią pytania.
Z kolei konstrukcje w rodzaju UPDATE nowy FROM artykuly VALUE TRUE; przypominają czasem składnię innych języków lub narzędzi, ale nie są poprawnym SQL-em. Standard SQL wymaga, żeby po słowie UPDATE pojawiła się nazwa tabeli, a po SET lista kolumn i przypisanych im wartości. Nie ma tu słów kluczowych FROM i VALUE w takiej kombinacji. FROM bywa używane w bardziej zaawansowanych UPDATE’ach, np. w PostgreSQL, ale w formie UPDATE tabela1 SET kolumna = coś FROM tabela2 WHERE warunek; – czyli z zupełnie inną logiką i strukturą.
Typowy błąd myślowy polega też na tym, że ktoś próbuje tłumaczyć składnię SQL „na polski” i układa komendy w stylu „INSERT INTO nowy FROM artykuly SET TRUE”, bo brzmi to logicznie w języku naturalnym. Niestety, SQL jest językiem ściśle zdefiniowanym, z bardzo konkretną kolejnością słów kluczowych. Standardowe podejście branżowe jest takie: jeśli modyfikujesz wartości w istniejących wierszach – używasz UPDATE; jeśli dodajesz nowe wiersze – używasz INSERT. Dobrą praktyką jest też najpierw napisać SELECT, który wybiera dokładnie te rekordy, które chcesz zmienić, a dopiero potem na jego podstawie zbudować UPDATE z odpowiednim SET i ewentualnym WHERE. Dzięki temu unikasz przypadkowego uszkodzenia danych.

Pytanie 14

Celem testów wydajnościowych jest ocena

A. możliwości oprogramowania do funkcjonowania w warunkach niewłaściwej pracy systemu

B. poziomu spełnienia wymagań dotyczących wydajności przez system bądź moduł

C. możliwości oprogramowania do funkcjonowania w warunkach błędnej pracy sprzętu

D. sekwencji zdarzeń, w której prawdopodobieństwo wystąpienia każdego zdarzenia zależy wyłącznie od wyniku zdarzenia poprzedniego

Odpowiedzi sugerujące, że testy wydajnościowe mają na celu sprawdzenie ciągu zdarzeń, w którym prawdopodobieństwo każdego zdarzenia zależy jedynie od wyniku poprzedniego, dotyczą zupełnie innej dziedziny – statystyki i teorii prawdopodobieństwa. W kontekście testów wydajnościowych mówimy o analizie zachowania systemu w odpowiedzi na obciążenie, a nie o modelowaniu zdarzeń losowych. Kolejne koncepcje, takie jak zdolność oprogramowania do działania w warunkach wadliwej pracy systemu lub sprzętu, odnoszą się do testów odpornościowych i awaryjnych, a nie do testów wydajnościowych. Testy te mają na celu zbadanie, jak system reaguje na sytuacje awaryjne, jednak nie są one bezpośrednio związane z oceną jego wydajności. Te nieporozumienia mogą wynikać z mylnego założenia, że testy wydajnościowe obejmują wszystkie aspekty funkcjonalności systemu, podczas gdy w rzeczywistości koncentrują się one na specyficznych wymaganiach dotyczących szybkości i efektywności działania. Właściwe rozumienie testów wydajnościowych jako narzędzia do pomiaru i optymalizacji wydajności systemu jest kluczowe dla zapewnienia jego sukcesu na rynku. Każda z tych nieprawidłowych odpowiedzi prowadzi do niedosłownego zrozumienia celów i metodologii stosowanych w testach wydajnościowych, co może skutkować poważnymi błędami w procesie wytwarzania oprogramowania.

Pytanie 15

Jednym z kluczowych identyfikatorów wpisu w bazie danych jest pole

A. klucza obcego

B. klucza podstawowego

C. relacji

D. numeryczne

Klucz podstawowy jest fundamentalnym elementem każdej relacyjnej bazy danych, ponieważ jednoznacznie identyfikuje każdy rekord w tabeli. Jego główną cechą jest unikalność, co oznacza, że żaden z rekordów w tabeli nie może mieć tego samego klucza podstawowego. Klucz podstawowy może składać się z jednego lub więcej atrybutów (kolumn), ale zawsze musi zapewniać jednoznaczność identyfikacji. Przykładem może być tabela 'Użytkownicy', gdzie 'ID_Użytkownika' działa jako klucz podstawowy, pozwalając na łatwe i szybkie wyszukiwanie konkretnych użytkowników. Zgodnie z najlepszymi praktykami projektowania baz danych, klucze podstawowe powinny być stabilne i niezmienne w czasie, aby uniknąć komplikacji związanych z aktualizacją wartości. Klucz podstawowy jest również kluczowy dla relacji między tabelami, ponieważ inne tabele mogą odwoływać się do niego poprzez klucze obce. Dzięki temu, struktura bazy danych staje się bardziej zorganizowana i lepiej znormalizowana, co z kolei prowadzi do zwiększonej wydajności i integralności danych.

Pytanie 16

Klucz obcy w tabeli jest używany w celu

A. połączenia go z innymi kluczami obcymi w tabeli

B. opracowania formularza do wprowadzania danych do tabeli

C. umożliwienia jednoznacznej identyfikacji rekordu w danej tabeli

D. zdefiniowania relacji 1..n łączącej go z kluczem głównym innej tabeli

Klucz obcy w tabeli często mylony jest z innymi elementami struktury bazy danych, co prowadzi do nieporozumień w jego zastosowaniu. Odpowiedzi sugerujące, że klucz obcy służy do łączenia go z innymi kluczami obcymi tabeli, są mylne, ponieważ klucze obce nie są same w sobie elementami łączącymi, ale raczej definiują relację z kluczem głównym innej tabeli. Tworzenie formularza wpisującego dane do tabeli również nie jest funkcją klucza obcego, który służy do wskazywania relacji między danymi, a nie do interakcji użytkownik-baza danych. Umożliwienie jednoznacznej identyfikacji rekordu w tabeli jest funkcją klucza głównego, a nie klucza obcego; klucz obcy zazwyczaj nie identyfikuje rekordu, lecz odnosi się do rekordu w innej tabeli. Przykładowo, jeśli w tabeli 'Zamówienia' klucz obcy wskazuje na 'KlientID' w tabeli 'Klienci', to nie identyfikuje on zamówienia, lecz łączy je z klientem. W wyniku tych błędnych założeń, projektanci baz danych mogą wprowadzać niepoprawne relacje, co prowadzi do problemów z integralnością i spójnością danych, a także utrudnia analizowanie związanych ze sobą informacji.

Pytanie 17

Jakie mogą być źródła rekordów dla raportu?

A. zapytanie INSERT INTO

B. inny raport

C. zapytanie GRANT

D. tabela

Odpowiedzi, które wskazują na inny raport, zapytanie GRANT lub zapytanie INSERT INTO jako źródła rekordów dla raportu, są niepoprawne. Inny raport, choć może zawierać dane, sam w sobie nie jest bezpośrednim źródłem do generowania nowych raportów. Może jednak posłużyć jako inspiracja lub szablon do tworzenia nowych analiz, co nie czyni go źródłem w sensie technicznym. Przykładowo, raport sprzedaży nie może być bezpośrednio wykorzystany jako źródło danych do raportu o wydatkach z powodu różnicy w kontekście i strukturze danych. Zapytanie GRANT natomiast, służy do przyznawania uprawnień użytkownikom w bazie danych, co jest zupełnie inną funkcjonalnością. Użycie tego zapytania w kontekście raportowania jest błędne, ponieważ nie ma ono związku z pozyskiwaniem danych, a jedynie z zarządzaniem dostępem. Na koniec, zapytanie INSERT INTO służy do wstawiania danych do tabel, a nie do ich pozyskiwania. Typowym błędem myślowym jest mylenie tych operacji z procesem tworzenia raportów, gdzie kluczowym elementem jest analizy danych już istniejących w tabelach, a nie dodawanie nowych danych. W kontekście tworzenia raportów, istotne jest, aby skupić się na źródłach, które już przechowują dane, a nie na operacjach, które te dane zmieniają lub manipulują.

Pytanie 18

Jakie zapytanie SQL umożliwi wyszukanie z podanej tabeli tylko imion i nazwisk pacjentów, którzy przyszli na świat przed rokiem 2002?

A. SELECT * FROM Pacjenci WHERE rok_urodzenia LIKE 2002

B. SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < 2002

C. SELECT * FROM Pacjenci WHERE rok_urodzenia <= 2002

D. SELECT imie, nazwisko FROM Pacjenci WHERE data_ostatniej_wizyty < 2002

To zapytanie SQL, które napisałeś, czyli SELECT imie, nazwisko FROM Pacjenci WHERE rok_urodzenia < 2002, jest całkiem trafione. Po pierwsze, używasz operatora SELECT, żeby wskazać, jakie kolumny chcesz zwrócić - czyli imię i nazwisko. To jest dokładnie to, co było potrzebne. Po drugie, warunek WHERE z rokiem urodzenia zapewnia, że do wyników dostają się tylko pacjenci, którzy przyszli na świat przed 2002 rokiem. No i to jest ważne, bo masz tutaj operator mniejszości <, który wyklucza sam rok 2002. Takie podejście jest super przydatne w bazach danych, bo pozwala na filtrowanie informacji w oparciu o lata, co często wykorzystuje się w raportach i analizach. Generalnie, dobre praktyki w SQL mówią, że warto precyzyjnie określać, jakie kolumny chcesz uwzględnić, bo to pomaga odciążyć system i zrobione zapytanie będzie działać wydajniej. Twoje zapytanie nie tylko spełnia wymagania, ale także jest optymalne, co jest naprawdę istotne w pracy z bazami danych.

Pytanie 19

Model fizyczny replikacji bazy danych pokazany na ilustracji jest modelem

A. centralnego subskrybenta

B. centralnego wydawcy

C. rozproszonym

D. równorzędnym

Model centralnego wydawcy jest popularnym rozwiązaniem w replikacji baz danych gdzie jeden centralny serwer działa jako główny wydawca danych do wielu subskrybentów. Kluczowa cecha tego modelu polega na tym że wszystkie zmiany są inicjowane na głównym serwerze co pozwala na scentralizowane zarządzanie danymi. Centralny wydawca zapewnia że dane są spójne i aktualizowane we wszystkich subskrybentach zmniejszając ryzyko konfliktów danych. Taka architektura jest często stosowana w organizacjach z rozproszonymi jednostkami gdzie centralny serwer w centrali obsługuje oddziały terenowe. Przykładami zastosowań są systemy ERP i CRM które wymagają jednoczesnej replikacji danych do wielu lokalizacji. Dobre praktyki w tej architekturze obejmują regularne monitorowanie wydajności serwerów oraz optymalizację przepustowości sieci by minimalizować opóźnienia. Modele centralnego wydawcy wykorzystują technologie takie jak SQL Server Replication czy Oracle Streams które są dobrze udokumentowane i szeroko stosowane w branży zapewniając niezawodność i skalowalność.

Pytanie 20

Jakie są etapy w odpowiedniej kolejności przy tworzeniu aplikacji?

A. Analiza oczekiwań klienta, określenie wymagań, programowanie, wdrożenie, testowanie

B. Określenie wymagań, analiza oczekiwań klienta, programowanie, wdrożenie, testowanie

C. Programowanie, analiza oczekiwań klienta, określenie wymagań, wdrożenie, testowanie

D. Analiza oczekiwań klienta, określenie wymagań, programowanie, testowanie, wdrożenie

Zrozumienie procesu tworzenia aplikacji wymaga znajomości właściwej sekwencji działań, co często bywa źródłem nieporozumień. Wiele osób uważa, że proces rozpoczyna się od samoistnego tworzenia aplikacji, co jest fundamentalnie błędne. Bez wcześniejszej analizy wymagań klienta, trudno jest określić, co tak naprawdę jest potrzebne. Przykładem tego błędnego myślenia jest odpowiedź, która zakłada, że tworzenie aplikacji może nastąpić przed zdefiniowaniem wymagań. Taki krok może prowadzić do stworzenia produktu, który nie spełnia oczekiwań użytkowników końcowych, co wiąże się z niepotrzebnymi kosztami korekcji i opóźnieniami w dostarczeniu finalnego rozwiązania. Wiele projektów zakończonych niepowodzeniem miało właśnie swoje źródło w braku odpowiednich faz analizy i specyfikacji, co jest wyraźnie widoczne w metodykach projektowych takich jak Waterfall. Nieprzemyślane wdrożenie bez wcześniejszych testów stanowi kolejny poważny błąd, ponieważ może prowadzić do sytuacji, w której użytkownicy otrzymują produkt pełen błędów i niedociągnięć. Zastosowanie podejścia opartego na solidnych praktykach inżynieryjnych, takich jak zbieranie wymagań, ich dokumentacja oraz przeprowadzanie testów przed wdrożeniem, jest kluczowe dla zapewnienia sukcesu projektu i satysfakcji użytkowników.

Pytanie 21

Po awarii serwera bazy danych, aby jak najszybciej przywrócić pełne działanie bazy, konieczne jest wykorzystanie

A. aktualnej wersji kopii zapasowej

B. opisu struktur danych w tabelach

C. kompletnej listy użytkowników serwera

D. najświeższej wersji instalacyjnej serwera

Aby skutecznie przywrócić działanie bazy danych po jej uszkodzeniu, kluczowe jest wykorzystanie aktualnej wersji kopii zapasowej. Kopie zapasowe są fundamentem każdego planu odzyskiwania danych i powinny być regularnie tworzone zgodnie z polityką zarządzania danymi. Przykładowo, jeśli korzystamy z bazy danych w środowisku produkcyjnym, zaleca się wykonywanie codziennych kopii zapasowych oraz pełnych kopii co tydzień. W przypadku awarii, przywrócenie systemu do stanu sprzed incydentu za pomocą najnowszej kopii zapasowej minimalizuje utratę danych i przestoje. Praktyki takie jak backup w czasie rzeczywistym (real-time backup) mogą być również rozważane, aby ograniczyć ryzyko utraty danych. W kontekście standardów branżowych, organizacje powinny stosować zasady RTO (Recovery Time Objective) i RPO (Recovery Point Objective), które pomogą w określeniu najodpowiedniejszej strategii tworzenia kopii zapasowych i ich przechowywania. Zastosowanie aktualnych kopii zapasowych jest zatem najskuteczniejszym sposobem na przywrócenie funkcjonalności bazy danych.

Pytanie 22

Z jaką bazą danych nawiązuje połączenie funkcja pg_connect w PHP?

A. MS Access

B. PostgreSQL

C. MySQL

D. MS SQL

Funkcja pg_connect() nawiązuje w PHP połączenie z bazą PostgreSQL - prefiks pg_ to skrót od „PostgreSQL”, tak jak mysqli_ wskazuje na MySQL. Każdy system bazodanowy ma w PHP własny zestaw funkcji. Zapamiętaj: po prefiksie funkcji poznasz, z jaką bazą pracujesz.

Pytanie 23

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

A. nigdy nie jest innego typu niż numeryczny

B. musi być unikalna

C. jest używana do szyfrowania zawartości tabeli

D. może przyjmować wartość null (NULL)

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

Pytanie 24

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

A. WHERE punkty > 3000 AND liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'

B. WHERE punkty > 3000 AND liczbaZakupow > 100 AND ostatnieZakupy >= '2022-01-01'

C. WHERE (punkty > 3000 OR liczbaZakupow > 100) AND ostatnieZakupy >= '2022-01'

D. WHERE punkty > 3000 OR liczbaZakupow > 100 OR ostatnieZakupy >= '2022-01-01'

W przypadku pozostałych odpowiedzi pojawiają się istotne błędy związane z logiką stosowania operatorów w klauzuli WHERE. W pierwszej z niepoprawnych opcji zastosowano operator OR w połączeniu z operatorami AND, co prowadzi do niejednoznaczności w logice kwerendy. Taki zapis sugeruje, że każdy klient, który spełnia tylko jeden z podanych warunków, zostanie wybrany, co nie jest zgodne z wymaganiami zadania. W drugim przypadku, zastosowanie operatora AND dla wszystkich warunków implikuje, że klient musi jednocześnie spełniać wszystkie trzy warunki, co znacząco zawęża grupę wyników i może prowadzić do pominięcia klientów, którzy są wartościowi z punktu widzenia transakcji, ale nie spełniają wszystkich kryteriów jednocześnie. W ostatniej opcji również zastosowano operator AND we wszystkich warunkach, co jest niezgodne z zamysłem zapytania. Ważne jest, aby w takich sytuacjach dobrze rozumieć logikę operacji logicznych oraz ich konsekwencje w praktyce. Kluczowym błędem jest nieodpowiednie zrozumienie relacji między warunkami oraz ich wzajemnego wpływu na ostateczny wynik zapytania. W SQL istotne jest precyzyjne formułowanie zapytań, aby uniknąć niezamierzonych wyników, dlatego warto na etapie pisania schematów myśleć o logice, która będzie spełniać założone cele analizy danych.

Pytanie 25

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

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

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

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

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

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

Pytanie 26

Jakie są przykłady standardowych poleceń w języku zapytań SQL, odnoszących się do operacji na danych SQL DML, takich jak wstawianie, usuwanie oraz modyfikacja danych?

A. DELETE, INSERT, UPDATE

B. SELECT, SELECT INTO

C. DENY, GRANT, REVOKE

D. ALTER, CREATE, DROP

Wybór innych odpowiedzi nie jest poprawny, ponieważ skupiają się na różnych aspektach zarządzania bazami danych. Polecenia typu ALTER, CREATE i DROP są związane z definicją danych (DDL, Data Definition Language). ALTER umożliwia modyfikację struktury tabeli, na przykład dodawanie nowych kolumn, natomiast CREATE jest używane do tworzenia nowych obiektów w bazie danych, takich jak tabele czy widoki. DROP z kolei służy do usuwania tych obiektów. Te polecenia są fundamentalne dla zarządzania strukturą bazy, ale nie dotyczą bezpośrednio operacji na danych. Inna grupa poleceń, takich jak DENY, GRANT i REVOKE, odnosi się do zarządzania uprawnieniami użytkowników w systemie baz danych, co jest istotne dla bezpieczeństwa, ale nie wpływa na manipulację danymi. Te polecenia kontrolują, kto ma dostęp do jakich danych, co jest kluczowe w kontekście bezpieczeństwa, ale nie są one używane do wprowadzania, usuwania czy aktualizacji danych w tabelach. Dlatego te zestawy poleceń, mimo że są istotne w kontekście zarządzania bazami danych, nie odpowiadają na pytanie dotyczące operacji na danych w kontekście DML.

Pytanie 27

Na podstawie tabeli Towar wykonano poniższe zapytanie SQL. Jaki będzie rezultat tej operacji?

SELECT nazwa_towaru
FROM`Towar`
WHERE cena_katalogowa<65
ORDER BY waga DESC

ID	nazwa_towaru	cena_katalogowa	waga	kolor
1	Papier ksero A4	11	2.3	biel
2	Zeszyt A5	4.2	0.13	wielokolorowy
3	Zeszyt A5 w linie	3.5	0.12	niebieski
4	Kredki 24 kolory	9	0.3	wielokolorowy
5	Plecak szkolny	65.5	1.3	zielony

A. Zeszyt A5 w linie, Zeszyt A5, Kredki 24 kolory, Papier ksero A4

B. Papier ksero A4, Kredki 24 kolory, Zeszyt A5 w linie, Zeszyt A5

C. Zeszyt A5, Zeszyt A5 w linie, Kredki 24 kolory, Papier ksero A4

D. Papier ksero A4, Kredki 24 kolory, Zeszyt A5, Zeszyt A5 w linie

Patrząc na błędne odpowiedzi, widzę, że poważnym błędem było niezrozumienie klauzuli WHERE oraz ORDER BY. Klauzula WHERE w SQL po prostu wyklucza towary z ceną 65 lub wyższą, co jest kluczowe, bo pozwala filtrować dane. Jak się to zignoruje, to produkt, który nie powinien się tam znaleźć, jak plecak szkolny, mógłby się pojawić. Co więcej, sporo osób myli sortowanie. ORDER BY waga DESC mówi nam, żeby sortować według wagi w kolejności malejącej. Niektórzy źle to interpretują, myśląc, że to jest w porządku rosnącym, albo całkowicie lekceważą wagę w sortowaniu. Wiedza o tym, jak działają te klauzule, jest ważna, gdy się pracuje z SQL. Trzeba zrozumieć, jak działa filtrowanie i sortowanie, bo to jest bazą pracy analityka danych i specjalisty od baz danych. W projektowaniu zapytań SQL każdy element powinien mieć swój cel i być dobrze zrozumiany, żeby pasował do logiki biznesowej i wymagań analizy danych.

Pytanie 28

Tabele Osoby oraz Adresy są ze sobą połączone relacją typu jeden do wielu. Jakie zapytanie SQL powinno być użyte, aby poprawnie wyświetlić nazwiska oraz odpowiadające im miasta?

A. SELECT nazwisko, Miasto FROM Osoby JOIN Adresy ON Osoby.Adresy_id=Adresy.id

B. SELECT nazwisko, Miasto FROM Osoby, Adresy

C. SELECT nazwisko, Miasto FROM Osoby.Adresy_id=Adresy.id FROM Osoby, Adresy

D. SELECT nazwisko, Miasto FROM Osoby, Adresy WHERE Osoby.id=Adresy.id

Użycie składni JOIN w zapytaniu SQL to naprawdę dobra decyzja, jeśli chodzi o pokazywanie powiązanych danych z różnych tabel w bazie danych. W odpowiedzi zastosowałeś INNER JOIN, co jest jednym z tych najpopularniejszych sposobów łączenia tabel, zwłaszcza gdy mamy wspólny klucz. W tym przypadku klucz obcy Adresy_id w tabeli Osoby łączy się z kluczem głównym id w tabeli Adresy, co pozwala na wyciągnięcie nazwisk z Osób oraz odpowiadających im miast z Adresów. W praktyce takie użycie JOIN jest zgodne z najlepszymi praktykami, bo ułatwia zarządzanie danymi i sprawia, że wszystko jest czytelniejsze. Gdy pracujesz nad bardziej skomplikowanymi systemami, umiejętność poprawnego łączenia tabel jest kluczowa. Umożliwia to utrzymanie porządku w danych i zmniejszenie ich powtarzalności przez normalizację. I naprawdę, takie zapytania są mega przydatne w analizie danych, generowaniu raportów czy w aplikacjach, które operują na dużych zbiorach, gdzie wydajność i przejrzystość kodu SQL są niezwykle ważne.

Pytanie 29

W hurtowni danych stworzono tabelę sprzedaz, która zawiera pola: id, kontrahent, grupa_cenowa, obrot. Jakie polecenie trzeba zastosować, aby znaleźć tylko kontrahentów z grupy cenowej numer dwa, których obrót przekracza 4000 zł?

A. SELECT sprzedaz FROM kontrahent WHERE grupa_cenowa = 2 AND obrot > 4000;

B. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa = 2 OR obrot > 4000;

C. SELECT kontrahent FROM sprzedaz WHERE grupa_cenowa = 2 AND obrot > 4000;

D. SELECT sprzedaz FROM kontrahent WHERE obrot > 4000;

Dwie niepoprawne odpowiedzi pokazują, że są pewne nieporozumienia w kwestii SQL. W pierwszej z nich używasz operatora OR, co psuje całą logikę zapytania. To sprawia, że możesz dostać kontrahentów z drugiej grupy cenowej albo tych, co mają obrót powyżej 4000 zł, a nie tylko tych, którzy spełniają oba warunki jednocześnie. W analizie danych ważne jest, żeby warunki były precyzyjne, bo inaczej wyniki mogą być nieczytelne. W kolejnej odpowiedzi widzę, że próbujesz wydobywać dane z kolumny kontrahent, co jest niepoprawne, bo kolumna to nie tabela. Musisz mieć jasność co do struktury bazy danych, żeby pisać odpowiednie zapytania. A ostatnia odpowiedź nie zawiera warunku dla grupy cenowej, więc zwróci jakieś niepełne dane. Dobrym pomysłem jest też testować swoje zapytania na mniejszych zbiorach danych, niż wdrażać je od razu w produkcji, żeby uniknąć takich błędów.

Pytanie 30

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

A. SELECT * FROM ksiazki

B. SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE()

C. SELECT tytul FROM ksiazki

D. SELECT tytul, data_wypoz FROM ksiazki WHERE data_wypoz = CURRDATENT_E()

Ta odpowiedź jest prawidłowa, ponieważ wykorzystuje funkcję CURRENT_DATE(), która zwraca bieżącą datę systemową. Zapytanie SQL SELECT tytul FROM ksiazki WHERE data_wypoz = CURRENT_DATE(); umożliwia wybranie jedynie tych książek, które zostały wypożyczone w dniu, w którym raport jest generowany. To podejście jest zgodne z dobrymi praktykami w zakresie zarządzania danymi, ponieważ pozwala na efektywne filtrowanie danych bez zbędnych informacji. W kontekście bazy danych, operacje takie jak filtrowanie danych według daty są kluczowe dla tworzenia raportów, które są użyteczne i zrozumiałe dla użytkowników. Dzięki temu możemy na przykład generować codzienne zestawienia wypożyczeń książek, co jest szczególnie przydatne w bibliotekach oraz innych instytucjach zajmujących się wynajmem materiałów. Użycie odpowiednich funkcji w SQL jest nie tylko korzystne, ale również zwiększa efektywność procesów analitycznych oraz zarządzania danymi.

Pytanie 31

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

A. SELECT SUM(ocena) FROM ilosc_kodu;

B. SELECT SUM(ilosc_kodu) FROM programisci;

C. SELECT COUNT(programisci) FROM ilosc_kodu;

D. SELECT MAX(ilosc_kodu) FROM programisci;

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

Pytanie 32

Zgodnie z zasadami ACID dotyczącymi przeprowadzania transakcji wymóg izolacji (ang. isolation) wskazuje, że

A. pod określonymi warunkami dane modyfikowane przez transakcję mogą być cofnięte

B. gdy dwie transakcje działają równocześnie, to zazwyczaj nie dostrzegają zmian wprowadzanych przez siebie

C. po zrealizowaniu transakcji system bazy danych będzie zgodny

D. w sytuacji konfliktu z inną transakcją obie zmieniają te same dane równocześnie

Izolacja (ang. isolation) jest jednym z kluczowych elementów właściwości ACID, które zapewniają niezawodność transakcji w systemach baz danych. Oznacza ona, że kiedy dwie lub więcej transakcji są wykonywane równolegle, nie powinny one wzajemnie wpływać na swoje wyniki. W praktyce oznacza to, że zmiany wprowadzone przez jedną transakcję nie są widoczne dla innych transakcji, dopóki nie zostaną one zatwierdzone (ang. commit). Przykładem może być sytuacja, w której jedna transakcja aktualizuje stan konta użytkownika, a druga transakcja odczytuje saldo tego konta. Dzięki właściwości izolacji, druga transakcja nie zobaczy zmian wprowadzonych przez pierwszą, co zapobiega niepożądanym efektom, takim jak odczytanie nieaktualnych danych. W praktycznych rozwiązaniach, takich jak bazy danych współczesnych systemów informatycznych, często stosuje się różne poziomy izolacji, takie jak Read Uncommitted, Read Committed, Repeatable Read czy Serializable, które pozwalają na dostosowanie stopnia izolacji do specyficznych wymagań aplikacji. Właściwe skonfigurowanie poziomu izolacji ma kluczowe znaczenie dla zachowania integralności danych oraz wydajności systemu.

Pytanie 33

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 nr_id tylko dla trzech tabel

B. Na podstawie parametru nr_id dla wszystkich tabel

C. Na podstawie parametru wyrob_id tylko dla trzech tabel

D. Na podstawie parametru wyrob_id tylko dla trzech tabel

Analizując błędne odpowiedzi można zauważyć że kluczowym aspektem w tym pytaniu jest zrozumienie zastosowania parametrów w klauzuli WHERE Odpowiedzi sugerujące selekcję według parametru wyrob_id są nieprawidłowe ponieważ w klauzuli WHERE dominującą rolę odgrywa parametr nr_id choć występuje tam także warunek dotyczący wyrob_id to jednak główną funkcją jest połączenie tabel według nr_id Jest to typowy błąd wynikający z nieuwzględnienia hierarchii oraz sposobu połączenia tabel w relacyjnych bazach danych Ponadto niektóre odpowiedzi ograniczają się wyłącznie do trzech tabel co również jest błędne ponieważ zapytanie obejmuje wszystkie cztery wymienione tabele producent hurtownia sklep i serwis Koncentracja na jednej lub dwóch tabelach często bierze się z pominięcia kluczowych związków logicznych między tabelami jak w przypadku odpowiedzi które ograniczają scope do mniejszej liczby tabel niż rzeczywiście obejmuje zapytanie Kluczową umiejętnością jest zrozumienie jak różne parametry mogą wpływać na wybór danych zwłaszcza w kontekście tworzenia złożonych zapytań SQL gdzie przemyślane zastosowanie klauzul jest niezbędne do efektywnego zarządzania danymi i unikania niepoprawnych interpretacji wyników Właściwe zrozumienie jak parametry takie jak nr_id czy wyrob_id funkcjonują w zapytaniach pozwala na ich poprawne i skuteczne zastosowanie co jest kluczowe w profesjonalnym podejściu do pracy z bazami danych

Pytanie 34

Przy założeniu, że użytkownik nie miał wcześniej żadnych uprawnień, polecenie SQL

GRANT SELECT, INSERT, UPDATE ON klienci TO anna;

nada użytkownikowi anna uprawnienia wyłącznie do

A. wybierania, wstawiania oraz aktualizacji danych w tabeli o nazwie klienci

B. wybierania, dodawania kolumn oraz zmiany struktury wszystkich tabel w bazie o nazwie klienci

C. wybierania, wstawiania oraz aktualizacji danych we wszystkich tabelach w bazie o nazwie klienci

D. wybierania, dodawania kolumn oraz zmiany struktury tabeli o nazwie klienci

Zrozumienie praw dostępu w bazach danych jest kluczowe dla bezpieczeństwa oraz efektywnego zarządzania danymi. Niepoprawne odpowiedzi często wynikają z mylącego interpretowania pojęć związanych z uprawnieniami. Na przykład, odpowiedź sugerująca, że użytkownik 'anna' ma możliwość dodawania pól w tabeli, jest błędna, ponieważ polecenie GRANT nie obejmuje uprawnień do modyfikacji struktury tabeli. Uprawnienia do dodawania kolumn (ALTER) są odrębną kategorią praw i muszą być przyznane w osobnym poleceniu. Kolejna nieprawidłowa koncepcja dotyczy rozumienia zakresu uprawnień. Odpowiedzi, które sugerują, że prawa te dotyczą wszystkich tabel w bazie danych, mylą pojęcie 'ON klienci' z szerszymi uprawnieniami, co mogłoby prowadzić do nadużyć. GRANT SELECT, INSERT, UPDATE na konkretnej tabeli 'klienci' dotyczy tylko tej tabeli, co jest zgodne z zasadą ograniczonego dostępu. Należy również pamiętać, że udzielanie zbyt szerokich uprawnień może narazić bazę danych na nieautoryzowane manipulacje, co jest sprzeczne z najlepszymi praktykami zarządzania bezpieczeństwem. W kontekście projektowania systemów bazodanowych, kluczowe jest zrozumienie oraz umiejętne zarządzanie uprawnieniami w celu zapewnienia odpowiedniego poziomu ochrony danych.

Pytanie 35

GRANT CREATE, ALTER ON sklep.* TO adam; Zakładając, że użytkownik adam nie dysponował wcześniej żadnymi uprawnieniami, to polecenie SQL przyzna mu prawa jedynie do

A. wstawiania oraz modyfikacji danych we wszystkich tabelach bazy sklep

B. tworzenia oraz modyfikacji struktury w tabeli sklep

C. wstawiania oraz modyfikacji danych w tabeli sklep

D. tworzenia oraz modyfikacji struktury wszystkich tabel w bazie sklep

Polecenie SQL 'GRANT CREATE, ALTER ON sklep.* TO adam;' przyznaje użytkownikowi adam prawa do tworzenia i modyfikowania struktury wszystkich tabel w bazie danych o nazwie 'sklep'. W kontekście zarządzania bazami danych, przyznawanie takich uprawnień jest kluczowe dla realizacji zadań związanych z projektowaniem i rozbudową bazy. Przykładowo, gdyby adam potrzebował dodać nową kolumnę do istniejącej tabeli lub utworzyć nową tabelę, mógłby to zrobić dzięki tym prawom. Z perspektywy bezpieczeństwa, nadawanie takich uprawnień powinna być starannie przemyślane, aby uniknąć nieautoryzowanych zmian w strukturze bazy. W praktyce, w sytuacjach, gdy wiele osób współpracuje nad projektem, zaleca się przyznawanie minimalnych uprawnień, które są niezbędne do wykonania określonych zadań. W związku z tym, wykorzystanie polecenia GRANT w sposób odpowiadający wymaganiom projektu jest najlepszą praktyką w zakresie administracji bazami danych.

Pytanie 36

Tabela psy ma pola imie, rasa, telefon_wlasciciela, rok_szczepienia. Która kwerenda zwróci telefony właścicieli psów szczepionych PRZED 2015?

SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia > 2015;

SELECT imie, rasa FROM psy WHERE rok_szczepienia > 2015;

SELECT psy FROM rok_szczepienia < 2015;

SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015;

Po SELECT wymienia się kolumny do POBRANIA, a w WHERE warunek wyboru wierszy. Chcemy telefony psów szczepionych przed 2015, więc bierzemy kolumnę telefon_wlasciciela i warunek rok_szczepienia < 2015: SELECT telefon_wlasciciela FROM psy WHERE rok_szczepienia < 2015;. Dlatego ta kwerenda jest poprawna.

Pytanie 37

W tabeli Recepta pola Imię oraz Nazwisko odnoszą się do pacjenta, dla którego recepta została wystawiona. Jaką kwerendę należy wykorzystać, aby dla wszystkich recept uzyskać datę ich wystawienia oraz imię i nazwisko lekarza, który je wystawił?

A. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta

B. SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id

C. SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id

D. SELECT Imie, Nazwisko, DataWystawienia FROM Recepta

Patrząc na inne odpowiedzi, widzę, że sporo osób ma problem z rozumieniem relacji między tabelami w bazach danych. W tym przypadku, kluczowe jest korzystanie z JOIN, żeby połączyć dane z Recepty i Lekarza. Kiedy ktoś nie używa tej klauzuli, no to nie ma jak prawidłowo powiązać lekarza z datą wystawienia recepty, co jest wymagane. Jeżeli kwerenda się ogranicza do jednej tabeli, to niestety nie dostaniesz wszystkich potrzebnych informacji. No i musisz pamiętać, że Imie i Nazwisko dotyczą lekarza, a nie pacjenta. Zrozumienie, jak działa klucz obcy (Lekarz_id) w Recepta to kluczowa sprawa. Właściwe skonstruowanie kwerendy polega na połączeniu tych danych przez JOIN – to podstawa, jak chcesz zarządzać bazami danych. Umiejętności w SQL są naprawdę niezbędne w wielu technicznych zawodach, a złe zapytania mogą skutkować błędnymi wynikami, co w pracy może mieć poważne konsekwencje. Myślę, że warto dobrze zrozumieć, jak te relacje działają.

Pytanie 38

W posiadanej tabeli zwanej przedmioty, która zawiera kolumny ocena oraz uczenID, aby wyliczyć średnią ocen dla ucznia z ID równym 7, należy użyć zapytania

A. SELECT AVG(ocena) FROM przedmioty WHERE uczenID = 7

B. SELECT COUNT(ocena) FROM przedmioty WHERE uczenID = 7

C. COUNT SELECT ocena FROM przedmioty WHERE uczenID = 7

D. AVG SELECT ocena FROM przedmioty WHERE uczenID = 7

Wybór innych opcji jest niepoprawny z kilku powodów. Odpowiedź, która zawiera 'AVG SELECT ocena FROM przedmioty WHERE uczenID = 7;' jest błędna, ponieważ nieprawidłowo formułuje składnię SQL. W SQL kolejność słów w zapytaniach jest kluczowa, a funkcje agregujące, takie jak AVG, muszą być używane po słowie SELECT. Z kolei wybór 'COUNT SELECT ocena FROM przedmioty WHERE uczenID = 7;' również jest błędny, ponieważ 'COUNT' jest funkcją, która zlicza ilość wierszy spełniających określone warunki, a nie średnią, co nie odpowiada zadaniu. Warto zauważyć, że mylenie funkcji agregujących, takich jak AVG i COUNT, to powszechny błąd, który wynika z niepełnego zrozumienia ich funkcji. W przypadku zapytania 'SELECT COUNT(ocena) FROM przedmioty WHERE uczenID = 7;' z kolei, chociaż składnia jest poprawna, zapytanie to zlicza liczbę ocen, a nie ich średnią, co nie spełnia wymagań pytania. To podejście nie tylko wprowadza w błąd, ale także może prowadzić do nieprawidłowych analiz danych. Kluczowe jest zrozumienie, że różne funkcje agregujące mają różne zastosowania i nie można ich stosować zamiennie. Użytkownicy pracujący z bazami danych powinni szczególnie zwracać uwagę na typy danych, jakie są przechowywane w ich tabelach oraz na odpowiednią składnię SQL, aby uzyskać zamierzony efekt.

Pytanie 39

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

A. UPDATE

B. ALTER TABLE

C. SELECT

D. INSERT INTO

Odpowiedź "UPDATE" jest właściwa, bo w SQL to właśnie to polecenie używamy do zmiany danych w już istniejących wierszach tabeli. Żeby zaktualizować konkretne kolumny w danym wierszu, trzeba wpisać coś takiego: "UPDATE nazwa_tabeli SET kolumna1 = wartość1, kolumna2 = wartość2 WHERE warunek". Dzięki klauzuli WHERE możemy dokładnie wskazać, które wiersze chcemy zmienić, co jest naprawdę ważne, żeby wszystko działało sprawnie i bezpiecznie. Na przykład, jeśli chcemy zmienić nazwisko użytkownika o id równym 1, napiszemy: "UPDATE Użytkownicy SET nazwisko = 'NoweNazwisko' WHERE id = 1". Używanie tego polecenia to dobra praktyka w zarządzaniu bazami danych. Nie zapominajmy o transakcjach, żeby mieć pewność, że dane są bezpieczne. A jak korzystamy z przygotowanych zapytań, to zminimalizujemy ryzyko ataków SQL injection, co jest bardzo istotne w kontekście bezpieczeństwa aplikacji bazodanowych.

Pytanie 40

Co zazwyczaj wchodzi w skład frameworka?

A. zarządzanie komunikacją z bazą oraz mechanizm uruchamiania i przetwarzania akcji

B. certyfikat HTTP oraz mechanizm przetwarzania akcji

C. obsługa błędów i domena

D. wbudowany serwer i obsługa formularzy

Pozostałe odpowiedzi mieszają pojęcia spoza frameworka. „Domena” to adres internetowy, certyfikat HTTP/SSL zapewnia szyfrowanie - to elementy hostingu, a nie składowe frameworka. Wbudowany serwer bywa narzędziem deweloperskim, lecz nie definiuje frameworka. Jego trzon to zarządzanie komunikacją z bazą oraz mechanizm przetwarzania akcji.

Rozpocznij nowy egzamin

Powrót do strony głównej