web-dev-qa-db-fra.com

Pourquoi le terme "relation (al)"?

En anglais, nous pourrions parler de la relation entre, disons, Bob et Tim. Ce sont peut-être des cousins. Le terme "relation" dans ce contexte me semble logique.

Dans le contexte des bases de données relationnelles, je comprends à quoi le terme fait référence, mais je ne comprends pas pourquoi il est utilisé. Je pense que comprendre pourquoi il est utilisé m'aidera à mieux comprendre le domaine, alors j'aimerais comprendre pourquoi il est utilisé.

  • Pourquoi, par exemple, une personne est-elle considérée comme une "relation"? En anglais, une relation est un nom qui décrit comment deux entités sont associées. Il ne fait pas référence aux entités elles-mêmes. Dans le contexte des bases de données relationnelles, la "relation" fait référence aux entités elles-mêmes. Pourquoi?
  • Je comprends que le modèle relationnel est venu après les modèles hiérarchiques et de réseau (ex. Parent, voisin). Mais dans ces modèles, les entités ont également des relations entre elles. Alors pourquoi appeler ce modèle le modèle relationnel? Y a-t-il une expression/un terme plus spécifique? Ou peut-être devrions-nous dire que les trois modèles sont des modèles relationnels, mais les modèles hiérarchiques et réseau sont des types spécifiques de modèles relationnels?
  • Et si nous avons des entités autonomes qui ne sont pas liées les unes aux autres. Dites, personne, porte et arbre. Le terme "relation (al)" est-il toujours applicable?

(Peut-être que cela devrait être de multiples questions. J'ai pensé que les réponses sont très liées - peut-être qu'il n'y a qu'une seule réponse - alors j'ai pensé qu'il serait logique que ce soit une seule question. Si je me trompe, faites-le moi savoir et je Je vais plutôt créer des questions distinctes.)

Modifier: ce diagramme peut être utile pour visualiser qu'une relation relie différents domaines entre eux:

enter image description here

relational-theoryterminology
26
Adam Zerner

Tout d'abord, je recommande fortement l'article scientifique dans lequel Dr. Edgar Frank Codd a publié le cadre relationnel au grand public en 1970, c'est-à-dire A Relational Model of Data for Grandes banques de données partagées . Là, dans la section 1.1, "Introduction", le Dr Codd lui-même déclare que:

Cet article s'intéresse à l'application de la théorie des relations élémentaires aux systèmes qui fournissent un accès partagé à de grandes banques de données formatées.

© Association pour les machines informatiques. Communications de l'ACM, Volume 13, Numéro 6 (pp. 377-387), juin 1970.

Donc, oui, les termes relation et (donc) relationnel proviennent d'un fond mathématique. Le Dr Codd - qui, en plus de ses diplômes universitaires et de recherche, avait environ 20 ans d'expérience de première main en informatique et en traitement de l'information - envisageait les énormes avantages de l'application de la relation (une construction abstraite, naturellement) dans le domaine de l'administration des données. .

Je ne suis pas un mathématicien mais, fondamentalement, une relation est une association entre ensembles, un ensemble étant une collection d'éléments ( cette ressource externe donne une définition de mathématique relation qui peuvent aider à le comprendre sous un angle différent). Lorsque vous travaillez à l'aide d'un système de gestion de base de données SQL (SGBD pour plus de concision), un approximation bien connu d'une relation est un tablea, auquel cas l'association a lieu entre les types de ses colonnes. De toute évidence, dans les plates-formes SQL qui offrent une prise en charge DOMAINE (par exemple, Firebird et PostgreSQL ), l'association se produit entre les domaines fixés pour les colonnes de la table en question; voir les sections ci-dessous pour plus de détails.

À cet égard, je vais citer à nouveau le Dr Codd qui, dans la section 1.3, "Une vue relationnelle des données", affirme que:

