Discussion :

[Chicna]

Salut !

je suis actuellement en stage dans un service qui s'occupe de reperer et d'affecter les eleves en difficultés dans des etablissements adaptés. L'etude, les propositions, et l'affectation se deroule lors de commissions.

voila où j'en suis dans mon MCD, pour l'instant :




Mes problemes :
1- les 3 associations entre COMMISSION et ELEVE me paraissent non approprié, car chaque association correspond en fait a un type de commission (entite TYPE_COMMISSION) :
- "etudie" correspond a la commission ayant le type : commission technique
- "propose" correspond a la commissioin ayant le type : CODEA
- "affecte" correspond a la commission ayant le type : commission d'affectation.
Ne pourrais-je pas faire un heritage avec la table COMMISSION et les 3 types plutot ?

2- j'ai fait une entite PARTICIPANT, mais mon probleme est que le chef d'etablissement (entite CHEF_ETABLISSEMENT) et le responsable legal (entite RESPONSABLE LEGAL) peuvent aussi etre defini en tant que participants...que dois-je faire pour modeliser cela ?


Si vous n'avez pas compris le MCD, n'hesitez pas a posez vos questions.

Merci d'avance pour vos reponses ! ^^

[fsmrel]

Bonjour,

Suite à un très rapide survol (de votre MCD qui a disparu et que je fais réapparaître ici).




1) Commissions et héritage

Si par héritage, vous déclinez l’entité-type Commission en 3 sous-types, cela signifie que celles-ci ont des propriétés spécifiques. Si vous les mettez en œuvre, les 3 relations Etudie, Propose, Affecte seront chacune branchées sur leur sous-type respectif. Cela veut dire que si les sous-types n’ont pas de propriétés propres (Commission restant porteuse des propriétés communes), elles n’offrent pas de valeur ajoutée sautant aux yeux. A voir à la lumière du rasoir d’Ockham : « Ne pas multiplier les entités au-delà du nécessaire ».

Question : peut-on affecter sans avoir étudié ou proposé ?

2) Chefs d’établissements et responsables

Vous pouvez définir une entité-type Personne (physique), ayant pour sous-types Chef établissement et Responsable. Les propriétés communes sont regroupées dans Personne et les propriétés spécifiques conservées par Chef établissement et Responsable. Les identifiants num_ce et numresp_leg disparaissent au profit d’un identifiant num_psn.

A son tour, Participant peut être défini comme sous-type de Personne, ou comme une relation entre Personne et Participe. Dans ce dernier cas, les relations avec des relations n’étant pas en odeur de sainteté en Merise, on en restera à utiliser graphiquement un carré : Participant est alors une entité faible (weak entity) dont l’identifiant est hérité de celui de Personne (cardinalité 1,1 entre parenthèses) et servant seulement à établir un pont avec les autres entités du modèle telles que Commission.

Tout ceci en première approche...

[Chicna]

1)

Question : peut-on affecter sans avoir étudié ou proposé ?

Non.
Quand on demande une orientation pour un quelconque eleve, on l'etudie tout d'abord durant la commission technique.
Ensuite, on effectue la commission dite CODEA, d'où decoule une proposition d'orientation (avis), et dont les responsables legaux doivent y repondre avant 15 jours de delai (reponse_parent), ensuite l'IA (inspecteur academique) tranche en decidant de l'orientation de l'eleve (decision_proposition).
Enfin, il y a la commission dite d'affectation, ou d'harmonisation, qui, comme son nom l'indique, affecte les eleves a un etablissement précis.

Si par héritage, vous déclinez l’entité-type Commission en 3 sous-types, cela signifie que celles-ci ont des propriétés spécifiques

Je pensais deplacer les donnés portées par les 3 association dans les entites-filles, mais maintenant, je ne crois pas que cela soit adequat, etant donne que celles-ci decoulent d'un eleve examiné en commission.

Je pense que je vais laisser les entité et associations sans rien changer.


