Encja (ang. entity) to obiekt lub pojęcie ze świata rzeczywistego, które chcesz reprezentować i przechowywać w modelu danych — na przykład klient, zamówienie, produkt albo faktura. To nie jest pojedynczy wiersz w bazie, tylko cały typ rzeczy: encja „Klient” opisuje wszystkich klientów, a konkretny Jan Kowalski to już jej instancja (egzemplarz). W praktyce jednej encji najczęściej odpowiada jedna tabela w relacyjnej bazie danych, a jej cechy (imię, e-mail, data rejestracji) to atrybuty, które stają się kolumnami.
Encja żyje przede wszystkim na etapie projektowania, w modelu konceptualnym i diagramie ERD (Entity-Relationship Diagram). Najpierw wypisujesz, jakie obiekty istnieją w Twojej domenie i jak się ze sobą łączą — klient składa zamówienia, zamówienie zawiera produkty. Dopiero potem ten model tłumaczysz na fizyczne tabele, klucze główne (PK) i klucze obce (FK). Dzięki temu projektujesz strukturę danych, zanim wklepiesz pierwszą komendę CREATE TABLE, i unikasz sytuacji, w której schemat rośnie chaotycznie pod presją bieżących potrzeb.
Przykład z praktyki
Załóżmy sklep internetowy. Wyłapujesz encje: Klient, Zamówienie, Produkt. Każda dostaje swoją tabelę, a relacje pilnują spójności kluczami obcymi:
CREATE TABLE klienci (id INT PRIMARY KEY, email VARCHAR(255), utworzono TIMESTAMP);CREATE TABLE zamowienia (id INT PRIMARY KEY, klient_id INT REFERENCES klienci(id), kwota DECIMAL(10,2));
W świecie ORM (np. Hibernate w Javie czy Doctrine w PHP) ta sama idea wraca jako klasa oznaczona adnotacją @Entity — obiekt w kodzie mapowany na wiersz w tabeli. Piszesz Klient jako klasę, a framework załatwia tłumaczenie na SQL.
Na co uważać
Najczęstszy mit: „encja zawsze równa się jedna tabela”. Zwykle tak, ale nie zawsze. Relacja wiele-do-wielu (klient i ulubione produkty) wymaga dodatkowej tabeli łączącej, która nie reprezentuje żadnego „obiektu z życia”. Z drugiej strony dziedziczenie encji bywa upychane do jednej tabeli. Drugi błąd to mylenie encji (typu) z jej instancją (konkretnym rekordem) — to dwa różne poziomy. I nie pakuj wszystkiego do jednej encji-potwora „Dane”: jeśli atrybuty opisują różne byty, rozdziel je, bo inaczej normalizacja zemści się przy pierwszym UPDATE.
Pojęcia powiązane: atrybut, relacja, encja słaba (weak entity), klucz główny i obcy, model ERD, normalizacja, krotka, schemat bazy danych oraz ORM.