W relacyjnym modelu baz danych atrybutem relacji (tabeli) nazywa się
A. wiersz tabeli.
B. całą tabelę wraz z danymi.
C. kolumnę tabeli.
D. powiązanie dwóch tabel.
Atrybut relacji w modelu relacyjnym to kolumna tabeli, czyli nazwane pole opisujące jedną cechę przechowywanych danych. Jeśli mamy tabelę Uczniowie, to atrybutami mogą być na przykład id_ucznia, imie, nazwisko, data_urodzenia albo klasa. Każdy atrybut ma zwykle określony typ danych, np. INT, VARCHAR, DATE, DECIMAL, oraz może mieć dodatkowe ograniczenia, takie jak NOT NULL, UNIQUE czy DEFAULT. To bardzo praktyczne, bo dzięki temu baza danych pilnuje poprawności informacji i łatwiej pisać zapytania SQL. Z mojego doświadczenia warto zapamiętać prostą zasadę: kolumna opisuje, jakie dane przechowujemy, a wiersz przechowuje konkretny zestaw wartości. W dobrym projektowaniu baz danych nazwy atrybutów powinny być jednoznaczne, spójne i techniczne, bez przypadkowych skrótów. To pomaga później przy tworzeniu formularzy, raportów, relacji między tabelami i zapytań SELECT, INSERT czy UPDATE.
W relacyjnym modelu baz danych łatwo pomylić kilka pojęć, bo w języku potocznym mówi się czasem tabela, rekord, relacja i powiązanie prawie zamiennie, ale technicznie to są różne rzeczy. Atrybut nie oznacza wiersza tabeli. Wiersz to pojedynczy rekord, nazywany też krotką, czyli konkretny zestaw wartości dla wszystkich kolumn. Na przykład jeden uczeń w dzienniku elektronicznym to jeden rekord, a jego imię, nazwisko i numer w dzienniku znajdują się w osobnych atrybutach. Atrybutem jest więc opis pola, a nie pojedynczy obiekt zapisany w tabeli.
Nie jest nim też powiązanie dwóch tabel. Takie powiązanie buduje się zwykle przez klucz główny i klucz obcy, na przykład tabela Zamowienia może wskazywać klienta z tabeli Klienci. To jest relacja między danymi w sensie projektowania bazy, ale nie atrybut relacji w ścisłym znaczeniu modelu relacyjnego. Tu często pojawia się błąd myślowy, bo słowo relacja kojarzy się z łączeniem tabel, a w teorii baz danych relacja oznacza strukturę podobną do tabeli.
Cała tabela wraz z danymi także nie jest atrybutem. Tabela, czyli relacja, składa się z wielu atrybutów oraz wielu rekordów. Moim zdaniem najlepiej widzieć to tak: tabela to cały arkusz, kolumny to atrybuty, a wiersze to konkretne dane. Dobre rozróżnianie tych pojęć jest ważne przy normalizacji, projektowaniu schematu bazy i pisaniu poprawnych zapytań SQL, bo inaczej łatwo zrobić bałagan w strukturze danych.
Nie jest nim też powiązanie dwóch tabel. Takie powiązanie buduje się zwykle przez klucz główny i klucz obcy, na przykład tabela Zamowienia może wskazywać klienta z tabeli Klienci. To jest relacja między danymi w sensie projektowania bazy, ale nie atrybut relacji w ścisłym znaczeniu modelu relacyjnego. Tu często pojawia się błąd myślowy, bo słowo relacja kojarzy się z łączeniem tabel, a w teorii baz danych relacja oznacza strukturę podobną do tabeli.
Cała tabela wraz z danymi także nie jest atrybutem. Tabela, czyli relacja, składa się z wielu atrybutów oraz wielu rekordów. Moim zdaniem najlepiej widzieć to tak: tabela to cały arkusz, kolumny to atrybuty, a wiersze to konkretne dane. Dobre rozróżnianie tych pojęć jest ważne przy normalizacji, projektowaniu schematu bazy i pisaniu poprawnych zapytań SQL, bo inaczej łatwo zrobić bałagan w strukturze danych.