2)

Participant est alors une entité faible (weak entity) dont l’identifiant est hérité de celui de Personne (cardinalité 1,1 entre parenthèses) et servant seulement à établir un pont avec les autres entités du modèle telles que Commission.

Je n'ais jamais envisagé cette solution (la notion d'entité faible et identifiant relatif n'est pas totalement acquise, j'ai encore un peu de mal a la modeliser dans les situations qui l'imposent). en y reflechissant, cela me parait correct, mais si l'entite mère est PERSONNE, serait-il logique, d'apres ce terme, de ne mettre qu'en entite-fille CHEF ETABLISSEMENT et REPONSABLE LEGAL et pas ELEVE, ou INSPECTEUR ?? Si j'applique votre solution, que devient l'entite CATEGORIE (celle-ci peut ne pas paraitre claire. Cette entite definit en fait la fonction des participants, comme par exemple : conseiller d'orientation, pedopsychiatre, psychologue, etc.) ??


quel est le logiciel de modelisation que vous utilisez ??


Merci beaucoup pour ces conseils

[fsmrel]

Je pense que je vais laisser les entité et associations sans rien changer.

Vous suivez les recommandations de Guillaume d’Ockham, pas de problème.

Si l'entité mère est PERSONNE, serait-il logique, d'après ce terme, de ne mettre qu'en entité-fille CHEF ETABLISSEMENT et REPONSABLE LEGAL et pas ELEVE, ou INSPECTEUR ?

N’oubliez pas que les propriétés d’un sous-type complètent celle d’une entité-type "polymorphe" : la relation (implicite) est "être" est non pas, par exemple, "composer" : Attention, dans l’exemple que j’ai donné, l’entité Personne n’est pas mère de l’entité Chef Etablissement. Une mère A des enfants, mais une personne EST un chef d’établissement ou un responsable. Chef d’établissement est une spécialisation de Personne et Personne peut être perçue comme une généralisation pour Chef d’établissement et Responsable. Rien n’empêche de considérer à leur tour un élève ou un inspecteur comme des personnes. Tous ces braves gens sont des personnes physiques partageant donc des propriétés communes. De même, un établissement est une personne d’un autre genre, partageant avec les précédentes certaines propriétés (téléphone, fax, adresse, ...)

Dans votre réflexion, n’oubliez pas qu’un sous-type peut à son tour faire l’objet d’un sous-typage. Par exemple, un parallélogramme peut être un rectangle qui peut être un carré. Ce même parallélogramme peut être un losange... Ce même parallélogramme peut être une spécialisation d’un trapèze qui est un quadrilatère, qui est un polygone, lequel peut être un cas particulier d’une figure plane, au même titre du reste qu’une ellipse se spécialisant à son tour en cercle, j’en passe est des meilleures.

La notion d'entité faible et identifiant relatif n'est pas totalement acquise

L’exemple bateau est celui de la ligne de facture : celle-ci n’a pas d’existence autonome, elle n’est qu’une propriété multivaluée de la facture. Pourquoi en fait-on une entité ? Entre autres parce qu’au niveau tabulaire, après dérivation du MCD en MLD, il est, à juste titre, plus simple de manipuler des attributs monovalués, même si selon la théorie relationnelle, un attribut multivalué est légal (première forme normale respectée, dès lors que chaque tuple de chaque relation (au sens du Modèle relationnel, informellement table au sens SQL) du genre Facture contient exactement une valeur pour chacun de ses attributs (une valeur pouvant être une autre relation (Ligne de facture en l’occurrence))).

La ligne de facture n’étant pas une entité "forte", elle est "faible" et conserve comme identifiant celui de la facture, plus un attribut (un séquenceur par exemple) permettant de distinguer deux lignes de facture distinctes d’une même facture. Ainsi, l’identifiant d’une ligne de facture est, par exemple, composé du couple {Facture_Id, Séquenceur_Relatif}. Dans le cas de Participant, le séquenceur est inutile, puisque qu’une personne joue au plus une fois le rôle de participant.

Quel est le logiciel de modélisation que vous utilisez ?

Il s’agit ici de PowerAMC, mais j’utilise aussi bien Toad Data Modeler ou DBDesigner ou autres, peu importe (mais je ne dispose pas hélas de Win’Design).


Concernant l’étude, la proposition et l’affectation d’un élève, il y a matière à un exercice intéressant : comment s’assurer que le cycle impliquant ces 3 types d’événements est cohérent ? Il serait peut-être déjà utile de définir des dates pour chacun d’eux.

[*alexandre*]

ou un statut

[Chicna]

Dans le cas de Participant, le séquenceur est inutile, puisque qu’une personne joue au plus une fois le rôle de participant.

L'entité PARTICIPANT n'aurait donc aucun identifiant ?
Si je place la fonction du participant dans cette entité, et non pas dans une entité "type", cela est-il correct, n'y aura-t-il pas redondance des informations, si par exemple, un chef d'etablissement doit participer a une commission, est donc perçu en tant que participant, et en tant que chef d'etablissement grace a la propriété "fonction" ET a l'entité CHEF ETABLISSEMENT ?

Concernant l’étude, la proposition et l’affectation d’un élève, il y a matière à un exercice intéressant : comment s’assurer que le cycle impliquant ces 3 types d’événements est cohérent ? Il serait peut-être déjà utile de définir des dates pour chacun d’eux.

J'ai posé la question concernant le cycle des commissions : il n'y pas de dates fixent chaque année, elles sont tres variables, sauf celle de la commission d'affectation qui se deroule durant le mois de juin.
Sinon je ne vois pas comment assurer la coherence de l'enchainement de ces commissions au niveau de l'analyse...

[*alexandre*]

si tu places dans participant il y aura forcément redondance !

personellement j aurais modélisé différament, j aurais une entité personne

et je pourrais ensuite traduire :

"une personne participe à une commission" et dans participe tu as une référence sur la nature de la participation

[Chicna]

oui c'est une bonne idée. Mais ce n'est pas la nature de la participation, mais du participant, c'est a dire de la personne qui doit etre mise en valeur.

Beaucoup de personne participent aux commissions, pouvoir les differencier par rapport a leur roles est donc primordial.

Mais je retiens ta proposition, puisqu'elle simplifie le probleme.

[fsmrel]

Dans le cas de Participant, le séquenceur est inutile, puisque qu’une personne joue au plus une fois le rôle de participant.

L'entité PARTICIPANT n'aurait donc aucun identifiant ?

Dans le mécanisme d’identification relative, PARTICIPANT hérite de l’identifiant de PERSONNE. Graphiquement cela apparaît au niveau du modèle logique mais pas à celui du modèle conceptuel. Il est évident que toute entité est identifiée.
J’ai seulement précisé que, contrairement aux lignes de facture, il n’y a pas à ajouter de séquenceur dans cet identifiant, dans la mesure où une personne ne joue qu’une seule fois le rôle de participant. Si une personne pouvait jouer plusieurs rôles, alors le séquenceur devrait intervenir.

Si je place la fonction du participant dans cette entité, et non pas dans une entité "type", cela est-il correct, n'y aura-t-il pas redondance des informations, si par exemple, un chef d'établissement doit participer a une commission, est donc perçu en tant que participant, et en tant que chef d'établissement ?

Si un chef d’établissement ne peut intervenir en tant que participant que comme chef d’établissement, alors il y aurait redondance à doter PARTICIPANT d’une propriété Type de participant, avec tous les risques d’incohérence que cela comporte. Si malgré tout vous souhaitez contrevenir aux règles de la modélisation en ajoutant cette propriété, mettez en œuvre au niveau logique une contrainte (assertion ou un trigger, suivant les possibilités de votre SGBD) permettant de s’assurer de la cohérence de la redondance...

grâce a la propriété "fonction" ET

Je suppose que ET est à interpréter comme EST ?

J'ai posé la question concernant le cycle des commissions : il n'y pas de dates fixent chaque année, elles sont très variables, sauf celle de la commission d'affectation qui se déroule durant le mois de juin. Sinon je ne vois pas comment assurer la cohérence de l'enchainement de ces commissions au niveau de l'analyse...

Ma remarque allait dans le sens suivant : si les événements sont datés (à la date à laquelle ils ont eu effectivement lieu !), est-il normal de faire un constat tel qu’une date de proposition antérieure à une date d’étude ? (Ce qui implique déjà qu’une étude existe en cas de proposition). Si la date figurant dans COMISSION permet d’assurer le contrôle chronologique, il resterait seulement à s’assurer qu’une proposition n’existe qu’à la condition qu’une étude la précède. Techniquement, cela pourrait être contrôlé au niveau logique par une contrainte (assertion ou un trigger, cf. ci-dessus).

[Chicna]

assertion ou un trigger

c'est a dire ?


La solution de l'entité faible me gene : il faut que je determine, sans redondance, la fonction ou le titre (psy, infirmier, pedopsy...et il y en a beaucoup d'autres : ce serait inutile et fastidieu d'en faire des entites), dans la table PARTICIPANT, et je ne peut pas l'indiquer sans creer de doublons.

Les entite RESPONSABLE LEGAL et CHEF_ETABLISSEMENT me genent enormement puisqu'elle peuvent aussi etre des participant. Dans ce cas, comment et où indiquer la fonction du participant ?

La solution d'Alexandres avec la generalisation en l'entite PERSONNE + une association participe avec comme propriété fonction, n'est donc pas valide.

[fsmrel]

Assertion ou un trigger :

Une assertion est une contrainte que l’on définit au niveau SQL et directement comprise par le SGBDR, par opposition à ce que l’on programme dans du code qui échappe au contrôle du SGBDR (curieusement, les principaux éditeurs de SGBDR ne fournissent pas cette possibilité, alors qu’elle existait dans le prototype SYSTEM R d’IBM, ancêtre de tous les SGBDR).

Un trigger (déclencheur) permet de déclencher des actions lors d’opérations de mise à jour portant sur une table donnée. Tous les grands SGBDR offrent cette possibilité qui permet de pallier plus ou moins facilement la lacune précédente.

Il faut que je détermine, sans redondance, la fonction ou le titre (psy, infirmier, pedopsy...et il y en a beaucoup d'autres : ce serait inutile et fastidieux d'en faire des entités), dans la table PARTICIPANT

Il est évident qu’il est hors de question de définir autant d’entités-types qu’il y a de natures différentes d’intervenants. Dans ce genre de situation, dans la mesure où l’on a défini le surtype PERSONNE, on peut définir un sous-type général où serait précisé la nature des personnes autres que les chefs d’établissement et responsables légaux (psy, infirmier, etc.) Si CATEGORIE correspond à cette nature, alors le MCD pourrait être celui défini en pièce jointe. A noter que si CATEGORIE change de place, les personnes peuvent participer directement aux commissions.

L’intérêt de la modélisation par type/sous-type est ici de n’avoir qu’à un seul endroit les éléments caractéristiques des personnes (nom, prénom, adresse, téléphone, etc.)

Maintenant, le MCD que vous avez proposé peut rester inchangé, sinon qu’il faut mettre en oeuvre une association entre COMMISSION et RESPONSABLE LEGAL et une autre entre COMMISSION et CHEF_ETABLISSEMENT. Ces associations permettront de savoir au niveau logique que tel chef d’établissement participe effectivement en tant que tel à telle commission, même chose pour les responsables légaux.

[Chicna]

Genial ! Vous venez de regler mon probleme ! Maintenant, je peut choisir entre les 2 solutions que vous venez de presenter (Concernant les 2 solutions, quel est votre avis ? Laquelle choisirez-vous a ma place ?).

La generalisation peut simplifier beaucoup de situation, mais lors de l'enregistrement des tables dans la base, j'ais trouvé plusieurs solutions (version simplifiée) :

PERSONNE (num_pers, nom, pren)
Primary key (num_pers)

CHEF_ET (num_pers, nom, pren, titre)
Primary key (num_pers)

RESP_LEG (num_pers, nom, pren)
Primary key (num_pers)

Une autre solution consiste a supprimer les propriétés communes des entités filles, et encore une autre consiste a supprimer les entité filles, et a mettre une propriété intitulé par exemple "code_type (chef_et/resp_leg)" dans PERSONNE.

[fsmrel]

Génial ! Vous venez de régler mon problème !

Comme disait ma grand-mère, « c’est toujours ça de pris ! »

Concernant les 2 solutions, quel est votre avis ?

Appelons « Scénario A » (cf. Pièce jointe ci-dessous) la solution où l’on utilise l’héritage. On a donc un surtype PERSONNE porteur des attributs communs et 3 sous-types porteurs de leurs attributs spécifiques.

Appelons « Scénario B » votre MCD.

Avec PowerAMC, lors de la dérivation du MCD en MPD (en fait MLD, si l’on s’en tient à la représentation graphique) on a la possibilité de produire une version collant à l’héritage (Pièce jointe : MLD, Scénario A) ou bien une version correspondant en fait à une dérivation de votre MCD (Pièce jointe : MLD, Scénario B).

Si vous utilisez PowerAMC, vous pouvez donc produire un MCD selon le Scénario A, en choisissant lors de l’étape suivante de générer les parents tout en ne faisant hériter que l’identifiant (MLD, Scénario A) ou bien de ne générer que les enfants, avec héritage de tous les attributs (MLD, Scénario B).

Si vous utilisez un autre AGL, je ne sais pas quelles sont les possibilités offertes à ce sujet.

Quoi qu’il en soit, au niveau MLD, on se trouve donc maintenant face à l’alternative : Scénario A ou Scénario B. La solution à retenir fait intervenir des paramètres logiques et physiques.

Par exemple, faire porter par PERSONNE les propriétés communes aux personnes, cela permet de faire des économies en termes de développement. Mais, si votre SGBD permet le typage (en créant par exemple un type NOM_PERSONNE et en déclarant le nom des personnes (chefs d’établissement, responsables légaux, participants, élèves, inspecteurs...) comme étant du type NOM_PERSONNE, vous pouvez aussi en une seule instruction de création de type, contrôler les noms et définir les opérateurs correspondants).

Si le SGBD ne permet pas de typer de façon satisfaisante, envisagez de retenir la solution MLD, Scénario A. Mais en contrepartie, la table PERSONNE peut poser des problèmes si elle fait l’objet par exemple de mises à jour concurrentes massives : le mécanisme de verrouillage fera patiner le système. Au contraire, plus les données sont éparpillées (MLD, Scénario B), moins les contentions ont des chances de se produire.

Bref, le choix de la solution est à faire en concertation avec l’administrateur de la base de données, avec une bonne idée des traitements de mise à jour, de la volumétrie, etc.

Une [solution] autre consiste à supprimer l’entité filles.

Cette solution n’est pas à retenir, car elle est produit un grand mélange, une sorte de big mac avec ketchup, confiture, etc. intégrés. En plus, cela est source de valeurs nulles extrêmement dangereuses dans les opérations. Et je ne parle pas des problèmes de contention et de volumétrie (la table devient obèse).


Deux remarques :

1) Selon votre MCD, un inspecteur ne peut participer qu’à une seule commission. Est-ce normal ?

