Discussion :

[Soten]

Bonjour!
Me voilà avec un petit problème de conception de bdd, enfin surtout une partie...
Alors j'ai une entité personnel (avec clé), 2 entités qui en héritent (deux catégories de personnel, ingé et commercial par exemple). Mon problème est que je veux que le personnel soit, soit de type contractuel, soit de type titulaire.
J'ai aussi une table Poste (avec clé et caractéristiques), et je veux que ce poste soit occupé par un personnel de type titulaire (1 au plus), de type contractuel (1, 2 ou plus), ou par personne. Et cela de manière exclusive (ie pas un titulaire et 2 contractuels sur le même poste).

J'ai pensé à mettre un attibut de plus dans Personnel, genre TypeEmploi, mais je ne sais pas comment je m'en servirais pour représenter les occupants d'un poste. De plus un titulaire a des caractéristiques, un contractuel aussi, mais différentes. Ca me laisse à penser que je devrais faire une entité pour chaque et les faire heriter de personnel, mais ça passera pas je pense (vu que je fais déja hériter des trucs différents, comme dit plus haut)...

Je vois pas trop comment représenter ça...

Merci !

[apad]

Bonjour

1) L'information Titulaire ou Contractuel peut être positionner dans la table PERSONNE.
2) Les caractéristiques d'un titulaire peuvent être positionnés dans la table TITULAIRE (table qui reprend l'identifiant de la table PERSONNE en clé étrangère)
3) Les caractéristiques d'un contractuel peuvent être positionnés dans la table CONTRACTUEL (table qui reprend l'identifiant de la table PERSONNE en clé étrangère)
4) D'après ce que je comprends, tu veux positionner des contraites sur l'association entre la table POSTE et la table PERSONNE du type :
Règle 1 : toutes les personnes sont titulaires ou toutes les personnes sont contractuelles
Règle 2 : Si "les" personnes sont titulaires alors il n'y en a qu'une seule.

Vite vu, je pense que tu n'y arriveras pas avec des contraintes de type Check car elles ne permettent pas de parcourir la table pour vérifier l'état des autres enregistrements.
Pour moi la solution passe par un trigger sur la table entre POSTE et PERSONNE ou par un contrôle applicatif de la saisie en dehors de la base de données.

[fsmrel]

Bonjour Soten,

Pour aller dans le sens de Apad, mais en remontant au niveau purement conceptuel, de même que vous avez spécialisé l’entité-type Personne en Ingénieur et Commercial, pourquoi ne pas mettre en œuvre une spécialisation supplémentaire de l’entité-type Personne ?

Une personne est soit titulaire, soit contractuelle, chaque sous-type, Titulaire et Contractuel, étant porteur des propriétés spécifiques de l’une ou de l’autre.

Dans ces conditions vous pouvez :

- Associer un titulaire à (je suppose au plus) un poste et un poste à au plus à un titulaire.

- Associer un contractuel à (je suppose au plus) un poste et un poste à au plus plusieurs contractuels.

Au niveau SQL, la contrainte voulant qu’un poste ne puisse être partagé par un titulaire et des contractuels peut s’exprimer au moyen d’une assertion portant sur les tables dérivées des sous-types, ressemblant à quelque chose comme ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
Create Assertion Contrainte_xx 
    Check (Not Exists 
                     (Select * 
                      From Titulaire T 
                      Where Exists 
                                (Select * 
                                  From Contractuel C
                                  Where T.PosteId = C.PosteId
                                )
                     )
             ) ;

Dans la mesure où votre SGBD ne propose pas l’instruction Create Assertion, vous pouvez utiliser un trigger.

[Soten]

Bonjour Soten,

Pour aller dans le sens de Apad, mais en remontant au niveau purement conceptuel, de même que vous avez spécialisé l’entité-type Personne en Ingénieur et Commercial, pourquoi ne pas mettre en œuvre une spécialisation supplémentaire de l’entité-type Personne ?

Une personne est soit titulaire, soit contractuelle, chaque sous-type, Titulaire et Contractuel, étant porteur des propriétés spécifiques de l’une ou de l’autre.

Dans ces conditions vous pouvez :

- Associer un titulaire à (je suppose au plus) un poste et un poste à au plus à un titulaire.

- Associer un contractuel à (je suppose au plus) un poste et un poste à au plus plusieurs contractuels.

Déja merci de votre aide à vous deux!
J'ai un peu de mal à comprendre, cela reviendrait à un héritage multiple?
J'ai fait un petit diagramme rapidement, mais ce n'est point très clair...

[fsmrel]

Bonjour Soten,

Dans la mesure où les concepts Ingé, Commercial sont indépendants de ceux de Titulaire et Contractuel, je verrais plutôt les choses comme indiqué dans la pièce que je joins.

[Soten]

