Auf Englisch könnten wir über die Beziehung zwischen beispielsweise Bob und Tim sprechen. Vielleicht sind sie Cousins. Der Begriff "Beziehung" ist in diesem Zusammenhang für mich sinnvoll.

Im Zusammenhang mit relationalen Datenbanken verstehe ich, worauf sich der Begriff bezieht, aber ich verstehe nicht, warum er verwendet wird. Ich denke, dass das Verständnis, warum es verwendet wird, mir hilft, das Feld besser zu verstehen. Deshalb möchte ich verstehen, warum es verwendet wird.

• Warum wird zum Beispiel eine Person als "Beziehung" angesehen? Im Englischen ist eine Beziehung ein Substantiv, das beschreibt, wie zwei Entitäten verbunden sind. Es bezieht sich nicht auf die Entitäten selbst. Im Kontext relationaler Datenbanken bezieht sich "Beziehung" auf die Entitäten selbst. Warum?
• Ich verstehe, dass das relationale Modell dem hierarchischen Modell und dem Netzwerkmodell folgte (z. B. Elternteil, Nachbarn). Aber in diesen Modellen haben die Entitäten auch Beziehungen zueinander. Warum also dieses Modell das relationale Modell nennen? Gibt es einen genaueren Ausdruck? Oder sollten wir vielleicht sagen, dass alle drei Modelle relationale Modelle sind, aber die hierarchischen und Netzwerkmodelle spezifische Typen relationaler Modelle sind?
• Was ist, wenn wir eigenständige Entitäten haben, die sich nicht aufeinander beziehen? Sagen Sie, Person, Tür und Baum. Ist der Begriff "Relation (al)" noch gültig?

(Vielleicht sollten dies mehrere Fragen sein. Ich dachte, dass die Antworten in hohem Maße miteinander zusammenhängen - vielleicht gibt es nur eine Antwort -, also dachte ich, dass dies eine einzige Frage sein könnte. Wenn ich mich irre, lass es mich wissen und ich erstelle stattdessen separate Fragen.)

Bearbeiten: Dieses Diagramm kann hilfreich sein, um zu veranschaulichen, dass eine Beziehung verschiedene Domänen miteinander verknüpft:

Zuallererst empfehle ich die wissenschaftliche Arbeit, in der Dr. Edgar Frank Codd 1970 den relationalen Rahmen für die Öffentlichkeit veröffentlichte, dh ein relationales Datenmodell für große gemeinsame Datenbanken . Dort stellt Dr. Codd in Abschnitt 1.1 „Einführung“ selbst fest, dass:

Dieses Papier befasst sich mit der Anwendung der Elementarbeziehungstheorie auf Systeme, die den gemeinsamen Zugriff auf große Banken formatierter Daten ermöglichen.

---

_{© Vereinigung für Computermaschinen. Mitteilungen der ACM , Band 13, Ausgabe 6 (S. 377-387), Juni 1970.}

Also, ja, die Begriffe Relation und (daher) Relational stammen aus einem mathematischen Hintergrund. Dr. Codd - der neben seiner akademischen und wissenschaftlichen Qualifikation über 20 Jahre Erfahrung in der Datenverarbeitung und -verarbeitung verfügt - stellte sich die enormen Vorteile der Anwendung der Relation (natürlich ein abstraktes Konstrukt) im Bereich der Datenverwaltung vor .

Ich bin kein Mathematiker, aber im Grunde genommen ist eine Beziehung eine Assoziation zwischen Mengen , wobei eine Menge eine Sammlung von Elementen ist ( diese externe Ressource gibt eine Definition der mathematischen Beziehung , die dazu beitragen kann, sie aus einer anderen Perspektive zu verstehen). Bei der Arbeit mit einem SQL-Datenbankverwaltungssystem (der Kürze halber DBMS) ist eine bekannte Annäherung einer Beziehung eine Tabelle . In diesem Fall erfolgt die Zuordnung zwischen den Typen ihrer Spalten . Bei SQL-Plattformen, die DOMAIN-Unterstützung bieten (z. B. Firebird und PostgreSQL ), tritt die Zuordnung offensichtlich zwischen demfür die Spalten der betreffenden Tabelle festgelegte Domänen ; In den folgenden Abschnitten finden Sie wichtige Details.

