Wyniki egzaminu

Niepoprawna odpowiedź. Tabela to struktura bazy danych, która służy do przechowywania danych w formie zorganizowanej w wiersze i kolumny. Tabele są fundamentem relacyjnych baz danych, jednak nie umożliwiają one bezpośredniego generowania raportów ani wizualizacji danych. Tabele są wykorzystywane w procesie wprowadzania i edycji danych, a nie w ich przetwarzaniu do analizy. Zapytanie to forma polecenia, która umożliwia użytkownikowi pobieranie określonych danych z bazy, na podstawie zdefiniowanych kryteriów. Mimo że zapytania są kluczowe w procesie obróbki danych, same w sobie nie generują raportów ani wykresów, lecz zwracają wyniki w postaci zbioru danych. Formularz to narzędzie, które służy do wprowadzania i edytowania danych w bazie. Rola formularzy polega na ułatwieniu interakcji użytkownika z bazą danych poprzez umożliwienie wprowadzania informacji w zorganizowanej formie. Formularze są przydatne w procesach zarządzania danymi, ale ich funkcjonalność nie obejmuje analizy ani prezentacji danych w formie raportów. W związku z tym, zarówno tabela, jak i zapytanie oraz formularz nie spełniają kryteriów określonych w pytaniu, ponieważ nie są dedykowane wyłącznie do odczytu danych w formie raportów.

YEAR

BOOLEAN

DATE

TIMESTAMP

Niepoprawna odpowiedź. Pozostałe typy przechowują tylko fragment informacji lub coś innego. DATE zapisuje samą datę (bez godziny) - nie da się w nim zapamiętać czasu. YEAR przechowuje wyłącznie rok, więc to jeszcze mniej danych. BOOLEAN to typ logiczny przyjmujący prawda/fałsz, zupełnie niezwiązany z datą. Datę razem z czasem przechowuje TIMESTAMP (lub DATETIME), dlatego ta odpowiedź jest poprawna.

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

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

SELECT Imie, Nazwisko, DataWystawienia FROM Recepta

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

Niepoprawna odpowiedź. Błędne odpowiedzi wynikają z nieprawidłowego zrozumienia struktury relacyjnej baz danych i mechanizmu łączenia tabel. W przypadku odpowiedzi pierwszej, kwerenda SELECT Imie, Nazwisko, DataWystawienia FROM Recepta; pobiera dane o pacjencie, a nie o lekarzu, ponieważ kolumny Imie i Nazwisko w tabeli Recepta odnoszą się do pacjenta. Chociaż uzyskujemy datę wystawienia recepty, brakuje kluczowej informacji o lekarzu wystawiającym. Odpowiedź druga, SELECT Lekarz.Imie, Lekarz.Nazwisko, DataWystawienia FROM Recepta;, jest błędna, ponieważ nie zawiera mechanizmu JOIN, który jest niezbędny do połączenia danych z tabeli Recepta z tabelą Lekarz. Bez tego połączenia próba odwołania się do kolumn z tabeli Lekarz zakończy się błędem. Odpowiedź trzecia, SELECT Imie, DataWystawienia FROM Recepta JOIN Lekarz ON Recepta.Lekarz_id = Lekarz.id;, również nie spełnia wymagań, ponieważ pobiera tylko imię pacjenta (co jest nieprawidłowe), a nie informacje o lekarzu. Podstawowym błędem w tych odpowiedziach jest brak zrozumienia relacji między tabelami oraz poprawnego zastosowania kluczy, co jest kluczowe w pracy z relacyjnymi bazami danych. Zrozumienie mechanizmu JOIN i prawidłowego odniesienia się do kolumn w różnych tabelach jest fundamentem efektywnego projektowania i wykorzystywania baz danych.

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

Niepoprawna odpowiedź. Klucz tego pytania to dwa słowa: pliki i bezpiecznie. POP3 oraz IMAP odpadają już na pierwszym z nich - oba to protokoły poczty elektronicznej. POP3 pobiera wiadomości ze skrzynki na komputer i zwykle usuwa je z serwera, a IMAP zarządza nimi bezpośrednio na serwerze pocztowym; żaden z nich nie służy do wysyłania plików witryny na serwer WWW i pomyłka tu bierze się głównie z tego, że wszystkie cztery nazwy to skróty protokołów sieciowych. Telnet z kolei rzeczywiście łączy się ze zdalnym hostem, ale to narzędzie zdalnej konsoli, a nie transferu plików - i co najważniejsze, przesyła dane oraz hasła tekstem jawnym, więc nie spełnia warunku bezpieczeństwa. Pozostaje SFTP: przesyła pliki w sesji SSH, w pełni zaszyfrowanej, dzięki czemu zarówno zawartość, jak i dane logowania są chronione w drodze na serwer. To dlatego do bezpiecznej publikacji strony używa się SFTP, a nie nieszyfrowanego FTP czy któregokolwiek z pozostałych protokołów.

