Discussion :

[Lepetitpanda]

Bonjour à tous !

Vous allez très certainement pouvoir me renseigné.

Salut ! J'aurais une question SQL dont j'ai malheureusement pas trouvé d'exemple pour comprendre : Exemple concret avec le schéma conceptuel puis la traduction en schéma relationnel puis la traduction en SQL. Comment traduire concrètement les constraint.

Souvent on a ça que pour les héritages, concepts que je trouve le plus simple à comprendre en réalité.


Les constraint de disjonction ce représentes-elles de la même manière que les constraint de non disjonction? Faut t'il utilisé les triggers ? (sachant que certains outils ne les prennent pas encore en compte. Exemple : Mysql)



Merci pour votre aide qui me permettra de comprend ce dernier morceau SQL



J'ai rencontrer le cas pour un de mes projets :

[escartefigue]

Bonjour,

Exemple concret avec le schéma conceptuel puis la traduction en schéma relationnel puis la traduction en SQL.

Ce schéma conceptuel est erroné : la contrainte d'inclusion ne doit pas aller d'une type d'entité vers une association, mais d'une association vers une autre.
Pour pouvoir vous renseigner sur la bonne modélisation, il faut que vous communiquiez vos règles de gestion. Le MCD n'étant que la traduction sous forme graphique de ces règles

Comment traduire concrètement les constraint.

Un contrainte d'inclusion se traduit dans le code SQL de création de la table concernée par un instruction de type
CONSTRAINT Ma_contrainte_FK FOREIGN KEY (Ma_colonne) REFERENCES Mon_autre_table(Mon_autre_colonne).

Les constraint de disjonction ce représentes-elles de la même manière que les constraint de non disjonction?

La symbolique est la même, mais la lettre change en fonction du type de contrainte : I pour inclusion, X pour exclusion, T pour totalité, XT pour partition et S pour simultanéité

sachant que certains outils ne les prennent pas encore en compte. Exemple : Mysql

Faux, d'une part MySQL n'est pas un outil mais un SGBD, d'autre part MySQL connait les triggers BEFORE et AFTER, mais pas les INSTEAD OF



Je vous recommande par ailleurs de réaliser vos MCD avec un logiciel fait pour, ce sera autrement plus présentable que ce que vous avez posté ici, et surtout, ça permet de gérer les versions, de créer le MLD et enfin le script SQL.

Parmi les logiciels gratuits, il y a le petit (mais costaud ) nouveau, Looping, conçu par Paprick, un contributeur du forum.
C'est un logiciel facile d'utilisation et riche en fonctionnalités
Vous pouvez le télécharger ici : https://www.looping-mcd.fr/

[Lepetitpanda]

Wep effectivement je me suis planté. A la base la contrainte aller de "répondre" vers "posséder". J'ai recopier au propre mon ancienne base (que j'avais modélisé en mode brouillons / réflexion) et j'ai crée une erreur. C'est d'entité vers entité et de association vers association il me semble, c'est bien ça? Je cherche à comprendre / perfectionné cette partie de SQL donc je prend vos critiques en compte pour modifier cela.

Je vais refaire cela au propre du coup avec le logiciel que vous me conseillez. Mon prof était très papier (ancienne école mais compétent) pour cela que j'ai modélisé ainsi. Il refusait d'ailleurs de corrigé sur autre chose que papier héhé. Je dois dire que j'avais jamais entendu parler de celui-ci. Merci pour la référence qui m'a l'air vraiment sympa.

Oui je sais que MySQl est une SGBD. Mon prof disait qu'on pouvait le mettre mais qu'il ne prenait pas en compte les constraint de ce type. Est-ce encore le cas? Idem pour les triggers, il est possible de faire cela et que ce soit pris en compte? (Comme sur PostgreSql par exemple : Qui m'a l'air plus complet de ce coté là).



=> Une utilisateur peut déposer aucune ou plusieurs vidéos / Une vidéo appartient à une et une seule personne (0, n / 1,1)

=> Pour chaque vidéo l'utilisateur répond à une ou plusieurs questions . Une question peut être répondu par aucune ou plusieurs personnes (comme la personne peut ne pas posséder une vidéo)

=> Une question peut correspondre à une ou plusieurs vidéos / une vidéo a une ou plusieurs questions qui lui correspond / concerne.


