Discussion :

[lagra007]

Bonjour,
Je souhaiterais avoir des avis sur le mcd que j'ai crée.
Je décris un peu le fonctionnement :

Il y-a plusieurs personnes : prof,enfant,chef de famille,admin
Tous ces personnes peuvent s'inscrire a la newsletter d'un stage auquel un admin (qui peut aussi etre prof ou une famille) envoie des emails.
Un stagiaire s'inscrit à 1 ou plusieurs stages et pour un stage il possède une famille et est placé dans un groupe de classe
Ce groupe est sous la responsabilité d'un seul professeur.
On doit savoir avant de recevoir les fiches des stagiaires quelles sont les familles qui pourront accueillir des stagiaires cette année, à quelle stage il participeraient et combien de stagiaires ils prendraient.

J'ai oublié de préciser quelques petites choses :

En faites j'aurais plutôt du appeler l'entité personne UTILISATEUR. Les profs, les admins, les stagiaires et les chefs de famille sont des utilisateurs. L'entité enfant sert juste à savoir combien d'enfants possède une famille car elles en possèdent en nombre variable et les enfants ne sont donc pas utilisateur (ils n’accèdent pas au site).

j'ai oublié de mettre un attribut e-mail dans l'entité UTILISATEUR (enfin PERSONNE) mais par contre l'entité e-mail associé à STAGIAIRES permet de lier des adresses e-mails en plus de celle que possède le stagiaire et qui correspond au adresses e-mails des ces proches qui veulent s'inscrire à la newsletter.

L'entité événement correspond à tous les activités qui se dérouleront pendant le stage (Activité, Cours, Fêtes) Elle permet de constituer le programme du stage.

Voici le mcd :

(voir l'image en pj)

Et le mpd correspondant :

(voir image en pj)

Maintenant, en regardant le mpd je me demande que viennent faire les lignes GRO_N°Stage et FAM_N°Personne dans la table INSCRIPTION STAGE ou FAM_N°Personne dans CHEF DE FAMILLE ou encore FAM_N°Personne dans FAMILLE

Pourquoi la traduction du MCD donne cela qui est inutile ?
Est-ce au niveau des liens identifiants ?

[fsmrel]

Bonsoir,


Vous vous demandez ce que vient faire l’attribut (et non pas la ligne) GRO_NoStage dans la table INSCRIPTION_STAGE : c’est la moindre des choses que Power AMC mette en œuvre un lien d’intégrité référentielle entre les tables GROUPE et INSCRIPTION_STAGE pour traduire l’association-type POSSEDER que vous avez établie entre les entités-types dont ces tables sont dérivées. Le nom d’attribut NoStage étant déjà utilisé à cause de l’association-type CONCERNER, Power AMC doit donc utiliser donc un autre nom, tel que GRO_NoStage.

Maintenant, si on analyse les relations que vous avez établies entre GROUPE, STAGE et INSCRIPTION_STAGE, on comprend ceci :

• Une inscription fait référence à un stage,
• Une inscription fait référence à un groupe,
• Un groupe fait référence à un stage.

Mais vous ne précisez pas si le stage auquel fait référence une inscription est le même que celui auquel fait référence le groupe, donc en toute logique, une inscription i1 peut faire référence à un stage s1 et à un groupe g1, lequel peut parfaitement faire référence à un stage s2. C’est bien ce que vous avez modélisé et justifie la présence des deux attributs N°Stage et GRO_NoStage.

Si vous voulez que l’inscription fasse référence au stage référencé par son groupe, supprimez l’association-type CONCERNER connectant INSCRIPTION_STAGE et STAGE, puisqu'elle est alors redondante. Ceci fait, l’inscription fera désormais référence au stage, transitivement, via le groupe.


Vous vous demandez ce que vient faire l’attribut FAM_NoPersonne dans la table CHEF_DE_FAMILLE. Je vous fais observer que dans le MCD vous avez établi une bijection entre les entités-types CHEF_DE_FAMILLE et FAMILLE. En conséquence, Power AMC établit un double lien d’intégrité référentielle entre les tables qui en sont dérivées : normal.

Concrètement, Power AMC établit évidemment un cycle perturbant. Pour éviter cela, vous pouvez utiliser la notation E/R+Merise (Outils > options du modèle > Paramètres du modèle) :





Et, en paramétrant ainsi l’association-type POSSEDER (Power AMC V11) :




Alors vous obtiendrez quelque chose ressemblant à ceci :



Et une absence de cycle au niveau MLD :



Vous noterez que je n’ai pas retenu votre attribut NoFamille. En effet, la table FAMILLE hérite de la clé de la table CHEF_DE_FAMILLE, ce qui suffit amplement. Il est probable que si vous procédez comme je l’ai fait, au moment de la dérivation du MCD en MLD, Power AMC (au fait quelle version utilisez-vous ?) réclamera un identifiant pour l’entité-type FAMILLE et déclenchera une erreur, du genre « Identifiant sans attribut ». Comme cette entité-type n’a pas à avoir d’identifiant en propre, vous supprimerez tout identifiant dans l’onglet Identifiants de la fenêtre « Propriétés de l’entité » :





Ceci dit, pourquoi avoir défini deux entités-types CHEF_DE_FAMILLE et FAMILLE ? Pourquoi la première n’absorberait-elle pas la seconde ?

Pourquoi la traduction du MCD donne cela qui est inutile ?

J’espère que vous mesurez mieux la part de responsabilité qui est la vôtre...


N.B. De grâce, dans le MLD, évitez l’affichage des noms des contraintes (passez par Outils > Préférences d’affichage > Référence).

[lagra007]

Bonjour,
Je vous remercie pour les informations que vous m'avez données concernant les avantages de l'identification relative du post en dessous et merci encore une fois pour cette réponse très claire.

Je comprends maintenant pourquoi dans la table CHEF_DE_FAMILLE je me retrouve avec FAM_N°Personne. (Une bijection c'est quand on a les cardinalités 1,1 - 1,1 ? C'est ça ?)

D'ailleurs je me rends compte comme vous me le faites remarquer que j'aurais du supprimer l'entité CHEF_DE_FAMILLE dans le MCD et appliquer l'héritage sur la famille comme ça il n'y-a pas de n° de Famille en auto incrément et ainsi le "numéro de famille" serait le n° de personne (en PK, FK). (Mais dans la conception du MCD, ça me faisait bizarre de me dire logiquement qu'une FAMILLE est une SORTE de PERSONNE) Bref...

