W diagramie ER powiązanie między dwoma zbiorami encji nazywamy

Poprawna odpowiedź to „związek”, bo w diagramie ER (Entity-Relationship) właśnie tak nazywamy powiązanie między dwoma zbiorami encji. Mamy encje, czyli zbiory obiektów z rzeczywistości, na przykład „Klient” i „Zamówienie”, a pomiędzy nimi rysujemy relację: „Klient składa Zamówienie”. Ta linia, często z nazwą i krotnością (1:1, 1:N, N:M), to właśnie związek. W notacji Chen’a czy notacji Crow’s Foot zawsze chodzi o to samo: formalne opisanie, jak dane z jednego zbioru encji są powiązane z danymi z innego zbioru. W praktyce projektowania baz danych związek w diagramie ER prawie zawsze przekłada się na relację w modelu relacyjnym: albo na klucz obcy (np. tabela zamówienia ma kolumnę klient_id), albo na dodatkową tabelę asocjacyjną przy relacjach wiele‑do‑wielu (np. tabela produkt_zamówienie). Moim zdaniem ważne jest, żeby od początku myśleć o związku nie tylko jako o kresce na diagramie, ale jako o czymś, co później będzie miało konkretne odwzorowanie w SQL, w kluczach obcych, indeksach i ograniczeniach integralności. Z punktu widzenia dobrych praktyk branżowych, poprawne modelowanie związków to podstawa: pozwala zadbać o integralność referencyjną, unikać duplikacji danych i poprawnie odzwierciedlić reguły biznesowe. Na przykład relacja 1:N między Klientem a Zamówieniem jasno mówi, że jedno zamówienie należy do dokładnie jednego klienta, ale klient może mieć wiele zamówień. Dzięki temu, gdy później piszesz kwerendy SQL, dokładnie wiesz, jak łączyć tabele za pomocą JOIN i które klucze obce są obowiązkowe. W praktyce w firmach, które poważnie podchodzą do projektowania baz, diagram ER z dobrze opisanymi związkami jest normalnym elementem dokumentacji technicznej i ułatwia współpracę między programistami, analitykami i administratorami baz danych.