Po angielsku możemy porozmawiać o relacji między, powiedzmy, Bobem i Timem. Być może są kuzynami. Pojęcie „relacja” w tym kontekście ma dla mnie sens.

W kontekście relacyjnych baz danych rozumiem, do czego odnosi się ten termin, ale nie rozumiem, dlaczego jest używany. Wydaje mi się, że zrozumienie, dlaczego jest używany, pomoże mi lepiej zrozumieć pole, dlatego chciałbym zrozumieć, dlaczego jest używany.

• Dlaczego na przykład Osoba jest uważana za „relację”? W języku angielskim relacja to rzeczownik opisujący, w jaki sposób powiązane są dwa byty. Nie odnosi się do samych bytów. W kontekście relacyjnych baz danych „relacja” odnosi się do samych podmiotów. Czemu?
• Rozumiem, że model relacyjny powstał po modelach hierarchicznych i sieciowych (np. Rodzic, sąsiad). Ale w tych modelach byty również mają ze sobą relacje. Dlaczego więc nazywać ten model modelem relacyjnym? Czy istnieje bardziej szczegółowe wyrażenie / termin? A może powinniśmy powiedzieć, że wszystkie trzy modele są modelami relacyjnymi, ale modele hierarchiczne i sieciowe to określone typy modeli relacyjnych?
• Co jeśli mamy samodzielne jednostki, które nie są ze sobą powiązane. Powiedz: osoba, drzwi i drzewo. Czy termin „relacja (al)” nadal obowiązuje?

(Być może powinno to być wiele pytań. Uznałem, że odpowiedzi są ze sobą ściśle powiązane - być może jest tylko jedna odpowiedź - więc doszedłem do wniosku, że ma sens, aby było to jedno pytanie. Jeśli się mylę, daj mi znać, a ja Zamiast tego utworzę osobne pytania).

Edycja: Ten diagram może być przydatny do wizualizacji, że relacja wiąże między sobą różne domeny:

Przede wszystkim bardzo polecam artykuł naukowy, w którym dr Edgar Frank Codd opublikował ogólne ramy relacji dla ogółu społeczeństwa w 1970 r., Tj . Relacyjny model danych dla dużych banków danych . Tam w sekcji 1.1 „Wprowadzenie” sam dr Codd stwierdza, że:

Artykuł dotyczy zastosowania teorii relacji elementarnych w systemach zapewniających wspólny dostęp do dużych banków sformatowanych danych.

---

_{© Association for Computing Machinery. Komunikat ACM , tom 13, wydanie 6 (str. 377-387), czerwiec 1970 r.}

Tak więc relacja terminów i (stąd) relacja pochodzą z tła matematycznego. Dr Codd - który, oprócz swoich kwalifikacji akademickich i badawczych, miał około 20 lat doświadczenia z pierwszej ręki w obliczeniach i przetwarzaniu informacji - przewidział ogromne zalety zastosowania tej relacji (oczywiście abstrakcyjnej konstrukcji) w dziedzinie administracji danymi .

Nie jestem matematykiem, ale w gruncie rzeczy relacja jest powiązaniem między zbiorami , zbiór jest zbiorem elementów ( ten zasób zewnętrzny podaje definicję relacji matematycznej, która może pomóc w zrozumieniu go z innej perspektywy). Podczas pracy z pomocą systemu zarządzania bazą danych SQL (zwięzłość DBMS) dobrze znanym przybliżeniem relacji jest tabela , w którym to przypadku zachodzi skojarzenie między typami jej kolumn . Oczywiście na platformach SQL, które oferują obsługę DOMAIN (np. Firebird i PostgreSQL ), powiązanie występuje międzydomeny ustalone dla kolumn danej tabeli; znaczące szczegóły znajdują się w poniższych sekcjach.

W związku z tym ponownie przytoczę dr Codda, który w sekcji 1.3 „Relacyjny pogląd na dane” twierdzi, że:

Termin relacja jest tu używany w jego przyjętym sensie matematycznym. Biorąc pod uwagę zbiory S ₁ , S ₂ , ⋯, S _n (niekoniecznie różne), R jest relacją na tych n zbiorach, jeśli jest to zbiór n- pary, z których każdy ma swój pierwszy element z S ₁ , jego drugi element od S ₂ i tak dalej. ¹ Będziemy odnosić się do S _j jako j -tego domenie z R . Jak zdefiniowano powyżej, mówi się, że R ma stopień n. Relacje stopnia 1 są często nazywane jednymi , stopień 2 dwójkowy , stopień 3 trójskładnikowy , a stopień n n-ary .

_{¹ Bardziej zwięźle, R jest podzbiorem iloczynu kartezjańskiego S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Association for Computing Machinery. Komunikat ACM , tom 13, wydanie 6 (str. 377-387), czerwiec 1970 r.}

I zgadzam się z innymi odpowiedziami, ponieważ bardzo istotne jest zwrócenie uwagi, że dr Codd dokonał pewnych zmian w relacji matematycznej, aby uzyskać jak najwięcej z tego w zakresie zarządzania danymi, i są one wyjaśnione w artykule, o którym mowa wcześniej i w całej jego obszernej bibliografii .

Relacja i związek

Warto wspomnieć o tym, że w kontaktach z tymi tematami mogą pojawić się zamieszanie z powodu podobieństw dotyczących codziennych (niematematycznych, nietechnicznych) definicji terminów relacja i relacja - które nie są moim ojczystym językiem angielskim jest szczególnie zrozumiałe—.

Widok podmiot-relacja oraz model relacyjny

Innym czynnikiem, który moim zdaniem może również powodować zamieszanie (i jest ściśle związany z technicznymi konotacjami dwóch przywołanych powyżej terminów) jest to, że podczas uczenia się projektowania baz danych student lub praktyka jest zazwyczaj najpierw wprowadzany do metodologii zaproponowanej przez Dr Peter Pin-Shan Chen w widoku danych relacji między bytem (opublikowanym w 1976 r.), Który sugeruje dwa różne narzędzia (tj. Byt i relację ) do nakreślenia schematu pojęciowego , a następnie dopiero po zdefiniowaniu tego schematu jest stabilny, uczeń lub praktykujący jest zaznajomiony z relacyjnymi terminami i instrumentami (np. relacją ) podczas deklarowanialogiczny układ odpowiedniej bazy danych. W koncepcyjnym układzie odniesienia związek zawiera konotacje, które są znacznie bliższe codziennemu sensowi tego słowa.

Być może ta okoliczność dodatkowo zwiększa kwestię relacji i relacji - ale sekwencja najpierw zdefiniowania schematu pojęciowego, a następnie zadeklarowania odpowiedniego projektu logicznego jest oczywiście całkiem odpowiednia, co szczegółowo omówię w poniższych sekcjach—.

Odpowiedzi na każde z twoich pytań

Uważam, że uwzględnienie tych trzech pytań jest naprawdę istotne, ponieważ stanowią szerszy kontekst dla tego postu, więc nie należy ich pomijać. W ten sposób, oprócz wyłącznie adresowania dlaczego terminy relacja i relacyjne są wykorzystywane (co z pewnością jest bardzo znaczący i jest tytuł tego postu, ale to nie cały post), powiedział subquestions może pomóc w rozumienia bardziej zakresu relacja i model relacyjny , gdy ktoś jest zaangażowany w projekt zarządzania cały informacyjnym (dość istotne, ponieważ ta strona o administracji bazami danych), a zatem działa na różnych poziomach abstrakcji. W ten sposób podzielę się z wami poniższymi szczegółami.

Pytanie nr 1

Dlaczego na przykład Osoba jest uważana za „relację”? W języku angielskim relacja to rzeczownik opisujący, w jaki sposób powiązane są dwa podmioty. Nie odnosi się do samych bytów. W kontekście relacyjnych baz danych „relacja” odnosi się do samych podmiotów. Czemu?