Maintenant au niveau de la table INSCRIPTION_STAGE, C'est vrai que quand on regarde comme ça c'est inutile de mettre que l'INSCRIPTION_STAGE concerne un STAGE vu qu’elle concerne un STAGE par le fait qu’elle concerne un GROUPE (qui concerne un stage) et que par conséquent on peut supprimer l’association.

Je pense donc que j'ai mal fait mon analyse et que j'aurais du créer une deuxième entité dans le mcd car ici je condense deux concepts.

Je vous explique :

En fait l'administrateur sait qu'un STAGIAIRE est inscrit dans un STAGE car il reçoit un courrier postal avec ça fiche de renseignements .etc. C'est à lui alors d'inscrire le stagiaire dans la base de données et l'inscrire au stage qu'il veut participer. Donc ICI j'aurai du créer une entité esclave INSCRIPTION_STAGIAIRE avec un lien identifiant vers l'entité STAGIAIRE et l'entité STAGE. (Car une inscription de stagiaire concerne un stagiaire à un stage).
Ce n'est qu'après plusieurs mois qu'il sera placé dans une famille, et dans un groupe. Donc la je devrais modifier le nom de l'entité INSCRIPTION_STAGE en PLACEMENT_STAGIAIRE

Voilà tout ça parait logique, maintenant je me dis : Une fois que tous les stagiaires sont placés dans les familles et le groupe (Table PLACEMENT_STAGIAIRE), que toutes les informations stockées dans la table INSCRIPTION_STAGE sont inutiles car redondantes dans la table PLACEMENT_STAGIAIRE

Je sais bien qu’il est possible de créer des automatisations dans certains SGBD pour supprimer le contenu de table mais j’aimerais autant éviter cela. Il y'aurait-il une solution pour faire autrement tout en gardant une logique dans le mcd ou quelle erreur dans mon analyse aurait-je pu faire ?

J'utilise la version 12 de PowerAMC. Malheureusement la version d'évaluation s'est terminée aujourd'hui. :O Sinon j'aurais bien refait le schéma pour que mes explications soient plus claires.

