Important

La traduction est le fruit d’un effort communautaire auquel vous pouvez vous joindre. Cette page est actuellement traduite à 100.00%.

12.4. Connecter et modifier des données entre couches

La capacité à connecter des données de différentes couches est une des raisons d’être des logiciels SIG. Une telle connexion peut être basée sur la relation spatiale entre les entités, ou sur leurs attributs communs. QGIS dispose d’outils pour gérer chacune de ces situations, et notamment :

Des algorithmes de traitement qui par interaction entre couches génèrent une nouvelle couche, comme par exemple Joindre les attributs par localisation, Joindre les attributs par le plus proche, Joindre des attributs par valeur de champ, …
Requêtes SQL de création d’une nouvelle couche depuis le Gestionnaire de Bases de données ou en tant que couche virtuelle
Les propriétés de jointure ou les paramètres de relation qui, de manière temporaire, étendent les attributs des entités d’une couche, à l’aide d’attributs d’entités d’une autre couche sur la base d’attribut(s) en commun.

Les jointures et les relations sont des concepts techniques issus des bases de données, qui permettent d’exploiter pleinement les données stockées dans des tables en combinant leur contenu. L’idée est d’associer les entités (les lignes des tables attributaires) de différentes couches (tables) entre elles. Le nombre de lignes correspondantes peut varier : aucune, une seule ou plusieurs.

12.4.1. Joindre des entités de deux couches 

Les jointures dans QGIS permettent d’associer les entités d’une couche active à celles d’une autre couche vectorielle chargée. Peu importe si elles sont spatialement activées ou leur type de géométrie. La jointure repose sur un attribut commun aux deux couches, selon une relation un-à-un.

Pour créer une jointure sur une couche (que nous appellerons ci-après couche cible) :

Rendez vous dans l’onglet Propriétés ► Jointures de la couche
Cliquez sur le bouton ^{Ajouter une nouvelle jointure}. La boîte de dialogue Ajouter une jointure vecteur apparaît.
Sélectionnez la Couche de jointure que vous souhaitez connecter avec la couche vecteur cible
Sélectionnez le Champ de jointure (de la couche jointe) et le Champ dans la couche cible (de la couche cible). Ce seront les champs utilisés pour trouver les entités associées dans les deux couches, ils doivent donc avoir des valeurs communes.
Appuyez sur OK et un résumé des paramètres sélectionnés est ajouté à l’onglet Jointure.

../../../_images/join_attributes.png — Fig. 12.105 Joindre une table attributaire à une couche vecteur existante

Les étapes ci-dessus créent une jointure où TOUS les attributs de la première entité correspondante de la couche à joindre sont ajoutés à l’entité de la couche cible. La logique appliquée lors du processus est la suivante :

Toutes les entités de la couche cible sont conservées, même si aucune correspondance n’existe.
Si le champ cible contient des doublons, ces entités se verront attribuer la même entité de la couche à joindre.
Si le champ de jointure contient des valeurs correspondantes dupliquées, seule la première entité trouvée est retenue.

Note

Les jointures dans QGIS reposent sur l’appariement d’un seul champ : dans la plupart des cas, il est donc recommandé de s’assurer que les valeurs des champs utilisés pour la jointure soient uniques.

QGIS dispose de quelque autres options pour ajuster la jointure :