Poziom koncepcyjny

W danym środowisku biznesowym Osoba może być uważana za typ jednostki w zależności od tego, jak ludzie, którzy tam pracują (eksperci biznesowi i projektanci baz danych) ją konceptualizują . I tak, w tym środowisku biznesowym mogą istnieć różne właściwości będące przedmiotem zainteresowania w odniesieniu do typu jednostki Osoba , np. Imię , Data urodzenia , Płeć itp.

Ponadto typ jednostki Osoba może posiadać określone typy relacji (lub powiązania lub połączenia ) ze sobą lub innymi typami jednostek; np. Osoba może być powiązana z typem jednostki o nazwie UserProfile , który z kolei może mieć własne właściwości, na przykład nazwę użytkownika i hasło .

Ale (a) typy jednostek, (b) ich odpowiednie właściwości, (c) typy relacji między typami jednostek oraz (d) relacje między samymi właściwościami są pojęciami „należącymi” do konkretnego środowiska biznesowego, w którym się znajdują uznane za istotne. Są to urządzenia używane przez projektantów baz danych, którzy ściśle współpracują z ekspertami biznesowymi w celu zdefiniowania kontekstowego schematu koncepcyjnego na etapie projektowania.

Tak więc, na poziomie koncepcyjnym, zasadniczo pracujemy ze strukturą pomysłów, które powstają w segmencie zainteresowań świata rzeczywistego, tj. (1) prototypy rzeczy i (2) prototypy relacji między prototypami rzeczy , z którymi nie pracujemy (3) relacje - wykorzystanie tego ostatniego terminu w sensie relacyjnych ram danych -.

Poziom logiczny

Po tym, jak Osoba została precyzyjnie wyznaczona jako typ bytu na poziomie pojęciowym, a jeśli ktoś chce wdrożyć relacyjną bazę danych, która przekazuje znaczenie Osoby i wszystkie związane z nią pojęcia, to faktami dotyczącymi bytów tego typu można zarządzać na mocy relacji matematycznej na poziomie logicznym i skorzystaj z naukowych operacji, które można wykonać na tym abstrakcyjnym konstrukcie (tj. zdefiniować, ograniczyć i manipulować).

Tak, można nazwać określoną relację Osoby podczas definiowania logicznego układu bazy danych, ale to nie przekształca koncepcji Osoby w „prawdziwym świecie” w relację, podchodzi się do niej jako takiej ze względu na korzyści, które uzyskuje się przy zarządzaniu informacjami o tym, np. zastosowanie na nim operacji algebry relacyjnej w celu uzyskania nowych relacji (i dlatego uzyskuje się „nowe” informacje). Wymienione korzyści stają się bardziej widoczne, biorąc pod uwagę fakt, że byty określonego typu tworzą zestaw, a wartości pewnej właściwości również tworzą zestaw.

I tak, jak wspomniano w poprzednich akapitach i w innych odpowiedziach, jednym z najważniejszych aspektów relacji jest połączenie między jej domenami - które są zwykle używane do przedstawienia właściwości typów jednostek lub powiązań, które są częścią schemat koncepcyjny—. Powiedzmy na przykład, że zadeklarowaliśmy następującą (trójskładnikową) relację:

• Salary (PersonNumber, EffectiveDate, Amount)

… I załóżmy, że w danym środowisku biznesowym krotka - która (i) oznacza konkretną jednostkę , tj. Instancję typu jednostki z obowiązującego schematu pojęciowego, i (ii) której odpowiednikiem SQL jest wiersz -

• Salary (x, y, z)

… Miałoby znaczenie

• „Wynagrodzenie wypłacone osobie wskazanej przez PersonNumber w xdniu wejścia w życie yodpowiada kwocie z” .