Le terme relation est utilisé ici dans son sens mathématique accepté. Ensembles donnés S1, S2, ⋯, Sn, (pas nécessairement distinct), R est une relation sur ces n ensembles s'il s'agit d'un ensemble de n- tuples dont chacun a son premier élément de S1, son deuxième élément de S2, etc.1 Nous ferons référence à Sj comme j ème domaine de R . Comme défini ci-dessus, R aurait degré n. Les relations de degré 1 sont souvent appelées naire, degré 2 binaire, degré 3 ternaire et degré nn-aire).

1 Plus concis, R est un sous-ensemble du produit cartésien S1 × S2 × S3 ⋯ × Sn.

© Association pour les machines informatiques. Communications de l'ACM, Volume 13, Numéro 6 (pp. 377-387), juin 1970.

Et je suis d'accord avec d'autres réponses en ce qu'il est très pertinent de souligner que le Dr Codd a apporté quelques adaptations à la relation mathématique afin d'en tirer le meilleur parti en ce qui concerne la gestion des données, et elles sont expliquées dans le document mentionné précédemment et tout au long de sa longue bibliographie .

Relation et relation

Une situation qui mérite d'être évoquée est que, lorsqu'il s'agit de ces sujets, il peut y avoir confusion en raison des similitudes qui existent concernant les définitions quotidiennes (non mathématiques, non techniques) des termes relation et relation —qui, en tant que non anglophone, je trouve particulièrement compréhensible—.

Le vue entité-relation et le modèle relationnel

Un autre facteur qui, je pense, peut aussi causer de la confusion (et qui est étroitement associé aux connotations techniques des deux termes évoqués ci-dessus) est que, lors de l'apprentissage de la conception de bases de données, un étudiant ou un praticien est généralement initié à la méthodologie proposée par - Dr Peter Pin-Shan Chen dans la vue entité-relation des données (publiée en 1976), qui suggère deux différentes implémente (c'est-à-dire le entité et le relation) pour délimiter un schéma conceptuel, puis, seulement après que la définition dudit schéma est stable, l'étudiant ou le praticien est initié aux termes et instruments relationnels (par exemple, la relation) lors de la déclaration de la disposition logique de la base de données pertinente. Dans le cadre conceptuel de référence, relation contient des connotations beaucoup plus proches du sens quotidien de la Parole.

Ensuite, peut-être, cette circonstance ajoute également à la question relation et relation - mais la séquence de définition du schéma conceptuel puis de déclaration de la conception logique correspondante est bien sûr tout à fait appropriée, comme je le détaillerai dans ce qui suit sections-.

Réponses à chacune de vos sous-questions

Je considère qu'avoir inclus ces trois sous-questions est vraiment pertinent car elles établissent un contexte plus large pour le poste, il ne faut donc pas les ignorer. De cette façon, en plus de traiter exclusivement pourquoi les termes relation et relationnel sont utilisés (ce qui est certainement très significatif et est le titre de la publication, mais il est pas le entier post), lesdites sous-questions peuvent aider à mieux comprendre la portée du relation et du modèle relationnel quand on est impliqué dans tout un projet de gestion de l'information (tout à fait pertinent puisqu'il s'agit d'un site sur l'administration de bases de données) et travaille donc à différents niveaux d'abstraction. De cette manière, je vais partager mon point de vue sur ces détails ci-dessous.

Sous-question no. 1

Pourquoi, par exemple, une personne est-elle considérée comme une "relation"? En anglais, une relation est un nom qui décrit comment deux entités sont associées. Il ne fait pas référence aux entités elles-mêmes. Dans le contexte des bases de données relationnelles, la "relation" fait référence aux entités elles-mêmes. Pourquoi?

Niveau conceptuel

Dans un environnement commercial donné, Personne peut être considéré comme un type d'entité selon la façon dont les personnes qui y travaillent (experts commerciaux et concepteurs de bases de données) conceptualisent. Et, oui, dans cet environnement commercial, il peut y avoir différents propriétés d'intérêt en ce qui concerne le type d'entité Personne, par exemple, Nom, BirthDate, Sexe, etc.