2) L’élève habite dans une ville et dans un district. Si le code postal (ou la ville) détermine le district, lors de la dérivation, il y aura viol de la 3e forme normale : pour éviter cela, il serait alors préférable de définir une entité-type porteuse des données code postal et ville, en relation avec ELEVE et couper le lien ELEVE-DISTRICT au bénéfice d’un lien entre la nouvelle entité-type et DISTRICT.

[Chicna]

Voila mes 2 resultats :
Pièce jointe 9508 Pièce jointe 9509

1) Selon votre MCD, un inspecteur ne peut participer qu’à une seule commission. Est-ce normal ?

Non. Desole, je me suis trompé : un inspecteur preside une commission, et d'autres y participent.

2) L’élève habite dans une ville et dans un district. Si le code postal (ou la ville) détermine le district, lors de la dérivation, il y aura viol de la 3e forme normale : pour éviter cela, il serait alors préférable de définir une entité-type porteuse des données code postal et ville, en relation avec ELEVE et couper le lien ELEVE-DISTRICT au bénéfice d’un lien entre la nouvelle entité-type et DISTRICT.

J'ai verifié et normalement, le district comprend plusieurs villes, par exemple : il existe le district de Saint-Etienne, qui ne comprend pas que la ville de Saint-Etienne, mais aussi Saint-Priest-en-Jarez, Sorbiers...