Pour qu'une utilisateur répond à une question il faut forcement qu'il possède une vidéo. (j'aurais pu faire du 1,N pour utilisateur => question ; utilisateurs => vidéo ).

Citation Envoyé par Lepetitpanda Voir le message
Les constraint de disjonction ce représentes-elles de la même manière que les constraint de non disjonction?

La symbolique est la même, mais la lettre change en fonction du type de contrainte : I pour inclusion, X pour exclusion, T pour totalité, XT pour partition et S pour simultanéité

Ou précisez-vous les raccourci que je connaissais déjà pour le coup. dans la ligne sql?. Comment modélisez-vous cela en schéma relationnel?

CONSTRAINT Ma_contrainte_FK FOREIGN KEY (Ma_colonne) REFERENCES Mon_autre_table(Mon_autre_colonne)

Merci pour le temps que vous passez à me répondre

[escartefigue]

Il y a plusieurs choses qui me semblent incorrectes

Tout d'abord, je suppose qu'il s'agit d'un QCM. L'utilisateur ne fournit pas des réponses libres, mais choisit parmi un panel de réponses possibles pour la question. Exact ?
Ensuite, il y a probablement plusieurs exemplaires d'une même vidéo, Aussi bien Paul que Martine peuvent posséder un exemplaire de "Paris Texas". Exact ?

Si les hypothèses ci-dessus sont avérées, je propose le modèle suivant (réalisé avec looping) :

Pièce jointe 552349

Le (R) sur certaines cardinalités symbolise l'identification relative.
Par exemple : l'exemplaire d'une vidéo est identifié relativement à la vidéo, ce qui signifie que la primary key (PK) de la vidéo participe à la PK de l'exemplaire.

La contrainte d'inclusion est matérialisée entre les associations "fournir" et "posséder" : on ne peut fournir une réponse à une question (qui concerne telle vidéo) que si on possède un exemplaire de cette vidéo.
La question étant identifiée d'une part relativement à l'utilisateur et d'autre part relativement à la question.
LA question est elle-même identifiée relativement à la vidéo
Du coup, la PK d'une question est identifiant utilisateur + identifiant vidéo + identifiant question + identifiant réponse.
Au niveau SQL, la contrainte d'inclusion se matérialisera par la vérification de la présence du couple id utilisateur + id vidéo dans la table issue de l'association "posséder"

Le DDL de création des différentes tables issues de ce MCD est donc le suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
CREATE TABLE UT_utilisateur(
   UT_ident COUNTER,
   UT_nom VARCHAR(50) NOT NULL,
   UT_prenom VARCHAR(50) NOT NULL,
   PRIMARY KEY(UT_ident)
);
 
CREATE TABLE VD_video(
   VD_ident COUNTER,
   VD_titre VARCHAR(255) NOT NULL,
   VD_annee CHAR(4) NOT NULL,
   PRIMARY KEY(VD_ident)
);
 
CREATE TABLE EX_exemplaire(
   UT_ident INT,
   VD_ident INT,
   EX_ident COUNTER,
   EX_code_barre CHAR(13) NOT NULL UNIQUE,
   PRIMARY KEY(UT_ident, VD_ident, EX_ident),
   FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident),
   FOREIGN KEY(VD_ident) REFERENCES VD_video(VD_ident)
);
 
CREATE TABLE QS_question(
   VD_ident INT,
   QS_ident COUNTER,
   QS_libelle VARCHAR(255) NOT NULL,
   PRIMARY KEY(VD_ident, QS_ident),
   FOREIGN KEY(VD_ident) REFERENCES VD_video(VD_ident)
);
 
CREATE TABLE RR_reponse(
   UT_ident INT,
   VD_ident INT,
   QS_ident INT,
   RR_ident COUNTER,
   RR_libelle VARCHAR(255),
   PRIMARY KEY(UT_ident, VD_ident, QS_ident, RR_ident),
   FOREIGN KEY(UT_ident) REFERENCES UT_utilisateur(UT_ident),
   FOREIGN KEY(VD_ident, QS_ident) REFERENCES QS_question(VD_ident, QS_ident)
   FOREIGN KEY(UT_ident, VD_ident) REFERENCES EX_exemplaire(UT_ident, VD_ident)
);

La dernière ligne du script ci-dessus correspond à la contrainte d'inclusion

[Lepetitpanda]

Merci pour ta super explication. Effectivement j'avais pas pensé à tout ça. Hum peut être un défaut du cheminement de ma réflexion dés le départ. Va falloir que je fasse plus gaffe à bien respecter les étapes et gagner en expérience par les exercices.

Bah ça m'a l'air de mieux correspondre aux règles de gestion effectivement du point de vue purement logique. Vous auriez des exercices corrigés sous la main pour m'exercer car là y'a plus de taff que je pensais pour en maitriser la conception visiblement.


J'avais pas non plus trouvé d'exemple sur ça dans le cours que j'avais suivis aussi ici pour apprendre en parallèle de mon prof. Du coup merci et j'espère que ça servira à d'autres.


Je laisse répondre puis je mettrais en résolu.

[escartefigue]

Il y a une section consacrée à la modélisation, elle se trouve là :
https://www.developpez.net/forums/f6...sation/schema/

Et dans cette section, certains des nombreux ouvrages qui abordent ce sujet sont référencés ici :
https://www.developpez.net/forums/d5...s-telecharger/

