📊 Comprendre les relations 1-N et N-1 en PostgreSQL : guide pratique pour mieux interroger vos tables

👉 Objectif de l’ article : vous apprendre à identifier facilement les relations entre tables PostgreSQL — en particulier les relations un-à-plusieurs (1-N) et plusieurs-à-un (N-1) — à l’aide de requêtes SQL simples.

Que vous soyez développeur, analyste ou architecte, cette compréhension est essentielle pour modéliser vos données, écrire des jointures pertinentes et fiabiliser votre code.

Dans une base de données relationnelle, bien concevoir les relations entre les tables PostgreSQL est essentiel pour garantir la cohérence des données et la performance des requêtes. Parmi les types de relations les plus courants en SQL, on retrouve les relations un-à-plusieurs (1-N) et plusieurs-à-un (N-1). Ces liens logiques structurent les interactions entre entités dans un schéma de base de données.

👉 Dans cet article, nous allons vous montrer comment identifier ces relations entre les tables PostgreSQL en utilisant deux requêtes SQL simples.

🤖 Marius, toujours dans la base, souffle :

« On ne touche pas à une jointure sans connaître les relations entre les tables… parole de DBA ! »

Bonjour !

Je suis Jean-Marc HENRY, ingénieur ESI, consultant IT/IS pour les entreprises depuis plus de 35 ans, et fondateur de LMVI Conseil.

À travers ce blog, je vous propose d’explorer ensemble tous les 15 jours les grands ou petits (!) sujets de l’informatique.

Ici, on parlera de sujets qui me servent quotidiennement et qui me tiennent à cœur, comme le Nocode, l’IA, l’IT, l’IS ou l’architecture logicielle et un peu WSO2.

D’ailleurs, je ne suis pas seul à rédiger ces billets !

Je suis accompagné de mon assistant IA prénommé Marius. C’est un bon pote d’Ollama et de ChatGPT (entre autres, car il a un sacré réseau !).

Il est assez secret et ne me dit pas tout sur la manière dont il m’aide à écrire mes articles. En revanche, je ne publie rien qui n’ait été validé par des sources sûres ou testé !

C’est parti, on vous embarque !

1- 🔍 Identifier les relations 1-N dans les tables PostgreSQL

****

Vous souhaitez connaître toutes les tables qui dépendent d’une table spécifique (ici product) via une clé étrangère ? C’est exactement ce que permet la première requête.

🤖 Marius ajoute en coin de terminal* : *

« 1 produit, plusieurs commandes ? Classique. Voici comment le voir noir sur blanc. »

SELECT kcu.constraint_name AS fk_name, kcu.table_name AS foreign_table_name, kcu.column_name AS foreign_column_name, ccu.table_name AS referenced_table_name, ccu.column_name AS referenced_column_name FROM information_schema.key_column_usage AS kcu JOIN information_schema.constraint_column_usage AS ccu ON kcu.constraint_name = ccu.constraint_name WHERE ccu.table_name = ‘product’ AND kcu.table_name <> ccu.table_name;

🧠 À retenir

• information_schema.key_column_usage : cette vue répertorie les colonnes impliquées dans les contraintes de clés étrangères.

• information_schema.constraint_column_usage : elle indique les colonnes qui sont référencées par ces contraintes.

• JOIN : les deux vues sont reliées via le nom de la contrainte, ce qui permet d’associer chaque clé étrangère à sa colonne de référence.

• WHERE : ce filtre cible uniquement les contraintes où la table référencée est product, tout en excluant les cas d’auto-référence.

👉 Résultat attendu

La requête retourne toutes les tables qui possèdent une clé étrangère pointant vers la table productdans une relation 1-N. Cela signifie que chaque ligne de la table product peut être associée à aucune ou plusieurs lignes dans d’autres tables, via des clés étrangères.

2- 🔄 Trouver les relations N-1 : qui référence quoi dans PostgreSQL ?

****

Vous cherchez maintenant à savoir quelles sont les clés étrangères présentes dans la table product ? C’est-à-dire, dans quelles tables product va chercher ses références (relation de type N-1) ? Voici la requête à utiliser :

SELECT kcu.constraint_name AS fk_name, kcu.table_name AS foreign_table_name, kcu.column_name AS foreign_column_name, ccu.table_name AS referenced_table_name, ccu.column_name AS referenced_column_name FROM information_schema.key_column_usage AS kcu JOIN information_schema.constraint_column_usage AS ccu ON kcu.constraint_name = ccu.constraint_name WHERE kcu.table_name = ‘product’ AND kcu.table_name <> ccu.table_name;

💡 À comprendre

La requête retourne toutes les tables que product référence via les clés étrangères déclarées dans la table product. Cela indique que pour chaque enregistrement dans product, il existe un enregistrement correspondant dans la table référencée — typique d’une relation N-1.

On est ici dans le cadre d’une relation plusieurs-à-un (N-1) : plusieurs enregistrements de product peuvent référencer une même ligne dans une table externe, via une clé étrangère.

✅ Pourquoi ces requêtes sont utiles ?

Repérer clairement les relations 1-N ou N-1 vous permet de :

• Visualiser la structure relationnelle de votre base de données sans outil tiers

• Éviter les erreurs de jointures SQL dans vos requêtes complexes

• Faciliter l’écriture de vues, de rapports ou de scripts d’export

• Auditer l’intégrité référentielle d’un modèle existant

Et surtout, dans un contexte de maintenance ou de documentation d’une base, ces requêtes vous évitent de parcourir manuellement chaque table du schéma.

🤖 Marius valide* : *

« Rien de tel qu’un bon information_schema pour échapper aux diagrammes flous en PDF. »

🎯 Conclusion

Comprendre les relations entre les tables est essentiel pour naviguer efficacement dans une base de données relationnelle.

Grâce aux requêtes présentées ici, vous pouvez :

• Identifier rapidement les relations 1-N et N-1 de la table product

• Mieux concevoir vos schémas de données

• Optimiser vos requêtes SQL

• Faciliter la maintenance de votre base

🔁 Il vous suffit de remplacer product par le nom de la table de votre choix pour explorer les relations dans votre propre base de données.

🤖 Le mot de la fin de Marius

« Ces vues système sont verbeuses, mais elles disent tout. Il suffit de leur poser les bonnes questions. »

** Vous utilisez une autre méthode ? Vous avez un retour d’expérience ou un piège à éviter ?**

Partagez-le en commentaire ou contactez-moi via lmvi-conseil.fr. On aime bien les scripts qui marchent… et les projets bien câblés.

Bonne intégration à tous !

Qui sommes-nous ?

---

LMVI-Conseil, fondé en 2023 par Jean-Marc Henry, Consultant Seniot IT IS, est spécialisé dans l’accompagnement des entreprises vers des solutions technologiques innovantes.

Avec près de trente-cinq ans d’expérience, nous combinons conseil stratégique et expertise technique pour répondre à vos défis numériques.

Nous Contacter