De plus, le type d'entité Personne peut contenir certains relation (ou association ou connexion) types avec lui-même ou d'autres types d'entités; par exemple, Person peut être associé à un type d'entité nommé serProfile, qui à son tour peut avoir ses propres propriétés d'intérêt, disons, sername et Mot de passe.

Mais, (a) les types d'entités, (b) leurs propriétés correspondantes, (c) les types de relations entre les types d'entités et (d) les relations entre les propriétés elles-mêmes sont des notions qui "appartiennent" à l'environnement commercial particulier dans lequel elles se trouvent. jugés importants. Ce sont des appareils utilisés par les concepteurs de bases de données qui travaillent en étroite collaboration avec des experts commerciaux afin de définir un schéma conceptuel spécifique au contexte, lors de la phase de conception.

Ainsi, au niveau conceptuel, nous travaillons essentiellement avec la structure des idées qui se posent dans le segment d'intérêt du monde réel, à savoir (1) prototypes de choses et (2) prototypes de relations entre prototypes de choses, nous ne travaillons pas avec (3) relations — employant ce dernier terme au sens du cadre relationnel des données—.

Niveau logique

Après que Personne a été délimitée avec précision comme un type d'entité au niveau conceptuel, et si on veut implémenter une base de données relationnelle qui transmet la signification de Personne et tous les les concepts qui lui sont associés, alors les faits sur les entités de ce type peuvent être gérés grâce à une relation mathématique au niveau logique, et tirer parti des opérations de à base scientifique qui peuvent être effectuée sur cette construction abstraite (c.-à-d. la définir, la contraindre et la manipuler).

Oui, on peut nommer une certaine relation Personne lors de la définition de l'arrangement logique d'une base de données, mais cela ne transforme pas le concept "réel" de Personne en relation, on s'en approche en tant que tel en raison des avantages qui sont obtenus lors de la gestion des informations le concernant, par exemple, en y appliquant des opérations d'algèbre relationnelle pour obtenir de nouvelles relations (et par conséquent, on tire de "nouvelles" informations). Ces avantages deviennent plus évidents compte tenu du fait que les entités d'un certain type constituent un ensemble et que les valeurs d'une certaine propriété constituent également un ensemble.

Et, oui, comme mentionné dans les paragraphes précédents et dans d'autres réponses également, l'un des aspects primordiaux d'une relation est le connexion qui existe entre ses domaines - qui sont généralement utilisés pour représentent les propriétés des types d'entité ou d'association qui font partie d'un schéma conceptuel. Par exemple, disons que nous avons déclaré la relation (ternaire) suivante:

  • Salary (PersonNumber, EffectiveDate, Amount)

… Et supposons que, dans l'environnement commercial en question, le Tuple —qui (i) représente un entité particulier, c'est-à-dire un instance de un type d'entité du schéma conceptuel applicable, et (ii) dont l'équivalent SQL est un ligne—

  • Salary (x, y, z)

… Porterait le sens

  • "Le salaire payé à la personne identifiée par PersonNumber x le EffectiveDate y correspond au montant de z".

En conséquence - pour décrire les choses de manière approximative -, la connexion entre les trois domaines est de première importance, ils sont tous liés (et, oui, une relation unaire impliquerait un seul domaine). La connexion entre tous les valeurs d'un certain domaine est également très significative, car ils constituent un ensemble d'un type précis. De plus, le contenu de chaque Tuple de la relation Salary doit tenir dans la structure de assertion illustrée ci-dessus.

niveau conceptuel relations et niveau logique relations

Comme démontré, j'ai maintenant traité de la gestion des bases de données à deux niveaux d'abstraction différents, à savoir conceptuel et logique — et il existe encore un niveau inférieur connu sous le nom de physique un, qui dans les SGBD SQL implique généralement, par exemple, des index, des pages, des extensions, etc.—.

Ainsi, conformément aux notions expliquées précédemment, au niveau logique on travaille exclusivement avec (a) des relations mathématiques, où (b) les relations ou associations conceptuelles sont représentées par (c ) les valeurs contenues dans les tuples de ces relations mathématiques, et lesdites valeurs sont généralement délimitées via des contraintes FOREIGN KEY afin qu'elles puissent représenter avec précision les relations applicables.

