Encja, atrybut, krotka, tabela

1. Od świata rzeczywistego do tabeli

Projekt bazy to trzy warstwy — nie skaczesz od razu do CREATE TABLE.

2. Encja, atrybut, krotka — definicje

Te trzy pojęcia są z poziomu koncepcyjnego (projektu). Zanim zobaczysz tabelę w phpMyAdmin, musisz umieć je wypowiedzieć własnymi słowami i nie pomylić kategorii z jednym wpisem.

Słowo „encja” bywa używane na dwa sposoby. Na kartkówce i na INF.03 rozróżniaj je świadomie:

Żeby coś uznać za encję (a nie za luźną cechę), sprawdź trzy pytania:

1. Czy da się wskazać wiele takich obiektów i odróżnić jeden od drugiego?
2. Czy obiekt ma własne cechy, które chcemy zapisać?
3. Czy jest ważny sam w sobie, a nie tylko jako wartość przy kimś innym? (PESEL to atrybut ucznia, nie encja.)

Na tym etapie zapamiętaj jeszcze trzy ograniczenia atrybutu:

• Należy do encji, nie jest encją. Nazwisko nie istnieje samodzielnie w modelu — istnieje przy uczniu. Gdy cecha sama zaczyna mieć historię i wiele wartości (np. kolejne numery telefonu), często wydzielasz osobną encję.
• Wartość powinna być atomowa — jedna informacja w jednej komórce, nie lista „Laptop, myszka, torba”.
• Ten sam atrybut, ta sama dziedzina dla wszystkich krotek tabeli. Nie trzymasz w kolumnie RokWydania raz roku, a raz nazwiska autora.

Atrybuty bywają opisowe (tytuł, kolor) albo identyfikujące (ISBN, PESEL, numer faktury) — te drugie pozwalają odróżnić egzemplarze. Klucz główny poznasz wkrótce; dziś wystarczy, że wiesz, po co taka cecha jest.

Egzemplarz to obiekt w świecie. Krotka to jego zapis w modelu: same wartości, ułożone według atrybutów typu. Bez kompletu atrybutów nie ma krotki — jest tylko luźna cecha.

• Dwie identyczne krotki w relacji są zabronione (stąd później klucz główny).
• Kolejność krotek w tabeli nie zmienia znaczenia danych — to zbiór, nie lista „od góry”.
• Kolejność atrybutów też nie jest istotna logicznie: krotkę rozpoznajesz po nazwach cech, nie po „trzeciej kolumnie”.

3. Słownik: poziom koncepcyjny vs fizyczny

Typ encji ≠ egzemplarz

Dopasuj pojęcia

Sprawdź, czy mapowanie siedzi. Potem wróć do tabeli, jeśli coś zgrzyta.

4. Dziedzina atrybutu i typy danych

Dziedzina to zbiór wartości, które atrybut ma prawo przyjąć. W MySQL przybliżasz ją typem i ograniczeniami. Na razie bez składni CHECK — ważne, żebyś umiał dziedzinę nazwać.

5. Reguły poprawnej tabeli relacyjnej

Model E.F. Codda (1970): tabela jest relacją, gdy spełnia kilka zasad. Na ocenę 6 możesz wspomnieć zbiór i iloczyn kartezjański dziedzin — bez wykładu akademickiego.

1. Atomowość. W komórce jedna wartość, nie lista. Źle: Jan Kowalski, tel. 500-600-700, 600-700-800. Dobrze: osobne kolumny imię / nazwisko; telefony w osobnej tabeli (wielowartościowość).
2. Unikalność krotek. Żadnych identycznych wierszy. Do tego służy klucz główny — poznasz go wkrótce, ale zasadę znasz już dziś.
3. Kolejność wierszy nie ma znaczenia. Relacja to zbiór, nie „wiersz 3 od góry”. Sortowanie robisz zapytaniem (ORDER BY), nie układem na dysku.
4. Kolejność kolumn nie ma znaczenia. Kolumnę wołasz po nazwie, nie po numerze pozycji.

6. Studium przypadku: encja KSIĄŻKA

Katalog biblioteczny. Typ encji KSIAZKA staje się tabelą.

• ISBN — kandydat na identyfikator (dziedzina: 13 cyfr).
• Tytul — opisowy, nieunikalny (dwa wydania mogą mieć ten sam tytuł).
• RokWydania — np. 1500–rok bieżący, nie „dwa tysiące dziewiętnaście” jako tekst.
• CenaNetto — pieniądze: nieujemne, dwa miejsca.

7. Przykładowa baza do importu

Tę samą strukturę masz w pliku SQL. Importujesz go w phpMyAdmin i na lekcji wskazujesz palcem: tabela = typ encji, kolumna = atrybut, wiersz = krotka.

Plik: sql/bd_rozdzial03.sql (prawy przycisk → zapisz, jeśli przeglądarka otworzy go jako tekst).

W bazie są trzy tabele:

SELECT * FROM ksiazki;
SELECT isbn, tytul FROM ksiazki;
SELECT * FROM czytelnicy;

Ćwiczenia do samodzielnego wykonania

Sprawdź się

Wymagania na ocenę

Rozdział 3 otwiera dział 2 (pojęcia i model relacyjny). Dziś oceniamy opanowanie czterech pojęć i mapowania na tabelę.

Lista „już umiem”