La notation E/R+Merise est elle officielle ou est-ce une notation PowerAMC ?

[fsmrel]

Bonsoir,

Je comprends maintenant pourquoi dans la table CHEF_DE_FAMILLE je me retrouve avec FAM_N°Personne. (Une bijection c'est quand on a les cardinalités 1,1 - 1,1 ? C'est ça ?)

Oui.

En fait l'administrateur sait qu'un STAGIAIRE est inscrit dans un STAGE car il reçoit un courrier postal avec sa fiche de renseignements .etc. C'est à lui alors d'inscrire le stagiaire dans la base de données et l'inscrire au stage qu'il veut participer. Donc ICI j'aurai du créer une entité esclave INSCRIPTION_STAGIAIRE avec un lien identifiant vers l'entité STAGIAIRE et l'entité STAGE. (Car une inscription de stagiaire concerne un stagiaire à un stage).

D’accord, mais à un instant t, un stagiaire peut-il être inscrit à plus d’un stage ? Dans la négative, la modélisation doit prendre en compte cette contrainte.

Ce n'est qu'après plusieurs mois qu'il sera placé dans une famille, et dans un groupe. Donc la je devrais modifier le nom de l'entité INSCRIPTION_STAGE en PLACEMENT_STAGIAIRE.

Encore d’accord, mais même question : à un instant t, un stagiaire peut-il être faire partie de plus d’un groupe ?

Je sais bien qu’il est possible de créer des automatisations dans certains SGBD pour supprimer le contenu de table mais j’aimerais autant éviter cela. Il y'aurait-il une solution pour faire autrement tout en gardant une logique dans le mcd ou quelle erreur dans mon analyse aurait-je pu faire ?

Il ne faut pas avoir peur des triggers. Lors de l’affectation d’un stagiaire a un groupe, automatiser la suppression de son affectation provisoire à un stage n’est pas un problème. Vous pouvez aussi faire les pieds au mur si vous êtes allergique à cette façon de procéder : réfléchissez par exxemple à la mise en œuvre d’une entité-type XXX généralisant Groupe et Stage (qui deviendraient donc des entités-types spécialisées de XXX), avec laquelle l’entité-type STAGIAIRE serait en relation.

J'utilise la version 12 de PowerAMC. Malheureusement la version d'évaluation s'est terminée aujourd'hui.

Vous pouvez utiliser Open ModelSphere qui est gratuit et vous permet de produire des MCD Merise (sans l’héritage) ou des diagrammes de classes ULM (avec...) Voyez par exemple ici.

[lagra007]

Non à un instant t, un stagiaire ne peut être inscrit dans plusieurs stages enfin (cela est très rare et donnera lieu à une autre inscription) ni dans plusieurs groupes.

Pour les triggers, c'est mieux.
Je n'ai pas compris ceci :

Vous pouvez aussi faire les pieds au mur si vous êtes allergique à cette façon de procéder : réfléchissez par exxemple à la mise en œuvre d’une entité-type XXX généralisant Groupe et Stage (qui deviendraient donc des entités-types spécialisées de XXX), avec laquelle l’entité-type STAGIAIRE serait en relation.

[fsmrel]

Bonsoir,

Je n'ai pas eu le temps de vous répondre, j'espère pouvoir le faire dans la journée. Une question tout de même : conservez-vous la trace, l'historique des placements des stagiaires dans les groupes ? Autrement dit, quand un stage S1 est terminé, si un stagiaire du groupe G1 rattaché à S1 s'inscrit pour un nouveau stage S2, conservez-vous dans la base de données la trace de son ancienne appartenance au groupe G1 du stage S1 ?

[lagra007]

Bonjour, je vous en prie ...
En fait, oui on conserve l'historique des placements des stagiaires avec pour un stage donné le groupe et la famille dans lequel ils étaient placés.

Ainsi sur le site de l'association les familles pourront consultés la liste de tous les stages et les stagiaires qui ont accueillis depuis leurs inscription, pareil pour les profs avec leurs élèves et les stagiaires avec leur familles qui se connecterons au site.

Ce qui est inutile par contre c'est de garder (une fois les stagiaires placés dans les familles et leur groupe ) : d'un cotés les l'inscription du stagiaire à un stage (qui est nécessaire car on ne sait au départ que le stage auquel il participe et on ne sait pas dans quel groupe il est placés) Ainsi que l'inscription des familles avec le nombre de stagiaires qu'ils veulent prendre).