bon, j'ai encore des modifications a faire alors...

[fsmrel]

Bel effort ! Ça commence à prendre tournure.

Concernant les villes et les districts, il y a un quiproquo. Ce que je voulais dire est exprimé par le graphique en PJ correspondant à l'hypothèse : une ville fait partie d'un seul district (décidemment, mieux vaut un dessin...)

Cas du calendrier

Étant donné que la règle générale veut que chaque entité-type fasse l’objet d’une table lors du processus de dérivation du MCD en MLD, l’entité-type CALENDRIER fait donc en toute rigueur l’objet d’une table. Maintenant, si pour chaque année calendaire on stocke a priori 365 lignes dans la table (366 pour les années bissextiles...), il faut reconnaître que l’intérêt de celle-ci est plus que limité. En réalité, si tel est le cas, alors on aura stocké en table l’extension du type DATE, chose parfaitement inutile. L’attribut Date_Debut (du type DATE) est évidemment à conserver dans la table SITUATION, comme élément participant à la clé primaire de cette dernière. Je vous suggère de réfléchir au manque total d’intérêt, au niveau relationnel, de faire participer l’attribut Date_Debut (de la table SITUATION) en tant que clé étrangère dans une contrainte référentielle en relation avec une table CALENDRIER susceptible de comporter 365 lignes pour chaque année, ce qui devrait en l’occurrence vous amener à la conséquence logique que la table CALENDRIER n’a pas à exister. Maintenant, s’il n’existe dans cette table que certaines dates très précises, ayant un sens pour elles-mêmes, alors on la conserve.