W związku z tym - aby opisać rzeczy w przybliżeniu - połączenie między tymi trzema domenami ma pierwszorzędne znaczenie, wszystkie są ze sobą powiązane (i tak, relacja jedności dotyczyłaby tylko jednej domeny). Związek między wszystkimi wartościami pewnej domeny jest również bardzo znaczący, ponieważ stanowią one zestaw dokładnego typu . Ponadto zawartość każdej krotki Salaryrelacji musi pasować do struktury twierdzenia zilustrowanego powyżej.

Koncepcyjne szczebla relacje i logiczny poziomu stosunków

Jak wykazano, zajmowałem się teraz zarządzaniem bazami danych na dwóch różnych poziomach abstrakcji, mianowicie pojęciowym i logicznym - i istnieje jeszcze niższy poziom znany jako fizyczny , który w SQL DBMS zwykle obejmuje np. Indeksy, strony, zakresy, itp.-.

Tak więc, zgodnie z wcześniej wyjaśnionymi pojęciami, na poziomie logicznym pracuje się wyłącznie z (a) relacjami matematycznymi, gdzie (b) relacje lub powiązania pojęciowe są reprezentowane przez (c) wartości zawarte w krotkach takich relacji matematycznych, a wspomniane wartości są zwykle rozdzielane ograniczeniami OBCYMI KLUCZAMI, aby mogły dokładnie reprezentować odpowiednie relacje.

I tak, jednostki asocjacyjne , tj. Instancje typów relacji o stosunku liczności wiele do wielu (M: N), mogą być przekazywane za pomocą krotek pojedynczej relacji matematycznej - z odpowiednimi zadeklarowanymi odpowiednio ograniczeniami kierunek-.

Pytanie nr 2)

Rozumiem, że model relacyjny powstał po modelach hierarchicznych i sieciowych. Ale w tych modelach byty również mają ze sobą relacje. Dlaczego więc nazywać ten model modelem relacyjnym? Czy istnieje bardziej szczegółowe wyrażenie / termin? A może powinniśmy powiedzieć, że wszystkie trzy modele są modelami relacyjnymi, ale modele hierarchiczne i sieciowe to określone typy modeli relacyjnych?

Sieciowe i hierarchiczne DBMS poprzedzały ich formalne wsparcie teoretyczne

Należy wskazać, że teoretyczne wsparcie wokół podejść hierarchicznych i sieciowych zostało w rzeczywistości utworzone w oparciu o wcześniej istniejące DBMS, w celu, między innymi, przetestowania i ustalenia poprawności (1) wspomnianych rodzajów oprogramowania i (2) powiązanych praktyk zarządzania danymi - z mojego punktu widzenia zjawisko do góry nogami -.

Niekompletny w porównaniu z ramami relacyjnymi

Biorąc to pod uwagę, chociaż istnieją hierarchiczne i sieciowe DBMS, które poprzedzają model relacyjny, a nawet gdy dr Codd określał każde z tych podejść jako „model”, żaden nie jest zdefiniowany jako taki w taki sam sposób, jak ramy relacyjne. Relacyjny paradygmat zapewnia konstrukty naukowe dla (i) definicji, (ii) ograniczenia i (iii) manipulacji danymi, a podejście hierarchiczne i sieciowe nie ma pełnego wsparcia teoretycznego, aby objąć wszystkie trzy rodzaje wcześniej wspomnianych konstrukcji.

Funkcje sieciowe i hierarchiczne

Jak już wspomniano, typy jednostek i relacji są urządzeniami na poziomie pojęciowym, nie należą one do podejść hierarchicznych ani sieciowych, z których każde oferuje określone mechanizmy reprezentujące wspomniane aspekty:

• Paradygmat sieci obejmuje dwa urządzenia do reprezentacji danych, tj. Węzły i łuki (i ta cecha oczywiście implikuje dwa różne rodzaje operacji manipulacji danymi), które w przeciwieństwie do modelu relacyjnego, który (zgodnie z zasadą informacyjną ) wymaga tylko jednej konstrukcji (relacja) uwidacznia niepotrzebną złożoność związaną z pracą w sieci. Na przykład, biorąc pod uwagę, że korzysta on z dwóch instrumentów reprezentacyjnych, podejście sieciowe narzuca niepraktyczne stronniczość zapytań, które utrudniają manipulację danymi.