Mettre la couche jointe en cache dans la mémoire virtuelle : permet de mettre en cache les valeurs (sans géométrie) de la couche jointe afin d’accélérer les recherches.
Créer un index des attributs sur le champ de la jointure pour accélérer les recherches
Formulaire dynamique : aide à synchroniser les champs de jointure à la volée, selon le Champ dans la couche cible. De cette façon, les contraintes des champs de jointure sont également correctement mises à jour. Notez qu’il est désactivé par défaut car cela peut prendre beaucoup de temps si vous avez beaucoup d’entités ou une myriade de jointures.
Si la couche cible est modifiable, certaines icônes seront affichées dans la table attributaire à côté des champs, afin de renseigner leur statut :
- : la couche de jointure n’est pas configurée pour être modifiable. Si vous souhaitez pouvoir modifier les fonctions de jointure à partir de la table d’attributs cible, vous devez cocher l’option Couche de jointure modifiable
- : la couche de jointure est bien configurée pour être modifiable, mais son état actuel est en lecture seule.
- : la couche de jointure est modifiable, mais les mécanismes de synchronisation ne sont pas activés. Si vous souhaitez ajouter automatiquement une entité dans la couche de jointure lorsqu’une entité est créée dans la couche cible, vous devez cocher l’option Mise à jour et insertion lors de l’édition. Symétriquement, l’option Supprimer en cascade peut être activée si vous souhaitez supprimer automatiquement les entités jointes.
Champs joints: au lieu d’ajouter tous les champs de la couche jointe, vous pouvez spécifier un sous-ensemble.
Préfixe de nom de champ personnalisé pour les champs joints, afin d’éviter la collision de noms

12.4.2. Définir des relations entre plusieurs couches 

Contrairement aux jointures qui établissent un lien un-à-un entre les entités de deux couches, les relations permettent de créer des interconnexions entre plusieurs entités à travers deux couches ou plus. De ce fait, elles s’appliquent au niveau du projet et se configurent via Projet ► Propriétés ► Relations. Depuis cet onglet, vous pouvez :

Ajouter une relation dont le type peut être :
- relation un à plusieurs
- relation plusieurs à plusieurs
- relation polymorphique que vous pouvez ajouter ou modifier grâce aux outils dédiés dans la liste déroulante.
Note

Il n’existe pas encore de méthode simple pour modifier une relation non polymorphique une fois créée. Seul le nom peut être édité via un double-clic. Pour tout autre paramètre, il faudra supprimer la relation et la recréer.
Découvrir les relations: QGIS peut découvrir les relations existantes dans les formats de bases de données pris en charge (PostgreSQL, GeoPackage, ESRI File Geodatabase, …). Cela peut être un bon moyen de faciliter la configuration des relations.
Supprimer relation

../../../_images/project_relations.png — Fig. 12.106 Onglet Relations

12.4.2.1. Relation un à plusieurs (1-N)

Comme exemple, nous prendrons une couche contenant toutes les régions de l’Alaska (des polygones) qui fournit quelques attributs sur le nom, le type de région et un identifiant unique (qui jouera le rôle de clé primaire).

Nous prenons ensuite une autre couche de point ou une table contenant des informations sur les aéroports localisés dans les régions. Si vous souhaitez y accéder, depuis la couche des régions, vous devez créer une relation “un à plusieurs”, en utilisant des clés étrangères, car il y a plusieurs aéroports dans la plupart des régions.

../../../_images/regions_with_airports.png — Fig. 12.107 Les régions d’Alaska contenant des aéroports

Couches et clés 

QGIS ne fait pas de distinction entre une table et une couche vecteur. Très simplement, une couche vecteur est une table associée à une géométrie. Ce qui signifie que vous pouvez ajouter votre table comme une couche vecteur. Pour démontrer la relation de 1 à n, vous pouvez charger les couches regions et airports du jeu de données. En pratique, chaque aéroport appartient à une et une seule région alors que chaque région peut avoir un nombre variable d’aéroports (une relation 1 à plusieurs).

En plus des attributs décrivant les aéroports, la couche des aéroports comporte un champ fk_region qui permet d’établir une clé étrangère (si vous disposez d’une base de données il peut être judicieux d’ajouter une contrainte sur ce champ). Ce champ fk_region contiendra toujours l’id d’une région. Il peut être vu comme un pointeur vers la région à laquelle il appartient.

Il vous suffit d’indiquer à QGIS la relation entre les couches pour concevoir un formulaire de saisie personnalisé pour l’édition et QGIS gère automatiquement la configuration. Cela fonctionne avec différents fournisseurs (y compris les fichiers shape et CSV).