[Chicna]

Concernant les villes et les districts, il y a un quiproquo. Ce que je voulais dire est exprimé par le graphique en PJ correspondant à l'hypothèse : une ville fait partie d'un seul district (décidemment, mieux vaut un dessin...)

J'avais tres bien compris, mais j'ai tendance a mal m'exprimer, ça doit etre ça le probleme ^^.

En ce qui concerne l'entite CALENDRIER, c'est un principe que j'ai appris cette année par un professeur : pour avoir un historique, toujours faire une entite CALENDRIER.
Ensuite, quand j'ai fait l'association situation et que j'ai voulu la faire verifier par mes professeurs, ils ont tout de suite mis un point sur l'importance d'utiliser une entité CALENDRIER puisqu'effectivement, je vais avoir besoin de faire des historiques. Je la garde donc.

[fsmrel]

Bonsoir Chicna,

Au niveau du MCD, je ne donnerai pas tort à votre professeur. Pour ma part, pendant de longues années j’ai enseigné, mais pour quitter le domaine des principes, j’ai aussi vérifié concrètement les conséquences de mes choix (et ceux des autres !), au niveau logique (tables), au niveau physique et en production. Si vous saviez les jours et les nuits que j’ai passés à supprimer les milliers de liens d’intégrité référentielle branchés sur des tables DATE ou CALENDRIER (sans, bien entendu, perdre quelque fonctionnalité que ce soit)...

