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:

Tout d'abord, je recommande fortement l'article scientifique dans lequel le Dr Edgar Frank Codd a publié le cadre relationnel au grand public en 1970, à savoir, Un modèle relationnel de données pour les 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 of the ACM , Volume 13, Issue 6 (pp. 377-387), juin 1970.}

Donc, oui, les termes relation et (donc) relationnel proviennent d'un arrière-plan 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 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 la relation mathématique qui peut aider à la 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), une approximation bien connue d'une relation est une table , auquel cas l'association a lieu entre les types de ses colonnes . De toute évidence, dans les plates-formes SQL qui offrent la prise en charge de DOMAIN (par exemple, Firebird et PostgreSQL ), l'association se produit entre lesdomaines fixés pour les colonnes du tableau 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é. Etant donné les ensembles S ₁ , S ₂ , ⋯, S _n , (pas nécessairement distincts), R est une relation sur ces n ensembles si c'est un ensemble de n -tuples dont chacun a son premier élément de S ₁ , son deuxième élément de S ₂ , et ainsi de suite. ¹ nous appellerons S _j comme j e domaine de R . Comme défini ci-dessus, R est dit avoir le degré n. Les relations de degré 1 sont souvent appelées unaires , de degré 2 binaires , de degré 3 ternaires et de degré n n-aire .

_{¹ Plus concis, R est un sous-ensemble du produit cartésien S 1 × S 2 × S 3 ⋯ × S n} .

---