Définir les relations 1-N 

La première chose que nous allons faire est de faire connaître au logiciel QGIS les relations entre les couches. Cela se fait dans Projet ► Propriétés…. Ouvrez l’onglet Relations et cliquez sur Ajout relation .

Nom sera utilisé comme titre. Il s’agit d’un texte lisible décrivant la relation. Ici, nous allons simplement mettre airport_relation.
Couche référencée (Parent) également considérée comme couche parent, est celle dont la clé primaire est pointée, donc ici c’est la couche regions. Vous devez définir la clé primaire de la couche référencée, c’est donc ID.
Référencement de la couche (enfant) également considérée comme la couche enfant, est celle sur laquelle se trouve le champ clé étrangère. Dans notre cas, il s’agit de la couche airports. Pour cette couche, vous devez ajouter un champ de référencement qui pointe vers l’autre couche, c’est donc la fk_region.

Note

Parfois, il faut plus qu’un seul champ pour identifier de manière unique les éléments d’une couche. Pour créer une relation avec une telle couche, il faut une clé composite, c’est-à-dire plus qu’une seule paire de champs correspondants. Utilisez le bouton ^{Ajouter une nouvelle paire de champ pour créer une clé composite} pour ajouter autant de paires que nécessaire.
Id sera utilisée pour des besoins internes et doit être unique. Vous pourriez en avoir besoin pour créer des formulaires personnalisés. Si vous laissez ce champ vide, un numéro sera généré automatiquement mais vous pouvez en assigner un si vous le souhaitez.
Force de la relation définit la force de la relation entre les couches parent et enfant. Le type par défaut Association signifie que la couche parente est seulement liée à la couche enfant. En revanche le type Composition permet de copier les entités enfantes lors de la copie d’une entité parente, ou de les supprimer lors de la suppression d’une entité parente. Cela provoque une cascade sur tous les niveaux (les enfants des enfants sont également supprimés).

../../../_images/regions_airports_mapping.png — Fig. 12.108 Ajout d’une relation entre les couches regions et airports

Depuis l’onglet Relations, vous pouvez également appuyer sur le bouton Découvrir relation pour récupérer les relations disponibles auprès des fournisseurs des couches chargées. Ceci est possible pour les couches stockées dans des fournisseurs de données comme PostgreSQL ou SpatiaLite.

Formulaires pour les relations de 1 à n 

Maintenant que QGIS a bien généré la relation, le formulaire d’édition va être amélioré. Nous n’avons pas modifié le formulaire d’édition par défaut (généré automatiquement), une nouvelle zone va simplement être ajoutée au formulaire. Sélectionnez la couche de régions dans la légende et utilisez l’outil d’identification. Selon vos préférences, le formulaire s’ouvre directement ou vous devez le faire via la zone d’identification qui s’affiche.

../../../_images/airport_relation_dataview.png — Fig. 12.109 Formulaire de la couche des régions affichant la relation avec les aéroports

Comme vous pouvez le voir, les aéroports liés à cette région en particulier sont tous visibles dans la table. Il y a également quelques boutons disponibles ; passons-les en revue rapidement :

Le bouton permet de passer en mode édition. Soyez conscients qu’il active le mode édition de la couche des aéroports bien qu’il soit situé dans le formulaire de la couche des régions. La table affiche bien les entités de la couche des aéroports.
Le bouton permet de sauvegarder toutes les modifications effectuées dans la couche fille (aéroport).
Le bouton permet de numériser la géométrie de l’aéroport dans la zone cartographique et l’associe par défaut à la région courante. Notez que l’icône s’adapte au type de géométrie (point, ligne, polygone).
Le bouton ajoute une nouvelle ligne dans la table d’attributs de la couche aéroport et l’associe à la région courante. La géométrie peut être dessinée ultérieurement avec l’outil Ajouter.
Le bouton copie une ou plusieurs entités enfant au sein de la même couche. Les copies peuvent ensuite être réaffectées à une autre entité parente ou voir leurs attributs modifiés.
Le bouton supprime définitivement les entités (aéroports ici) sélectionnées.
Le symbole ouvre une boîte de dialogue pour sélectionner un aéroport existant et l’assigner à la région courante. Utile si un aéroport a été créé par erreur dans une autre région.
Le symbole dissocie le(s) aéroport(s) sélectionné(s) de la région courante et le laisse « non assigné » (le champ « Région » est défini sur NULL).
Avec le bouton vous pouvez zoomer sur les entités enfant sélectionnées.
Les deux boutons et à droite font basculer entre la vue tabulaire et formulaire des entités enfant liées.

