Discussion :

[Wilburdiskedur]

Bonjour,

Tout d'abord, je ne sais pas exactement si c'est le bon endroit pour ce sujet, prière de vouloir me pardonner si ce n'est pas le cas.


J'ai un petit soucis au niveau de la conception de ma base de données.

Pour expliquer la chose simplement (j'espère en tout cas qu'elle sera relativement simple à comprendre), j'aimerais mettre en place un système d'alerte. Dans celles-ci, j'aimerais inclure un "objet".
Exemple : date d'échéance d'une facture impayée dépassée : l'alerte devrait pouvoir me renseigner l'identifiant de la facture.

Pas trop de problème jusque là, et sans me compliquer la vie, je n'aurais qu'à rajouter un champs dans la table Alerte qui pointerait vers l'identifiant de la facture.

Mais admettons que je veuille généraliser mon système d'alertes : en plus des factures, je voudrais ajouter des alertes sur d'autres choses. Je ne peux pas utiliser le même champs.

Comment concevoir un tel système? Un identifiant pouvant pointer sur telle ou telle table, et encore mieux : des identifiants n'ayant pas le même type (supposons que j'ai des identifiants entiers et des chaines de caractères).

Bien sûr, je peux gérer cela dans mon code, mais j'aimerais savoir s'il était possible de réaliser cela "proprement" au niveau de la base de données.

Merci d'avance pour votre temps,

Romain

[Richard_35]

Bonjour Wilburdiskedur,

.../... je n'aurais qu'à rajouter un champs dans la table Alerte qui pointerait vers l'identifiant de la facture.

Une solution serait de faire l'inverse :

Alerte(IdAlerte, ...) ;