_{© Association pour les machines informatiques. Communications of the ACM , Volume 13, Issue 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 en ce qui concerne les définitions quotidiennes (non mathématiques, non techniques) des termes relation et relation - qui, en tant que non anglophone natif, je trouve particulièrement compréhensible—.

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

Un autre facteur qui, à mon avis, 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 le Dr Peter Pin-Shan Chen dans la vue entité-relation des données (publiée en 1976), qui suggère deux outils différents (c.-à-d. L' entité et la relation ) pour délimiter un schéma conceptuel , puis seulement après la définition dudit schéma est stable, l'étudiant ou le praticien est initié aux termes et instruments relationnels (par exemple, la relation ) lorsqu'il déclareprésentation logique de la base de données pertinente. Dans le cadre conceptuel de référence, la relation contient des connotations beaucoup plus proches du sens quotidien du mot.

Ensuite, peut-être, cette circonstance ajoute également à la relation et à la question de la 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 les sections suivantes -.

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, donc elles ne doivent pas être négligées. De cette façon, en plus de traiter exclusivement la raison pour laquelle les termes relation et relationnel sont utilisés (ce qui est certainement très important et est le titre du poste, mais ce n'est pas le poste entier ), lesdites sous-questions peuvent aider à mieux comprendre la portée de la relation et le modèle relationnel quand on est impliqué dans tout un projet de gestion de l'information (assez 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é, la personne peut être considérée comme un type d'entité selon la façon dont les personnes qui y travaillent (experts commerciaux et concepteurs de bases de données) la conçoivent . Et, oui, dans cet environnement commercial, il peut y avoir différentes propriétés d'intérêt en ce qui concerne le type d'entité Personne , par exemple, Nom , Date de naissance , Sexe , etc.

De plus, la personne type d'entité peut détenir certains rapports (ou association ou connexion ) types avec lui - même ou d' autres types d'entités; Par exemple, la personne peut être associée à un type d'entité nommé UserProfile , qui à son tour peut avoir ses propres propriétés d'intérêt, disons, nom d' utilisateur 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 , au stade de la 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) les prototypes de choses et (2) les prototypes de relations entre les prototypes de choses , nous ne travaillons pas avec (3) les relations - employant ce dernier terme au sens du cadre relationnel des données -.

Niveau logique

Une fois que la personne a été délimitée avec précision comme un type d'entité au niveau conceptuel, et si l' on veut mettre en œuvre une base de données relationnelle qui transmet le sens de la personne et tous les concepts qui lui sont associés, alors les faits sur les entités de ce type peuvent être gérés par la vertu d'une relation mathématique au niveau logique , et tirer parti des opérations fondées sur la science qui peuvent être effectuées sur cette construction abstraite (c'est-à-dire la définir, la contraindre et la manipuler).

Oui, on peut nommer une certaine relation Personne lors de la définition de l'agencement logique d'une base de données, mais cela ne transforme pas le concept «réel» de Personne en relation, on l'aborde comme tel en raison des avantages obtenus lors de la gestion de l'information à ce sujet, par exemple, en lui appliquant des opérations d'algèbre relationnelle pour dériver de nouvelles relations (et donc on dérive 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 la connexion qui existe entre ses domaines - qui sont généralement utilisés pour représenter les propriétés des types d'entité ou d'association qui font partie de 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 une entité particulière , c'est-à-dire une instance d'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 xau EffectiveDate ycorrespond au Montant de z" .

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

Niveau conceptuel relations et niveau logique relations

Comme démontré, j'ai maintenant traité de la gestion de base 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 , qui dans les SGBD SQL implique généralement, par exemple, les index, les pages, les extensions, etc.-.

Ainsi, conformément aux notions expliquées précédemment, au niveau logique on travaille exclusivement avec (a) les 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 transmises au moyen des tuples d'une seule relation mathématique - avec les contraintes correspondantes déclarées de manière appropriée, de cours-.

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 soutien théorique autour des approches hiérarchiques et réseau a, en fait, été créé en termes de SGBD existants , dans le but, entre autres, de tester et d'établir la solidité de (1) ces types des logiciels et (2) les 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 de réseau implique deux dispositifs pour la représentation des données, à savoir, les nœuds et les arcs (et cette caractéristique implique bien sûr deux types différents d'opérations de manipulation de données) qui, contrairement au modèle relationnel qui (selon le principe de l' information ) ne nécessite qu'une seule construction (la relation), met en évidence la complexité inutile qu'implique un 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 par le biais de fichiers (physiques!) Constitués d' enregistrements (eux -mêmes constitués de champs ) organisés en trois parties; c'est-à-dire, un enregistrement parent chaîné avec éventuellement de nombreux homologues enfants via des 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 (dont n types d'ensembles ultérieurs, non anticipés à la phase de conception, peut être dérivée et ainsi de suite!).

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

Et, ce qui est très important, ni les vues hiérarchiques ni les vues de réseau ne sont des types spécifiques de modèles relationnels, ce sont simplement d'autres paradigmes que quelqu'un peut suivre pour (a) créer des SGBD et (b) créer des bases de données, mais veuillez garder à l'esprit que la hiérarchie et les approches de réseau sont considérées comme obsolètes depuis des décennies maintenant.

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.

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 .

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 les relations binaires . L'entrée de wikipedia sur la 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. 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 Relational Theory for Computing Professionals est une bonne introduction. J'espère que ça aide.

C'est un nom intuitif quand on y pense avec des clés 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 métier de "caissier" est lié aux patrons "Jane" et "Claire".

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 table avec deux colonnes:

• Appelons la colonne A "nom". Son ensemble mathématique Aest l'ensemble de tous les noms (humains).
• La colonne BI appelle "ville". Son ensemble mathématique Best l'ensemble de toutes les villes.
• Le produit cartésien A x B(en mathématiques) est un nouvel ensemble qui contient de toutes les paires (aka, tupels) (a, b)où aest membre Aet best membre de B. C'est à dire, aest un nom et best 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) toute quantité de paires (a, b)où aest un nom et best 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, lors de l' utilisation d' un SGBDR, complètement trivial et non pertinent.

Mais depuis que la science informatique, y compris les bases de données relationnelles, ne possède ses racines en mathématiques, nous sommes bénis par 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 (aka, 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+1aussi peut être exprimée comme un ensemble de tuples (1, 2), (2, 3), ..., mais elle ne peut avoir chaque numéro qu'une seule fois, sur la gauche du tuple. -À- dire, ce ne serait pas une fonction valide: (1, 2), (1, 3), .... Mais ce dernier serait une relation valable; c'est-à-dire que vous pouvez avoir un Bob à New York et un Bob à Hollywood.

Les bases de données relationnelles sont basées sur le modèle relationnel d'EFCodd. L' 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 tuple des départements que nous avons défini ci-dessus est une relation binaire, la relation des employés est une relation à 6 aires.