Dans ce cas, il n'y-a que l'utilisation de triggers.
Et en même temps on ne va pas supprimer le contenu de la table inscription stagiaire (#Id_Personne,#Id_Stage,FicheInscription) car on ne doit pas supprimer la FicheInscription du stagiaire (nom du fichier pdf) car elle doit être consultable par les admin / famille / stagiaire ) Ou alors déplacer à l'aide de trigger la valeur du champ InscriptionStage de la table INSCRIPTION_STAGIAIRE vers un champs InscriptionStage de la table PLACEMENT_STAGIAIRE_DEFINITIF. Apres peut être qu'il serait plus simple de laisser ces tables tranquilles ...

J'ai l'impression de faire beaucoup de bidouille à partir du MPD.
Merci d'avance.

[fsmrel]

Bonsoir,


Je ne vous oublie pas. Avez-vous regardé Open ModelSphere ? Voire MySQL Workbench ? (qui permet de construire des MLD de façon simple).

[lagra007]

Merci,
J'ai téléchargé OpenModelSphere et à vrai dire j'ai un peu du mal (pas d'héritage, de lien identifiant) Pour les MCDs je préfère utiliser le bon vieux PowerAMC (Dont je vais bientôt retrouver l'utilisation (Je vous explique pas comment ^^)) Sinon MysqlWorkBench est pas mal. Bref, je refais bientôt le MLD. Pour plus de clarté.

Une petite question en passant : J'ai tendance à abuser des liens identifiants lorsqu'il y'a les cardinalités 1,n - 1,1 par exemple .Alors que ma prof n'en utilise pas dans certains et beaucoup de cas, Pourtant je me dis que c’est plus pratique de propager les identifiant et on évite de passer par des tables intermédiaires comme je l'ai lu dans votre très intéressant article.)
ex: Client {n°Client} --- 0,n--PASSER---(1,1)----Commande{n°Commande} ici elle n'en utiliserais pas donc pas si important.
et Commande {N°Commande} -----1,n----LIVRER-----(1,1)---Colis{N°Colis}
Mais après si on veut savoir quelles colis à été livré par la commande de Jean Dupont. On n’est pas obligé de passer par COMMANDE. Donc c'est cool.
(Ma prof la plupart du temps en utilise que dans le contexte de numerotation de chambre par hôtel par exemple).
Alors abuser des liens identifiants, est-ce grave ? ^^ Ou plutot, est-ce pas bien ne ne pas en abuser, Car je n’en vois pas beaucoup dans les MCDs ces temps ci.
Voilà, Bonne soirée.

[lagra007]

Autre question d'ordre technique, Dans le cas d'historique on à tendance à intégrer la date dans un identifiant. Car c'est le couple {N°Id,date} qui définit de manière unique l'enregistrement. Est-ce une bonne manière de faire ou est-ce qu'une champ de type date peut ralentir la recherche dans une base de donnée. (Je pense au chaines de caractères).

[fsmrel]

Bonsoir,

J'ai tendance à abuser des liens identifiants lorsqu'il y'a les cardinalités 1,n - 1,1 par exemple. ... (Ma prof la plupart du temps en utilise que dans le contexte de numérotation de chambre par hôtel par exemple).

Il y a des cas d’utilisation légitime de l’identification relative, justifiés du point de vue de la sémantique, des cas pas très légitimes mais utiles et des cas où elle ne s’impose pas.

Si votre professeur s’en sert peu, elle a raison car elle vous force à réfléchir au bien fondé de l’usage qu’on en fait et, comme dans tous les domaines, la parcimonie est de mise, utere sed non abutere. Son exemple des chambres d’hôtel est un bon exemple d’utilisation légitime. A l’opposé, j’en fais un usage qu’elle pourrait trouver pas très légitime, mais j’ai toujours travaillé dans le monde de la production, là où l’on trouve les grandes bases de données (tables se comptant par 1000 ou 2000, certaines pouvant atteindre quelques centaines de millions de lignes, et même quelques milliards de lignes si l’on ne mettait pas un frein aux délires de la maîtrise d’ouvrage...), là où la performance est vitale pour la production informatique et ce sont bien ces considérations bassement matérielles qui m’ont conduit à user sans trop de modération de cette identification relative. Ainsi, vous avez relevé dans mon article cet intérêt qu’on peut avoir à propager les identifiants. Scolairement parlant je ne suis donc pas forcément un modèle à suivre, mais sur le terrain les résultats sont là et c’est surtout cela qui m’intéresse, outre la validité du contenu de la base de données (voyez à ce sujet le paragraphe dans lequel je traite des offres en relation avec la motorisation et la finition des modèles de voiture), en effet à quoi sert de pédaler à toute vitesse si ce que l’on manipule est faux ? Autrement dit, mes MCD sont parfois sémantiquement discutables, mais je ne vais pas m’amuser à éviter l’identification relative si ensuite j’ai des montagnes de tables dont la composition des clés primaires et étrangères est à modifier manuellement (sans compter la mise en œuvre de triggers qui s’imposeraient si j’en restais à l’identification absolue) : dans mes MCD j’identifie relativement et ensuite l’AGL répercute tout ça dans les tables, sans état d’âme.

Dans votre cas, il est des situations pour lesquelles l’identification relative ne s’impose pas a priori mais peut se justifier, cf. le cas des familles, mais en attendant considérons le schéma suivant :




N’est-il pas remplaçable par le suivant ?





En effet, le MLD qui en résulte est le même :




Accessoirement vous noterez que la clé primaire de la table GROUPE est la paire {NoStage, NoGroupe}, conséquence de l’identification relative. La clé primaire de la table PLACEMENT est donc le triplet {NoPersonne, NoStage, NoGroupe}. Étant donné qu’à un instant t un stagiaire appartient à un seul groupe, la table PLACEMENT est dotée d’une clé alternative {NoPersonne, DatePlace}. Cette clé (voyez le mickey <ak>, comme alternate key) est ajoutée manuellement, car à partir du MCD Merise, on peut produire soit la paire, soit le triplet, mais pas les deux simultanément. Du fait de vos observations successives, ne tenons pas trop compte de la partie inscription, sinon c’est mutatis mutandis (kif-kif).

Par ailleurs, la propagation de l’attribut NoStage jusque dans la table PLACEMENT est bien utile. En effet, quand un stagiaire est placé dans un groupe, il doit être placé dans une famille mais, si je ne m’abuse, le stage dont dépend le groupe doit être un stage auquel participe la famille accueillant le stagiaire. Cette contrainte peut être modélisée ainsi au niveau du MLD :




Pour plus de clarté, j’ai renommé l’attribut NoPersonne en NoFamille en ce qui concerne la table FAMILLE (au fait, une personne morale est une personne au même titre qu’une personne physique, donc exit CHEF_DE_FAMILLE).

La table PLACEMENT a toujours la même clé primaire {NoPersonne, NoStage, NoGroupe}, la même clé alternative {NoPersonne, DatePlace}, mais ce qui est intéressant, c’est que cette table est dotée d’une clé étrangère (cf. <fk3>) {NoFamille, NoStage} qui référence la clé primaire de la table PARTICIPATION : le stage auquel se rattache le groupe du stagiaire est un stage auquel participe la famille qui s’occupe de lui.

A titre d’exercice, je vous laisse le soin de réaliser le MCD correspondant, tout en sachant que Power AMC ou autre est incapable d’en inférer le MLD ci-dessus qui a nécessité que je le retouche légèrement. On est dans une situation comparable à celle qui concerne les offres évoquées ci-dessus (la finition et la motorisation caractérisant une offre doivent faire référence au même modèle de voiture).


Je n’ai pas répondu à l’ensemble de vos questions, mais tout en même temps ça fait un peu beaucoup...

A suivre donc (sachant que je vais devoir passer pas mal de temps avec ma pelle à neige...)

[fsmrel]

Bonsoir,

on ne doit pas supprimer la FicheInscription du stagiaire (nom du fichier pdf) car elle doit être consultable par les admin / famille / stagiaire).