Il est évident qu’il ne s’agit en aucune façon de faire abstraction de l’aspect historique des données. Je dis simplement qu’au niveau tabulaire il ne s’agit plus simplement de représenter les choses sous forme graphique, mais de produire un système opérationnel sous le contrôle du SGBD.

Supposons donc que nous soyons au niveau tabulaire et que les instructions de création des tables soient les suivantes :

Code :

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
24
25
26
27
28
29
30
31
CREATE TABLE CALENDRIER (
   DATE_DEBUT          DATE                NOT NULL,
   CONSTRAINT PK_CALENDRIER PRIMARY KEY  (DATE_DEBUT)
) ;

CREATE TABLE CLASSE (
   CODE_CLASSE         INT                 NOT NULL,
   LIBELLE_CLASSE      CHAR(32)            NOT NULL,
   CONSTRAINT PK_CLASSE PRIMARY KEY  (CODE_CLASSE)
) ;

CREATE TABLE ELEVE (
   NUM_ELEVE           INT                 NOT NULL,
   NOM_ELEVE           CHAR(32)            NOT NULL,
   PRENOM_ELEVE        CHAR(32)            NOT NULL,
   CONSTRAINT PK_ELEVE PRIMARY KEY  (NUM_ELEVE)
) ;

CREATE TABLE SITUATION (
   NUM_ELEVE            INT                  NOT NULL,
   CODE_CLASSE          INT                  NOT NULL,
   DATE_DEBUT           DATE                 NOT NULL,
   CONSTRAINT PK_SITUATION PRIMARY KEY  (CODE_CLASSE, NUM_ELEVE, DATE_DEBUT),
   CONSTRAINT FK_CLASSE FOREIGN KEY (CODE_CLASSE)
      REFERENCES CLASSE (CODE_CLASSE),
   CONSTRAINT FK_ELEVE FOREIGN KEY (NUM_ELEVE)
      REFERENCES ELEVE (NUM_ELEVE) ON DELETE CASCADE
   CONSTRAINT FK_CALENDRIER FOREIGN KEY (DATE_DEBUT)
      REFERENCES CALENDRIER (DATE_DEBUT)
) ;