Si vous utilisez le Drag and Drop Designer pour les entités de la couche région, vous pouvez sélectionner les outils disponibles. Vous pouvez décider de masquer le formulaire lorsqu’une entité est ajoutée avec l’option Force hide form on add feature. Sachez que cette option implique que les valeurs par défaut soient définies pour les attributs ne pouvant pas être nuls.

../../../_images/airport_relation_formproperties.png — Fig. 12.110 Concepteur par glisser/déposer pour la configuration des outils de relation region-aéroports

Dans l’exemple ci-dessus, la couche référence à des géométries (ce n’est pas seulement une table alphanumérique) ce qui implique que les étapes citées créeront une entrée dans la table d’attribut qui n’aura pas de géométrie correspondante. Pour ajouter une géométrie :

Choisir Ouvrir la table d’attributs pour la couche référence.
Sélectionner l’enregistrement ajouté précédemment dans le formulaire d’entité de la couche référence .
Utiliser l’outil de numérisation ^{Ajouter une partie} pour attacher une géométrie à l’entité sélectionnée dans la table attributaire.

Si vous travaillez dans la table d’attributs des aéroports, le widget Relation de référence sera automatiquement réglé sur le champ fk_region (celui utilisée pour créer la relation); voir le Widget de Relation de référence.

Dans le formulaire des aéroports, vous voyez le bouton à droite du champ fk_region : si vous cliquez sur le bouton, le formulaire de la couche région s’ouvrira. Ce widget vous permet d’ouvrir et modifier rapidement les formulaires des entités parent liées.

../../../_images/airport_attributes.png — Fig. 12.111 Formulaire d’identification d’un aéroport et de sa région associée

Le widget de Relation de référence a également une option pour incruster le formulaire de la couche parent dans celui de la couche enfant. Il est disponible depuis le menu Propriétés ► Formulaire d’attributs de la couche des aéroports : sélectionner le champ fk_region et cocher l’option Montrer le formulaire incrusté

Vous devriez ainsi voir que le formulaire de la région est inclus dans celui d’un aéroport et il vous permet via une liste déroulante de modifier la région assignée à l’aéroport.

../../../_images/airport_attributes_expanded.png

De plus, si vous basculez la couche aéroport en mode édition, le champ fk_region aura également une fonctionnalité d’autocomplétion. De ce fait, tout en complétant le champ, vous verrez toutes les valeurs du champ id de la couche des régions. Si vous activez l’option Autoriser l'ajout de nouvelles entités disponible dans le menu Propriétés ► Formulaire d’attributs de la couche des aéroports, il est également possible de numériser un nouveau polygone pour la couche région en utilisant le bouton .

La couche enfant peut également être utilisée dans l’outil Sélectionner des Entités par Valeur afin de sélectionner les entités de la couche parent en fonction des attributs de leurs enfants.

Dans Fig. 12.112, toutes les régions où l’altitude moyenne des aéroports est supérieure à 500 mètres au-dessus du niveau de la mer sont sélectionnées.

Vous constaterez que de nombreuses fonctions d’agrégation différentes sont disponibles dans le formulaire.

../../../_images/relation_select_by_value.png — Fig. 12.112 Sélectionner les entités des parents avec les valeurs des enfants

12.4.2.2. Relations plusieurs à plusieurs (N-M)