In dieser Hinsicht werde ich noch einmal Dr. Codd zitieren, der in Abschnitt 1.3, „Eine relationale Sicht der Daten“, behauptet:

Der Begriff Relation wird hier in seinem akzeptierten mathematischen Sinn verwendet. Bei gegebenen Mengen S ₁ , S ₂ , ⋯, S _n (nicht notwendigerweise verschieden) ist R eine Beziehung zu diesen n Mengen, wenn es sich um eine Menge von n- Tupeln handelt, von denen jedes sein erstes Element von S _{1 hat} , sein zweites Element von S ₂ und so weiter. ¹ Wir werden beziehen S _j als j - ten Domäne von R . Wie oben definiert, R gesagt haben Grad n. Beziehungen vom Grad 1 werden oft genannt unären , Grad 2 binärer , Grad 3 ternärer und den Grad n n-ary .

_{¹ Genauer gesagt ist R eine Teilmenge des kartesischen Produkts S 1 × S 2 × S 3 ≤ × S n} .

---

_{© Vereinigung für Computermaschinen. Mitteilungen der ACM , Band 13, Ausgabe 6 (S. 377-387), Juni 1970.}

Und ich stimme anderen Antworten darin zu, dass es sehr wichtig ist, darauf hinzuweisen, dass Dr. Codd einige Anpassungen an der mathematischen Relation vorgenommen hat, um das Beste aus der Datenverwaltung herauszuholen. Diese werden in dem zuvor erwähnten Artikel und erläutert in seiner umfangreichen Bibliographie .

Beziehung und Beziehung

Eine Situation , lohnt sich der Erziehung ist , dass, wenn sie mit diesen Themen beschäftigen, es Verwirrung wegen der Ähnlichkeiten entstehen können , die die alltägliche (nicht-mathematischen, nicht-technische) sind in Bezug auf Definitionen der Begriffe Beziehung und Beziehung -Welche, als nicht Englisch als Muttersprache finde ich besonders verständlich -.

Die Entity-Relationship-Sicht und das relationale Modell

Ein weiterer Faktor, von dem ich denke, dass er ebenso Verwirrung stiften kann (und der eng mit den technischen Konnotationen der beiden oben genannten Begriffe zusammenhängt), ist, dass ein Student oder Praktiker beim Erlernen des Entwurfs von Datenbanken in der Regel zuerst in die von Dr Peter Pin-Shan Chen in der Entity-Relationship- Sicht von Daten (1976 veröffentlicht), die zwei verschiedene Implementierungen (dh die Entität und die Beziehung ) vorschlägt , um ein konzeptuelles Schema abzugrenzen , und dann erst nach der Definition des Schemas stabil ist, wird der Student oder Praktiker mit relationalen Begriffen und Instrumenten (z. B. der Beziehung ) bekannt gemacht, wenn er das erklärtlogischer Aufbau der dazugehörigen Datenbank. Innerhalb des konzeptuellen Bezugsrahmens enthält die Beziehung Konnotationen, die dem alltäglichen Sinn des Wortes viel näher sind.

Dann trägt dieser Umstand vielleicht auch zum Beziehungs- und Beziehungsproblem bei - aber die Abfolge, zuerst das konzeptionelle Schema zu definieren und anschließend das entsprechende logische Design zu deklarieren, ist natürlich angemessen, wie ich in den folgenden Abschnitten ausführlicher erläutern werde.

Antworten auf jede Ihrer Unterfragen

Ich bin der Meinung, dass es wirklich relevant ist, diese drei Unterfragen aufgenommen zu haben, da sie einen breiteren Kontext für die Stelle schaffen, so dass sie nicht übersehen werden sollten. Auf diese Weise können die Teilfragen , abgesehen von der ausschließlichen Auseinandersetzung mit der Frage, warum die Begriffe Relation und Relational verwendet werden (was sicherlich sehr wichtig ist und der Titel des Beitrags ist, aber nicht der gesamte Beitrag), dazu beitragen, den Anwendungsbereich von besser zu verstehen die Beziehung und das relationale Modell, wenn man in ein ganzes Informationsmanagementprojekt involviert ist (ziemlich relevant, da dies eine Site über Datenbankadministration ist) und daher auf verschiedenen Abstraktionsebenen arbeitet. Auf diese Weise werde ich meine Meinung zu den folgenden Einzelheiten teilen.

