Jakie jest zastosowanie w kodzie relacji między tabelami w SQLu?

Wie ktoś może jakie jest zastosowanie w kodzie relacje między tabelami w sqlu?

przecież baza funkcjonuje tak samo i bez relacji:p

a chyba nie chodzi tylko o wizualizacje na kartce wydrukowanego papieru ze schematem bazy danej?

wiadomo jest że można dodać pewne funkcje tej relacji np ON DELETE CASCADE,
ale nie każdy chce usuwać fizycznie dane z bazy.

Wiec moje pytanie jakie jest zastosowanie relacji między tabelami ? :)

Dla utrzymania spójności bazy.

Idąc za ciosem, co to dokładnie znaczy? Bez relacji nie utrzymam spójności bazy?

A do spójności bazy danych nie służą transakcje albo klucze ?

Ja bym powiedział, że dzięki relacjom możemy pozbyć się redundancji danych (postacie normalne).

poniatowski napisał(a):

Bez relacji nie utrzymam spójności bazy?

Jeśli wszystkie operacje na danych w bazie będą zgodne z modelem na Twojej kartce - wtedy faktycznie tworzenie kluczy obcych nie jest potrzebne. Jakakolwiek walidacja zaczyna być potrzebna dopiero wtedy, kiedy ktoś spróbuje podać błędne dane.

@mszewicz
Czyli twierdzisz, że bez relacji będę miał nadmiarowość w tabelach? Z tego co wiem, to relacje też wspomagają zapytania (jak indexy) tzn, że przy ich zastosowaniu dane są szybciej wyszukiwane, ale dalej to coś za mało. Tyle się mówi o relacjach etc a ja czuje niedosyt :)

Konkretny przykład relacji z wykorzystaniem postaci normalnej:
Mamy 100 pracowników, przy czym pracują oni w 10 różnych firmach. Bez wykorzystania relacji można by utworzyć tabelę postaci:
pracownik_id, pracownik_imie, ..., pracownik_firma
W takim przypadku występuje nadmiarowość danych. Każda dziesiątka pracowników ma wpisaną tą samą firmę.

Korzystając z relacji możemy znormalizować dane do dwóch tabel:
**FIRMY: firma_id, firma_nazwa, ...
PRACOWNICY: pracownik_id, firma_id, pracownik_imie, ...
**
Nadmiarowość danych znika, ponadto dzięki relacjom można łatwo znaleźć wszystkich pracowników danej firmy.

Możemy pójść o krok dalej i założyć, że pracownik może pracować w większej ilości firm. Należałoby w takim przypadku dodać trzecią tabelę opisującą relację pomiędzy pracownikami, a firmami:
PRACOWNICY_FIRMY: pracownik_id, firma_id
Równocześnie można zrezygnować z pola firma_id w tabeli pracowników.

Efekt - mamy dwustronną relację (wiele do wielu), brak szans na nadmiarowość danych, zerowy poziom skomplikowania struktury tabel.

Gdyby z relacji nie korzystać wyobraź sobie jak szeroka (ilość kolumn) musiałaby być tabela firm, żeby pomieścić wszystkich pracowników.
Ponadto byłby problem ze zrywaniem takich relacji - które pole wyzerować w tabeli firm, żeby usunąć danego pracownika?

Mam nadzieję, że rozjaśniłem trochę temat.

1. Relacyjność bazy danych nie ma nic wspólnego z powiązaniami między tabelami! Relacja to podzbiór iloczynu kartezjańskiego (czyli pewien podzbiór wszystkich możliwych wartości które mógłbyś mieć w tabeli, przy uwzględnieniu ograniczeń). Czemu stosuje się tutaj taką matematyczną definicje? Dlatego, że silniki bazodanowe stosują matematyczne operacje w celu optymalizacji zapytań do bazy. Takie cudo nazywa sie "optymalizatorem kosztowym" i sprawdza jak najlepiej wykonać dane zapytanie. Potrafi to zrobić właśnie dlatego że baza danych stosuje pewien matematyczny formalizm.
   Po co w ogóle bawić się w takie optymalizowanie zapytania? Bo na przykład operacja JOIN w bazie może być wykonana za pomocą jednego z ~20 algorytmów z których każdy sprawdza się w innych warunkach. Poza tym w przypadku JOINa kluczowa bywa kolejność złączania tabel.
2. Powiązania są potrzebne żeby uzyskać 3 formę normalną dla bazy (czyli m.in. brak redundancji i brak anomalii przy usuwaniu/aktualizacji danych) a także żeby utrzymać spójność.

1. Wątek przenoszę, bo wzięło w nim udział ileś osób, i dopiero @Shalom zwrócił uwagę, że nikt nie wie o czym pisze.
2. Jeszcze raz, tym razem głośniej: z punktu widzenia bazy danych, to tabela jest relacją.
3. Jeśli chodzi o materiały do nauki o bazach danych po polsku, to dobrze jest zacząć tutaj: http://osilek.mimuw.edu.pl/index.php?title=Bazy_danych Wykład 2 powinien wyjaśnić wszystko w temacie tego wątku.