Et, oui, les entités associatives, c'est-à-dire les instances de types de relations avec un rapport de cardinalité plusieurs-à-plusieurs (M: N), peuvent être véhiculées au moyen des tuples d'une seule relation mathématique - avec le les contraintes correspondantes déclarées de manière appropriée, bien sûr….

Sous-question no. 2

Je comprends que le modèle relationnel est venu après les modèles hiérarchiques et réseau. Mais dans ces modèles, les entités ont également des relations entre elles. Alors pourquoi appeler ce modèle le modèle relationnel? Y a-t-il une expression/un terme plus spécifique? Ou peut-être devrions-nous dire que les trois modèles sont des modèles relationnels, mais les modèles hiérarchiques et réseau sont des types spécifiques de modèles relationnels?

Les SGBD réseau et hiérarchiques ont précédé leur support théorique formel

Il est opportun de souligner que le support théorique autour des approches hiérarchique et résea a en fait été créé en termes de SGBD anciennement, avec le objectif, entre autres, de tester et d'établir la solidité (1) desdits types de logiciels et (2) des pratiques de gestion des données liées - un phénomène à l'envers, de mon point de vue -.

Incomplet par rapport au cadre relationnel

Cela étant dit, bien qu'il existe des SGBD hiérarchiques et réseau antérieurs au modèle relationnel, et même lorsque le Dr Codd a qualifié chacune de ces approches de "modèle", aucune n'est définie comme telle de la même manière que le cadre relationnel. Le paradigme relationnel fournit des constructions scientifiques pour (i) la définition, (ii) la restriction et (iii) la manipulation des données, et les approches hiérarchiques et de réseau manquent d'un support théorique complet pour couvrir les trois types de constructions précédemment mentionnées.

Fonctionnalités réseau et hiérarchiques