Unterfrage Nr. 1

Warum wird zum Beispiel eine Person als "Beziehung" angesehen? Im Englischen ist eine Beziehung ein Substantiv, das beschreibt, wie zwei Entitäten verbunden sind. Es bezieht sich nicht auf die Entitäten selbst. Im Kontext relationaler Datenbanken bezieht sich "Beziehung" auf die Entitäten selbst. Warum?

Konzeptionelle Ebene

In einem gegebenen Geschäftsumfeld Person kann ein betrachten Entitätstyp je nachdem , wie die Menschen , die dort arbeiten (Business - Experten und Datenbank - Designer) conceptualize es. Ja, in diesem Geschäftsumfeld gibt es möglicherweise unterschiedliche interessante Eigenschaften in Bezug auf den Entitätstyp " Person ", z. B. Name , Geburtsdatum , Geschlecht usw.

Darüber hinaus kann die Person kann Entitätstyp bestimmte halten Beziehung (oder Vereinigung oder Verbindung ) Typen mit sich selbst oder anderen Entität; Beispiel: Person kann einem Entitätstyp mit dem Namen UserProfile zugeordnet sein , der wiederum seine eigenen interessanten Eigenschaften hat, z. B. Benutzername und Passwort .

Aber (a) die Entitätstypen, (b) ihre entsprechenden Eigenschaften, (c) die Beziehungstypen zwischen Entitätstypen und (d) die Beziehungen zwischen den Eigenschaften selbst sind Begriffe, die zu dem bestimmten Geschäftsumfeld „gehören“, in dem sie sich befinden von Bedeutung erachtet. Hierbei handelt es sich um Geräte, die von Datenbankdesignern verwendet werden, die eng mit Geschäftsexperten zusammenarbeiten , um in der Entwurfsphase ein kontextspezifisches konzeptionelles Schema zu definieren .

Auf konzeptioneller Ebene arbeiten wir also im Wesentlichen mit der Struktur der Ideen, die im realen Interessenssegment entstehen, dh (1) Prototypen von Dingen und (2) Prototypen von Beziehungen zwischen Prototypen von Dingen , mit denen wir nicht arbeiten (3) Beziehungen - Einsatz dieses letzten Begriffs im Sinne des relationalen Datenrahmens -.

Logische Ebene

Nach Person wurde als Entitätstyp auf der konzeptionellen Ebene genau abgegrenzte, und wenn man will , eine relationale Datenbank implementieren , dass die Bedeutung vermittelt Person und alle damit verbundenen Konzepte, dann können die Fakten über Entitäten dieser Art aufgrund verwaltet werden einer mathematischen Beziehung auf der logischen Ebene , und nutzen Sie die naturwissenschaftlichen Operationen, die an diesem abstrakten Konstrukt durchgeführt werden können (dh definieren, beschränken und manipulieren).

Ja, man kann eine gewisse Beziehung nennt Person , wenn die logische Anordnung einer Datenbank definiert, sondern dass das „reale Welt“ -Konzept von nicht verwandelt Person in eine Beziehung, nähert man sich als solche wegen der Vorteile , die erhalten werden , wenn Informationen verwalten B. relationale Algebraoperationen anwenden, um neue Beziehungen abzuleiten (und man leitet daher „neue“ Informationen ab). Diese Vorteile werden deutlicher, wenn man berücksichtigt, dass die Entitäten eines bestimmten Typs eine Menge bilden und die Werte einer bestimmten Eigenschaft auch eine Menge bilden.