CREATE TABLE dane (kolumna INTEGER(3));

Niepoprawna odpowiedź. W tym zadaniu bardzo łatwo wpaść w pułapkę skojarzeń z programowaniem w innych językach, gdzie nawias przy typie sugeruje rozmiar tablicy albo liczbę elementów. W SQL, a szczególnie w składni zbliżonej do MySQL, zapis `INTEGER(3)` nie tworzy trzech kolumn ani trzyelementowej tablicy, tylko opisuje jedną kolumnę typu liczbowego. Nawias w tym miejscu oznacza co najwyżej szerokość wyświetlania albo pewne ograniczenie prezentacji, a nie ilość powtórzeń typu. Dlatego interpretacja, że tabela ma trzy kolumny typu całkowitego, jest po prostu przeniesieniem logiki z np. C lub Java na SQL, co jest częstym, ale błędnym nawykiem. Podobnie mylenie `INTEGER(3)` z tablicą trzyelementową wynika z tego, że w wielu językach zapis z nawiasami kwadratowymi czy okrągłymi kojarzy się z kolekcją. W relacyjnych bazach danych pojedyncza kolumna przechowuje pojedynczą wartość skalarnej dziedziny (liczba, tekst, data), a nie tablicę, chyba że używamy bardzo specyficznych typów, jak np. ARRAY w PostgreSQL – ale to wygląda zupełnie inaczej w definicji. Kolejny błąd to założenie, że skoro przy typie pojawia się liczba 3, to kolumny zostaną automatycznie nazwane `kolumna1`, `kolumna2`, `kolumna3`. Silniki SQL niczego takiego nie robią. Nazwy kolumn muszą być jawnie podane w definicji tabeli, oddzielone przecinkami, np. `kolumna1 INTEGER, kolumna2 INTEGER, kolumna3 INTEGER`. Jeżeli w nawiasie przy CREATE TABLE jest tylko jeden wpis `kolumna INTEGER(3)`, to mamy dokładnie jedną kolumnę o nazwie `kolumna`. Moim zdaniem dobrym nawykiem jest zawsze patrzeć na przecinki: ile jest elementów oddzielonych przecinkami w nawiasie po nazwie tabeli, tyle jest kolumn. Liczby w nawiasach przy typach (np. VARCHAR(50), DECIMAL(10,2), INT(3)) opisują parametry typu, a nie liczbę kolumn. To podstawowa, ale bardzo ważna zasada przy projektowaniu schematów baz danych i unikaniu dziwnych, mylących interpretacji.

CONSTRAINT fk_osoba_uczen FOREIGN KEY(nazwisko, imie) REFERENCES osoby (nazwisko, imie)

CONSTRAINT (nazwisko, imie) FOREIGN REFERENCES KEY osoby (nazwisko, imie)

CONSTRAINT fk_osoba_uczen FOREIGN KEY ON(nazwisko, imie) REFERENCES osoby (nazwisko, imie)

CONSTRAINT (nazwisko, imie) FOREIGN KEY REFERENCES osoby (nazwisko, imie)

Niepoprawna odpowiedź. Pozostałe zapisy łamią składnię definicji klucza obcego. W dwóch brakuje listy kolumn zaraz po FOREIGN KEY albo przestawiono słowa kluczowe (FOREIGN REFERENCES KEY zamiast FOREIGN KEY ... REFERENCES) - serwer odrzuci je jako błąd. W jeszcze innym po FOREIGN KEY dopisano zbędne ON, którego w tej konstrukcji nie ma. Prawidłowy wielokolumnowy klucz obcy to CONSTRAINT nazwa FOREIGN KEY(kolumny) REFERENCES tabela(kolumny), dlatego to ten zapis jest poprawny.

