Bonjour,
 
J'ai pour l'instant 3 relations.
 
Mettons que la première stocke différents types de jeux en équipe avec pour chacun, le nombre minimum de joueurs nécessaires (jeu, nb_joueurs_min)
Une aute relation stocke différents noms d'équipes en leur associant le nombre de personnes qui les constituent (equipe, nb_joueurs)
 
j'aimerais mettre les équipes et les types de jeux dans une troisième relation en assurant que l'équipe contient assez de personnes pour pouvoir jouer au jeu en question.
 
Comment puis-je exprimer cette contrainte en SQL ?
 
Merci d'avance

Tu mélanges relations et tables dans une grande soupe, on dirait.
 
Si j'ai bien compris ce que tu veux, c'est un trigger qu'il te faut.

Une relation n'est-elle pas la "description" d'une table ? Peux-tu m'expliquer la nuance ?
 
Et mes recherches m'ont bien amené à me renseigner sur les triggers, mais si je demande c'est que je ne vois pas comment écrire ce dont j'ai besoin

Non, ce que tu dis est correct, mais c'est une terminologie peu usitée - sauf sans doute pour se la pêter, comme le font les linguistes avec le vocabulaire ou comme quand j'utilise des locutions latines sur ce forum.
 
Parce qu'on peut parler de relation (table) et de relation (relation). Dans le dernier paragraphe, j'ai cru que tu parlais de relation (relation) au lieu de relation (table), ce qui aurait été confus. Parce qu'en fait, on peut aussi parler de relation (relation) entre tes deux relations (tables), tu me suis ?
 
Sinon, pour les tiggerz, beeeh, eh ! Fais des essais avec des triggers simples (p.e. empêcher l'insertion d'une équipe de plus de 4 joueurs ou que sais-je) pour te faire la main et observe les réactions offusquées de ton DBMS. Ca te paraitra limpide.

Ok pour le relation-table, c'est qu'en fait je débute et que mes profs aiment bien parler de relation plutôt que de table, ils restent dans leur bulle théorique et moi je les suis bêtement
 
Je vois comment poser des contraintes simples du genre CHECK (nb_joueurs < 5), mais c'est quand il s'agit d'aller regarder des valeurs dans les tables voisines que ça me chagrine... Enfin je vais bien finir par mettre la main sur un exemple
 
Merci quand même.

Garde toujours un oeil critique.
 

Beh, rien ne t'empêche de faire un SELECT avoir une jointure dans ton trigger, non ?

En fait on n'a pas étudié la création des triggers
 
Et je ne sais pas du tout si un SELECT dans un CHECK est faisable... Enfin je peux tenter.
 
Je vais peut-être gérer cette contrainte dans l'appli qui chapeaute la base si il n'y a pas de moyen simple d'écrire ça simplement, de toute façon.

Et bien voilà une belle occasion de briller.

 

Un exemple pris au hasard (c'est du Sybase mais ça s'applique mutatis mutandis à d'autres DBMS) :
 

 
Ca devrait aller, non ?
 
 

L'idéal est de faire les deux - et d'expliquer pq à tes profs. Ceci dit, contrairement à ce qu'on apprend à l'école, il existe des DB sans aucune contrainte d'intégrité (pas de relations entre tables, que dalle), mais ce n'est pas très didactique, on va dire.
 
Bon, si c'est pour un cours de DB, tu serais sans doute mieux inspiré de travailler au niveau DB et de pondre un beau trigger bien robuste.  

Je vais tenter de comprendre ton exemple, ça a l'air relativement abordable
 
Et effectivement, le cours porte sur la BD mais on s'est attardé d'avantage sur la conception (schéma E-A) que sur la gestion des contraintes en SQL, où ce fut assez basique (ON DELETE CASCADE, FOREIGN KEY et basta). Les profs nous laissant implémenter les contraintes un peu complexes dans l'appli java, je ne voulais pas pousser trop loin.
 
Merci pour tes réponses, il faut maintenant que je taquine postresql en priant pour qu'oracle se comporte de façon similaire