Discussion :

[Tofalu]

Bonjour,

Je vous propose un nouveau tutoriel concernant la notion d'héritage des données au sein des tables Access.

Plusieurs questions reviennent fréquemment sur ce forum et j'espère en avoir fait une bonne synthèse.

http://warin.developpez.com/tutoriel...onnees-access/

En termes de modélisation, une question qui revient sur les forums des différents SGBD-R est la suivante :


Comment conserver la notion d'héritage lors du passage du modèle conceptuel au modèle relationnel ?


Il n'existe pas de règle pouvant répondre à coup sûr à la problématique. Merise a bien défini des méthodes pour transformer par exemple un identifiant en clé primaire, ou bien encore une association avec des cardinalités maximales à N en une table, mais rien à ce sujet. La raison est simple : tout dépend de la structure des entités concernées par l'héritage, du volume de données mis en jeu, des requêtes attendues, des compétences du moteur, etc.


A travers ce document, je vous propose d'étudier les différentes possibilités (elles sont au nombre de trois) en détaillant les raisons qui pourraient favoriser un tel choix plutôt qu'un autre et les incidences sur le reste du développement et plus particulièrement les requêtes.

pour vos éventuelles remarques

[f-leb]

bonsoir,

merci pour cette synthèse qui donne un nouvel éclairage sur la généralisation/spécialisation d’entités-type sous Access.
Je n’ai pas manqué (entre autres) la contrainte CHECK du paragraphe VI-C. Spécialisation sur le modèle du MCD qui va enfin m’assurer de manière infaillible l’intégrité de mes données pour un héritage(XT) de mes contacts.

Le hasard faisant bien les choses, le lecteur pourra compléter l’analyse grâce au post de cette discussion toute fraiche ici: Héritage ou pas héritage ? sur un cas particulier d’héritage où les entités filles sont associées (Tiens ! voilà une suggestion pour un éventuel futur complément/mise à jour de l’article)

En tout cas, « chapeau bas » pour la qualité de tes synthèses. J’en redemande.

[f-leb]

Bonsoir,

J’ai un problème d’héritage.

Dans le cas d’un héritage XT, j’ai donc implanté les contraintes sur les deux tables tblSalarié et tblIndépendant (http://warin.developpez.com/tutoriel...-access/#LVI-C )

Code sql :

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

1
2
3
ALTER TABLE tblSalarie ADD CONSTRAINT Unicite CHECK …
 
ALTER TABLE tblIndependant ADD CONSTRAINT Unicite CHECK…

Une fois les contraintes mises en place, les insertions marchent nickel et prennent bien en compte la contrainte XT, MAIS (il y a toujours un MAIS) :

Si je supprime par exemple toutes les lignes de tblSalarie puis ensuite je commence par supprimer toutes les lignes de tblIndependant, ça coince : impossible de supprimer la dernière ligne (violation de la contrainte « Unicite »).
Ce qui est logique puisque lorsque les deux tables tblSalarie et tblIndependant sont vides, la requête :

Code :

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

SELECT count(*) FROM tblSalarie… + SELECT count(*) FROM tblIndependant…

retourne 0 et viole donc la contrainte « unicite ».

C’est un peu embêtant tout ça, non ? Comment pourrait-on prendre en compte ce cas particulier ?

[Tofalu]

Salut

Euh, dans un modèle XT, tu ne peux pas avoir les tables independants et salariés vide, sinon, cela veut dire que tu as des intervenant qui ne sont ni independant, ni salarié. Tu ne couvres donc plus la totalité.

Il faut supprimer les intervenants en cascade, mais il se peut là aussi que la contrainte gène à voir

[f-leb]

Euh, dans un modèle XT, tu ne peux pas avoir les tables independants et salariés vide...

Oui pardon, j’avais pris un raccourci car la suppression en cascade à partir de la table mère tblIntervenant ne résout rien : Impossible de supprimer le dernier intervenant pour la même raison.

Faut-il se résoudre à écrire un code qui supprime la règle de validation juste avant de supprimer le dernier intervenant ? (Certes, ce n’est pas très compliqué mais le phénomène est tout de même à prendre en compte).

[Tofalu]

En fait, je ne comprend pas pourquoi ça le fait sur le dernier intervenant et pas sur les autres. Si ça pose soucis sur le dernier, ça devrait le poser pour tous. Tu es sûr que tu n'as pas fait une boulette quelque part ?

Tu as essayé au sein d'une transaction ?

Si le moteur considère la suppression en cascade comme non atomique, c-à-d composé des suppressions successives alors, pourquoi il ne signale rien quand on supprime un autre enregistrement que le dernier. A un moment donné, celui-ci aussi se retrouve être ni salarié ni indépendant.

[philipp06]

Bonjour,

j'ai étudié avec beaucoup d'intérêts le tutoriel concernant
l'implantation de l'héritage sous Access.

Ma Question est la suivante:
Je constate que l'on peut créer un Intervenant seul, i.e.
sans pour autant créer un Salarié ou un Indépendant.
Est-il possible de modéliser ceci :
Un intervenant n'existe que si Salarié ou Intervenant existe.
(un peu l'équivalent en Java d'une classe Abstract que je ne peux
instancier)

Autrement dit, à partir du formulaire de saisie d'un Intervenant
forcer la saisie des données de Salarié (ou de l'indépendant).
Si ces données ne sont pas saisies, alors annuler la saisie de
l'Intervenant.

Est-il possible de faire ceci proprement et efficacement sous Access.
(sans recourir à des delete...)

En espérant avoir été clair,
Merci de votre contribution.

[Oliv'67]

Bonjour et encore bravo pour ce super document qui m'a aidé dans la conception d'une base de données utilisant des Personnes (morale et physique)

Mais j'ai une petite question... si ma base est répliquée en plusieurs bases comment se passe la mise à jour de l'ID lors de la synchronisation ? Ne risque t-on pas d'avoir des doublons ?