Niepoprawna odpowiedź. Zamknięcie bazy danych w kontekście nieudanego połączenia jest koncepcją, która nie ma sensu. Jeśli połączenie się nie uda, to nie ma nawet nawiązanej sesji, która mogłaby być zamknięta. Połączenie z bazą danych powinno być zamykane tylko w momencie, gdy zostało nawiązane i jest już niepotrzebne, a nie w przypadku, gdy wystąpił błąd w trakcie łączenia. Komunikat o pomyślnym połączeniu także nie ma zastosowania w tej sytuacji, ponieważ, skoro połączenie się nie udało, nie ma podstaw do informowania użytkownika o jego powodzeniu. Obsługa danych pobranych z bazy również nie ma miejsca, jeśli połączenie nie zostało ustanowione, co czyni te odpowiedzi błędnymi. Właściwe podejście w takich sytuacjach to zawsze najpierw sprawdzenie, czy połączenie zostało nawiązane, a następnie działania w przypadku usunięcia błędu. Ignorowanie tej zasady może prowadzić do nieprzewidzianych zachowań aplikacji, a nawet do wycieków danych lub awarii serwerów.

TRUNCATE TABLE zadania;

DELETE FROM zadania;

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

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

Niepoprawna odpowiedź. Kwerendy 'TRUNCATE TABLE zadania;' i 'TRUNCATE TABLE zadania WHERE status = 'zamknięte';' są nieodpowiednie do rozwiązania przedstawionego problemu. W przypadku użycia 'TRUNCATE TABLE zadania;', następuje całkowite usunięcie wszystkich rekordów z tabeli, co jest nie tylko ryzykowne, ale również niezgodne z wymaganiem usunięcia tylko tych z określonym statusem. Ta operacja nie posiada możliwości ograniczenia działań do konkretnego zestawu danych, dlatego zawsze należy podchodzić do jej użycia z dużą ostrożnością. Dodatkowo, 'TRUNCATE TABLE' jest operacją szybszą od 'DELETE', ale nie można jej stosować z klauzulą WHERE, co sprawia, że 'TRUNCATE TABLE zadania WHERE status = 'zamknięte';' jest syntaktycznie błędne. Praktka używania TRUNCATE jest zalecana, gdy chcemy szybko usunąć wszystkie dane z tabeli, na przykład przed załadowaniem nowych danych, lecz w tym wypadku jest to niewłaściwa strategia. Warto również zauważyć, że podczas usuwania danych z bazy danych, kluczowe jest rozważenie wpływu na relacje między tabelami, integralność danych oraz możliwość ich późniejszej analizy. Używanie DELETE z odpowiednim warunkiem jest bardziej kontrolowane, co jest zgodne z najlepszymi praktykami w tworzeniu i zarządzaniu bazami danych.

ANALYZE TABLE

RESTORE TABLE

BACKUP TABLE

REPAIR TABLE

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

Niepoprawna odpowiedź. W tym zadaniu kluczowe jest zrozumienie różnicy między katalogiem serwera, adresem IP, nazwą hosta i numerem portu. W XAMPP-ie Apache udostępnia pliki z katalogu „htdocs”, ale ten katalog nie jest adresem, pod który łączy się przeglądarka. To tylko folder w systemie plików, fizyczna lokalizacja plików strony. Adres, którego używamy w pasku URL, zawsze składa się z protokołu (np. http), nazwy hosta lub adresu IP oraz opcjonalnie numeru portu. Dlatego wpisanie samego „htdocs” w przeglądarce nie ma sensu – to nie jest ani host, ani protokół. Częsty błąd polega na myleniu ścieżki na dysku z adresem URL. Kolejna pułapka to założenie, że Apache w XAMPP zawsze działa na domyślnym porcie 80, więc „localhost:80” będzie na pewno poprawny. W teorii HTTP faktycznie używa domyślnie portu 80, ale w praktyce w środowisku deweloperskim bardzo często port jest zmieniany, np. gdy port 80 jest zajęty przez inny proces. Na zrzucie ekranu w kolumnie „Port(s)” wyraźnie widać, że Apache nasłuchuje na porcie 70, więc użycie „localhost:80” wskazywałoby na inny port niż rzeczywiście skonfigurowany. To powoduje brak połączenia lub połączenie z zupełnie inną usługą. Podobnie adres „127.0.0.1:70” jest poprawną kombinacją hosta lokalnego i właściwego portu, ale przykład „127.0.0.1:70” w zadaniu jest właśnie tą właściwą odpowiedzią, a nie jej modyfikacją z innym portem. Z kolei „192.168.0.1:3306” to już zupełnie inna bajka: adres z puli prywatnej sieci LAN i port 3306, który standardowo jest używany przez serwer MySQL, a nie przez serwer WWW Apache. Taki adres może wskazywać na bazę danych, do której łączy się aplikacja, ale nie jest to adres, pod który użytkownik wchodzi w przeglądarce, żeby zobaczyć stronę. Typowy błąd myślowy polega tutaj na mieszaniu pojęć: katalogu dokumentów, portu HTTP, portu MySQL oraz lokalnego adresu IP. Dobra praktyka jest taka, żeby zawsze patrzeć w panelu XAMPP konkretnie na kolumnę „Port(s)” przy module Apache i na tej podstawie budować URL, np. http://127.0.0.1:port lub http://localhost:port. Dzięki temu unikasz zgadywania i szybko wychwytujesz, czy problem leży w złym porcie, czy gdzie indziej.