Conservez-vous seulement la dernière fiche d’inscription, ou bien comptez-vous gérer un historique des fiches ?


Table PLACEMENT

J’ai proposé une clé alternative {NoPersonne, DatePlace} pour la table PLACEMENT, pour s’assurer qu’à la même date un stagiaire ne participe pas en même temps à deux stages différents. Mais cette date fait vraisemblablement double emploi avec celle qui a été défini pour la table STAGE (attribut DateDeb) : s’il en est ainsi, j’ai introduit une redondance qui conduit à un viol de la forme normale de Boyce-Codd... Dans ces conditions, l’attribut DatePlace doit disparaître de la table PLACEMENT, mais on devra continuer à s’assurer qu’un stagiaire ne participe pas en même temps à deux stages différents, un trigger ad-hoc est donc à prévoir, sur la base de la règle : si un stagiaire p1 a participé aux stages s1 et s2, la période i1 du stage s1 et la période i2 du stage s2 ne peuvent pas se chevaucher pour ce stagiaire.

Dans le cas d'historique on à tendance à intégrer la date dans un identifiant. Car c'est le couple {N°Id,date} qui définit de manière unique l'enregistrement. Est-ce une bonne manière de faire ou est-ce qu'une champ de type date peut ralentir la recherche dans une base de donnée. (Je pense au chaines de caractères).