• Ze swojej strony, widok hierarchiczny proponuje reprezentowanie danych za pomocą (fizycznych!) Plików złożonych z rekordów (które z kolei składają się z pól ) zorganizowanych w trójpodobny układ; tj. jeden rekord nadrzędny połączony prawdopodobnie z wieloma podrzędnymi odpowiednikami za pośrednictwem wskaźników , który tworzy fizyczną ścieżkę dostępu w odniesieniu do manipulacji danymi. Podejście to jest również niekorzystne, ponieważ stanowi zaplątanie między aspektami koncepcyjnymi i fizycznymi, więc zmiany w fizycznych układach pamięci wymagają reorganizacji struktur danych, co z kolei wymaga zmian w zakresie operacji manipulacji danymi.

Jak pokazano, widoki hierarchiczne i sieciowe narzucają swoje konstrukcje na dane, które mają być zarządzane, podczas gdy model relacyjny proponuje eleganckie administrowanie danymi w ich naturalnej strukturze za pomocą zestawów powiązanych faktów (z których n kolejnych rodzajów zestawów nie przewiduje się faza projektowania, można wyprowadzić i tak dalej!).

Model relacyjny nie ma podmodeli

I, co dość ważne, ani widok hierarchiczny, ani widok sieci nie są konkretnymi typami modeli relacyjnych, są to po prostu inne paradygmaty, które ktoś może zastosować do (a) budowania DBMS i (b) tworzenia baz danych, ale należy pamiętać, że hierarchiczny a podejścia sieciowe są uważane za przestarzałe od dziesięcioleci.

Pytanie nr 3)

Co jeśli mamy samodzielne jednostki, które nie są ze sobą powiązane. Powiedz: osoba, drzwi i drzewo. Czy termin „relacja (al)” nadal obowiązuje?

Tak, ma to zastosowanie, jeśli (1) zarządza się informacjami o tych typach bytów za pomocą dostosowanych relacji matematycznych i (2) wykonuje odpowiednie operacje relacyjne na poziomie logicznym w pewnej bazie danych administrowanej przy wsparciu danego relacyjnego DBMS .

Nie ma znaczenia, czy na poziomie pojęciowym wspomniane typy jednostek nie mają żadnych typów relacji z innymi typami jednostek (i warto zauważyć, że typ jednostki może mieć stosunek współczynnika liczebności jeden do zera, jeden lub wiele z samym sobą), a zatem nie przekazuje się ani nie wymusza żadnego związku między wartościami krotek rozważanych relacji.

Interesującą rzeczą „relacyjnej bazy danych” jest to, że (przede wszystkim) nie odnosi się ona do relacji między tabelami, jak można się spodziewać, ale odnosi się do relacji wielu właściwości (kolumn) w krotce. Relacyjna baza danych przechowuje te krotki jako wiersz w tabeli.

Opiera się na algebrze relacyjnej zdefiniowanej przez Alfreda Tarskiego w jego artykule z 1941 r. (!) O rachunku różniczkowym relacji . Podsumował historię tego terminu i użycie w logice symbolicznej, ale zdefiniował operacje, które ostatecznie stały się podstawą SQL.

Codd przekształcił to w definicję tego, co można rozumieć jako relacyjną bazę danych w swoich 12 przykazaniach .

Termin „relacyjny” pochodzi od matematyki i nie ma nic wspólnego z relacjami między bytami. Nie jestem matematykiem (podczas gdy Codd miał doktorat z matematyki), więc nie będę się rozwijał, ale wskaże ci ten artykuł w Wikipedii na temat relacji binarnych . Wpis wikipedii dotyczący relacji (baz danych) zawiera dodatkowe szczegóły na temat tego, w jaki sposób Codd dostosował koncepcje matematyczne do zarządzania danymi. Jeśli chodzi o to, dlaczego tę matematyczną strukturę nazywa się relacją, myślę, że ma to związek z ideą, że istnieje „relacja” między domenami, które ją tworzą. Najlepszym źródłem, jakie znam, by lepiej zrozumieć oryginalne myślenie Codda, jest Fabian Pascal. Chris Date napisał również obszernie o RDM, a jego strona z Manifestem Trzecim zawiera sekcję zawierającą artykuły i książki. Jego książka Relacyjna teoria dla informatyków jest dobrym wstępem. Mam nadzieję, że to pomoże.

