Discussion :

[fsmrel]

Ave,
 

c'est quand plus classe et plus lisible avec la modélisation de la contrainte d'inclusion 

 
Je suis bien évidemment d’accord
 
Pour ma part, si j’éprouve le besoin de mettre en oeuvre le MCD classique, dans lequel la sémantique est bien en place, avec les contraintes bien présentes , lisibilité garantie et tout ça (cf. ton premier MCD), j’éprouve aussi le besoin de disposer d’un MCD « optimisé » (cf. ton second mcd), situé entre ce MCD classique et le MLD, à partir duquel on peut produire le code SQL correct...
Quand je regarde le paquet de mes gribouillages dans le chapitre 13 de l’ouvrage de Nanci, je me dis qu’il y a de quoi faire à ce propos.
 
De ton côté, comment vois-tu la suite des opérations ?

[Paprick]

Bonsoir François,

De ton côté, comment vois-tu la suite des opérations ?

Les derniers exemples que nous avons pris offrent un panel assez complet des types de contraintes à traiter.
Pour être complet, pourrais-tu me donner ta vision pour le trigger qui bloque la suppression de la dernière ligne d'un devis (cf. pb cardinalité 1,N) ?

Par ailleurs, j'ai un autre petit cas à te soumettre pour le contrôle des cardinalités Max.
Imaginons une bibliothèque qui possède plusieurs exemplaires de plusieurs ouvrages mis à la disposition des étudiants.
Une version simple du MCD donne cela :

Que proposerais-tu (en PostgreSQL) pour contrôler :

• d'une part le fait qu'un étudiant ne peut pas emprunter plus de 10 ouvrages (sachant que, quand il ramène un ouvrage, on supprime le lien dans "Emprunt" sans garder l'historique),
• d'autre part, qu'un même ouvrage possède un nombre d'exemplaires limité.

J'imagine un CHECK qui renvoie à une fonction (cf. contrainte X pour l'héritage) ou un trigger INSTEAD OF INSERT...
Qu'en penses-tu ?

[fsmrel]

Salve,

Les derniers exemples que nous avons pris offrent un panel assez complet des types de contraintes à traiter.
Pour être complet, pourrais-tu me donner ta vision pour le trigger qui bloque la suppression de la dernière ligne d'un devis (cf. pb cardinalité 1,N) ?

 
J’ai besoin de souffler un peu...
J’ai éprouvé quelques difficultés avec cette histoire de suppression de la dernière ligne (contexte SQL Server). Connaissant très mal PostgreSQL, il faudra que je prenne le temps d’étudier le problème de la suppression d’un devis avec squeeze du trigger qui bloque la suppression de la dernière ligne par Hilarion.
 
 

Que proposerais-tu (en PostgreSQL) pour contrôler :

• d'une part le fait qu'un étudiant ne peut pas emprunter plus de 10 ouvrages (sachant que, quand il ramène un ouvrage, on supprime le lien dans "Emprunt" sans garder l'historique),
• d'autre part, qu'un même ouvrage possède un nombre d'exemplaires limité.

J'imagine un CHECK qui renvoie à une fonction (cf. contrainte X pour l'héritage) ou un trigger INSTEAD OF INSERT...
Qu'en penses-tu ?

 
un CHECK qui renvoie à une fonction, ça devrait être jouable.

Qu'un même ouvrage possède un nombre d'exemplaires limité, ça doit être du même ordre, je vais regarder tout ça. Si je comprends bien, si c’est Hilarion qui valorise l’attribut NbExemplaires (entité-type Ouvrage), alors il faudra l’empêcher fournir une valeur délirante. Autrement dit, la limite doit être la même pour tous les ouvrages : c’est ça ?

[Paprick]

Salut François,

Si je comprends bien, si c’est Hilarion qui valorise l’attribut NbExemplaires (entité-type Ouvrage), alors il faudra l’empêcher fournir une valeur délirante. Autrement dit, la limite doit être la même pour tous les ouvrages : c’est ça ?

Cet aspect-là est secondaire : Hilarion peut donner la valeur qu'il veut au nombre d'exemplaires (on peut aussi définir un Max avec un CHECK local à la rubrique), le nombre d'exemplaires pouvant bien sûr varier en fonction de l'ouvrage.
L'important est de bloquer un nouvel emprunt s'il n'y a plus d'exemplaire disponible.