Discussion :

[Imotepp]

Bonjour,

Je souhaiterai savoir comment implémenter un héritage de type XT ma BDD.

Par exemple, si j'ai un MCD :

Personne -0,1-------XT-------(1,1)-Homme
l
---------(1,1) Femme

Dans la BDD, j'ai créé une clé étrangère dans la table Homme qui référence IdPersonne.
Idem pour la table Femme

Mais il faut également que je m'assure qu'une personne est un homme ou une femme et rien d'autre, c'est-à-dire qu'il doit être interdit de créer une ligne dans la table personne si la clé primaire n'exite pas dans les tables Homme ou Femme.
Par exemple, si quelqu'un tente un jour d'ajouter une ligne uniquement dans la table personne, il faudrait qu'il ne puisse pas pour satisfaire la contrainte XT. Quelle est la solution habituellement utilisée dans vos bdd (quelquesoit le sgbdr) ?

Merci

[CinePhil]

il doit être interdit de créer une ligne dans la table personne si la clé primaire n'exite pas dans les tables Homme ou Femme.

C'est le contraire ! Puisque ce sont les entités Homme et Femme qui héritent de Personne, il est impossible de créer un homme ou une femme sans que celui ou celle-ci ne soit associé(e) à une Personne.

Votre MCD donnera par exemple les tables suivantes :

te_personne_prs (prs_id,...)
th_homme_hom (hom_id_personne,...)
th_femme_fem (fem_id_personne,...)

Ensuite, il faut créer une contrainte qui empêche la création d'un homme s'il existe déjà une femme avec le même identifiant et vice-versa.

Le meilleur moyen est de créer une procédure de création d'une personne qui créera la personne puis qui récupérera l'identifiant créé pour l'utiliser comme identifiant de l'homme ou de la femme.
On peut aussi prévoir une procédure de changement de sexe qui supprimera l'homme ou la femme puis créera la femme ou l'homme.

Dans la mesure où l'héritage n'a souvent d'intérêt que par l'existence de propriétés différentes entre les hommes et les femmes, il sera peut-être nécessaire de créer deux procédures de création au lieu d'une et deux procédure de changement de sexe au lieu d'une. Si l'héritage n'est dû qu'à des associations différentes, alors une procédure de création et une procédure de changement suffiront.

Si votre SGBD le permet, au lieu de procédures, vous pouvez utiliser des triggers INSTEAD OF.

[Imotepp]

Bonjour et merci pour la réponse,

Mon problème est d'empêcher quelqu'un d'aller créer une personne par erreur, par exemple en accédant directement à la table PERSONNE ou en passant par une autre application informatique (donc en passant outre mes procédures stockées).

Des triggers INSTEAD OF seraient parfait, mais mon sgbd ne le permet pas.


Merci de me faire part de vos idées et de votre pratique en la matière.

Et Bonne Année à tous !

[CinePhil]

Mon problème est d'empêcher quelqu'un d'aller créer une personne par erreur, par exemple en accédant directement à la table PERSONNE ou en passant par une autre application informatique (donc en passant outre mes procédures stockées).

Des triggers INSTEAD OF seraient parfait, mais mon sgbd ne le permet pas.

Comme dirait SQLPro : c'est MySQMerde ?

Il faut alors créer les procédures puisque les triggers instead off sont impossibles, puis retirer le privilège INSERT sur les trois tables.

[Imotepp]

Comme dirait SQLPro : c'est MySQMerde ?

Of course !
L'infamie de se sgbd n'a d'égale que sa prédominance sur le net, ce qui atteste des lacunes des informaticiens sur la partie "données".

Il faut alors créer les procédures puisque les triggers instead off sont impossibles, puis retirer le privilège INSERT sur les trois tables.

Effectivement, on fera avec les moyens du bord.


Merci pour votre dévouement.