SQL Interview Prep · Lekcja

Modelowanie ER i krotność relacji

Przekładanie wymagań na encje, relacje i tabele pośredniczące.

Modelowanie ER i krotność relacji to bezpłatna lekcja SQL Interview Prep na CoddyKit. To lekcja 2 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej SQL Interview Prep, a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs SQL Interview Prep zawiera 4 lekcji w sumie.

Dlaczego modelowanie ER pojawia się na rozmowach kwalifikacyjnych

Po normalizacji osoby prowadzące rozmowę sprawdzają, czy potrafią Państwo przełożyć wymagania na schemat. Zadanie jest zwykle otwarte: „Zaprojektuj bazę danych dla aplikacji do współdzielenia przejazdów” albo „Zamodeluj system biblioteczny”.

Jest to ćwiczenie z modelowania encja–związek (ER). Ocenia się sposób identyfikowania encji, atrybutów i relacji między nimi, w tym kardynalności.

Chodzi o przełożenie angielskich rzeczowników i czasowników na tabele oraz klucze obce.

Encje, atrybuty i relacje

Każdy model ER składa się z trzech podstawowych elementów:

Encja: obiekt, o którym przechowuje się dane (Klient, Zamówienie, Produkt). Zwykle staje się tabelą.
Atrybut: właściwość encji (name, price, created_at). Zwykle staje się kolumną.
Relacja: sposób, w jaki encje są ze sobą powiązane (Klient składa Zamówienie). Jest implementowana za pomocą kluczy obcych lub tabel pośrednich.

Wskazówka wynikająca z treści zadania: rzeczowniki stają się encjami lub atrybutami, a czasowniki stają się relacjami.

Kardynalność: kluczowe pojęcie

Kardynalność opisuje, ile wystąpień jednej encji może być powiązanych z inną encją. Wyróżniamy trzy rodzaje:

Jeden do jednego (1:1): jeden wiersz po tej stronie odpowiada co najwyżej jednemu wierszowi po drugiej stronie.
Jeden do wielu (1:N): jeden wiersz po tej stronie odpowiada wielu wierszom po drugiej stronie (jest to najczęstszy przypadek).
Wiele do wielu (M:N): wiele wierszy po jednej stronie odpowiada wielu wierszom po drugiej stronie.

Poprawne określenie kardynalności decyduje o tym, gdzie umieścić klucze obce i czy potrzebna jest tabela pośrednia.

Implementacja relacji jeden do wielu

Relację jeden do wielu implementuje się, umieszczając klucz obcy po stronie „wiele”. Klient ma wiele zamówień, więc każdy wiersz zamówienia zawiera customer_id.

Podczas rozmowy należy zawsze jasno określić kierunek: „Jeden klient ma wiele zamówień, więc klucz obcy znajduje się w tabeli orders.”

CREATE TABLE customers (
  customer_id INT PRIMARY KEY,
  name        VARCHAR(100)
);

CREATE TABLE orders (
  order_id    INT PRIMARY KEY,
  customer_id INT NOT NULL,
  order_date  DATE,
  FOREIGN KEY (customer_id) REFERENCES customers(customer_id)
);

Implementacja relacji wiele do wielu

Relacyjna baza danych nie może przechowywać relacji M:N bezpośrednio. Odpowiedzią oczekiwaną przez osoby prowadzące rozmowę jest tabela pośrednia (nazywana także tabelą łącznikową, powiązań lub asocjacyjną).

Studenci zapisują się na wiele kursów, a każdy kurs ma wielu studentów. Należy utworzyć tabelę enrollments, której klucz składa się z obu kluczy obcych. W ten sposób relacja M:N zostaje rozbita na dwie relacje 1:N.

CREATE TABLE students (
  student_id INT PRIMARY KEY,
  name       VARCHAR(100)
);

CREATE TABLE courses (
  course_id  INT PRIMARY KEY,
  title      VARCHAR(100)
);

CREATE TABLE enrollments (
  student_id INT,
  course_id  INT,
  enrolled_at DATE,
  PRIMARY KEY (student_id, course_id),
  FOREIGN KEY (student_id) REFERENCES students(student_id),
  FOREIGN KEY (course_id)  REFERENCES courses(course_id)
);

Tabela pośrednia może przechowywać dane

Częste pytanie uzupełniające brzmi: „Gdzie należy przechowywać ocenę, którą student otrzymał z kursu?”

Ocena dotyczy relacji, a nie samego studenta ani samego kursu. Dlatego należy umieścić ją w tabeli pośredniej. Właśnie tę zależność sprawdzają osoby prowadzące rozmowę: atrybuty relacji M:N znajdują się w tabeli łącznikowej.

Przykłady: data zapisania, ocena, ilość na pozycji zamówienia, rola członka projektu.

ALTER TABLE enrollments
  ADD COLUMN grade CHAR(2);
-- grade describes THIS student in THIS course,
-- so it belongs on the junction table

Implementacja relacji jeden do jednego

Relacja 1:1 występuje rzadziej. Implementuje się ją, nadając tabeli zależnej klucz obcy, który jest również kluczem unikalnym (często samym kluczem głównym).

Przykładem są user i user_profile z rozszerzonymi, opcjonalnymi informacjami. Ustanowienie user_id kluczem głównym tabeli profilu wymusza istnienie najwyżej jednego profilu dla użytkownika.