Facture(IdFacture, Date, ...) ;
Facture_Alerte(IdFacture, #IdAlerte, ...) ;
==> pour éviter une clé étrangère à NULL.

TableAvecAlerte1(IdTableAvecAlerte1, ...) ;
TableAvecAlerte1_Alerte(IdTableAvecAlerte1, #IdAlerte, ...) ;
==> pour éviter une clé étrangère à NULL.

TableAvecAlerte2(IdTableAvecAlerte2, ...) ;
TableAvecAlerte2_Alerte(IdTableAvecAlerte2, #IdAlerte, ...) ;
==> pour éviter une clé étrangère à NULL.
...
TableAvecAlerteN(IdTableAvecAlerteN, ...) ;
TableAvecAlerteN_Alerte(IdTableAvecAlerteN, #IdAlerte, ...).
==> pour éviter une clé étrangère à NULL.

[Wilburdiskedur]

Bonjour Richard_35,

Avec ta solution, qu'est-ce qui empêcherait ceci :

Alerte(1)

TableAvecAlerte1(xxx)
TableAvecAlerte1_Alerte(xxx, 1)

TableAvecAlerte2(yyy)
TableAvecAlerte2_Alerte(yyy, 1)


D'après ce que j'ai compris, cela est possible et tout simplement hors de question : cela voudrait dire qu'une alerte peut "pointer" vers deux tables. Modifier l'alerte pour la TableAvecAlerte1 modifierait l'alerte pour TableAvecAlerte2.

[Richard_35]

Exact, je n'avais pas intégré cette (nouvelle) règle de gestion.

Un trigger pour chaque table concernée par l'alerte pourrait interdire l'écriture de TableAvecAlerte2_Alerte(yyy, 1), en allant tester l'existence de l'id=1 déjà présent dans Alerte(1).

A noter que les tables

TableAvecAlerteX_Alerte(IdTableAvecAlerteX, #IdAlerte, ...)

permettent de lier un même IdTableAvecAlerteX à plusieurs alertes.

[Wilburdiskedur]

Merci pour ces réponses.

Aucun souci, je n'ai pas énoncé clairement toutes les règles de gestion.

J'ai en effet envisagé de passer par les triggers, mais j'aurais voulu m'en passer si cela avait été possible d'adapter mon modèle.


Pour ta note : oui cela est possible, et c'est prévu comme cela.


Merci pour le temps que tu m'as accordé.

Je vais attendre encore un peu avant de me lancer, pour voir si personne n'a une autre solution.

[CinePhil]

Et à l'envers, c'est à dire avec une spécialisation des alertes, ce ne serait pas mieux ?

facture -0,n----avoir----0,n- alerte_facture -(1,1)----être----0,1-------- alerte
commande -0,n----avoir----0,n- alerte_commande -(1,1)----être----0,1-|

À toi de voir si les cardinalités des associations "avoir" conviennent.

[Wilburdiskedur]

Bonjour CinePhil,

(merci d'avoir déplacé le message dans la bonne section au fait)

Et à l'envers, c'est à dire avec une spécialisation des alertes, ce ne serait pas mieux ?

facture -0,n----avoir----0,n- alerte_facture -(1,1)----être----0,1-------- alerte
commande -0,n----avoir----0,n- alerte_commande -(1,1)----être----0,1-|

À toi de voir si les cardinalités des associations "avoir" conviennent.

En effet, j'ai modifié les cardinalités de ces relations "avoir" pour que cela corresponde mieux avec mes règles.



Mais j'ai toujours besoin des triggers dans ma DB ou d'un controle rigoureux dans mon application n'est-ce pas? Pour ne pas avoir un enregistrement alerte_facture et un enregistrement alerte_commande pointant vers la même alerte?

[CinePhil]

Mais j'ai toujours besoin des triggers dans ma DB ou d'un controle rigoureux dans mon application n'est-ce pas? Pour ne pas avoir un enregistrement alerte_facture et un enregistrement alerte_commande pointant vers la même alerte?

Effectivement mais il n'y a plus qu'un trigger sur la table des alertes.

Peut-être qu'avec un SGBD qui implémente l'héritage par ses propres mécanismes y a t-il aussi les contraintes de partition ou d'exclusion entre les tables filles ? Pas avec MySQL en tout cas qui ignore le concept d'héritage.

[Wilburdiskedur]

Effectivement mais il n'y a plus qu'un trigger sur la table des alertes.

Je n'ai pas compris cela. Je dois réaliser une insertion d'alerte en premier, afin de récupérer son identifiant et pouvoir fournir ce dernier aux autres INSERT. Mais le problème cité ne se situe pas au niveau de la table alerte, mais bien au niveau des tables alerte_facture et alerte_commande.
Comme le disait Richard_35, j'ai bien l'impression qu'un trigger par table alerte_xxx est requis.
Ou alors ma vision des choses et/ou implémentation de DB sont erronées?

Peut-être qu'avec un SGBD qui implémente l'héritage par ses propres mécanismes y a t-il aussi les contraintes de partition ou d'exclusion entre les tables filles ? Pas avec MySQL en tout cas qui ignore le concept d'héritage.

Ce sera MySQL dans mon cas, donc pas "d'héritage"...

Merci pour les réponses.

[Richard_35]

Bonjour Wilburdiskedur et Philippe,

Wilburdiskedur, ne pas confondre "traitement" et "sécurisation des données".

En effet, sans doute que, via le traitement (formulaires de saisie), tu t'arrangeras pour qu'un même IdAlerte ne soit pas distribué à deux entités concernées différentes (facture, commande, ...). Mais nous parlons, ici, de sécurisation au niveau des données. En clair, il faut prévoir le cas que tu pressentais, même en passant par la modification directe des tables (sans passer par les formulaires de saisie).

Donc, tu as le choix :

• trigger sur la table Alerte :
  
  • évènement : avant écriture ;
  • traitement : si IdAlerte existe déjà dans au moins une des tables concernées (sauf celle en cours, bien entendu), alors refus.

• trigger sur les tables concernées par Alerte :
  
  • évènement : avant écriture ;
  • traitement : si IdAlerte existe déjà dans Alerte (sauf pour celle en cours, bien entendu), alors refus.

Si une nouvelle table devient éligible aux alertes, de toutes les manières, il faudra modifier le trigger que tu auras choisi.

[Wilburdiskedur]

Wilburdiskedur, ne pas confondre "traitement" et "sécurisation des données".

En effet, sans doute que, via le traitement (formulaires de saisie), tu t'arrangeras pour qu'un même IdAlerte ne soit pas distribué à deux entités concernées différentes (facture, commande, ...). Mais nous parlons, ici, de sécurisation au niveau des données. En clair, il faut prévoir le cas que tu pressentais, même en passant par la modification directe des tables (sans passer par les formulaires de saisie).

Richard_35,

Je pense avoir fait la part des choses entre traitement et sécurisation des données -du je l'espère

Ce que je ne parviens pas à saisir, c'est vos explications concernant les triggers. Soit je n'ai pas bien expliqué ce que je voulais avoir comme résultat, soit il me manque certaines notions en DB -ou peut-être les deux.

• trigger sur la table Alerte :
  
  • évènement : avant écriture ;
  • traitement : si IdAlerte existe déjà dans au moins une des tables concernées (sauf celle en cours, bien entendu), alors refus.

En plaçant un trigger sur la table Alerte dont l'identifiant est généré par le système (auto-incrément), je ne comprends pas comment cela peut vérifier l'existence de quelque chose qui n'a pas encore été inséré (enfin techniquement je vois, mais je ne vois pas l'utilité).
Pour pouvoir insérer un nouvel enregistrement dans la table alerte_facture, j'ai besoin de l'identifiant d'un enregistrement de la table Alerte déjà existant. Pour moi, le problème est là : à l'insertion/modification d'un enregistrement de la table alerte_facture (et toutes les autres tables du même genre).

• trigger sur les tables concernées par Alerte :
  
  • évènement : avant écriture ;
  • traitement : si IdAlerte existe déjà dans Alerte (sauf pour celle en cours, bien entendu), alors refus.

Ici j'espère juste que c'est une petite erreur de copier/coller, sinon je pige plus rien

Si une nouvelle table devient éligible aux alertes, de toutes les manières, il faudra modifier le trigger que tu auras choisi.

Effectivement, l'ajout d'un nouveau type d'alerte implique une modification de mon code, merci de le faire remarquer.

[Richard_35]

En plaçant un trigger sur la table Alerte dont l'identifiant est généré par le système (auto-incrément), je ne comprends pas comment cela peut vérifier l'existence de quelque chose qui n'a pas encore été inséré (enfin techniquement je vois, mais je ne vois pas l'utilité).
Pour pouvoir insérer un nouvel enregistrement dans la table alerte_facture, j'ai besoin de l'identifiant d'un enregistrement de la table Alerte déjà existant. Pour moi, le problème est là : à l'insertion/modification d'un enregistrement de la table alerte_facture (et toutes les autres tables du même genre).

==> tu parles, ici, du développement proprement-dit.

La modélisation des données s'occupe de dire : "il faut qu'une alerte soit affectée à une et une seule entité". D'où, la création d'un trigger qui assure la cohérence nécessaire.

Le développement orientera ton choix sur le trigger qu'il faut.

Dans ton exemple :

Pour pouvoir insérer un nouvel enregistrement dans la table alerte_facture, j'ai besoin de l'identifiant d'un enregistrement de la table Alerte déjà existant.

==> ton développement :

• va créer un enregistrement dans Alerte (avec IdAlerte en auto-incrément) ;
• doit récupérer l'IdAlerte précédemment créé pour l'affecter à la table concernée.

trigger sur les tables concernées par Alerte :
évènement : avant écriture ;
traitement : si IdAlerte existe déjà dans Alerte (sauf pour celle en cours, bien entendu), alors refus.

Ici j'espère juste que c'est une petite erreur de copier/coller, sinon je pige plus rien

==> eh bien, non, ce n'est pas une erreur de copier/coller.
Que dit ce trigger ?
"=> Avant d'écrire un enregistrement dans Alerte, vérifier si l'IdAlerte qui va être créé n'est pas déjà affecté à une table soumise aux alertes."
et, cela, indépendamment de tout développement.

Toutes tes interrogations sont, semble-t-il, liées au fait que tu raisonnes "développement" avant de raisonner "données".

[CinePhil]

Que dit ce trigger ?
"=> Avant d'écrire un enregistrement dans Alerte, vérifier si l'IdAlerte qui va être créé n'est pas déjà affecté à une table soumise aux alertes."
et, cela, indépendamment de tout développement.

C'est normalement impossible.

Soit les tables en héritage :
alerte (alt_id,...)
alerte_facture (af_id_alerte,...)
alerte_commande (ac_id_alerte,...)

Si j'insère une ligne dans "alerte", l'identifiant sera forcément nouveau ou, si une valeur d'identifiant est donnée dans la requête d'insertion, rejeté car déjà existant puisqu'il s'agit de la clé primaire.

Et comme les tables filles ont pour clé primaire une clé étrangère référençant l'identifiant de "alerte", l'identifiant de la nouvelle ligne insérée dans "alerte" ne peut pas exister dans une table fille.

Par contre, c'est bien à l'insertion ou à la mise à jour d'une ligne dans une des tables filles qu'il faudra s'assurer que l'identifiant n'est pas déjà utilisé dans une autre table fille.

Au final, je pense qu'il faut au moins un trigger par table fille.

[Richard_35]

Bonjour Philippe,

En fait, avec :

Et à l'envers, c'est à dire avec une spécialisation des alertes, ce ne serait pas mieux ?

Code :

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

1
2
facture --0,n----avoir----0,n- alerte_facture --(1,1)----être----0,1-------- alerte
commande -0,n----avoir----0,n- alerte_commande -(1,1)----être----0,1-----------|

nous obtenons les tables :

alerte (alt_id,...) ;

alerte_facture (#af_id_alerte, #af_id_facture, ...) ;
alerte_commande (#ac_id_alerte, #ac_id_commande, ...) ;

facture (id_facture, ...) ;
commande (id_commande, ...).

Voir le post #2.

[CinePhil]

Pas tout à fait, avec mon schéma et les cardinalités qui y figurent, il y a ces tables :
alerte (alt_id,...)
alerte_facture (af_id_alerte,...)
alerte_commande (ac_id_alerte,...)
facture (fac_id...)
commande (cmd_id...)
fac_avoir_af (faa_if_facture, faa_id_alerte_facture)
cmd_avoir_ac (caa_id_commande, caa_id_alerte_commande)

À mon schéma, Wilburdiskedur m'a répondu :

En effet, j'ai modifié les cardinalités de ces relations "avoir" pour que cela corresponde mieux avec mes règles.

Mais, sauf si j'ai lu de travers, il ne nous a pas donné les bonnes cardinalités.

Ce qui deviendrait intéressant, c'est si une alerte_facture ne se rapporte qu'à une seule facture et si une alerte_commande ne se rapporte qu'à une seule commande :
facture --0,n----avoir----(1,1)- alerte_facture --(1,1)----être----0,1-------- alerte
commande -0,n----avoir----(1,1)- alerte_commande -(1,1)----être----0,1----|

Dans ce schéma, alerte_facture et alerte_commande sont en fait deux tables associatives et le schéma peut être passé à l'un des instruments favoris de fsmrel, le rasoir d'Occam, pour devenir ceci :
facture -0,n----avoir----0,1- alerte
commande -0,n----avoir----0,1-|

Ce qui donne alors les tables suivantes :
facture (fac_id...)
commande (cmd_id...)
alerte (alt_id,...)
fac_avoir_al (faa_id_alerte, faa_id_facture)
cmd_avoir_al (caa_id_alerte, caa_id_commande)

Ceci n'empêche d'ailleurs pas d'avoir un (ou des) trigger(s) pour vérifier qu'une alerte ne figure pas à la fois dans fac_avoir_al et dans cmd_avoir_al.

Si Wilburdiskedur écrit correctement les règles de gestion de son système d'alertes, il pourra dessiner sans problème le MCD, puis construire les tables en fonctions des cardinalités.

[Richard_35]

J'étais en train de préparer le rectificatif qui va bien...

[Richard_35]

Bonjour Wilburdiskedur et Philippe,

Pour préciser, à l'attention de Wilburdiskedur :

• si tu souhaites personnaliser les alertes à une facture/commande. Par exemple, une alerte de type :
  "Date d'échéance de la facture XXX, d'un montant de YYY€ dépassée."
  alors, les tables seront les suivantes :
  
  fac_avoir_al (#faa_id_alerte, #faa_id_facture)
  cmd_avoir_al (#caa_id_alerte, #caa_id_commande)

• si tu souhaites avoir des alertes génériques pour des factures/commandes. Par exemple, une alerte de type :
  "Date d'échéance dépassée."
  alors, les tables seront les suivantes :
  
  fac_avoir_al (#faa_id_alerte, #faa_id_facture)
  cmd_avoir_al (#caa_id_alerte, #caa_id_commande)

[Wilburdiskedur]

Tout est beaucoup plus clair.

Je suis arrivé à quelque chose qui me plait, et qui me parait correct.



Merci beaucoup à tous les deux !