1) Dans le cas général, la date (ou de préférence la période) entre dans la composition de l’identifiant d’une entité-type de type historique. Dans le cas de la table PLACEMENT, on évitera comme je l’ai dit, si la période d’un stage suivi par un stagiaire est égale à celle qui figure dans l’entité-type STAGE.

2) Je coiffe ma casquette de DBA : avec un SGBD digne de nom, aucun ralentissement perceptible à prévoir. Une date équivaut à une chaîne de caractères fixe de 10 octets (format AAAA-MM-JJ).

[lagra007]

Je vous remercie de prendre du temps
Je donnerais suite à vos messages demain.
Bonne nuit et merci de ces informations intéressantes.

[lagra007]

Bonjour, D'abord Joyeux Noël.
Oui, je garde toutes les fiches d'inscription d'un stagiaire.
En fait il n'est pas impossible qu'un stagiaire participe à plusieurs stages car les périodes de stages ne se chevauchent jamais. Mais c'est vrai qu'au niveau de la base de données c'est intéressant. (Même si étant le cas, je ne me serais pas embêter à vérifier qu'un stagiaire ne participe à 2 stages qui se chevauchent)
Bref, J'ai refait le mcd et régénéré le MLD.

Le MCD:

voir image en pj


Et voici le MLD

voir image en pj

Bien entendu j'ai modifié le MLD, en remplaçant N°Personne par N°Famille,Stagiaire,Prof etc..