To intuicyjna nazwa, kiedy myślisz o nich za pomocą naturalnych klawiszy. Możesz uznać wartość komórki za reprezentującą byt.

Relation: Employee
|--------+------------+--------|
| name   | job        | boss   |
|--------+------------+--------|
| Mark   | owner      | NULL   |
| Bob    | manager    | Mark   |
| Jane   | supervisor | Bob    |
| Claire | supervisor | Bob    |
| John   | cashier    | Jane   |
| Jesse  | cashier    | Jane   |
| Jason  | cashier    | Claire |
|--------+------------+--------|

• Nazwisko pracownika „Jane” jest powiązane z zadaniem „przełożonego”.
• Nazwisko pracownika „John” jest powiązane z szefem „Jane”.
• Praca „kasjer” jest związana z nazwiskami pracowników „John”, „Jesse” i „Jason”.
• Praca „kasjerka” dotyczy szefów „Jane” i „Claire”.

Zaakceptowałeś już bardzo długą odpowiedź, która ma wiele do powiedzenia na temat baz danych, ale pozwól mi odpowiedzieć na pytanie, które faktycznie zadałeś:

Dlaczego termin „relacyjny”.

Ponieważ tabela jest konkretnym przykładem „relacji” obiektu matematycznego.

Zobaczmy, co Wikipedia ma do powiedzenia na temat terminu „relacja” (w matematyce, nie RDBMS), a następnie przetłumaczmy go na bazy danych:

Formalnie relacja jest zbiorem n-krotek równego stopnia. Tak więc relacja binarna jest zbiorem par, relacja trójskładnikowa zbiorem potrójnych itd. W języku teorii zbiorów relacja między dwoma zbiorami jest podzbiorem ich produktu kartezjańskiego.

Mathematics             | RDBMS
========================|===============
A relation is           | A table is
a set of                | a bunch of 
n-tuples                | rows
of equal degree.        | with the same cell (a.k.a. column) types and sizes.

Kontynuuje teorię zbiorów. Pamiętaj, że to matematyka, o wiele bardziej abstrakcyjna niż baza danych. Tak więc ostatnie zdanie

relacja między dwoma zbiorami jest podzbiorem ich produktu kartezjańskiego.

To przekłada się na jedną tabelę z dwiema kolumnami:

• Nazwijmy kolumnę A „nazwą”. Jego zestaw matematyczny Ajest zbiorem wszystkich (ludzkich) nazw.
• Kolumna BI nazywa „miasto”. Jego zestaw matematyczny Bjest zbiorem wszystkich miast.
• Produkt kartezjański A x B(w matematyce) to nowy zestaw, który zawiera wszystkie pary (aka, tupele), w (a, b)których ajest członkiem Ai bjest członkiem B. Tj. aTo nazwa i bmiasto. Przykładami mogą być (Alice, New York)lub (Bob, Hollywood). Ale produkt kartezjański to nie tylko kilka z nich, ale wszystkie z nich. Relacja, aby przejść do sedna, jest podzbiorem tego kartezjańskiego produktu. Innymi słowy, relacja to (zdefiniowana jako) dowolna liczba par, w (a, b)których aznajduje się nazwa i bmiasto, a nawet żadna.

Teraz mam nadzieję, że wszystko zacznie mieć sens. W RDBMS wiersze tabeli po prostu wybierają podzbiór iloczynu kartezjańskiego wszystkich możliwych kombinacji w tych kolumnach. Co oznacza, że ​​podczas korzystania z RDBMS jest całkowicie trywialny i nieistotny.