Und ja, wie in den vorhergehenden Absätzen und auch in anderen Antworten erwähnt, ist einer der wichtigsten Aspekte einer Beziehung die Verbindung , die zwischen ihren Domänen besteht - diese werden normalerweise verwendet, um die Eigenschaften von Entitäts- oder Zuordnungstypen darzustellen, die Teil von sind ein konzeptionelles Schema -. Angenommen, wir haben die folgende (ternäre) Beziehung deklariert:

• Salary (PersonNumber, EffectiveDate, Amount)

… Und nehmen wir an, dass in der fraglichen Geschäftsumgebung das Tupel (i) für eine bestimmte Entität steht , dh eine Instanz eines Entitätstyps aus dem anwendbaren konzeptionellen Schema, und (ii) dessen SQL-Gegenstück a ist Reihe -

• Salary (x, y, z)

... würde die Bedeutung tragen

• "Das Gehalt, das an die Person gezahlt wird, die von PersonNumber xam EffectiveDate identifiziert wurde, yentspricht dem Betrag von z" .

Dementsprechend ist - um die Dinge näherungsweise zu beschreiben - die Verbindung zwischen den drei Domänen von höchster Wichtigkeit, sie hängen alle zusammen (und ja, eine unäre Beziehung würde nur eine Domäne betreffen). Die Verbindung zwischen allen Werten einer bestimmten Domäne ist ebenfalls sehr wichtig, da sie eine Menge eines genauen Typs darstellen . Außerdem muss der Inhalt jedes Tupels der SalaryBeziehung in die Struktur der oben dargestellten Behauptung passen .

Konzeptionelle Ebene Beziehungen und logische Ebene Beziehungen

Wie gezeigt, habe ich mich jetzt mit der Datenbankverwaltung auf zwei verschiedenen Abstraktionsebenen befasst, nämlich der konzeptionellen und der logischen - und es gibt noch eine niedrigere Ebene, die als physische Ebene bezeichnet wird. etc.-.

Also, in Übereinstimmung mit den Begriffen erklärte vor, auf der logischen Ebene arbeitet man ausschließlich mit (a) mathematischen Beziehungen, wobei (b) die konzeptionellen Beziehungen oder Verbände vertreten durch (c) die Werte , die in den Tupeln solcher mathematischen Beziehungen, und diese Werte werden normalerweise über FOREIGN KEY-Beschränkungen abgegrenzt, damit sie die anwendbaren Beziehungen genau wiedergeben können.

Und ja, assoziative Entitäten, dh Instanzen von Beziehungstypen mit einem Kardinalitätsverhältnis von vielen zu vielen (M: N), können über die Tupel einer einzelnen mathematischen Beziehung vermittelt werden - mit den entsprechenden Bedingungen, die in geeigneter Weise für deklariert wurden Kurs-.

Unterfrage Nr. 2

Ich verstehe, dass das relationale Modell dem hierarchischen Modell und dem Netzwerkmodell folgte. Aber in diesen Modellen haben die Entitäten auch Beziehungen zueinander. Warum also dieses Modell das relationale Modell nennen? Gibt es einen genaueren Ausdruck? Oder sollten wir vielleicht sagen, dass alle drei Modelle relationale Modelle sind, aber die hierarchischen und Netzwerkmodelle spezifische Typen relationaler Modelle sind?

Netzwerk- und hierarchische DBMS gingen ihrer formalen theoretischen Unterstützung voraus

Es ist angebracht, darauf hinzuweisen, dass die theoretische Unterstützung im Zusammenhang mit den hierarchischen Ansätzen und den Netzwerkansätzen in der Tat im Hinblick auf zuvor vorhandene DBMS geschaffen wurde, um unter anderem die Solidität von (1) diesen Arten zu testen und festzustellen von Software und (2) die verknüpften Datenverwaltungspraktiken - aus meiner Sicht ein verkehrtes Phänomen -.

Im Vergleich zum relationalen Rahmen unvollständig

Davon abgesehen gibt es zwar hierarchische und Netzwerk-DBMS, die vor dem relationalen Modell erstellt wurden, und selbst wenn Dr. Codd jeden dieser Ansätze als „Modell“ bezeichnet, ist keiner so definiert wie der relationale Rahmen. Das relationale Paradigma liefert wissenschaftliche Konstrukte für die (i) Definition, (ii) Einschränkung und (iii) Manipulation von Daten, und den hierarchischen und Netzwerkansätzen mangelt es an vollständiger theoretischer Unterstützung, um alle drei Arten von Konstrukten abzudecken, die zuvor erwähnt wurden.