La date DATE_DEBUT est bien présente dans la table SITUATION et la clé primaire de cette table est composée du triplet {CODE_CLASSE, NUM_ELEVE, DATE_DEBUT}, conformément à ce que l’on attend. Vous observerez aussi que cet attribut DATE_DEBUT est du type DATE.

Si notre calendrier est lambda, c’est-à-dire devant comporter toutes les dates possibles (à défaut un ajout dans la table SITUATION provoquerait une erreur pour viol d’intégrité référentielle), je vous demande de me préciser l’inconvénient que vous verriez à supprimer le lien d’intégrité référentielle figurant dans la table SITUATION (CONSTRAINT FK_CALENDRIER FOREIGN KEY (DATE_DEBUT) REFERENCES CALENDRIER (DATE_DEBUT)) et, conséquence logique, à supprimer la table CALENDRIER devenue inutile ? Pour ma part, j’agis au nom du principe d’essentialité, corolaire du rasoir d’Ockham (« Ne multipliez pas les entités au-delà du nécessaire »).

Je n’hésite donc pas à trancher et simplifier. Par rétroconception, j’obtiens le MCD figurant en PJ, dans lequel SITUATION est une entité-type associative, c’est-à-dire une relation au sens Merise du terme, faisant que l’on retrouve sans problème votre propre représentation. Cela signifie que ma façon de procéder n’a pas provoqué de perte, dans la mesure où le calendrier est lambda.