[escartefigue]

Mon prof disait qu'on pouvait le mettre mais qu'il ne prenait pas en compte les constraint de ce type. Est-ce encore le cas? Idem pour les triggers, il est possible de faire cela et que ce soit pris en compte? (Comme sur PostgreSql par exemple : Qui m'a l'air plus complet de ce coté là).

Soit vous avez mal compris, soit votre professeur a besoin de recyclage !
MySQL propose deux moteurs : Innodb et MyIsam. Effectivement, MyIsam ignore les contraintes de type reference (on peut les déclarer dans le script, mais elle sont ignorées et ne servent donc à rien ), par contre, le moteur Innodb applique les contraintes, comme à peu près tous les SGBD-R. Vous l'aurez compris, MyIsam est un vieux coucou, à ne plus utiliser !
Pour les triggers, comme expliqué plus haut, MySQL les connait sauf les triggers "instead of".
Il faut savoir que MySQL a le mérite d'être gratuit mais présente pas mal de lacunes fonctionnelles et d'écarts par rapport aux normes SQL.
La version 8 de MySQL a comblé certaines de ces lacunes, mais il en reste encore (justement les triggers "instead of" toujours pas supportés, les jointure "full outer join" et les contraintes "check" par exemple)

Ou précisez-vous les raccourci que je connaissais déjà pour le coup. dans la ligne sql?. Comment modélisez-vous cela en schéma relationnel?

Je ne comprends pas cette question

Merci pour le temps que vous passez à me répondre

N'hésitez pas à approuver les réponses qui ont pu aider ou éventuellement voter contre celles qui sont hors sujet : les pouces verts et rouges sont là pour ça

[Lepetitpanda]

Oui il est en retraite et continue d'enseigné à "l'ancienne". Du coup pas sur qu'il soit au courant des derniéres nouveautés de ce point de vue là. Du coup c'est plutôt complet aussi. J'ai compris par le SQL ne vous souciez plus de la question.

Si j'ai bien compris le "relatif" que vous expliquez, c'est que l'un est identifié / est dépendant par / de l'autre (entité fort => faible). Ah juste une chose, la table qui contient l'inclusion, comment vous savez lequel c'est. C'est en fonction de la flèche je suppose ou alors en fonction de la logique.


J'approuverais sans soucis votre réponse avec un pouce vert. Vous avez expliqué calmement et de façon très clair un concept pas si évident pour les personnes pas suffisamment rodés aux SQL. J'ai pas envie de me contenter d'utiliser Mysql / autres SGBD du genre sans rien comprendre comme certains le font.

[escartefigue]

Oui l'identification relative concerne effectivement les entités-type dites "faibles".
Exemple : une chambre d’hôtel. Sans hôtel, pas de chambre, la chambre est identifié relativement à l’hôtel. Il en va de même pour les lignes d'une facture, ou les lignes d'une commande.

Concernant la "table" qui "contient" l'inclusion : je m'en fiche ou à peu près !
L'inclusion se modélise au niveau conceptuel, c'est à dire dans le MCD. Or, au niveau conceptuel, il n'y a pas de table, seulement des types d'entité ou entités-type (les rectangles) et des associations (les ovales).
La contrainte va d'une association vers une autre association.
À partir de là, certains logiciels de modélisation appliquent directement la contrainte lors de la génération du DDL de création des tables, auquel cas il n'y rien de plus à faire .
D'autres logiciels ne font pas ce travail, ça n'est pas beaucoup plus compliqué : il suffit de savoir ce que deviennent les associations concernées.
Les associations avec des cardinalités n,n deviennent des tables, pour les autres, la clef étrangère est copiée dans la table coté cardinalité maxi 1.
Du coup, il suffit d'ajouter manuellement la contrainte dans la table ainsi identifiée

Dans le MCD que j'ai proposé, la contrainte va de l'association "fournir" vers l'association "posseder"
"fournir" a une cardinalité maxi de 1 coté "RR_réponse", du coup, elle ne devient pas une table, et la table issue de "RR_reponse" va hériter de la clef étrangère identifiant "UT_utilisateur"
"posseder" a une cardinalité maxi de 1 coté "EX_exemplaire", du coup elle ne devient pas une table, et la table issue de "EX_exemplaire" va hériter de la clef étrangère identifiant "UT_utilisateur"
Donc la contrainte sera positionnée dans RR_reponse et vérifiée dans "UT_utilisateur", tout simplement

au niveau SQL, ça se traduit par cette instruction dans le CREATE TABLE RR_reponse :
FOREIGN KEY(UT_ident, VD_ident) REFERENCES EX_exemplaire(UT_ident, VD_ident)

[Lepetitpanda]

Encore merci. Je vais m’entrainer. Faut que je sois au point.