Discussion :

[sg.jiri]

Merci fsmrel.

Voyez par exemple la figure 13.37.

Après avoir consulté "Ingénierie des systèmes d'information", je pense que la figure la plus correspondante à mon cas est la 13.34. Elle emploie la contrainte d'exclusivité, ce qui est également mon cas. Maintenant, il y a le code SQL à réaliser. D'après mes recherches, la commande CREATE ASSERTION n'est pas supportée par la plupart des systèmes de gestion de base de données relationnelles (SGBDR). Il faut donc passer par des fonctions et des triggers comme vous l'avez mentionné. Voici ce qui me semble être une solution potentielle :

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
-- Création d'une fonction pour le trigger
CREATE OR REPLACE FUNCTION fn_prevent_self_like()
RETURNS TRIGGER AS $$
BEGIN
    IF EXISTS (
        SELECT 1 
        FROM Ad
        WHERE Ad.id_ad = NEW.id_ad AND Ad.user_id = NEW.user_id
    ) THEN
        RAISE EXCEPTION 'Un utilisateur ne peut pas liker sa propre annonce.';
    END IF;
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

-- Création du trigger
CREATE TRIGGER tr_prevent_self_like
BEFORE INSERT ON Likes
FOR EACH ROW
EXECUTE FUNCTION fn_prevent_self_like();

[fsmrel]

Bonjour sg.giri,

Votre référence à la figure 13.34 est plus adéquate que ma référence à la figure 13.37.

Votre solution SQL a une bonne tête et va dans le bon sens. Votre trigger prend en compte les inserts, mais il faudrait qu’il tienne compte aussi des updates.

N’oubliez pas de voter quand une réponse vous apporte quelque chose (escartefigue ne sera pas contre, il a fourni un beau MCD). Pour ma part, j’ai voté pour votre précédent message...

[escartefigue]

Bonsoir,

dans ma formation, on nous a toujours dit qu'il est préférable de favoriser l'utilisation de l'anglais en informatique. Quel est votre avis sur ce sujet ?

J'y suis défavorable, et ce pour plusieurs raisons
La première est que l'utilisation d'une langue non maîtrisée par tous est une source de confusion. Ça complique inutilement le projet si l'on est dans un contexte francophone.
Petite anecdote vécue récemment : l'un de mes clients a traduit bêtement le terme anglais "context" utilisé par un automate d'exploitation en "contexte"...
Il faut savoir que si "context" peut en effet se traduire "contexte", il signifie également "localisation" ou "situation", or, dans ce cas précis, il s'agissait de la localisation de la plate forme d'exécution sur laquelle l'automate doit lancer les traitements (test, recette, pré-prod, production). Du coup, quand ce client me parlait de contexte d'exécution, je comprenais tout autre chose, voir la définition d'un contexte d'exécution ICI.
Voilà ce qui arrive quand on utilise une langue étrangère non maîtrisée !
La deuxième raison, plus marginale, est que l'anglais est aussi utilisé en SQL, du coup si un nom d'objet percute avec un mot réservé SQL, ça complique inutilement les requêtes : "USER" doit être encadré de doubles quotes alors que "UTILISATEUR" ne le nécessite pas !

Merci également à escartefigue pour son commentaire. J'ai bien compris pourquoi il faut mettre en œuvre une contrainte d'exclusion pour empêcher un utilisateur de liker ses propres annonces. Je peux facilement réaliser cette contrainte en PHP, donc il n'y a pas de souci de ce côté-là.

ATTENTION : la contrainte doit être codée coté base de données au moyen d'un trigger, l'application ne saurait garantir à 100% l'intégrité de la base, car seul le moteur du SGBD sait gérer les accès concurrents.

J'ai quelques questions concernant la réalisation des entités-types "city" et "postal_code", ainsi que la mise en place des contraintes d'inclusion. J'imagine que cela implique l'utilisation d'une API pour vérifier si le code postal correspond bien à la ville. Cela risque d'être un peu compliqué pour moi à mon niveau de développement. De plus, je ne comprends pas très bien la relation entre les deux associations "C_P" et "P_A" réalisées par une flèche. Je me suis inspiré du lien que vous m'avez envoyé, mais je ne saisis pas clairement cette liaison. Peut-être dans un premier temps il est préférable de garder la ville et son code postal en intérieur de l'entité type AD.

Il faut avoir à l'esprit que les grandes villes peuvent avoir plusieurs codes postaux, alors que les petites communes partagent un même code postal.
C'est la raison d'être de la partie dédiée du MCD que je vous ai communiquée plus haut et dont je recopie l'extrait ici :



Ça peut paraitre un peu complexe en premier abord, mais c'est finalement assez simple :

• l'adresse est localisée dans une et une seule ville (association LO_localiser)
• une ville peut avoir un à plusieurs codes postaux (association VP_ville_CP)
• l'adresse utilise un et un seul code postal (association AP_adr_CP)

Mais il faut contrôler que le code postal choisi pour l'adresse appartient bien à la liste des codes postaux valides pour la ville de cette même adresse, c'est l'objet de la contrainte d'inclusion (I)
La flèche vers VP_ville_CP indique la cible de la contrainte (on vérifie dans les occurrences de la table issue de cette association que l'élément existe)
Les liens en pointillé vers VI_ville et CP_code_post matérialisent que c'est le couple (identifiant ville, identifiant code postal) dont on vérifie la présence dans la cible.

Le code SQL correspondant est publié à la fin du script qui suit le MCD, je le recopie ci-dessous :

Code SQL :

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

1
2
3
alter tabble AD_adresse
foreign key (VI_ident, CP_ident)
references VP_ville_cp (VI_ident, CP_ident)

Ce code porte sur la table AD_adresse et non pas sur l'association AP_adr_CP, car cette association étant de cardinalité maximale de 1 ne devient pas une table, c'est donc dans la table coté 1 que la contrainte s'applique
J'espère que c'est plus clair désormais.

[fsmrel]

Ave,

Conceptuellement, la modélisation proposée par escartefigue est irréprochable.

Le problème est qu’il faut ajouter manuellement l’alter table pour le code SQL.

En modélisant comme ci-dessous, la table produite par Looping, AD_Adresse, est directement dotée de la clé étrangère pertinente, (VI_ident, CP_ident). Il n’y a pas de clé étrangère faisant référence au tables VI_Ville et CP_code_post (principe de parcimonie).