Je viens de réaliser que j'ai posté à côté du forum uml, bizarre j'avais vraiment l'impression que non. Un modo pour déplacer?

Bonjour Soten,

Dans la mesure où les concepts Ingé, Commercial sont indépendants de ceux de Titulaire et Contractuel, je verrais plutôt les choses comme indiqué dans la pièce que je joins.

Hum. Cette représentation ne m'est pas trop familière.
Je vois bien l'héritage ingé/commercial de Personne, l'héritage Contractuel/Titulaire de Personne (Que signifie le X par contre?), mais ce qui relie les liaisons de Titulaire/Contractuel à Poste, qu'est ce que ça signifie?

Merci encore !

[fsmrel]

Désolé Soten. Vous êtes sur le forum Merise et j'ai utilisé la notation entité/relation plutôt que la notation Merise pour exprimer les relations entre entités.

Que signifie le X

Le X marque l'exclusion : on ne peut pas être simultanément Titulaire et Contractuel. De même, un contractuel et un titulaire ne peuvent pas être affectés au même poste (cf. l'assertion dans mon premier message).

Hum. Cette représentation ne m'est pas trop familière

Suivant la notation entité/relation, un contractuel est affecté à un poste (est en relation avec), tandis qu'à un poste on peut affecter de 0 à N contractuels (le mickey en forme de trident exprime le N). Un titulaire est affecté à un poste et à un poste on affecte de 0 à 1 titulaire.

S'il reste un point obscur dans l'interprétation du graphique, n’hésitez pas...

[Soten]

Je pense juste à quelque chose, ce n'est pas gênant de séparer les deux héritages dans la mesure où une Personne peut être à la fois Ingé et Contractuel par exemple?

Je me demande aussi, au niveau de la création des tables pour traduire ce schéma, si j'ai bon :
une table PERSONNE(attributs), une table INGE(ATTRIBUTS+cle de PERSONNE), de même pour COMMERCIAL, TITULAIRE, et CONTRACTUEL?

[fsmrel]

Je pense juste à quelque chose, ce n'est pas gênant de séparer les deux héritages dans la mesure où une Personne peut être à la fois Ingé et Contractuel par exemple?

Dans la mesure où toute personne peut être ingénieur et/ou commercial, indépendamment du fait qu’elle puisse être soit titulaire soit contractuelle, je ne vois pas pourquoi rajouter une contrainte gratuite. Tricoter les 2 héritages ne pourrait être que la conséquence de règles de gestion stipulant des contraintes jusqu’ici non exprimées et les impliquant.

Je me demande aussi, au niveau de la création des tables pour traduire ce schéma, si j'ai bon :
une table PERSONNE (attributs), une table INGE(ATTRIBUTS+cle de PERSONNE), de même pour COMMERCIAL, TITULAIRE, et CONTRACTUEL?

De fait, mettre en œuvre une table PERSONNE, de clé primaire PersonneId, une table INGE, de clé primaire PersonneId (qui est aussi clé étrangère référençant la clé primaire PersonneId de la table PERSONNE). Même principe pour COMMERCIAL, TITULAIRE, et CONTRACTUEL.

Concernant les contraintes d’exclusion, cf. mon premier message (Create Assertion).

[Soten]

Très bien merci!

Ca n'a pas grand chose à voir mais dans un autre morceau de ma base, je dois modéliser une entité "module". De plus un module peut avoir comme prérequis d'autres modules.
J'ai crée un attribut listePrerequis, peut etre aurais je du faire une association réflexive 0..n, 0..n (un module peut avoir entre 0 et n prerequis, ou etre prerequis de 0 à n modules), mais je ne sais pas quelles tables je devrais créer pour modéliser ça?

En lisant un peu la FAQ, j'ai pensé à créer une table supplémentaire LISTEPREREQUIS(CodeModule, CodeModulePrérequis) avec CodeModule le code d'un module quelconque et CodeModulePrerequis le code d'un module prerequis de CodeModule. La clé de cette relation serait le couple (CodeModule, CodeModulePrerequis). J'ai bon?

[fsmrel]

J'ai bon?

Yes Sir ! Mettre en œuvre une association réflexive LISTEPREREQUIS au niveau MCD, se traduisant au niveau logique par une table :

LISTEPREREQUIS (CodeModule, CodeModulePrerequis)

Au niveau des requêtes, tout dépend du SGBD. Par exemple, Le standard SQL, DB2, MS SQL utilise l’instruction With. Voir par exemple ma réponse à Acidation ("Tri par rapport au précédent") :

http://www.developpez.net/forums/sho...d.php?t=257305

Concernant Oracle, il s’agit de la clause Connect By, Voir le message de Corben ("Gestion d'une nomenclature et des ensembles"). Pour la partie MCD, voir notamment ce que dit Nanci :

http://www.developpez.net/forums/sho...d.php?t=210410