Bref, conservez votre modélisation, mais n’oubliez pas les conséquences en aval, pensez aux pauvres DBA, chargés de vérifier qu'une table contient bien toutes les dates possibles, jusqu'à la saint Glinglin incluse...

[*alexandre*]

modéliser les calendrier est inutile c'est résolu par ton applicatif

[fsmrel]

modéliser les calendrier est inutile c'est résolu par ton applicatif

Je ne comprends pas le sens de ce que vous écrivez. Un calendrier est un ensemble de dates et dans le cas général, une date étant une donnée, relevant donc de la modélisation des données, il en va de même pour un calendrier. Maintenant, la date ici en cause est à considérer comme un type, utilisé en particulier pour la propriété Date_Debut. Au niveau logique, le type Date est accompagné des opérateurs qui permettent de simplifier l’expression des requêtes SQL. En tout état de cause, une fois à ce niveau, l’attribut Date_Debut doit nécessairement figurer dans la table SITUATION, quelle que soit la façon dont cette table a été dérivée, y-compris à partir d’une entité-type CALENDRIER, laquelle, j’en conviens n’a pas à faire ici l’objet d’une table, au nom du principe d’essentialité et du rasoir d’Ockham.

[Chicna]

Premierement, vos instructions sont fausses pour 2 raisons :
- en tant qu'entité faible, la table classe dispose de l'identifiant code_classe et num_etablissement en tant que cle primaire.
- il y a une dependance fonctionnelle avec cette association (desole, je n'ai pas trouve comment la modeliser avec win'design) : date + num_eleve => num_classe (et donc num_etablissement).

Voici donc les instructions a realiser lors de la creation des tables :

Code :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

CREATE TABLE ELEVE (
num_eleve 		INT		NOT NULL,
nom_eleve 		VARCHAR(40) 	       NOT NULL,
pren_eleve 	        VARCHAR(40) 	        NOT NULL,
sexe_eleve 	        VARCHAR(8) 		NOT NULL,
datenai_eleve 	       DATE 			  NOT NULL default '0000-00-00',
rue_eleve		 VARCHAR(40)		NOT NULL,
cp_eleve 		 VARCHAR(40)		NOT NULL,
ville_eleve 	VARCHAR(40)		NOT NULL,
tel_eleve 		VARCHAR(40)		NULL,
mail_eleve		VARCHAR(40)		NULL,
code_district	VARCHAR(5)		NULL,
PRIMARY KEY (num_eleve),
FOREIGN KEY (code_district) REFERENCES DISTRICT(code_district)
) TYPE = InnoDB;

CREATE TABLE CLASSE (
code_classe		VARCHAR(20)		NOT NULL,
num_et		VARCHAR(40)		NOT NULL,
PRIMARY KEY (code_classe, num_et),
FOREIGN KEY (num_et) REFERENCES ETABLISSEMENT(num_et)
) TYPE = InnoDB;


CREATE TABLE CALENDRIER (
datedeb		DATE 			NOT NULL,
PRIMARY KEY (datedeb)
) TYPE = InnoDB;


CREATE TABLE SITUATION (
num_eleve		INT			NOT NULL,
datedeb		DATE			NOT NULL,
code_classe		VARCHAR(20)		NOT NULL,
num_et		VARCHAR(40)		NOT NULL,
PRIMARY KEY (num_eleve, date_debut),
FOREIGN KEY (num_eleve) REFERENCES ELEVE(num_eleve),
FOREIGN KEY (datedeb) REFERENCES CALENDRIER(datedeb),
FOREIGN KEY (code_classe) REFERENCES CLASSE(code_classe),
FOREIGN KEY (num_et) REFERENCES CLASSE(num_et)
) TYPE = InnoDB;

Deuxiemement, je vois pas a quoi correspond exactement le terme Lambda, mais en tout cas, la table calendrier aura le contenu que l'utilisateur decidera d'inserer, rien de plus (comme par exemple la date de tout les jours).