Netzwerk- und hierarchische Funktionen

Wie bereits erwähnt, handelt es sich bei den Entitäts- und Beziehungstypen um Geräte auf konzeptioneller Ebene. Sie gehören nicht zu den hierarchischen oder Netzwerkansätzen, von denen jeder bestimmte Mechanismen zur Darstellung der folgenden Aspekte bietet:

• Das Netzwerkparadigma beinhaltet zwei Geräte zur Datendarstellung, dh Knoten und Bögen (und dieses Merkmal impliziert natürlich zwei verschiedene Arten von Datenmanipulationsoperationen), die im Gegensatz zu dem relationalen Modell (gemäß dem Informationsprinzip ) nur ein Konstrukt erfordern (die Beziehung) verdeutlicht die unnötige Komplexität, die das Arbeiten in einem Netzwerk mit sich bringt. Da beispielsweise auf zwei Darstellungsinstrumente zurückgegriffen wird, erlegt der Netzwerkansatz eine unpraktische Abfrageverzerrung auf , die die Datenmanipulation behindert.

• Die hierarchische Ansicht schlägt ihrerseits vor, die Daten durch (physische!) Dateien darzustellen, die aus Datensätzen bestehen (die wiederum aus Feldern bestehen ), die in einer dreifachen Anordnung angeordnet sind. dh ein übergeordneter Datensatz , der über Zeiger mit möglicherweise vielen untergeordneten Gegenstücken verkettet ist , wodurch ein physischer Zugriffspfad in Bezug auf die Datenmanipulation erzeugt wird. Dieser Ansatz ist auch ungünstig, weil er eine Verflechtung zwischen konzeptionellen und physikalischen Aspekten darstellt, so dass die Änderungen in den physikalischen Speicheranordnungen eine Reorganisation der Datenstrukturen erfordern, was wiederum Änderungen in den betreffenden Datenmanipulationsoperationen erforderlich macht.

Wie gezeigt, schreiben die hierarchischen Ansichten und die Netzwerkansichten den zu verwaltenden Daten ihre Konstrukte vor, während das relationale Modell vorschlägt, die Daten elegant in ihrer natürlichen Struktur mit Hilfe von Mengen zugehöriger Fakten zu verwalten (von denen n nachfolgende Arten von Mengen nicht erwartet werden) die Entwurfsphase kann abgeleitet werden und so weiter!).

Das relationale Modell hat keine Untermodelle

Und ganz wichtig ist, dass weder die hierarchische noch die Netzwerkansicht bestimmte Arten von relationalen Modellen sind. Es handelt sich lediglich um andere Paradigmen, denen jemand folgen kann, um (a) DBMS zu erstellen und (b) Datenbanken zu erstellen und Netzwerkansätze gelten seit Jahrzehnten als obsolet.

Unterfrage Nr. 3

Was ist, wenn wir eigenständige Entitäten haben, die sich nicht aufeinander beziehen? Sagen Sie, Person, Tür und Baum. Ist der Begriff "Relation (al)" noch gültig?

Ja, es ist perfekt anwendbar, wenn man (1) Informationen über diese Entitätstypen durch angepasste mathematische Beziehungen verwaltet und (2) die anwendbaren relationalen Operationen auf der logischen Ebene in einer bestimmten Datenbank ausführt, die mit Unterstützung eines bestimmten relationalen DBMS verwaltet wird .

Es spielt keine Rolle, ob die Entitätstypen auf konzeptioneller Ebene keine Beziehungstypen mit anderen Entitätstypen aufweisen (und es ist erwähnenswert, dass ein Entitätstyp eine Beziehung mit einem Verhältnis von 1 zu 0 zu 1 oder zu vielen Kardinalitäten aufweisen kann mit sich selbst), und somit vermittelt oder erzwingt man keine Beziehung zwischen den Werten der Tupel der betrachteten Beziehungen.