Niepoprawna odpowiedź. Pozostałe pojęcia to mniejsze elementy. Wiersz (krotka) to pojedynczy egzemplarz encji, a nie cała encja. Kolumna i atrybut opisują pojedynczą cechę. Całej encji odpowiada tabela.

Niepoprawna odpowiedź. Tagi inteligentne są narzędziem umożliwiającym szybki dostęp do dodatkowych funkcji lub opcji związanych z danymi w polu. Nie mają jednak zdolności do ograniczania samej zawartości pola w kontekście dozwolonych znaków. Ich rola jest raczej wspomagająca użytkownika poprzez dodawanie kontekstowych opcji, ale nie dotyczą bezpośrednio walidacji danych. Wartość domyślna to z kolei predefiniowana wartość, jaką pole przyjmuje w momencie tworzenia nowego rekordu, jednak nie wpływa na to, jakie dane użytkownik może wprowadzić. Jest użyteczna do ułatwienia tworzenia danych, ale nie służy do ograniczania formatu wprowadzanych danych. Chociaż reguła sprawdzania poprawności może być stosowana do określania, jakie dane są uznawane za poprawne, jej główną rolą jest weryfikacja już wprowadzonych danych, a nie ich formatowanie w trakcie wprowadzania. Reguły te mogą informować o błędach po wprowadzeniu danych, lecz nie zapobiegają samemu wprowadzaniu błędnych danych. Wiele osób może mylnie sądzić, że reguła sprawdzania poprawności i maska wprowadzania pełnią podobne funkcje, jednak maska działa na poziomie interfejsu wprowadzania, wymuszając określony format w czasie rzeczywistym, podczas gdy reguła działa retrospektywnie. Zrozumienie tych różnic pozwala na odpowiednie zastosowanie tych narzędzi w projektowaniu baz danych, co skutkuje lepszym zarządzaniem jakością danych oraz zwiększeniem intuicyjności interfejsu użytkownika. Stosowanie masek wprowadzania jest szczególnie korzystne w kontekście aplikacji z dużą ilością danych liczbowych, gdzie precyzja jest kluczowa, a reguły poprawności lepiej sprawdzają się w kontekście logicznych zależności pomiędzy polami danych. To rozróżnienie jest kluczowe dla osiągnięcia wysokiej jakości danych i łatwej obsługi w systemach informatycznych.

config.inc.php

php.ini

my.ini

httpd.conf

Niepoprawna odpowiedź. Pozostałe pliki konfigurują inne oprogramowanie. my.ini to plik ustawień serwera bazodanowego MySQL (w systemach Windows), niezwiązany z PHP. httpd.conf to główna konfiguracja serwera WWW Apache - steruje samym serwerem, a nie interpreterem PHP. config.inc.php to plik konfiguracyjny konkretnej aplikacji napisanej w PHP (np. phpMyAdmin), a nie globalnych ustawień języka. Parametry PHP dla całego serwera ustawia php.ini, dlatego ta odpowiedź jest poprawna.

Niepoprawna odpowiedź. Pozostałe odpowiedzi opisują inne czynności związane z domeną. Zakup (rejestracja) domeny to nabycie prawa do nazwy w danym rejestrze - pierwszy krok, ale jeszcze nie parkowanie. Dodanie rekordu CNAME to konkretna operacja na DNS (alias jednej nazwy na drugą), a nie całościowe skonfigurowanie domeny. Zmiana właściciela (cesja) to przeniesienie praw do domeny na inny podmiot. Parkowanie polega na ustawieniu strefy DNS i wskazaniu serwerów nazw, dlatego ta odpowiedź jest poprawna.