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 11:04
Data zakończenia: 15 czerwca 2026 11:06

Egzamin niezdany

Wynik: 10/40 punktów (25,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

Podaj zapytanie SQL, które tworzy użytkownika sekretarka na localhost z hasłem zaq123?

A. CREATE USER `sekretarka`@`localhost` IDENTIFY "zaq123";

B. CREATE USER `sekretarka`@`localhost` IDENTIFIED BY 'zaq123';

C. CREATE USER `sekretarka`@`localhost` IDENTIFY BY `zaq123`;

D. CREATE USER 'sekretarka'@'localhost' IDENTIFIED `zaq123`;

Odpowiedź "CREATE USER `sekretarka`@`localhost` IDENTIFIED BY 'zaq123';" jest prawidłowa, ponieważ wykorzystuje poprawną składnię do tworzenia nowego użytkownika w systemie zarządzania bazą danych MySQL. Kluczowe jest użycie słowa kluczowego 'IDENTIFIED BY', które wskazuje, że podane hasło ('zaq123') ma być powiązane z nowym użytkownikiem. Wartości w apostrofach są odpowiednie dla łańcuchów tekstowych w SQL, co jest zgodne z dobrymi praktykami programowania w MySQL. W praktyce, tworzenie użytkowników z odpowiednimi uprawnieniami jest niezbędne do zarządzania dostępem do bazy danych oraz zapewnienia bezpieczeństwa. Dobrą praktyką jest stosowanie silnych haseł oraz regularne audyty kont użytkowników. Warto również zwrócić uwagę na konwencje nazewnictwa oraz ograniczenia w zakresie adresów IP, co ma znaczenie w kontekście bezpieczeństwa i zarządzania użytkownikami w systemie zarządzania bazą danych.

Pytanie 2

Co według zasad ACID oznacza wymóg TRWAŁOŚCI (durability) transakcji?

A. przy naruszeniu spójności transakcja usuwa tabele z kluczami obcymi

B. dane zatwierdzone przez transakcję pozostają dostępne mimo późniejszych zdarzeń

C. w trakcie transakcji dane mogą zmieniać inne transakcje

D. transakcję można podzielić na dwa niezależne etapy

Trwałość (durability) z reguł ACID gwarantuje, że dane raz ZATWIERDZONE (commit) przez transakcję pozostaną w bazie na stałe - nawet jeśli zaraz potem nastąpi awaria zasilania czy restart serwera. System osiąga to, zapisując zmiany w sposób przetrwający awarię, np. w dzienniku transakcji. Dlatego trwałość oznacza, że zatwierdzone dane pozostają dostępne mimo późniejszych awarii.

Pytanie 3

Co utworzyć dla pól często wyszukiwanych lub sortowanych, aby przyspieszyć operacje na bazie?

A. więzy integralności

B. osobną tabelę na te pola

C. klucz obcy

D. indeks

Pozostałe elementy nie służą do przyspieszania wyszukiwania. Klucz obcy i więzy integralności pilnują SPÓJNOŚCI danych, a tworzenie osobnej tabeli na te pola nie przyspiesza zapytań. Operacje wyszukiwania i sortowania przyspiesza indeks.

Pytanie 4

W formularzu dokumentu PHP znajduje się pole <input name="im" />. Po wpisaniu przez użytkownika ciągu „Janek”, aby dodać wartość tego pola do bazy danych, w tablicy $_POST będzie obecny element

A. im z indeksem Janek

B. Janek z indeksem im

C. Janek z kolejnym numerem indeksu

D. im z kolejnym numerem indeksu

Odpowiedzi, które nie są poprawne, bazują na nieprawidłowych założeniach dotyczących sposobu, w jaki PHP przetwarza dane z formularzy. Pierwsza z niepoprawnych odpowiedzi sugeruje, że w tablicy $_POST istnieje element o kluczu 'im' z indeksem 'Janek'. W rzeczywistości, kluczem jest nazwa pola, a wartością jest to, co zostało wprowadzone przez użytkownika, więc takie połączenie klucza i wartości jest mylące. W drugiej niepoprawnej opcji mowa o 'Janek' jako kluczu, co również jest błędne, ponieważ 'Janek' jest wartością, a nie kluczem. Klucz w tablicy $_POST to zawsze nazwa pola formularza, czyli w tym przypadku 'im', a jego wartość to 'Janek'. Trzecia niepoprawna odpowiedź sugeruje, że klucz 'im' miałby być skojarzony z kolejnym numerem indeksu. To również jest niewłaściwe, ponieważ PHP nie dodaje automatycznie numerów indeksów do kluczy tablic, a klucze pozostają takie same, jak nazwy w formularzu. W każdej sytuacji nazwa pola pozostaje kluczem, co jest istotnym elementem przetwarzania danych w PHP.

Pytanie 5

Którego polecenia użyć, aby usunąć WSZYSTKIE rekordy z tabeli, nie usuwając jej samej?

DROP

UPDATE

ALTER

TRUNCATE

Pozostałe polecenia robią co innego. DROP usunąłby CAŁĄ tabelę (razem ze strukturą). ALTER zmienia strukturę tabeli, a UPDATE modyfikuje wartości w istniejących wierszach, nie usuwając ich. Opróżnienie tabeli z rekordów daje TRUNCATE.

Pytanie 6

Za pomocą podanego zapytania w tabeli zostanie wykonane

ALTER TABLE nazwa1 ADD nazwa2 DOUBLE NOT NULL;

A. Zmieniono typ kolumny nazwa2 na DOUBLE.

B. Została zmieniona nazwa kolumny z nazwa1 na nazwa2.

C. Dodana kolumna nazwa2, która nie przyjmuje wartości domyślnej.

D. Dodana kolumna nazwa2 o typie zmiennoprzecinkowym.

Analizując dostępne odpowiedzi, warto zwrócić uwagę na kilka istotnych kwestii związanych z instrukcją ALTER TABLE oraz jej zastosowaniem. Pierwsza koncepcja, dotycząca zmiany nazwy kolumny z nazwa1 na nazwa2, jest niepoprawna, ponieważ zapytanie nie wskazuje na taką operację. Zamiast tego, tworzymy nową kolumnę, a nie modyfikujemy istniejącą. Przechodząc do drugiej odpowiedzi, zmiana wartości kolumny nazwa2 na DOUBLE jest błędna, ponieważ instrukcja nie odnosi się do zmian wartości, ale do struktury tabeli. Kolejna nieprawidłowa koncepcja, sugerująca dodanie kolumny nazwa2 przyjmującej wartość domyślną DOUBLE, jest również myląca, ponieważ w zapytaniu nie ma ustawienia wartości domyślnej, a jedynie określenie typu kolumny oraz ograniczenia NOT NULL. Typowe błędy myślowe, które prowadzą do takich wniosków, to nieścisłe rozumienie roli polecenia ALTER TABLE oraz mylenie operacji na kolumnach z ich definicjami. W praktyce, ważne jest, aby dokładnie rozumieć jak działają typy danych w SQL oraz jakie ograniczenia można na nich nakładać, aby zapewnić integralność i jakość przechowywanych danych.

Pytanie 7

Aby stworzyć poprawną kopię zapasową bazy danych, która będzie mogła zostać później przywrócona, należy najpierw sprawdzić

A. możliwość udostępnienia bazy danych

B. spójność bazy

C. poprawność składni zapytań

D. uprawnienia dostępu do serwera bazy danych

Spójność bazy danych jest kluczowym elementem, który należy sprawdzić przed wykonaniem kopii bezpieczeństwa, ponieważ zapewnia, że wszystkie dane są zgodne i nie zawierają błędów. Spójność oznacza, że wszelkie reguły i ograniczenia, takie jak klucze główne, klucze obce oraz unikalne indeksy, są spełnione. W przypadku naruszenia spójności, kopia bazy danych mogłaby zawierać uszkodzone lub niekompletne dane, co mogłoby uniemożliwić jej prawidłowe odtworzenie w przyszłości. Przykładem może być sytuacja, gdy mamy tabelę zamówień, która odwołuje się do tabeli klientów. Jeśli rekord klienta został usunięty, a zamówienia pozostają, to mamy do czynienia z naruszeniem spójności. Standardy, takie jak ACID (Atomicity, Consistency, Isolation, Durability), podkreślają znaczenie spójności w zarządzaniu bazami danych, co czyni ją niezbędnym krokiem w procesie tworzenia kopii zapasowych.

Pytanie 8

W tabeli uczniowie (kolumny: imie, nazwisko, klasa) wszyscy uczniowie klas 1-5 przeszli do następnej klasy. Które polecenie zwiększy wartość w kolumnie klasa o 1?

SELECT uczniowie WHERE klasa BETWEEN 1 AND 5

SELECT nazwisko, imie FROM uczniowie

UPDATE uczniowie SET klasa = klasa + 1 WHERE klasa >= 1 AND klasa <= 5

UPDATE nazwisko, imie SET klasa = klasa + 1

Pozostałe zapytania nie zmienią danych lub są błędne składniowo. Oba warianty z SELECT jedynie odczytują wiersze - tym poleceniem nie da się zmodyfikować zawartości tabeli. Czwarta odpowiedź używa wprawdzie UPDATE, ale po nim wpisano nazwy kolumn (nazwisko, imie) zamiast nazwy tabeli, co jest niezgodne ze składnią. Zwiększenie wartości w kolumnie dla wybranych wierszy wykonuje UPDATE uczniowie SET klasa = klasa + 1 WHERE ..., dlatego to ono jest poprawne.

Pytanie 9

Dana jest tabela uczniowie, do której wpisano rekordy jak na rysunku. Co będzie wynikiem działania przedstawionego zapytania SQL?

SELECT AVG(ocena) FROM uczniowie;

Nazwisko	Imie	ocena
Kowalski	Sebastian	4
Kaczmarek	Marta	3
Baryła	Zenon	4
Gota	Anna	3

A. Liczba wierszy równa 4

B. Wartość 3.5

C. Suma ocen równa 14

D. Dane 4, 3, 4, 3

Widzę, że popełniłeś parę błędów w odpowiedziach. Stwierdzenie 'Suma ocen równa 14' pokazuje, że mogłeś nie do końca zrozumieć, jak działa AVG, bo ta funkcja nie sumuje wartości, ale liczy średnią. Z kolei odpowiedzi 'Dane 4, 3, 4, 3' i 'Liczba wierszy równa 4' też sugerują, że coś nie tak z interpretacją wyników. Pierwsza sugeruje, że zapytanie wyciąga konkretne liczby, a to nieprawda, bo AVG zwraca tylko jedną wartość – średnią. A druga odpowiedź wprowadza w błąd, mówiąc o liczbie wierszy, podczas gdy AVG operuje na wartościach, a nie ich ilości. Tego typu pomyłki mogą wynikać z nieznajomości funkcji agregujących w SQL. Ważne jest, żeby zrozumieć, co każda funkcja robi i jakie zwraca wyniki.

Pytanie 10

Według którego parametru oraz dla ilu tabel zostaną zwrócone wiersze na liście w wyniku przedstawionego 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. Według parametru wyrób Jd wyłącznie dla trzech tabel.

B. Według parametru wyrób id dla wszystkich tabel.

C. Według parametru nr id dla wszystkich tabel.

D. Według parametru nr id wyłącznie dla trzech tabel.

Brawo! Wybrałeś poprawną odpowiedź, zgodnie z którą parametrem nr id zwraca wiersze dla wszystkich tabel. To zapytanie SQL odnosi się do czterech tabel: producent, hurtownia, sklep i serwis. Zwraca ono wiersze, gdzie wartość kolumny nr_id jest taka sama we wszystkich tych tabelach i równa 1. Dodatkowo, jakość danych jest wspierana przez fakt, że zapytanie sprawdza zgodność wartości kolumny wyrob_id między tabelami producent i serwis. Zrozumienie tego, jak działa to zapytanie i dlaczego to jest ważne, jest kluczowe w praktyce programistycznej. Zapewnia to, że możemy skutecznie i efektywnie manipulować danymi, a także zrozumieć, jak nasze zapytania wpływają na wyniki, które otrzymujemy. Dobra praktyka jest zawsze zrozumienie, jakie dane są zwracane przez nasze zapytanie, zanim zaczniemy z nich korzystać w naszym kodzie. Ostatecznie, zrozumienie, jak korzystać z zapytań SQL do manipulacji i odzyskiwania danych, jest kluczowym elementem dowolnej roli programistycznej.

Pytanie 11

Które z poniższych zdań poprawnie opisuje utworzoną tabelę?

CREATE TABLE dane (kolumna INTEGER(3));

A. Kolumny tabeli dane są nazwane: kolumna1, kolumna2, kolumna3

B. Tabela o nazwie dane ma jedną kolumnę typu całkowitego

C. Tabela zawiera jedną kolumnę, która przechowuje trzyelementowe tablice

D. Tabela o nazwie dane składa się z trzech kolumn typu całkowitego

Instrukcja CREATE TABLE w podanym przykładzie tworzy tabelę o nazwie `dane` z jedną, jedyną kolumną o nazwie `kolumna` i typie `INTEGER(3)`. Kluczowe są tu dwie rzeczy: po pierwsze, nazwa tabeli (`dane`), po drugie, lista kolumn w nawiasie. W tej liście jest tylko jedna pozycja: nazwa kolumny i jej typ danych. W SQL każda definicja kolumny to osobny wpis, oddzielany przecinkiem. Skoro nie ma przecinka, to znaczy, że jest dokładnie jedna kolumna. Zapis `INTEGER(3)` nie oznacza trzech kolumn ani tablicy, tylko typ liczbowy całkowity z określoną „szerokością wyświetlania” (w MySQL) lub po prostu liczbę całkowitą – w wielu silnikach baz danych nawias jest wręcz ignorowany. W praktyce tę kolumnę możemy potem używać np. do przechowywania wieku, liczby sztuk towaru, numeru poziomu uprawnień itp. Przykładowo: `INSERT INTO dane (kolumna) VALUES (5);` wstawi rekord z wartością 5 w tej jednej kolumnie. Z mojego doświadczenia warto przy projektowaniu tabel zawsze jasno nazywać kolumny, tak żeby z samej nazwy wynikało, co przechowują, np. `wiek`, `ilosc_sztuk`, a nie ogólne `kolumna`. Dobrą praktyką jest też od razu dodanie klucza głównego, np. `id INT AUTO_INCREMENT PRIMARY KEY`, ale w tym zadaniu skupiamy się tylko na liczbie kolumn i ich typie. To pytanie dobrze pokazuje, że w SQL struktura tabeli wynika z liczby pozycji w nawiasie, a nie z liczby w nawiasie przy typie danych.

Pytanie 12

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

A. mysqli_error()

B. mysqli_use_result()

C. mysqli_error_list()

D. mysqli_errno()

W kontekście użycia funkcji do uzyskania komunikatów o błędach w bibliotece mysqli, niektóre z odpowiedzi mogą prowadzić do nieporozumień. Na przykład, mysqli_use_result() jest funkcją, która służy do pobierania zestawu wyników z zapytania SELECT w trybie pamięci. Jej głównym zadaniem jest przetwarzanie wyników, a nie błędów, co czyni ją nieodpowiednią w tym kontekście. Użycie tej funkcji nie zapewnia informacji o błędach, czego można się spodziewać w przypadku zapytań, które mogą zakończyć się niepowodzeniem. Z kolei mysqli_errno() zwraca numer błędu związanego z ostatnią operacją, co może być przydatne, ale samo w sobie nie dostarcza opisu błędu, a tym samym nie spełnia wymagań dotyczących uzyskania ostatniego komunikatu o błędzie w formie tekstowej. Mimo że może być użyteczne w niektórych kontekstach, np. w logice warunkowej, nie jest w stanie dostarczyć pełnego opisu, którego można oczekiwać. Funkcja mysqli_error_list() zwraca tablicę wszystkich błędów związanych z ostatnią operacją, co również jest przydatne w określonych sytuacjach, jednak wciąż nie spełnia wymagań dotyczących prostego i bezpośredniego uzyskania ostatniego komunikatu o błędzie. Ostatecznie, przy wyborze metody obsługi błędów, kluczowe jest zrozumienie, że funkcje te mają różne zastosowania i nie każda z nich będzie odpowiednia w kontekście uzyskania pełnego opisu błędu. Podsumowując, wybór odpowiednich funkcji do obsługi błędów jest kluczowy dla efektywnego debugowania i poprawnego działania aplikacji opartych na PHP.

Pytanie 13

Która kwerenda utworzy WIDOK z klientami o statusie „Platynowy” (tabela klienci, pole status)?

CREATE VIEW KlienciPlatyna AS SELECT * FROM klienci WHERE status = "Platynowy";

CREATE VIEW KlienciPlatyna AS SELECT status FROM klienci WHERE "Platynowy";

CREATE VIEW KlienciPlatyna FROM klienci WHERE status = "Platynowy";

CREATE VIEW KlienciPlatyna AS klient WHERE status = "Platynowy";

Po AS musi nastąpić poprawne SELECT ... FROM ... WHERE .... Wariant z AS klient WHERE pomija SELECT i FROM. Wariant z FROM klienci bez AS SELECT nie ma definicji widoku. Wariant WHERE "Platynowy" gubi nazwę pola w warunku. Poprawne jest CREATE VIEW KlienciPlatyna AS SELECT * FROM klienci WHERE status = "Platynowy".

Pytanie 14

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, dodawania kolumn oraz zmiany struktury wszystkich tabel w bazie o nazwie klienci

B. wybierania, wstawiania oraz aktualizacji danych w tabeli 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

Polecenie SQL 'GRANT SELECT, INSERT, UPDATE ON klienci TO anna;' przyznaje użytkownikowi 'anna' konkretne uprawnienia do tabeli 'klienci'. Oznacza to, że użytkownik ten będzie miał możliwość wybierania (SELECT), wstawiania (INSERT) oraz aktualizacji (UPDATE) danych w tej konkretnej tabeli. To podejście jest zgodne z zasadą minimalnych uprawnień, co oznacza, że użytkownik powinien mieć jedynie te prawa, które są niezbędne do wykonywania jego zadań. Na przykład, jeśli 'anna' jest pracownikiem działu sprzedaży, może być konieczne, aby miała dostęp do aktualizacji informacji o klientach, ale nie potrzebuje uprawnień do usuwania rekordów (DELETE) czy zmiany struktury tabeli (ALTER). Praktyczne zastosowanie takiego przydzielania uprawnień pomaga w zabezpieczeniu danych oraz minimalizuje ryzyko nieautoryzowanych zmian, co jest standardem w zarządzaniu bazami danych. Dodatkowo, stosowanie takich restrykcji w przydzielaniu ról jest zgodne z najlepszymi praktykami bezpieczeństwa w branży IT, aby zapobiegać potencjalnym nadużyciom.

Pytanie 15

Jakie są prawidłowe kroki w kolejności, które należy podjąć, aby nawiązać współpracę między aplikacją internetową działającą na serwerze a bazą SQL?

A. zapytanie do bazy, wybór bazy, wyświetlenie na stronie WWW, zamknięcie połączenia

B. wybór bazy, zapytanie do bazy, nawiązanie połączenia z serwerem baz danych, wyświetlenie na stronie WWW, zamknięcie połączenia

C. nawiązanie połączenia z serwerem baz danych, wybór bazy, zapytanie do bazy - wyświetlane na stronie WWW, zamknięcie połączenia

D. wybór bazy danych, nawiązanie połączenia z serwerem baz danych, zapytanie do bazy, wyświetlenie na stronie WWW, zamknięcie połączenia

Analizując inne odpowiedzi, można dostrzec kilka kluczowych nieprawidłowości. W pierwszej z nich podano, że należy najpierw wybrać bazę, co jest nielogiczne, ponieważ przed dokonaniem wyboru bazy konieczne jest nawiązanie połączenia z serwerem. Bez tego połączenia aplikacja nie ma możliwości komunikacji z bazą danych, a zatem nie można dokonać wyboru bazy. Kolejna odpowiedź sugeruje, że zapytanie do bazy powinno nastąpić przed dokonaniem wyboru bazy, co także jest błędne. Zapytania SQL są wykonywane w kontekście określonej bazy danych, więc konieczne jest jej wcześniejsze wybranie. Podobnie, trzecia odpowiedź wprowadza mylne rozumienie kolejności operacji, sugerując, że wyświetlenie danych może nastąpić bez wcześniejszego zapytania do bazy. To podejście ignoruje fakt, iż dane muszą być najpierw pobrane przed ich prezentacją na stronie. Te błędne koncepcje często wynikają z braku zrozumienia procesu interakcji z bazą danych oraz jego podstawowych zasad. W praktyce, aby efektywnie współpracować z bazą danych, istotne jest, by każdy krok był realizowany w odpowiedniej kolejności, co nie tylko zwiększa efektywność, ale również minimalizuje ryzyko błędów oraz problemów z bezpieczeństwem. Dlatego tak ważne jest, aby zrozumieć i stosować się do ustalonych standardów i dobrych praktyk w tym zakresie.

Pytanie 16

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

A. SELECT SUM(ilosc_kodu) FROM programisci;

B. SELECT MAX(ilosc_kodu) FROM programisci;

C. SELECT COUNT(programisci) FROM ilosc_kodu;

D. SELECT SUM(ocena) FROM ilosc_kodu;

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

Pytanie 17

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

NO REPEAT

UNIQUE

SINGLE

NOT NULL

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

Pytanie 18

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

A. ALTER TABLE Uczniowie ADD FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

B. ALTER TABLE Uczniowie DROP FOREIGN KEY FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

C. ALTER TABLE Uczniowie DROP CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

D. ALTER TABLE Uczniowie ADD CONSTRAINT FKKlasy FOREIGN KEY(Klasy_id) REFERENCES Klasy(id);

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

Pytanie 19

W przedstawionym kodzie PHP przeprowadzono operację na bazie danych. Jaką funkcję należy wywołać, aby uzyskać liczbę wierszy, które zostały zmienione w tabeli?

$zapytanie="UPDATE kadra SET stanowisko='Programista' WHERE id < 10"; mysqli_query($db, $zapytanie);

A. mysqli_num_rows()

B. mysqli_use_result()

C. mysqli_affected_rows()

D. mysqli_field_count()

Wybór innych funkcji zamiast mysqli_affected_rows() prowadzi do nieporozumień dotyczących ich przeznaczenia i zastosowania. Przykładowo, funkcja mysqli_num_rows() jest używana w kontekście kwerend SELECT, gdzie zwraca liczbę wierszy w zestawie wyników. Nie może być zastosowana po operacjach modyfikujących bazę danych, takich jak UPDATE, ponieważ nie dostarcza informacji o efektach tych operacji. Z kolei mysqli_use_result() jest przeznaczona do przetwarzania zestawów wyników z zapytań, co znowu nie odnosi się do sytuacji, w której chcemy znać liczbę zmienionych wierszy. Funkcja mysqli_field_count() zwraca liczbę kolumn w ostatnim zapytaniu, które zwróciło rezultat, co również nie ma zastosowania w kontekście zapytań modyfikujących. Typowym błędem myślowym jest mieszanie funkcji związanych z różnymi rodzajami zapytań. Ważne jest, aby rozumieć, jak różne funkcje w PHP dotyczące MySQL są ze sobą powiązane i jakie mają specyficzne zastosowania. Nieprawidłowe użycie tych funkcji może prowadzić do błędnych wniosków o stanie bazy danych i utrudniać debugowanie aplikacji. W związku z tym kluczowym elementem efektywnego zarządzania bazami danych jest znajomość odpowiednich funkcji oraz ich funkcji i ograniczeń.

Pytanie 20

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

A. reguły

B. klucze podstawowe

C. indeksy

D. wartości domyślne

Indeksy przyspieszają WYSZUKIWANIE danych (szybciej odnajdują wiersze), ale spowalniają zapis - przy każdym INSERT/UPDATE trzeba też zaktualizować indeks. Dlatego tę cechę mają indeksy.

Pytanie 21

Które zapytanie SQL wybiera nazwiska z tabeli klient, które mają co najmniej jedną literę i zaczynają się na literę Z?

A. SELECT nazwisko FROM klient WHERE nazwisko='Z?'

B. SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z_%'

C. SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z%'

D. SELECT nazwisko FROM klient WHERE nazwisko='Z_?'

Odpowiedź SELECT nazwisko FROM klient WHERE nazwisko LIKE 'Z%'; jest poprawna, ponieważ wykorzystuje operator LIKE, który jest standardowym narzędziem w SQL do wyszukiwania wzorców w danych tekstowych. Znak procenta (%) w tym kontekście oznacza, że może wystąpić dowolna liczba znaków po literze Z, co jest zgodne z wymaganiem, aby nazwiska były co najmniej jednoliterowe. W praktyce, takie zapytanie umożliwia efektywne wyszukiwanie danych w bazach, co jest kluczowe w kontekście aplikacji zarządzających danymi klientów. Dobre praktyki w projektowaniu baz danych zalecają stosowanie operatora LIKE do filtrowania wyników, co pozwala na zwiększenie przejrzystości i wydajności. W przypadku wyszukiwania nazwisk, można również użyć indeksów, aby przyspieszyć wykonanie zapytań, co jest ważne w kontekście dużych zbiorów danych, gdzie czas odpowiedzi aplikacji może mieć istotne znaczenie dla użytkowników końcowych. Używanie LIKE w połączeniu z odpowiednimi znakami wieloznacznymi jest więc kluczowym elementem efektywnego zarządzania danymi.

Pytanie 22

Do czego służy polecenie DROP w SQL?

A. do aktualizacji danych obiektu

B. do dodania nowego obiektu

C. do zmiany parametrów obiektu

D. do usunięcia istniejącego obiektu (np. tabeli)

Trzeba odróżnić usuwanie od innych operacji. Zmianę parametrów obiektu wykonuje ALTER, aktualizację DANYCH - UPDATE, a dodanie nowego obiektu - CREATE. Skasowaniem istniejącego obiektu zajmuje się DROP.

Pytanie 23

Której funkcji PHP użyć, aby NAWIĄZAĆ połączenie z serwerem bazy danych?

mysqli_get_connection_stats()

mysqli_autocommit()

mysqli_fetch_row()

mysqli_connect()

Pozostałe funkcje zakładają, że połączenie JUŻ istnieje, więc nie mogą go tworzyć. mysqli_get_connection_stats() zwraca statystyki istniejącego połączenia. mysqli_fetch_row() pobiera kolejny wiersz z wyniku zapytania. mysqli_autocommit() włącza lub wyłącza automatyczne zatwierdzanie transakcji. Wszystkie wymagają wcześniejszego połączenia, które nawiązuje dopiero mysqli_connect().

Pytanie 24

Na zakończenie dnia w bazie danych sklepu spożywczego generowany jest raport, który pokazuje produkty wraz z ich dostawcami, dla których liczba sztuk w magazynie jest poniżej 10. Do stworzenia tego raportu użyto kwerendy

A. UPDATE

B. SELECT

C. CHECK TABLE

D. INSERT INTO

Wybór instrukcji UPDATE, INSERT INTO oraz CHECK TABLE jako metod do generowania raportu w bazie danych jest niepoprawny. Instrukcja UPDATE służy do modyfikacji istniejących danych w tabeli, co oznacza, że nie można jej użyć do wyświetlania informacji. Gdyby użytkownik spróbował użyć UPDATE do generowania raportu, mógłby nieumyślnie zmienić wartości w bazie danych, co jest sprzeczne z zamierzeniem uzyskania jedynie informacji. Z kolei INSERT INTO jest używane do dodawania nowych rekordów do bazy danych i również nie ma zastosowania w kontekście generowania raportów. Ta instrukcja nie tylko nie udostępnia żadnych informacji o istniejących danych, ale także może prowadzić do nieporozumień, gdyż wprowadza nowe dane zamiast ich przeszukiwać. Natomiast CHECK TABLE jest instrukcją używaną do sprawdzania integralności tabeli w bazie danych i nie ma związku z pobieraniem danych ani ich wyświetlaniem. Z tego powodu, wszystkie te trzy odpowiedzi są nieodpowiednie w kontekście tworzenia raportu w bazie danych, ponieważ każda z nich działa na zupełnie innych zasadach niż SELECT, który jest właściwym narzędziem do przeszukiwania i wyświetlania danych.

Pytanie 25

Na przedstawionym diagramie ER zapis FK1 oznacza

A. klucz obcy.

B. relację 1:1.

C. relację 1:N.

D. klucz podstawowy.

Na diagramach ER oznaczenia typu FK1 zwykle odnoszą się do kluczy obcych, a nie do samej relacji ani do kluczy podstawowych. Łatwo się tu pomylić, bo obok tego symbolu widać też graficzne oznaczenie relacji 1:N między tabelami Klienci i Zamówienia, więc część osób automatycznie kojarzy podpis z typem połączenia. Tymczasem relacja 1:1 czy 1:N jest przedstawiana linią i odpowiednimi znacznikami przy końcach (kreska, „gałązki”, kółko), natomiast skróty PK i FK pojawiają się wewnątrz tabel i opisują role konkretnych kolumn. PK to primary key, czyli klucz podstawowy – unikalny identyfikator w danej tabeli. Na diagramie widać go przy NR_klienta w tabeli Klienci oraz przy ID_Zamówienia w tabeli Zamówienia. Oznaczenie FK1 przy NR_klienta w tabeli Zamówienia nie może więc oznaczać kolejnego klucza podstawowego ani samej relacji, tylko właśnie klucz obcy, który wskazuje na PK w innej tabeli. Częsty błąd polega na mieszaniu pojęć „relacja 1:N” z „kluczem obcym”. Relacja 1:N jest pojęciem konceptualnym: mówi, że jeden klient może mieć wiele zamówień. Klucz obcy to implementacja tej relacji w fizycznym modelu bazy: konkretna kolumna, która przechowuje wartość klucza podstawowego z drugiej tabeli. Innymi słowy, FK jest narzędziem, a 1:N opisem zależności. Kiedy ktoś interpretuje FK1 jako relację 1:1 albo 1:N, miesza warstwę symboliki linii z opisem kolumn. Dobra praktyka w projektowaniu baz danych i w narzędziach CASE jest taka, że PK i FK stoją zawsze przy nazwach atrybutów, a typ relacji rozczytujemy z grafiki między encjami, nie z tych skrótów. Zrozumienie tej różnicy jest kluczowe, bo potem w SQL dokładnie tak samo rozdzielamy definicję struktury tabel (PRIMARY KEY, FOREIGN KEY) od logicznej interpretacji, ile rekordów może być po każdej stronie relacji.

Pytanie 26

W zakresie ochrony serwera bazy danych przed atakami hakerównie wlicza się

A. defragmentacja dysków

B. używanie skomplikowanych haseł do bazy

C. blokada portów powiązanych z bazą danych

D. aktywacja zapory

Wybór odpowiedzi związanej z blokowaniem portów, włączeniem zapory oraz stosowaniem złożonych haseł jest zgodny z najlepszymi praktykami w zakresie zabezpieczeń serwera bazy danych. Blokowanie portów to kluczowy krok, który ogranicza dostęp do usług bazodanowych tylko dla autoryzowanych użytkowników. Wiele ataków z zewnątrz wykorzystuje otwarte porty, dlatego ich zablokowanie jest podstawowym zabezpieczeniem. Zapory sieciowe, zarówno sprzętowe, jak i programowe, są niezbędne do filtrowania ruchu i ochrony przed nieautoryzowanym dostępem. Z kolei stosowanie złożonych haseł jest fundamentalnym elementem ochrony danych - hasła powinny być długie, zawierać znaki specjalne, cyfry oraz różne przypadki liter, aby znacznie utrudnić ich złamanie. Praktyczne przykłady pokazują, że organizacje, które nie implementują tych zabezpieczeń, stają się łatwym celem dla cyberprzestępców. Warto również wspomnieć o dodatkowych środkach, takich jak szyfrowanie danych w bazach, co dodatkowo podnosi poziom ochrony informacji. Brak znajomości tych zasad może prowadzić do niedostatecznej ochrony przed zagrożeniami, co w dzisiejszym, złożonym środowisku IT, jest nieakceptowalne.

Pytanie 27

Na zaprezentowanym schemacie bazy danych biblioteka, elementy takie jak: czytelnik, wypożyczenie oraz książka stanowią

A. krotki

B. atrybuty

C. pola

D. encje

Na tym schemacie bazy danych warto najpierw odróżnić kilka podstawowych pojęć: encja, atrybut, krotka i pole. To jest taki fundament, bez którego łatwo się pogubić. Prostokąty podpisane „czytelnik”, „wypożyczenie” i „książka” reprezentują ogólne typy obiektów, które występują w systemie. W języku modelowania danych nazywamy je encjami. Encja to nie pojedynczy rekord, tylko pewien rodzaj bytu, np. każdy konkretny czytelnik będzie instancją encji CZYTELNIK.
Częsty błąd polega na myleniu encji z atrybutami. Atrybut to pojedyncza cecha encji – na przykład imię, nazwisko, tytuł, rok wydania. Na diagramie są one wypisane wewnątrz prostokąta, pod nazwą encji. Gdyby „czytelnik” był atrybutem, to musiałby opisywać jakąś inną encję, co tu nie ma sensu. Podobnie jest z pojęciem pola: w praktyce pola kojarzymy z kolumnami w tabeli lub polami formularza. Pole to techniczna reprezentacja atrybutu w konkretnej tabeli, a nie osobny obiekt biznesowy.
Zdarza się też, że uczniowie zaznaczają odpowiedź „krotki”, bo widzą powiązanie z relacyjną bazą danych. Krotka (rekord, wiersz tabeli) oznacza jednak pojedyńczy wpis w tabeli, np. jednego konkretnego Kowalskiego jako czytelnika albo jedną konkretną książkę. Na diagramie nie widzimy pojedynczych rekordów, tylko definicję struktur, z których te rekordy będą się składać. Innymi słowy: encja to wzór, a krotka to jego konkretne wystąpienie.
Moim zdaniem najbezpieczniejsza metoda zapamiętania jest taka: na etapie projektowania koncepcyjnego mówimy o encjach i atrybutach, na etapie fizycznej bazy – o tabelach, kolumnach (polach) i rekordach (krotkach). W tym pytaniu mówimy właśnie o poziomie modelu koncepcyjnego, dlatego poprawnym pojęciem są encje, a nie atrybuty, krotki czy pola.

Pytanie 28

Co robi polecenie:

ALTER TABLE miasta ADD kod text;

A. zmienia nazwę kolumny kod na text

B. zmienia nazwę tabeli miasta na kod

C. dodaje dwie kolumny: kod i text

D. dodaje do tabeli kolumnę kod typu text

Pozostałe interpretacje są błędne. W zapisie ADD kod text jest jedna nazwa kolumny (kod) i jeden typ (text), więc powstaje JEDNA kolumna, a nie dwie. Nazwa tabeli się nie zmienia (to nie RENAME), a nazwa kolumny nie jest podmieniana. Efektem jest dodanie kolumny kod typu text.

Pytanie 29

SELECT ocena FROM oceny WHERE ocena > 2 ORDER BY ocena;

Załóżmy, że istnieje tabela oceny zawierająca kolumny id, nazwisko, imię oraz ocena. Przykładowe zapytanie ilustruje:

A. selekcję.

B. sumę.

C. łączenie.

D. rekurencję.

Zapytanie przedstawione w pytaniu nie jest przykładem łączenia ponieważ nie występuje w nim klauzula JOIN która jest podstawowym narzędziem do łączenia tabel w bazach danych. Łączenie danych jest używane gdy potrzebujemy zintegrować informacje z różnych źródeł i polega na zestawieniu wierszy z dwóch lub więcej tabel na podstawie wspólnego klucza. Zamiast tego zapytanie używa klauzuli WHERE która służy do selekcji danych. Nie jest też przykładem rekurencji. Rekurencja w kontekście baz danych dotyczy wykonywania operacji powtarzających się w określonej sekwencji lub hierarchii co jest typowe dla struktur takich jak drzewa. Wiąże się to zwykle z użyciem zapytań zawierających takie konstrukcje jak WITH RECURSIVE w SQL co nie jest obecne w tym zapytaniu. Ponadto zapytanie nie jest przykładem sumy ponieważ nie zawiera funkcji agregujących takich jak SUM które służą do zliczania wartości w kolumnie. Suma jest używana do obliczeń statystycznych a nie do filtrowania danych na podstawie kryteriów logicznych jak to ma miejsce w przedstawionym przykładzie. Zrozumienie tych różnic jest kluczowe dla poprawnego formułowania zapytań i efektywnego wykorzystania systemów bazodanowych. Poprawne identyfikowanie mechanizmów w SQL pozwala efektywnie wykorzystać możliwości języka w analizie danych i zarządzaniu bazami co jest szczególnie istotne w profesjonalnych projektach IT. Zrozumienie logicznej struktury SQL i różnic między tymi koncepcjami jest kluczowe dla skutecznego i wydajnego wykorzystania baz danych w praktyce zawodowej i biznesowej.

Pytanie 30

Jakie cechy powinien posiadać klucz główny?

A. Jest unikatowy, nie może zawierać pustych wartości

B. Nie może przybierać wartości, reprezentowany jest przez dokładnie jedno pole tabeli

C. Jest unikatowy, może mieć tylko wartości całkowite

D. Reprezentowany jest przez jedno pole tabeli, jego wartość nie może ulegać zmianie

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

Pytanie 31

Polecenie w języku SQL w formie

ALTER TABLE 'miasta' 
ADD 'kod' text;

A. zmienia nazwę tabeli miasta na kod.

B. dodaje do tabeli dwie kolumny o nazwach: kod i text.

C. dodaje do tabeli kolumnę o nazwie kod typu text.

D. w tabeli miasta zmienia nazwę kolumny kod na text.

Wszystkie niepoprawne odpowiedzi opierają się na błędnym zrozumieniu polecenia ALTER TABLE oraz jego składni. Po pierwsze, zmiana nazwy kolumny i zmiana nazwy tabeli to operacje, które wymagają użycia innych poleceń SQL, takich jak RENAME COLUMN lub RENAME TABLE, a nie polecenia ADD. W przypadku zmiany nazwy kolumny, nie dodajemy nowej kolumny, lecz po prostu modyfikujemy istniejącą. Co więcej, zmiana tabeli za pomocą ALTER TABLE nie powoduje zamiany jej nazwy na nową, jak sugeruje jedna z odpowiedzi. Dodawanie dwóch kolumn w jednym poleceniu również jest błędne, ponieważ polecenie ADD w tym kontekście dotyczy tylko jednej kolumny. W praktyce, gdy chcemy dodać więcej niż jedną kolumnę, stosujemy wielokrotne polecenia ADD w ramach jednego ALTER TABLE lub używamy składni, która pozwala na dodanie wielu kolumn jednocześnie, ale to nadal nie jest to, co przedstawiono w tym pytaniu. Błędy te mogą wynikać z braku zrozumienia składni SQL oraz funkcji poszczególnych poleceń, co prowadzi do mylnych interpretacji i błędnych wniosków. Właściwe zrozumienie tych podstaw jest kluczowe dla efektywnego projektowania i zarządzania bazami danych.

Pytanie 32

Jaką integralność określa przytoczona definicja?

A. Statyczną

B. Semantyczną

C. Encji

D. Referencyjną

Integralność encji odnosi się do unikalności danych w tabeli poprzez klucze główne. Jest to fundamentalna koncepcja w relacyjnych bazach danych polegająca na tym że każda encja czyli rekord w tabeli musi być jednoznacznie identyfikowalna. Klucz główny zapewnia tę unikalność co jest niezależne od relacji między tabelami opisywanych przez integralność referencyjną. Pojęcie integralności statycznej odnosi się do stanu danych który nie zmienia się w czasie co nie jest bezpośrednio związane z relacjami pomiędzy tabelami. Integralność statyczna może odnosić się do historycznych danych lub archiwów gdzie dane muszą pozostać niezmienne po ich zarejestrowaniu. Podczas gdy integralność referencyjna dotyczy dynamicznych relacji między różnymi zestawami danych integralność statyczna wiąże się z zachowaniem niezmienności danych w obrębie pojedynczego zbioru. Integralność semantyczna odnosi się natomiast do znaczenia i logiki biznesowej danych. Chodzi o zapewnienie że dane w bazie są zgodne z regułami i założeniami biznesowymi. Na przykład data urodzenia nie może być późniejsza niż data zatrudnienia. Chociaż integralność semantyczna jest ważna dla poprawności danych z punktu widzenia aplikacji biznesowej nie opisuje ona relacji między tabelami w taki sposób jak integralność referencyjna. Właściwe rozumienie tych różnych koncepcji jest kluczowe dla projektowania i utrzymania spójnych i niezawodnych systemów baz danych.

Pytanie 33

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

A. XML

B. CSV

C. SQL

D. ESRI

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

Pytanie 34

Zawarte polecenie SQL wykonuje

UPDATE Uczen SET id_klasy = id_klasy + 1;

A. zwiększyć o jeden wartość w kolumnie id_klasy dla wszystkich rekordów tabeli Uczen

B. ustalić wartość kolumny id_klasy na 1 dla wszystkich rekordów w tabeli Uczen

C. powiększyć wartość pola Uczen o jeden

D. ustalić wartość pola Uczen na 1

Analizując podane odpowiedzi, możemy zauważyć pewne błędne założenia co do działania polecenia SQL. Pierwsza z opcji sugeruje ustawienie wartości pola `Uczen` na 1, co jest nieprawidłowe, ponieważ polecenie nie odnosi się bezpośrednio do pola o nazwie `Uczen`, lecz dotyczy kolumny `id_klasy` w tabeli `Uczen`. Druga odpowiedź koncentruje się na zwiększeniu wartości pola `Uczen`, lecz polecenie nie zawiera odniesienia do pola o takiej nazwie, zajmuje się kolumną `id_klasy`. Trzecia możliwość mówi o ustawieniu wartości `id_klasy` na 1 dla wszystkich rekordów, co również jest nieprawidłową interpretacją, gdyż zgodnie z poleceniem SQL, wartość ta nie jest ustawiana na stałą wartość 1, ale jest zwiększana o 1. Często spotykanym błędem jest nieuwzględnianie specyfiki polecenia `UPDATE`, które modyfikuje istniejące dane, i mylenie go z `SET`, które może być używane w kontekście `INSERT`, jeżeli chcemy przypisywać stałe wartości. Aby uniknąć takich nieporozumień, zawsze warto dokładnie analizować składnię i logikę poleceń SQL.

Pytanie 35

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

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

A. do zarządzania strukturą tabeli klienci

B. do manipulowania danymi w tabeli klienci

C. do manipulowania danymi bazy danych klienci

D. do zarządzania strukturą bazy danych klienci

Polecenie SQL GRANT SELECT INSERT UPDATE DELETE ON klienci TO adam@localhost nadaje użytkownikowi adam@localhost prawa manipulowania danymi w tabeli klienci Komendy SELECT INSERT UPDATE DELETE są podstawowymi operacjami manipulacji danymi w systemach zarządzania bazami danych (DBMS) SELECT umożliwia odczytywanie danych z tabeli INSERT pozwala na dodawanie nowych rekordów do tabeli UPDATE umożliwia modyfikację istniejących danych DELETE daje możliwość usuwania rekordów z tabeli Takie operacje są kluczowe przy codziennym zarządzaniu danymi w bazach danych oraz podczas tworzenia aplikacji które z tych danych korzystają Nadanie takich uprawnień jest często stosowane w środowiskach produkcyjnych i deweloperskich gdzie użytkownicy muszą wykonywać różnorodne operacje na danych Przydzielanie uprawnień powinno być jednak dobrze przemyślane aby zapewnić bezpieczeństwo danych oraz zgodność z najlepszymi praktykami branżowymi Takie podejście minimalizuje ryzyko nieautoryzowanych modyfikacji i utraty danych co jest zgodne z zasadami zarządzania bezpieczeństwem informacji

Pytanie 36

Tabela programy ma kolumny nazwa, producent, rokWydania. Która kwerenda zwróci producentów BEZ powtórzeń?

SELECT UNIQUE producent FROM programy;

SELECT producent FROM programy WHERE UNIQUE;

SELECT DISTINCT producent FROM programy;

SELECT producent FROM programy WHERE producent NOT DUPLICATE;

Pozostałe zapisy są błędne składniowo. SELECT UNIQUE producent używa słowa UNIQUE, które w SQL jest OGRANICZENIEM kolumny przy tworzeniu tabeli, a nie sposobem odsiewania duplikatów w zapytaniu (w MySQL nie zadziała). WHERE UNIQUE oraz WHERE producent NOT DUPLICATE to konstrukcje, które w SQL nie istnieją. Duplikaty usuwa SELECT DISTINCT producent FROM programy;.

Pytanie 37

Przedstawiony fragment kodu ilustruje działanie

A. pozyskiwania danych

B. wykorzystania zdefiniowanej procedury lub funkcji

C. prezentacji danych

D. podjęcia decyzji

Zastosowanie gotowej procedury lub funkcji nie jest reprezentowane przez blok w kształcie rombu. Takie czynności zazwyczaj ilustruje się prostokątem z zaokrąglonymi narożnikami lub innym charakterystycznym symbolem, który wskazuje na działanie sekwencyjne. Wczytanie danych z kolei często reprezentowane jest przez blok w kształcie równoległoboku, podkreślający operacje wejścia-wyjścia, czyli interakcję z zewnętrznym źródłem danych. Wyświetlanie danych również jest związane z operacjami wejścia-wyjścia, co sugeruje podobny symbol jak w przypadku wczytywania danych. Podstawowy błąd myślowy w tych odpowiedziach polega na myleniu struktury kontrolnej z funkcjami operacyjnymi. Struktury kontrolne, jak decyzje, są kluczowe dla logiki programu, podczas gdy operacje wejścia-wyjścia są bardziej związane z przetwarzaniem danych. Zrozumienie tych różnic jest fundamentalne dla poprawnego projektowania algorytmów i diagramów przepływu, co znacząco wpływa na efektywność i czytelność projektowanych systemów.

Pytanie 38

Która funkcja PHP ustawia KODOWANIE znaków połączenia z bazą (np. dla polskich liter)?

mysqli_fetch_assoc()

mysqli_set_charset()

mysqli_connect()

mysqli_query()

Pozostałe funkcje nie dotyczą kodowania. mysqli_connect() nawiązuje połączenie (ale samo z siebie nie ustawia poprawnego charsetu), mysqli_query() wysyła zapytanie, a mysqli_fetch_assoc() pobiera wiersz wyniku jako tablicę asocjacyjną. Kodowanie znaków połączenia ustawia wyłącznie mysqli_set_charset().

Pytanie 39

Jakie polecenie należy zastosować, aby cofnąć uprawnienia przyznane użytkownikowi?

GRANT NO PRIVILEGES

DROP PRIVILEGES

REVOKE

REMOVE

Pozostałe odpowiedzi tylko udają polecenia zarządzające uprawnieniami. REMOVE, DROP PRIVILEGES oraz GRANT NO PRIVILEGES brzmią wiarygodnie, ale w standardzie SQL takich komend nie ma - serwer odrzuciłby je jako błąd składni. Zarządzanie prawami opiera się na dwóch poleceniach: GRANT nadaje uprawnienia, a REVOKE je odbiera. Aby cofnąć przyznane wcześniej uprawnienia, właściwe jest więc REVOKE, a nie żadna z wymyślonych nazw.

Pytanie 40

Rozważ tabelę mieszkań, która zawiera kolumny: adres, metraż, ile_pokoi, standard, status, cena. Wykonanie poniższej kwerendy SQL SELECT spowoduje wyświetlenie:

SELECT metraz, cena FROM mieszkania WHERE ile_pokoi > 3;

A. metraż oraz cena tych mieszkań, które posiadają co najmniej 3 pokoje

B. wszystkie dane mieszkań, które mają co najmniej 3 pokoje

C. wszystkie informacje, z wyjątkiem adresu, dotyczące mieszkań z więcej niż 3 pokojami

D. metraż oraz cena tych mieszkań, które mają więcej niż 3 pokoje

Odpowiedzi, które sugerują, że kwerenda wyświetla wszystkie dane mieszkań z co najmniej 3 pokojami lub wszystkie dane oprócz adresu, są nieprawidłowe z kilku powodów. Przede wszystkim, operator '>' w kwerendzie oznacza, że zapytanie dotyczy jedynie mieszkań z większą liczbą pokoi niż 3, a więc tylko te, które mają 4 lub więcej pokoi będą brane pod uwagę. Odpowiedzi sugerujące, że zwracane są wszystkie dane mieszkań, nie uwzględniają, że kwerenda skupia się wyłącznie na kolumnach metraż i cena, co jest kluczowe w kontekście efektywności i przejrzystości zapytań. W kontekście SQL, wybór określonych kolumn jest bardzo istotny, ponieważ nie tylko zmniejsza objętość przesyłanych danych, ale również ułatwia ich analizę. Niezrozumienie tego aspektu może prowadzić do nieefektywnego korzystania z zasobów bazy danych. Ponadto, stwierdzenie, że kwerenda zwraca wszystkie dane oprócz adresu, jest mylne, ponieważ zapytanie w ogóle nie uwzględnia adresu ani innych informacji, a jedynie metraż i cenę. Tego typu nieprecyzyjne interpretacje mogą zniekształcić obraz tego, jak działa SQL i w jaki sposób można efektywnie zarządzać danymi.

Rozpocznij nowy egzamin

Powrót do strony głównej