Les relations de n à n sont des relations de plusieurs à plusieurs entre deux tables. Par exemple, les couches airports et airlines: un aéroport reçoit plusieurs compagnies aériennes et une compagnie aérienne utilise plusieurs aéroports.

Ce code SQL crée les trois tables dont nous avons besoin pour une relation de n à n dans un schéma PostgreSQL/PostGIS nommé locations. Vous pouvez lancer le code en utilisant Base de données ► DB Manager… pour PostGIS ou des outils extérieurs tels que pgAdmin. La table des aéroports stocke la couche airports et la table airlines stocke des lignes aériennes. Dans les deux tables, il y a peu de champs, pour faire simple. La partie délicate est la table airports_airlines. Il faut qu’elle compile toutes les lignes aériennes pour tous les aéroports (et vice versa). Ce genre de table s’appelle une table pivot. Les contraintes de cette table ne rendent possible l’association d’un aéroport avec une ligne que si les deux existent déjà dans leurs couches.

CREATE SCHEMA locations;

CREATE TABLE locations.airports
(
   id serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   airport_name text NOT NULL,
   CONSTRAINT airports_pkey PRIMARY KEY (id)
);

CREATE INDEX airports_geom_idx ON locations.airports USING gist (geom);

CREATE TABLE locations.airlines
(
   id serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   airline_name text NOT NULL,
   CONSTRAINT airlines_pkey PRIMARY KEY (id)
);

CREATE INDEX airlines_geom_idx ON locations.airlines USING gist (geom);

