Discussion :

[bigbob195]

Bonjour tout le monde,

Voila j'ai un petit problème avec un schéma que j'ai réalisé à l'aide de la méthode Merise.

En effet, lors de la construction des tables, je me rends compte que je ne peux pas créer les tables "personnel formé" et "non formé" car elles ont en clé étrangère id du service et vice versa pour la table Service.

Y a-t-il un problème dans mon schéma ?

[tatayo]

Bonjour,

Y a t il un problème dans mon schéma ?

A part le fait qu'il soit bourré de fautes ?
Je ne comprends pas pourquoi tu as deux tables: "personnel formé" et "personnel non formé". Une table avec une colonne formé de type booléen ne suffirait-elle pas ?

Tatayo.

[bigbob195]

Bourré de fautes d’orthographe tu veux dire ?

Je peux effectivement ne pas différentier le personnel (quoi que le reste du MCD m'en empêche peut-être). Quoiqu'il en soit, un membre du personnel formé de type 1 doit être co-responsable d'un service avec un membre du personnel non formé de type 3.
Aussi, chaque membre du personnel formé de type 1 appartient à un et un seul service.

Ce qui fait 3 jointures entre personnel et service si je ne fais pas erreur et qui revient au même problème avec des clés étrangères de chaque côté, ce qui me pose problème pour créer les tables.

[aieeeuuuuu]

Bonjour,

Pour créer vos tables, il faut en créer une sans la contrainte d'intégrité référentielle, puis créer la deuxième avec la CIR, puis ajouter la CIR à la première.

Vous aurez également des problèmes lors de l'insertion : Si votre SGBDR (quel est-il) supporte les contraintes déferrées, utilisez-les, sinon prévoyez une solution de contournement.

Cependant, il me semble qu'il vous faudrait un héritage pour les tables personnel, quelles sont les propriétés respectives des employés formés et des employés non formés ?

[bigbob195]

La création de table sans CIR est-elle normale ou indique-t-elle un problème dans la conception ?

En ce qui concerne mes entités "personnel formé" et "non formé", elles sont en fait classes filles de l'entité Personnel.
Les deux classes filles n'ont pas de propriétés respectives mais le problème est que les formés réalisent des opérations (opération qui est une entité) que le personnel non formé ne peux faire.

[aieeeuuuuu]

La création de table sans CIR est elle normal ou indique tel un problème dans la conception ?

Au final, chaque table a bien sa CIR. C'est juste pour la création qu'il faut procéder en plusieurs étapes. Donc non, cela n'indique pas un problème de modélisation.

En ce qui concerne mes entités personnel formé et non formé elle sont enfaite classe fille de l'entité Personnel.
Les deux classes fille n'ont pas de propriétés respectives mais le problème est que les formés réalisent des opérations (opération qui est une entité) que le personnel non formé ne peux faire.

Vous aurez donc trois tables :
PERSONNEL
PERSONNEL_FORME
PERSONNEL_NON_FORME

Est-ce cela ? Cet héritage n'apparait pas dans votre MCD !

[bigbob195]

Ci dessous un partie plus importante du MCD

[bigbob195]

Est-ce cela ? Cet héritage n'apparait pas dans votre MCD !

Il manque encore des tables je c'est surtout cette partie qui me pose probleme

[fsmrel]

Bonjour,


Bigbob, seriez-vous aux prises avec le problème de l’œuf et de la poule ?

Comme dit aieeeuuuuu :

« Si votre SGBDR (quel est-il) supporte les contraintes déferrées , utilisez-les, sinon prévoyez une solution de contournement »

S'il faut contourner et se dépêtrer d’un cycle, on peut passer par la mise en oeuvre d'une table s’association entre les tables PERSONNE_FORMEE et SERVICE :



Supposons maintenant que vous créiez les personnes avant les services : pour être sûr qu’au moment où vous créerez un service, celui-ci ne reste pas orphelin de directeur de type « personne formée », un trigger appliqué à la table SERVICE insérera en même temps la ligne qui va bien dans la table DIRECTION. Un autre trigger veillera à ce qu’une instruction DELETE ne rende pas un service orphelin.