Ensuite il y-avait encore bien-sur 2 fois N°Stage dans INSCRIPTION_STAGE (conséquence de l'id. relative)

Une question qui peut êtres va vous sembler idiote, en faites je comprends bien dans la table INSCRIPTION_STAGE que le N°Stage doit concerner le groupe du stagiaire et le stage de la famille mais je ne vois cela que par les jointures.

Je me dis donc, libre à n'importe qui de mettre dans INSCRIPTION_STAGE un N° de Famille qui ne participe pas au N° Stage du Stagiaire ?
J'imagine qu'il doit y-avoir du SQL derrière qui créer ces contraintes ?

Je suis bête, j'avais oublié que je n’avais pas mis de lien identifiant entre INSCRIPTION_STAGE et (ASSO FAMILLE_STAGE et GROUPE) mais même dans ce cas là, il y-a un mécanisme derrière ? Et si je n'inclue pas Groupe et Famille, c’est là je peux mettre n'importe quelle Stage qui ne concerne pas la famille ou le groupe ?
Je n'ai pas intégré Groupe et Famille à l'identification de INSCRIPTION_STAGE car bien sur on ne connait la famille et le groupe qu'après.

Désolé, j'suis vraiment brouillon là !

[fsmrel]

Bonsoir et joyeux Noël à vous aussi.


Quelques remarques préalables concernant la forme :

Du fait de l’AGL et du caractère anglo-saxon de SQL, pour les noms des objets (entités-types, attributs, etc.) il est préférable de se limiter aux lettres non accentuées, au symbole "_", aux chiffres et d’éviter les espaces :

ASSO FAMILLE STAGE devient ASSO_FAMILLE_STAGE (que l’on peut réduire à FAMILLE_STAGE car ASSO n’apporte pas de valeur ajoutée).

Typez au plus tôt les attributs (c'est-à-dire au niveau du MCD) : entier, caractère, date, etc.

Bien entendu j'ai modifié le MLD, en remplaçant N°Personne par N°Famille, Stagiaire, Prof etc.

Parfait. Ça n’était absolument pas une obligation, mais il faut reconnaître que du point de vue de la lecture du MLD c’est quand même bien pratique et moins ambigu.

Conservez-vous seulement la dernière fiche d’inscription, ou bien comptez-vous gérer un historique des fiches ?

Oui, je garde toutes les fiches d'inscription d'un stagiaire.

Puisque vous conservez toutes les fiches, vous conservez donc l’entité-type INSCRIPTION (alias INSCRIPTION_STAGE) et tant qu’à faire, vous pouvez y définir un attribut de type date correspondant par exemple à la date de réception ou de prise en compte de la fiche d’inscription, ça peut servir.

Cela dit, il y a un truc qui ne colle pas : vous avez établi une relation entre les entités-types INSCRIPTION et GROUPE avec une cardinalité 1,1, mais cette cardinalité devrait être 0,1 puisque le groupe n’est connu que plus tard : comme précédemment, autant mettre en œuvre l’entité-type PLACEMENT, mais en la rattachant à INSCRIPTION, d’où le MCD :




Ou bien, pour éviter le cycle produit par l’AGL entre INSCRIPTION et PLACEMENT :




En tout état de cause, une fois évacués les attributs redondants de la table PLACEMENT, le MLD produit est le suivant :

Ensuite il y-avait encore bien-sur 2 fois N°Stage dans INSCRIPTION_STAGE (conséquence de l'id. relative).
Une question qui peut êtres va vous sembler idiote, en faites je comprends bien dans la table INSCRIPTION_STAGE que le N°Stage doit concerner le groupe du stagiaire et le stage de la famille mais je ne vois cela que par les jointures.
Je me dis donc, libre à n'importe qui de mettre dans INSCRIPTION_STAGE un N° de Famille qui ne participe pas au N° Stage du Stagiaire ?
J'imagine qu'il doit y-avoir du SQL derrière qui créer ces contraintes ?

Je ne sais pas où vous en êtes en SQL quant aux contraintes, aussi je reprends les bases : il y a bien du SQL derrière, qui permet d’exprimer une contrainte générale dite d’intégrité référentielle. A cet effet, on utilise la clause FOREIGN KEY de l’instruction CREATE TABLE.

En ce sens, on code ainsi (on demande en fait à l’AGL de le faire pour nous) :

Définition (de la personne et) du stagiaire :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 CREATE TABLE PERSONNE (
   NoPersonne           INT                  NOT NULL,
   Nom                  VARCHAR(48)          NOT NULL,
   Prenom               VARCHAR(48)          NOT NULL,
   Etc                  VARCHAR(48)          NOT NULL,
   CONSTRAINT PERSONNE_PK PRIMARY KEY  (NoPersonne)
) ;
CREATE TABLE STAGIAIRE (
   NoStagiaire          INT                  NOT NULL,
   CONSTRAINT STAGIAIRE_PK PRIMARY KEY  (NoStagiaire),
   CONSTRAINT STAGIAIRE_PERSONNE_FK FOREIGN KEY (NoStagiaire)
      REFERENCES PERSONNE (NoPersonne)
) ;

Du fait de la contrainte STAGIAIRE_PERSONNE_FK, le SGBD surveille que chaque valeur prise par l’attribut NoStagiaire de la table STAGIAIRE est une valeur prise par l’attribut NoPersonne de la table PERSONNE. En cas de tentative de viol de la contrainte : échec de la requête coupable.

Concernant l’implication des familles dans les stages, le SGBD surveille que chaque valeur prise par l’attribut NoFamille de la table FAMILLE est une valeur prise par l’attribut NoPersonne de la table PERSONNE. Le SGBD surveille que chaque valeur prise par l’attribut NoFamille de la table PARTICIPATION est une valeur prise par l’attribut NoFamille de la table FAMILLE. Il surveille aussi que chaque valeur prise par l’attribut NoStage de la table PARTICIPATION est une valeur prise par l’attribut NoStage de la table STAGE :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
CREATE TABLE STAGE (
   NoStage              INT                  NOT NULL,
   DateDeb              DATE                 NOT NULL,
   DateFin              DATE                 NOT NULL,
   Etc                  VARCHAR(48)          NOT NULL,
   CONSTRAINT STAGE_PK PRIMARY KEY  (NoStage)
) ;
CREATE TABLE FAMILLE (
   NoFamille            INT                  NOT NULL,
   CONSTRAINT FAMILLE_PK PRIMARY KEY  (NoFamille),
   CONSTRAINT FAMILLE_PERSONNE_FK FOREIGN KEY (NoFamille)
      REFERENCES PERSONNE (NoPersonne)
) ;
CREATE TABLE PARTICIPATION (
   NoStage              INT                  NOT NULL,
   NoFamille            INT                  NOT NULL,
   NbStagiaires         INT                  NOT NULL,
   CONSTRAINT PARTICIPATION_PK PRIMARY KEY  (NoStage, NoFamille),
   CONSTRAINT PARTICIPATION_FAMILLE_FK FOREIGN KEY (NoFamille)
      REFERENCES FAMILLE (NoFamille),
   CONSTRAINT PARTICIPATION_STAGE_FK FOREIGN KEY (NoStage)
      REFERENCES STAGE (NoStage)
) ;

Concernant la composition des groupes, même principe :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE GROUPE (
   NoStage              INT                  NOT NULL,
   NoGroupe             INT                  NOT NULL,
   LibGroupe            VARCHAR(48)          NOT NULL,
   CONSTRAINT GROUPE_PK PRIMARY KEY  (NoStage, NoGroupe),
   CONSTRAINT GROUPE_STAGE_FK FOREIGN KEY (NoStage)
      REFERENCES STAGE (NoStage)
) ;

Idem pour les inscriptions :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE INSCRIPTION (
   NoStage              INT                  NOT NULL,
   NoStagiaire          INT                  NOT NULL,
   FicheInscr           VARCHAR(48)          NOT NULL,
   DateInscr            DATE                 NOT NULL,
   CONSTRAINT INSCRIPTION_PK PRIMARY KEY  (NoStage, NoStagiaire),
   CONSTRAINT INSCRIPTION_STAGIAIRE_FK FOREIGN KEY (NoStagiaire)
      REFERENCES STAGIAIRE (NoStagiaire),
   CONSTRAINT INSCRIPTION_STAGE_FK FOREIGN KEY (NoStage)
      REFERENCES STAGE (NoStage)
) ;

Venons-en aux placements. Le code SQL produit est le suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TABLE PLACEMENT (
   NoStage              INT                  NOT NULL,
   NoGroupe             INT                  NOT NULL,
   NoStagiaire          INT                  NOT NULL,
   NoFamille            INT                  NOT NULL,
   CONSTRAINT PLACEMENT_PK PRIMARY KEY  (NoStage, NoStagiaire),
   CONSTRAINT PLACEMENT_INSCRIPTION_FK FOREIGN KEY (NoStage, NoStagiaire)
      REFERENCES INSCRIPTION (NoStage, NoStagiaire),
   CONSTRAINT PLACEMENT_GROUPE_FK FOREIGN KEY (NoStage, NoGroupe)
      REFERENCES GROUPE (NoStage, NoGroupe),
   CONSTRAINT PLACEMENT_PARTICIPATION_FK FOREIGN KEY (NoStage, NoFamille)
      REFERENCES PARTICIPATION (NoStage, NoFamille)
) ;

Prenons le cas du stagiaire P1, inscrit dans le stage S1 : la présence de la contrainte PLACEMENT_INSCRIPTION_FK fait que le SGBD vérifie que la paire <S1, P1> est bien présente dans la table INSCRIPTION.

Maintenant, vous craignez que n'importe qui puisse affecter dans la table PLACEMENT une valeur de numéro de famille F1 qui ne participe pas au stage S1 du stagiaire P1, mais à un autre stage : soyez sans crainte.

En effet, du fait de la contrainte PLACEMENT_PARTICIPATION_FK (table PLACEMENT), on ne peut rattacher le stagiaire P1 qu’à la famille F1 du stage S1 : si la paire <S1, F1> est absente dans la table PARTICIPATION, la tentative de rattachement échouera. Même punition, même motif concernant le rattachement à un groupe.


Faites-moi penser à revenir sur la réflexive attachée à la table FAMILLE (parrainage).