CREATE TABLE locations.airports_airlines
(
   id serial NOT NULL,
   airport_fk integer NOT NULL,
   airline_fk integer NOT NULL,
   CONSTRAINT airports_airlines_pkey PRIMARY KEY (id),
   CONSTRAINT airports_airlines_airport_fk_fkey FOREIGN KEY (airport_fk)
      REFERENCES locations.airports (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED,
   CONSTRAINT airports_airlines_airline_fk_fkey FOREIGN KEY (airline_fk)
      REFERENCES locations.airlines (id)
      ON DELETE CASCADE
      ON UPDATE CASCADE
      DEFERRABLE INITIALLY DEFERRED
 );

Au lieu de PostgreSQL, vous pouvez utiliser GeoPackage. Dans ce cas, les trois tables sont créées manuellement avec le menu Base de données ► DB Manager…. Dans GeoPackage, il n’y a pas de schémas, donc le préfixe locations n’est pas requis.

Les contraintes de clé étrangère dans la table airports_airlines ne peuvent être créées en utilisant Table ► Créer une Table… ou Table ► Modifier une table…. Elles doivent donc être créées en sélectionnant Base de données ► Fenêtre SQL…. GeoPackage n’accepte pas les déclarations ADD CONSTRAINT ce qui fait que la table airports_airlines doit être créée en deux étapes :

Créer la table avec seulement le champ id en utilisant Table ► Créer une Table…

Avec Base de données ► Fenêtre SQL…, copier et exécuter ce code SQL :

ALTER TABLE airports_airlines
   ADD COLUMN airport_fk INTEGER
   REFERENCES airports (id)
   ON DELETE CASCADE
   ON UPDATE CASCADE
   DEFERRABLE INITIALLY DEFERRED;

ALTER TABLE airports_airlines
   ADD COLUMN airline_fk INTEGER
   REFERENCES airlines (id)
   ON DELETE CASCADE
   ON UPDATE CASCADE
   DEFERRABLE INITIALLY DEFERRED;

Puis dans QGIS, vous devez établir deux relations « un à plusieurs » comme expliqué au-dessus :

une relation entre la table airlines et la table pivot ;
et une seconde entre la table airports et la table pivot.

Une façon plus simple de faire cela (seulement pour PostgreSQL) est d’utiliser Découvrir des relations dans Projet ► Propriétés ► Relations. QGIS lit automatiquement toutes les relations de votre base de données et vous n’avez qu’à sélectionner les deux dont vous avez besoin. Pensez à charger les trois tables dans le projet QGIS d’abord.

../../../_images/airports_airlines_relation.png — Fig. 12.113 Relations et découverte automatique

Si vous souhaitez supprimer un airport ou une airline, QGIS ne supprimera pas la ou les entité(s) associée(s) dans la table airports_airlines. Cette tâche sera effectuée par la base de données si nous lui fournissons les bonnes contraintes lors de la création de la table pivot comme dans l’exemple actuel.

Note

Combiner des relations de n à n avec un groupe de transaction automatique

Vous devez activer le mode de transaction dans Propriétés du projet ► Sources de données ► quand vous travaillez dans de tels contextes. QGIS doit pouvoir ajouter ou mettre à jour un ou plusieurs champs dans toutes les tables (lignes aériennes, aéroports et les tables pivot).

Pour finir il faut sélectionner la bonne cardinalité dans Layer Properties ► Attributes Form pour les couches airports et airlines. Pour la première il faut choisir l’option airlines (id) et pour la seconde l’option airports (id).

../../../_images/airports_airlines_relation_formproperties.png — Fig. 12.114 Régler la relation de cardinalité

Vous pouvez maintenant associer un aéroport avec une ligne aérienne (ou une ligne aérienne avec un aéroport) en utilisant Ajouter une entité enfant ou Lier à une entité enfant existante dans les sous-formulaires. Un enregistrement sera automatiquement inséré dans la table airports_airlines.

../../../_images/add_airport_airline.png — Fig. 12.115 relation de n à n entre aéroports et lignes aériennes

Note

Utiliser la cardinalité Relation de n à 1

Il n’est parfois pas souhaitable de cacher la table pivot dans une relation de n à n. Principalement parce qu’il y a des attributs dans cette relation qui ne peuvent avoir de valeurs que lorsque la relation est établie. Si vos tables sont des couches (qui ont un champ géométrie), il peut être intéressant d’activer l’option Identification sur la carte (Propriétés de la couche ► Formulaire d’attributs ► Outils disponibles ► Champs) pour les champs de clé étrangère dans la table pivot.

Note

Clé primaire de la table pivot

Évitez d’utiliser des champs multiples dans la clé primaire de la table pivot. QGIS attend une clé primaire unique donc une contrainte comme constraint airports_airlines_pkey primary key (airport_fk, airline_fk) ne fonctionnera pas.

12.4.2.3. Les relations polymorphiques 

L’objectif 

Les relations polymorphiques sont des cas particuliers de relations 1-N où une couche de référence peut faire référence aux enregistrements de plusieurs autres couches contrairement aux relations habituelles dans lesquelles elle ne ferait référence qu’aux enregistrements d’une seule autre couche. Cette relation est mise en place par l’ajout d’un champ supplémentaire layer_field dans la couche de référence qui va enregistrer l’identifiant de la couche référencée. Dans la forme la plus simple, cet identifiant sera le nom de la couche.

Vu autrement, une relation polymorphique est un ensemble de relations qui ont la même couche de référence mais des couches référençantes définies dynamiquement. Cette définition utilise une expression qui doit correspondre à des propriétés définies de la couche référençante comme son id ou son nom.

Imaginez que nous allions au parc pour prendre des photos de différentes espèces de plantes et d”animaux. Chaque plante ou animal peut avoir plusieurs photos associées. Si nous utilisons des relations 1-N classiques pour enregistrer ces images, nous aurions besoin de deux tables distinctes, image_plante et image_animal. Cela ne serait peut-être pas un problème pour deux tables, mais imaginez que nous souhaitions également prendre des photos de champignons, d’oiseaux etc.

Les relations polymorphiques sont une solution à ce problème car toutes les entités référençantes sont enregistrées dans la même table documents. Pour chaque entité la couche de référence est stockée dans le champ `` referenced_layer`` et l’identifiant de l’entité de référence dans le champ referenced_id.

Définir les relations polymorphiques 

Premièrement, il faut indiquer à QGIS l’existence d’une relation polymorphique entre les couches. Cela se paramètre dans Project ► Properties…. Ouvrez l’onglet Relations et cliquez sur la petite flèche bas proche du bouton Ajouter une relation, pour sélectionner l’option Ajouter une relation polymorphique dans la liste qui apparaît.

../../../_images/polymorphic_relation_properties.png — Fig. 12.116 Ajout d’une relation polymorphique en utilisant `documents` comme couche référençante et `plants` et `animals` comme couches référencées.

Id sera utilisée pour des besoins internes et doit être unique. Vous pourriez en avoir besoin pour créer des formulaires personnalisés. Si vous laissez ce champ vide, un numéro sera généré automatiquement mais vous pouvez en assigner un si vous le souhaitez.
Couche référençante aussi considérée comme couche enfant est la couche comportant le champ de clé étrangère. Dans ce cas il s’agit de la couche documents. Pour cette couche, il faut ajouter un champ de liaison avec l’autre couche, il s’agit de referenced_id.

Note

Parfois, il faut plus qu’un seul champ pour identifier de manière unique les éléments d’une couche. Pour créer une relation avec une telle couche, il faut une clé composite, c’est-à-dire plus qu’une seule paire de champs correspondants. Utilisez le bouton ^{Ajouter une nouvelle paire de champ pour créer une clé composite} pour ajouter autant de paires que nécessaire.
Layer Field indique le champ de la couche référençante contenant le résultat de l’expression de champ de couche. Cette expression indique la couche à laquelle l’entité appartient. Dans ce cas il s’agit du champ referenced_layer.
Expression de champ de couche définit un identifiant unique de couche. Il peut s’agir du nom de la couche @layer_name, de son identifiant @layer_id, du nom de la table decode_uri(@layer, 'table') ou d’un autre élément permettant une identification unique d’une couche.
Force de la relation définit la force de la relation entre les couches parent et enfant. Le type Association par défaut signifie que la couche parent est seulement liée aux enfants tandis que le type Composition permet de copier les entités des couches enfants lorsque les entités parentes sont copiées. Il en va de même lors de la suppression d’une entité parente qui implique la suppression en cascade des entités enfants (et de même pour les enfants des enfants).
Couches référencées, également appelées couches parentes, définit les couches contenant les clés primaires vers lesquelles la relation pointe. Ici il s’agit des couches plants et animals. Vous devez définir les clés primaires des couches référencées dans la liste déroulante, il s’agit donc de fid. Retenez que la clé primaire spécifiée implique que toutes les couches référencées disposent d’un champ avec ce nom. Si ce n’est pas le cas vous ne pouvez pas enregistrer la relation.

Une fois créée, la relation polymorphique peut être éditée avec l’option Modifier une relation polymorphique dans le menu ouvert en cliquant sur la flèche bas à droite du bouton Ajouter une relation

../../../_images/polymorphic_relations.png — Fig. 12.117 Previsualisation de la nouvelle relation polymorphique et de ses relations enfants pour animals et plants

L’exemple ci-dessus utilise le schéma de base de données suivant :

CREATE SCHEMA park;

CREATE TABLE park.animals
(
   fid serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   animal_species text NOT NULL,
   CONSTRAINT animals_pkey PRIMARY KEY (fid)
);

CREATE INDEX animals_geom_idx ON park.animals USING gist (geom);

CREATE TABLE park.plants
(
   fid serial NOT NULL,
   geom geometry(Point, 4326) NOT NULL,
   plant_species text NOT NULL,
   CONSTRAINT plants_pkey PRIMARY KEY (fid)
);

CREATE INDEX plants_geom_idx ON park.plants USING gist (geom);

CREATE TABLE park.documents
(
   fid serial NOT NULL,
   referenced_layer text NOT NULL,
   referenced_id integer NOT NULL,
   image_filename text NOT NULL,
   CONSTRAINT documents_pkey PRIMARY KEY (fid)
);