Das Interessante an der relationalen Datenbank ist, dass sie sich nicht (hauptsächlich) auf die Beziehungen zwischen Tabellen bezieht, wie Sie vielleicht erwarten, sondern auf die Beziehung mehrerer Eigenschaften (Spalten) in einem Tupel. In einer relationalen Datenbank werden diese Tupel als Zeile in einer Tabelle gespeichert.

Es basiert auf der relationalen Algebra, die Alfred Tarski 1941 (!) In seinem Aufsatz Über die Berechnung von Beziehungen definiert hat . Er fasste die Geschichte des Begriffs und der Verwendung in symbolischer Logik zusammen, definierte aber die Operationen, die am Ende die Grundlage für SQL wurden.

Codd verwandelte dies in eine Definition für das, was in seinen 12 Geboten als relationale Datenbank verstanden werden kann .

Der Begriff "relational" stammt aus der Mathematik und hat nichts mit Beziehungen zwischen Entitäten zu tun. Ich bin kein Mathematiker (während Codd in Mathematik promoviert hat) und werde daher nicht näher darauf eingehen, aber auf diesen Wikipedia-Artikel über binäre Beziehungen verweisen . Der Wikipedia-Eintrag zu Relationen (Datenbanken) gibt zusätzliche Informationen darüber, wie Codd die mathematischen Konzepte an die Datenverwaltung anpasste. Was den Grund für die Bezeichnung dieser mathematischen Struktur als Beziehung anbelangt, so hat dies meiner Meinung nach mit der Vorstellung zu tun, dass zwischen den Domänen, aus denen die Beziehung besteht, eine "Beziehung" besteht. Die beste Quelle, die ich kenne, um Codds originelles Denken besser zu verstehen, ist Fabian Pascal '. Chris Date hat auch ausführlich über das RDM geschrieben, und seine Website zum Dritten Manifest enthält einen Abschnitt mit Aufsätzen und Büchern. Sein Buch Relational Theory for Computing Professionals ist eine gute Einführung. Ich hoffe das hilft.

Es ist ein intuitiver Name, wenn Sie an sie mit natürlichen Schlüsseln denken. Sie können sich einen Zellenwert als eine Entität vorstellen.

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 |
|--------+------------+--------|

• Der Name des Mitarbeiters "Jane" steht im Zusammenhang mit dem Job "Vorgesetzter".
• Der Angestelltenname "John" ist verwandt mit der Chefin "Jane".
• Der Job "Kassierer" ist mit den Mitarbeiternamen "John", "Jesse" und "Jason" verwandt.
• Der Beruf "Kassierer" ist mit den Chefs "Jane" und "Claire" verwandt.

Sie haben bereits eine sehr lange Antwort akzeptiert, die viel über Datenbanken zu sagen hat, aber lassen Sie mich die Frage beantworten, die Sie tatsächlich gestellt haben:

Warum der Begriff "relational".

Denn eine Tabelle ist eine konkrete Instanz des mathematischen Objekts "Relation".

Lassen Sie uns sehen, was Wikipedia über den Begriff "Relation" zu sagen hat (in der Mathematik nicht RDBMS), und ihn dann in Datenbanken übersetzen:

Formal ist eine Beziehung eine Menge von n-Tupeln gleichen Grades. So ist eine binäre Beziehung eine Menge von Paaren, eine ternäre Beziehung eine Menge von Dreifachen und so weiter. In der Sprache der Mengenlehre ist eine Beziehung zwischen zwei Mengen eine Teilmenge ihres kartesischen Produkts.

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.

Es geht weiter mit der Mengenlehre. Denken Sie daran, dass dies Mathematik ist, viel abstrakter als Datenbankmaterial. Der letzte Satz ist also

Eine Beziehung zwischen zwei Mengen ist eine Teilmenge ihres kartesischen Produkts.

Dies führt zu einer Tabelle mit zwei Spalten:

• Nennen wir Spalte A "Name". Seine mathematische Menge Aist die Menge aller (menschlichen) Namen.
• Spalte BI "Stadt" aufrufen. Ihre mathematische Menge Bist die Menge aller Städte.
• Das kartesische Produkt A x B(in Mathematik) ist eine neue Menge, die alle Paare (auch Tupel genannt) enthält, bei (a, b)denen aMitglied Aist und bbei denen Mitglied ist B. Dh aist ein Name und bist eine Stadt. Beispiele wären (Alice, New York)oder (Bob, Hollywood). Aber das kartesische Produkt sind nicht nur einige, sondern alle . Eine Beziehung ist, um auf den Punkt zu kommen, eine Teilmenge dieses kartesischen Produkts. Mit anderen Worten, die Relation ist (definiert als) eine beliebige Anzahl von Paaren, bei (a, b)denen aes sich um einen Namen und beine Stadt handelt, auch gar keine.

Jetzt hoffe ich, dass alles einen Sinn ergibt. In einem RDBMS wählen die Zeilen einer Tabelle einfach die Teilmenge des kartesischen Produkts aller möglichen Kombinationen in diesen Spalten aus. Was bei Verwendung eines RDBMS völlig trivial und irrelevant ist.

Aber da Informatik, einschließlich relationalen Datenbanken, hat seine Wurzeln in der Mathematik hat, sind wir mit dem Begriff „relational“ gesegnet hier. Es ist ganz abstrakt und hat überhaupt nichts mit Beziehungen zwischen Menschen oder was haben Sie zu tun.

Abgesehen davon wird der Begriff "Relation" manchmal auch für "Assoziation" verwendet, und er ist genau der gleiche (hier sind die zugrunde liegenden Mengen der Relation selbst Relationen, wie oben beschrieben (auch bekannt als Tabellen)).

NB: In der Mathematik geht es bei Relationen nicht um Datenbanken, sondern um Funktionen, die nur allgemeiner sind (bitte, alle Mathematiker, fangen jetzt nicht an zu picken, wir sind in dba.SE, nicht in math.SE; mir ist bewusst dass dies der falsche Weg ist :)). Eine Funktion wie f(x)=x+1kann auch als eine Menge von Tupeln ausgedrückt werden (1, 2), (2, 3), ..., sie kann jedoch nur eine Zahl auf der linken Seite des Tupels haben. Das heißt, würde dies keine gültige Funktion sein: (1, 2), (1, 3), .... Aber das letztere wäre eine gültige Beziehung; Sie können also einen Bob in New York und einen Bob in Hollywood haben.

Relationale Datenbanken basieren auf dem relationalen Modell von EFCodd. Die relationale Algebra beschreibt Methoden zum Abfragen von Daten. Eine Relation ist einfach eine Teilmenge des Kreuzprodukts einiger Mengen (Domänen).

Beispiel

Wir haben folgende Sets:

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', ...}

Weiterhin haben wir die Tupelsätze

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 ist eine Teilmenge von

    DepIds x DepNames

und so ist es eine Beziehung.

employees ist eine Teilmenge von

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

und so ist es auch eine Beziehung.

Es ist offensichtlich, wie Relationen durch Tabellen implementiert werden können.

Warum bezeichnen Mathematiker eine Menge von Tupeln als Beziehung?

Normalerweise werden solche Eigenschaften wie '2 kleiner als 3', '4 gleich 4', '2 liegt zwischen 1 und 3,4', '-1 ist negativ' als Relationen bezeichnet.

Die Beziehung 'kleiner als' für die Menge A = {1, 2, 3} wird durch die Teilmenge definiert

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

von

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) } 

In ähnlicher Weise können andere Beziehungen als Teilmenge eines Kreuzprodukts angesehen werden. 'x kleiner als y', 'x gleich y' sind binäre Beziehungen und werden daher durch eine Menge von Paaren definiert. 'x zwischen y und z' ist eine ternäre Beziehung 'und wird daher durch eine Menge von Tripeln definiert. 'x ist negativ' ist eine unäre Beziehung und wird daher durch eine Menge von Singletons definiert.

Das oben definierte Abteilungs-Tupel-Set ist eine binäre Beziehung, die Mitarbeiter-Beziehung ist eine 6-stellige Beziehung.