CREATE TABLE users (
  user_id INT PRIMARY KEY,
  email   VARCHAR(255)
);

CREATE TABLE user_profiles (
  user_id INT PRIMARY KEY,           -- 1:1 enforced here
  bio     TEXT,
  avatar_url VARCHAR(255),
  FOREIGN KEY (user_id) REFERENCES users(user_id)
);

Opcjonalność i uczestnictwo

Kardynalność ma drugi wymiar, na który osoby prowadzące rozmowę zwracają uwagę: opcjonalność (nazywana także uczestnictwem).

Obowiązkowe: każde zamówienie musi mieć klienta, więc customer_id ma wartość NOT NULL.
Opcjonalne: użytkownik może mieć profil, ale nie musi, więc relacja może nie występować.

Obowiązkowe uczestnictwo wyraża się za pomocą NOT NULL na kluczu obcym. Wspomnienie o możliwości wystąpienia wartości NULL pokazuje, że uwzględniają Państwo rzeczywiste ograniczenia, a nie tylko kształt schematu.

Relacje odwołujące się do samej encji

Niektóre relacje wskazują encję samą na siebie. Pracownik ma przełożonego, który również jest pracownikiem; kategoria ma kategorię nadrzędną.

Modeluje się to za pomocą klucza obcego odwołującego się do tej samej tabeli. Osoby prowadzące rozmowę oczekują tego rozwiązania w przypadku schematów organizacyjnych i struktur drzewiastych; naturalnie łączy się ono z samozłączeniami i rekurencyjnymi CTE.

CREATE TABLE employees (
  employee_id INT PRIMARY KEY,
  name        VARCHAR(100),
  manager_id  INT NULL,
  FOREIGN KEY (manager_id) REFERENCES employees(employee_id)
);
-- manager_id NULL = top of the hierarchy (e.g. CEO)

Miniaturowy przykład modelowania

Przećwiczmy metodę zamiany czasowników na relacje. Zadanie: „Klienci składają zamówienia; każde zamówienie zawiera wiele produktów; produkty należą do dostawców.”

Klient 1:N Zamówienie (klucz obcy customer_id w tabeli orders).
Zamówienie M:N Produkt -> tabela pośrednia order_items (z ilością).
Dostawca 1:N Produkt (klucz obcy supplier_id w tabeli products).

Należy podać każdą kardynalność i wskazać, gdzie umieszczany jest klucz. Takie objaśnienie jest kluczem do sukcesu podczas rozmowy.

Pytania doprecyzowujące, które warto zadać

Osoby prowadzące rozmowę doceniają kandydatów, którzy zadają pytania przed rozpoczęciem projektowania. Dobre pytania doprecyzowujące:

„Czy produkt może należeć do więcej niż jednego dostawcy?” (decyduje o wyborze 1:N lub M:N).
„Czy każde zamówienie musi zawierać co najmniej jedną pozycję?” (uczestnictwo).
„Czy potrzebujemy historii, czy tylko bieżącego stanu?” (wpływa na dodatkowe tabele).

Odpowiedzi zmieniają kardynalność i liczbę tabel, dlatego nigdy nie należy zakładać z góry żadnego rozwiązania. Zadawanie pytań świadczy o dojrzałości zawodowej.

Szybki test

Modelują Państwo studentów i kursy, przy czym każdy student może wybrać wiele kursów, a każdy kurs ma wielu studentów.

Podsumowanie: modelowanie ER i kardynalność

Mogą już Państwo samodzielnie rozwiązywać otwarte pytania dotyczące projektowania schematu:

rzeczowniki zamieniać na encje/atrybuty, a czasowniki na relacje.
1:N: klucz obcy po stronie „wiele”.
M:N: tabela pośrednia przechowująca oba klucze obce oraz ewentualne atrybuty relacji.
1:1: wspólny/unikatowy klucz w tabeli zależnej.
Za pomocą NOT NULL należy wyrażać obowiązkowy udział, a do modelowania hierarchii używać kluczy obcych odwołujących się do tej samej tabeli.
Przed ostatecznym ustaleniem kardynalności należy zadawać pytania doprecyzowujące.

Często zadawane pytania

Czy lekcja „Modelowanie ER i krotność relacji” jest bezpłatna?

Tak — pełny tekst „Modelowanie ER i krotność relacji” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu SQL Interview Prep, przejdź na CoddyKit PRO. Kurs SQL Interview Prep zawiera 4 lekcji w sumie.

Co nauczysz się w „Modelowanie ER i krotność relacji”?

Przekładanie wymagań na encje, relacje i tabele pośredniczące. Ćwiczysz SQL Interview Prep z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć SQL Interview Prep?

Nie wymagamy żadnego doświadczenia. SQL Interview Prep w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 2 z 4.

Ile czasu zajmuje lekcja „Modelowanie ER i krotność relacji”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji SQL Interview Prep?

Tak. Każda lekcja SQL Interview Prep zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

Normalizacja do postaci 3NF
Modelowanie ER i krotność relacji
Schemat gwiazdy i projektowanie hurtowni danych
Pełny zestaw zadań do próbnej rozmowy rekrutacyjnej

← Powrót do SQL Interview Prep