De plus, comme indiqué précédemment, les types d'entité et de relation sont des dispositifs de niveau conceptuel, ils n'appartiennent pas aux approches hiérarchiques ou réseau, chacune offrant des mécanismes particuliers pour représenter lesdits aspects:

  • Le paradigme du réseau implique deux dispositifs pour la représentation des données, c'est-à-dire nœuds et arcs (et cette caractéristique implique bien sûr deux types différents d'opérations de manipulation de données) qui, en contraste avec le modèle relationnel qui (selon le principe d'information) ne requiert que la construction n (la relation), met en évidence la complexité inutile qu'implique le travail en réseau. Par exemple, étant donné qu'elle recourt à deux instruments de représentation, l'approche réseau impose un biais de requête peu pratique qui entrave la manipulation des données.

  • De son côté, la vue hiérarchique propose de représenter les données au moyen de (physiques!) Fichiers constitués de enregistrements (qui à leur tour sont constitués de champs) organisés dans un arrangement trois-like; c'est-à-dire, un enregistrement parent chaîné avec éventuellement plusieurs homologues enfant via pointeurs, ce qui produit un chemin d'accès physique en ce qui concerne la manipulation des données. Cette approche est également défavorable car elle présente un enchevêtrement entre les aspects conceptuels et physiques, de sorte que les changements dans les dispositions de stockage physique nécessitent une réorganisation des structures de données, qui à son tour exige des changements dans les opérations de manipulation des données concernant.

Comme illustré, les vues hiérarchiques et réseau imposent leurs constructions aux données à gérer, tandis que le modèle relationnel propose d'administrer les données avec élégance dans sa structure naturelle au moyen d'ensembles de faits associés (à partir desquels n les types d'ensembles suivants, non prévus lors de la conception, peuvent être dérivés et ainsi de suite!).

Le modèle relationnel n'a pas de sous-modèles

Et, assez important, ni la hiérarchie ni les vues de réseau sont des types spécifiques de modèles relationnels, ce sont simplement d'autres paradigmes que quelqu'un peut suivre pour (a) construire des SGBD et (b ) créer des bases de données, mais n'oubliez pas que les approches hiérarchiques et réseau sont considérées comme obsolètes depuis des décennies.

Sous-question no. 3

Et si nous avons des entités autonomes qui ne sont pas liées les unes aux autres. Dites, personne, porte et arbre. Le terme "relation (al)" est-il toujours applicable?

Oui, il est parfaitement applicable si l'on (1) gère des informations sur ces types d'entités à force de relations mathématiques adaptées et (2) effectue les opérations relationnelles applicables au niveau logique dans une certaine base de données administrée avec le support d'un SGBD relationnel donné .

Peu importe si, au niveau conceptuel, lesdits types d'entité ne contiennent aucun type de relation avec d'autres types d'entité (et il convient de noter qu'un type d'entité peut avoir une relation de cardinalité de un à zéro, un ou plusieurs). avec lui-même), et donc on ne transmet ni n'impose aucune relation entre les valeurs des tuples des relations considérées.

33
MDCCL

La chose intéressante derrière la `` base de données relationnelle '' est qu'elle ne fait pas (principalement) référence aux relations entre les tables, comme on pourrait s'y attendre, mais elle se réfère à la relation de plusieurs propriétés (colonnes) dans un tuple. Une base de données relationnelle stocke ces tuples sous forme de ligne dans une table.

Il est basé sur l'algèbre relationnelle définie par Alfred Tarski dans son article de 1941 (!) Sur le calcul des relations . Il a résumé l'histoire du terme et de son utilisation dans la logique symbolique, mais a défini les opérations qui sont finalement devenues le fondement de SQL.

Codd a transformé cela en une définition de ce qui peut être compris comme une base de données relationnelle dans ses 12 commandements .

16
eckes

Le terme "relationnel" vient des mathématiques et n'a rien à voir avec les relations entre les entités. Je ne suis pas un mathématicien (alors que Codd avait un doctorat en mathématiques) et ne développerai donc pas, mais je vous indiquerai cet article de wikipedia sur relations binaires . L'entrée de wikipedia sur relation (bases de données) donne des détails supplémentaires sur la façon dont Codd a adapté les concepts mathématiques à appliquer à la gestion des données. Quant à savoir pourquoi cette structure mathématique est appelée une relation, je pense que cela a à voir avec l'idée qu'il existe une "relation" entre les domaines qui composent la relation. La meilleure source que je connaisse pour mieux comprendre la pensée originale de Codd est Fabian Pascal Fondements pratiques de la base de données et compréhension du vrai RDM série d'articles . Chris Date a également beaucoup écrit sur le RDM et son site Third Manifesto a une section répertoriant les articles et les livres. Son livre The Relational Theory for Computing Professionals est une bonne introduction. J'espère que ça aide.

10
Todd Everett

C'est un nom intuitif quand on y pense avec des touches naturelles. Vous pouvez considérer une valeur de cellule comme représentant une entité.

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 |
|--------+------------+--------|
  • Le nom d'employé "Jane" est lié au poste de "superviseur".
  • Le nom de l'employé "John" est lié au patron "Jane".
  • Le poste de "caissier" est lié aux noms d'employés "John", "Jesse" et "Jason".
  • Le poste de "caissier" est lié aux patrons "Jane" et "Claire".
7
JoL

Vous avez déjà accepté une réponse très longue qui doit en dire long sur les bases de données, mais permettez-moi de répondre à la question que vous avez effectivement posée:

Pourquoi le terme "relationnel".

Parce qu'une table est une instance concrète de l'objet mathématique "relation".

Voyons ce que Wikipedia a à dire sur le terme "relation" (en mathématiques, pas RDBMS), puis traduisons-le en bases de données:

Formellement, une relation est un ensemble de n-tuples de même degré. Ainsi, une relation binaire est un ensemble de paires, une relation ternaire un ensemble de triplets, etc. Dans le langage de la théorie des ensembles, une relation entre deux ensembles est un sous-ensemble de leur produit cartésien.

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.

Il continue avec la théorie des ensembles. N'oubliez pas qu'il s'agit de mathématiques, bien plus abstraites que de bases de données. La dernière phrase est donc

une relation entre deux ensembles est un sous-ensemble de leur produit cartésien.

Cela se traduit par une une table avec deux colonnes:

  • Appelons la colonne A "nom". Son ensemble mathématique A est l'ensemble de tous les noms (humains).
  • Colonne B J'appelle "ville". Son ensemble mathématique B est l'ensemble de toutes les villes.
  • Le produit cartésien A x B (En mathématiques) est un nouvel ensemble qui contient toutes les paires (aka, tupels) (a, b) Où a est membre de A et b est membre de B. C'est-à-dire, a est un nom et b est une ville. Les exemples seraient (Alice, New York) Ou (Bob, Hollywood). Mais le produit cartésien n'en est pas seulement quelques-uns, mais tous . Une relation, pour en venir au fait, est un sous-ensemble de ce produit cartésien. En d'autres termes, la relation est (définie comme étant) n'importe quel nombre de paires (a, b) Où a est un nom et b est une ville, même pas du tout.

Maintenant, j'espère que tout commence à avoir un sens. Dans un SGBDR, les lignes d'un tableau sélectionnent simplement le sous-ensemble du produit cartésien de toutes les combinaisons possibles dans ces colonnes. Ce qui est, lorsque utilise un SGBDR, complètement trivial et non pertinent.

Mais puisque l'informatique, y compris les bases de données relationnelles, a ses racines dans les mathématiques, nous sommes bénis avec le terme "relationnel" ici. Il est totalement abstrait et n'a rien à voir avec les relations entre les gens ou ce que vous avez.

Soit dit en passant, le terme "relation" est également parfois utilisé pour "association", et il est exactement le même (ici, les ensembles sous-jacents de la relation étant eux-mêmes des relations comme décrit ci-dessus (a.k.a., tableaux)).

NB: en mathématiques, les relations ne concernent pas les bases de données, mais sont quelque chose comme des fonctions, juste plus générales (s'il vous plaît, vous tous les mathématiciens, ne commencez pas à tâtonner maintenant, nous sommes dans dba.SE, pas math.SE; je suis au courant que c'est le mauvais sens :)). Une fonction comme f(x)=x+1 peut également être exprimée sous la forme d'un ensemble de tuples (1, 2), (2, 3), ..., Mais elle ne peut avoir chaque numéro qu'une seule fois, dans la main gauche du Tuple. C'est-à-dire que ce ne serait pas une fonction valide: (1, 2), (1, 3), .... Mais ce dernier serait une relation valide; c'est-à-dire que vous pouvez avoir un Bob à New York et un Bob à Hollywood.

6
AnoE

Bases de données relationnelles est basé sur le modèle relationnel de E.F.Codd. algèbre relationnelle décrit les méthodes d'interrogation des données. Une relation est simplement un sous-ensemble du produit croisé de certains ensembles (domaines).

Exemple

Nous avons les ensembles suivants:

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

De plus, nous avons les ensembles de tuples

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 est un sous-ensemble de

    DepIds x DepNames

et c'est donc une relation.

employees est un sous-ensemble de

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

et c'est donc aussi une relation.

Il est évident que les relations peuvent être implémentées par des tables.

Pourquoi les mathématiciens appellent-ils un ensemble de tuples une relation?

Habituellement, de telles propriétés comme "2 moins de 3", "4 est égal à 4", "2 est compris entre 1 et 3,4", "-1 est négatif" sont appelées relations.

La relation 'inférieur à' sur l'ensemble A = {1, 2, 3} est définie par le sous-ensemble

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

de

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

De la même manière, d'autres relations peuvent être considérées comme un sous-ensemble d'un produit croisé. 'x inférieur à y', 'x est égal à y' sont des relations binaires et sont donc définies par un ensemble de paires. "x entre y et z" est une relation ternaire "et donc définie par un ensemble de triplets. 'x est négatif' est une relation unaire et donc définie par un ensemble de singletons.

L'ensemble de départements Tuple que nous avons défini ci-dessus est une relation binaire, la relation employés est une relation 6-aire.

5
miracle173