Kwalifikacja: INF.03 - Tworzenie i administrowanie stronami i aplikacjami internetowymi oraz bazami danych

W tym pytaniu łatwo pomylić kilka podstawowych pojęć z teorii baz danych, szczególnie jeśli ktoś kojarzy je tylko z praktyki SQL, a nie z modelu ER. W modelu encja‑związek interesuje nas opis świata rzeczywistego na wyższym poziomie abstrakcji. Zbiory encji to na przykład Pracownicy, Projekty, Produkty, a powiązania między nimi opisujemy właśnie jako związki. Natomiast „krotka” to pojęcie z modelu relacyjnego, czyli z poziomu tabel. Krotka to po prostu pojedynczy wiersz w tabeli, jeden rekord zawierający konkretne wartości atrybutów. Ktoś może intuicyjnie pomyśleć, że skoro wiersz „łączy” wartości atrybutów, to jest jakimś powiązaniem, ale to zupełnie inny poziom opisu: krotka nie jest relacją między zbiorami encji, tylko instancją danych w jednym zbiorze. „Dziedzina” z kolei to zbiór dopuszczalnych wartości dla atrybutu, na przykład dziedzina dla kolumny wiek może być liczbą całkowitą z określonego przedziału, a dla kolumny email – tekstem spełniającym pewien wzorzec. Dziedzina opisuje typ i zakres danych, ale nie opisuje tego, jak tabele czy encje są ze sobą powiązane. Częsty błąd polega na wrzucaniu do jednego worka wszystkich pojęć typu: tabela, rekord, pole, domena, relacja, atrybut, związek – a każde z nich ma dość konkretną definicję. „Atrybut” to po prostu cecha encji, coś w rodzaju kolumny w tabeli: imię, nazwisko, data_urodzenia, cena, ilość. Atrybut opisuje właściwości pojedynczego obiektu, nie tworzy sam z siebie powiązania między zbiorami encji. Oczywiście atrybut może być kluczem obcym, czyli w modelu relacyjnym służyć do realizacji relacji, ale nadal jest to atrybut, a nie sam związek w sensie modelu ER. Z mojego doświadczenia wynika, że największy problem pojawia się, gdy miesza się poziom konceptualny (ER) z poziomem fizycznym (tabele SQL). Na diagramie ER powiązanie między dwoma zbiorami encji nazywamy właśnie związkiem i to ono określa typ relacji (1:1, 1:N, N:M), opcjonalność oraz reguły biznesowe. Dopiero później to powiązanie odwzorowujemy w postaci kluczy obcych, tabel pośredniczących i ograniczeń w konkretnej bazie danych. Dlatego poprawne rozróżnienie tych pojęć jest kluczowe przy profesjonalnym projektowaniu baz danych i zgodne z klasycznymi standardami modelowania danych, które stosuje się w poważnych projektach komercyjnych.