Ale od Computer Science, w tym relacyjnych baz danych, czy mają swoje korzenie w matematyce, jesteśmy błogosławieni z terminem „relacyjny” tutaj. Jest całkowicie abstrakcyjny i nie ma nic wspólnego z relacjami między ludźmi ani z tym, co masz.

Nawiasem mówiąc, termin „relacja” jest również czasami używany do „asocjacji” i jest dokładnie taki sam (tutaj, podstawowe zbiory relacji są relacjami, jak opisano powyżej (aka, tabele)).

Uwaga: w matematyce relacje nie dotyczą baz danych, ale są raczej funkcjami, są po prostu bardziej ogólne (proszę, wszyscy wy, matematycy, nie zaczynajcie się teraz dziwić, jesteśmy w dba.SE, nie w matematyce; wiem, że że to niewłaściwy sposób :)). Funkcja podobna f(x)=x+1również może być wyrażona jako zestaw krotek (1, 2), (2, 3), ..., ale może mieć każdy numer tylko raz, po lewej stronie krotki. To znaczy, to nie byłaby ważna funkcja: (1, 2), (1, 3), .... Ale ta ostatnia byłaby ważna relacja; tzn. możesz mieć Boba w Nowym Jorku i Boba w Hollywood.

Relacyjne bazy danych oparte są na modelu relacyjnym EFCodd. Relacyjnej algebry opisuje metody Jak kwerendy danych. Relacja jest po prostu podzbiorem produktu krzyżowego niektórych zbiorów (domen).

Przykład

Mamy następujące zestawy:

DepIds = {1, 2, 3, ...}
EmpIds = {1, 2, 3, ...}
DepNames = {'Engineering', 'Finance', 'Sales', ...}
FirstNames = {'John', 'Walter', 'Mary', 'Roxane', ...}
LastNames = {'Smith', 'Bondy', 'Taylor', ...}
BirthDates = {..., 1950-01-01, 1950-01-02, ...}
Jobs = {'Accountant', 'Programmer', 'Database Administrator', ...}

Ponadto mamy zestawy krotek

departements = { 
    (1, 'Engineering'), 
    (2, 'Finance')}
employees = { 
    (1, 1, 'John', 'Taylor', 1985-03-22, 'Programmer'), 
    (2, 1, 'Walter', 'Bondy', 1997-09-11, 'Database Administrator'), 
    (3, 2, 'Roxane', 'Myers', 1987-12-19, 'Accountant')}

departements jest podzbiorem

    DepIds x DepNames

i to jest relacja.

employees jest podzbiorem

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

i jest to również relacja.

Oczywiste jest, w jaki sposób relacje mogą być implementowane za pomocą tabel.

Dlaczego matematycy nazywają zbiór krotek relacją?

Zwykle takie właściwości jak „2 mniej niż 3”, „4 równa się 4”, „2 wynosi od 1 do 3,4”, „-1 jest ujemne” nazywa się relacjami.

Relacja „mniejsza niż” w zbiorze A = {1, 2, 3} jest zdefiniowana przez podzbiór

{(1, 2), (1, 3), (2, 3) }

z

A x A = {1, 2, 3} x {1, 2, 3}=
{ (1, 1), (1, 2), (1, 3), 
  (2, 1), (2, 2), (2, 3), 
  (3, 1), (3, 2), (3, 3) } 

W podobny sposób inne relacje można postrzegać jako podzbiór produktu krzyżowego. „x mniej niż y”, „x równa się y” są relacjami binarnymi i dlatego są zdefiniowane przez zestaw par. „x między y an z” jest relacją trójskładnikową ”i dlatego jest zdefiniowany przez zbiór potrójnych. „x jest ujemne” to relacja jednoargowa, a zatem zdefiniowana przez zbiór singletonów.

Zestaw krotek dla działów, który zdefiniowaliśmy powyżej, jest relacją binarną, relacja pracowników jest relacją 6-arytową.