Discussion :

[spring.time]

Merci beaucoup fsmrel

[DaizDev]

je peux l’implémenter sous vb.net?

Oui bien sûr mais je ne connais pas trop les RecordSet pour fusionner (Merge) les 2 listes. Tu as plusieurs solutions pour le faire. Tu as 2 requêtes à exécuter.

[spring.time]

{CNAME} = Cherche(Etudiant.Nom, {NAME_LISTE})


{NAME_LIST} = ListeEtudiantCritere(Niveau=Etudiant.Niveau AND Etudiant.PromotionInitial Est PromotionEnCours).OrderBy(Nom, ASC) + ListeEtudiantCritere(Niveau=Etudiant.Niveau Et Etudiant.PromotionInitial N'Est Pas PromotionEnCours).OrderBy(Nom, ASC)

svp pourriez vous m'expliquer cette {NAME_LIST}? j'aimerais la traduire en sql.

[fsmrel]

Bonsoir,


A propos du trio niveau, option, discipline.

Puisque d’une part seuls les niveaux 5 et 6 sont concernés par les options (spécialités), et que d’autre part les options du niveau 6 sont exactement celles du niveau 5, il est redondant, donc inutile d’établir une association entre les types d’entités NIVEAU et OPTION. Les associations entre les trois types d’entités peuvent être représentées ainsi au niveau MCD :



L’association-type CONSTITUER_DISCIPLINE_COMMUNE permet de prendre en compte les disciplines (matières) communes et l’association-type CONSTITUER_DISCIPLINE_A_OPTION permet de prendre en compte les disciplines parties prenantes dans les options. Rien n’interdit dans cette représentation qu’une discipline fasse partie à la fois des disciplines communes et des disciplines à option (par exemple, la discipline d fait partie des disciplines communes du niveau n (n < 5) et des disciplines à option du niveau 5).

Cela vous convient-il ?

Si oui, pour interdire en outre qu’une discipline soit à la fois discipline à option et discipline commune (de niveau 5 et 6 donc), il faudrait mettre en œuvre une contrainte d’exclusion, ce qui est faisable avec WinDesign mais pas avec PowerAMC. On pourrait représenter la chose ainsi :



Au niveau SQL, la contrainte est programmable à l’aide d’une assertion (ou de triggers si le SGBD ne sait pas ce qu’est une assertion).

[fsmrel]

@ DaizDev

Revenons sur votre diagramme. Ça coince cette fois-ci au sujet de l’option retenue par l’étudiant :




En effet, au vu de la clé, un étudiant peut opter pour plusieurs matières la même année, or il n’a droit en tout et pour tout qu’à une seule option durant son séjour à l’école.


Au niveau MCD, on pourrait représenter les choses ainsi (compte non tenu de l’année scolaire) :




Le type d’entité ETUDIANT_A_OPTION correspond à une spécialisation du type d’entité ETUDIANT et permet d’associer un étudiant à exactement (et non pas optionnellement) une option durant son séjour à l'école.

Au niveau SQL, il faudra s’assurer par une assertion (à défaut un trigger) qu’un étudiant n’est associé à une option que s’il a atteint le niveau 5.

Par ailleurs, la flèche bleue symbolise une CIF qui se traduit au niveau MLD par une clé candidate {EtudiantId, Annee} pour la table issue de l'association-type SE_SITUER : on s'assure ainsi qu’au cours d’une année scolaire un étudiant n’est bien qu’à un seul niveau.

En revanche, un étudiant peut rester plus d’une année au même niveau si j’ai bien compris.

[DaizDev]

svp pourriez vous m'expliquer cette {NAME_LIST}? j'aimerais la traduire en sql.

Il faut donc rajouter un champ promotioninitial_id à Etudiant qui sera une clé pour gérer les matricules des redoublants.

La requête 1 : Liste triée par ordre alphabétique des nom des étudiants qui ont pour promotion initiale, la promotion en cours et d'un niveau donné

La requête 2 : Liste triée par ordre alphabétique des nom des étudiants qui ont pour promotion initiale, une promotion différente que celle en cours et d'un niveau donné

il faut ensuite fusionner les 2 listes

[DaizDev]

Merci @fsmrel

En revanche, un étudiant peut rester plus d’une année au même niveau si j’ai bien compris.

Si j'ai bien compris, pour chaque année, le matricule d'un étudiant est recalculé. Le matricule est une clé donc naturelle si j'ai bien suivi. Est-il bon de reprendre le MCD en ce basant sur cette clé ?

[spring.time]

Bonjour tout le monde,

il n’a droit en tout et pour tout qu’à une seule option durant son séjour à l’école.

oh, pardon mon encadrant me l'a rectifié, un étudiant peut changer l'option, s'il échoue.

[spring.time]

En revanche, un étudiant peut rester plus d’une année au même niveau si j’ai bien compris.

oui, mais il fait partie de la promotion précédente et son matricule change.

[spring.time]

Si j'ai bien compris, pour chaque année, le matricule d'un étudiant est recalculé. Le matricule est une clé donc naturelle si j'ai bien suivi. Est-il bon de reprendre le MCD en ce basant sur cette clé ?

oui, elle est recalculé chaque année

[spring.time]

concernant la moyenne de la sixième année elle se calcule da la maniére suivante:
1: ((((note soutenance x 2)+(note documentation x 2))/4) x3)+ note militaire)/4
c'est la moyenne générale.

2: en deuxième lieu on va procéder au calcul de la moyenne de toutes les années :
(MG 3éme+MG 4éme+MG 5éme+MG 6éme)/4 donc c'est la moyenne des moyennes.

[spring.time]

à l'inscription à la 3e, chaque étudiant aura son matricule, donc j'ai fait une interface qui permet de choisir la promotion et l'année académique, donc,
etudiant e: niveau 3, annee=2012/2013, promotion 45(chaque année, on a une n°promotion pour la 3e)
donc matricule 4515 par exemple.

il me faut donc une table qui enregistre id_etudiant, id_niveau, id_promotion et id_annee.

que vous en pensez.?

[fsmrel]

Le matricule est une clé donc naturelle si j'ai bien suivi. Est-il bon de reprendre le MCD en ce basant sur cette clé ?

je répète pour la nième fois ce qu’à écrit Yves Tabourier dans les années quatre-vingts (De l’autre côté de MERISE page 81) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Comme Tabourier, conservez en mémoire ce que Goethe, Winston Churchill, George Santayana, Thomas Mann, et bien d'autres ont écrit :

« Ceux qui ont oublié le passé sont condamnés à le revivre ».

L’identifiant d’une entité-type ne doit rien décrire, être invariant, etc., il est fait d’une propriété purement artificielle.

S’il s’agit d’identifier l’étudiant, on le fera à partir d’une propriété de ce type, disons EtudiantId, à l'usage du système (intégrité d'entité, intégrité référentielle, opérations de jointure, etc.), tandis que le matricule bizarroïde donnera lieu à un identifiant naturel, à l'usage de l'utilisateur qui peut en faire ce qu'il veut, sauf à créer des doublons (respect de la règle d’unicité) et ne figurera sous forme de colonne que dans une seule table de la base de données.

Conséquence au niveau du MLD, comme je l’ai déjà mentionné :

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
 
CREATE TABLE ETUDIANT
(
        EtudiantId        INT          NOT NULL
      , Matricule         VARCHAR(8)   NOT NULL
      , EtudiantNom       VARCHAR(64)  NOT NULL 
      , PromotionId       INT          NOT NULL
      , ....
    , CONSTRAINT ETUDIANT_PK PRIMARY KEY (EtudiantId)
    , CONSTRAINT ETUDIANT_AK1 UNIQUE (Matricule)
    , CONSTRAINT ETUDIANT_PROMO_FK FOREIGN KEY (PromotionId)
                 REFERENCES PROMOTION (PromotionId)
    , ...
) ;

oh, pardon mon encadrant me l'a rectifié, un étudiant peut changer l'option, s'il échoue.

Faut pas pleurer spring.time, on va arranger ça ! (Mais tirez les oreilles de votre encadrant de ma part : des règles de gestion ça se grave dans le marbre, puis quand dans le temps elles fluctuent, les aménagements inhérents dans la base de données ça se monnaye...)


Bon, maintenant c'est moins drôle, je vais chez le dentiste

[fsmrel]

Bonsoir,

il me faut donc une table qui enregistre id_etudiant, id_niveau, id_promotion et id_annee.
que vous en pensez.?

J’en pense que votre vœu est légitime. La table qu’il vous faut est dérivée du type d’entité que j’ai appelée SCOLARITE dans le MCD ci-dessous (vous la renommez à votre guise).


MCD (notez l’identification relative)




MLD




J’ai ajouté Le type d’entité MATRICULE, car votre système d’identification des étudiants façon Pierre Dac fiche une zoubia pas possible. En effet, produire une base de données normalisée est tout à fait faisable, mais si on veut y arriver de façon rationnelle et autrement qu’au pif, il est nécessaire de connaître un minimum de théorie de la normalisation. On arrive à la structure de table (SCOLARISER) qui vous intéresse, mais il faut prouver que cette structure est valide. Vous n’êtes pas obligée d’apprendre par cœur ce qui suit, mais si cela vous intéresse, en étudiant ce qui suit, vous aurez un avant-goût de ce qu’il faut connaître pour normaliser une base de données...

On y va. Considérons les données de départ suivantes :

EtudiantId, Niveau, Promotion, Annee, Matricule

Voyons un échantillon de parcours d’étudiants.

Nous sommes en début d’année 2011.
L’étudiant identifié par EtudiantId = 1 s’appelle Albert, en 2008 (je simplifie la période scolaire 2008-2009) il est de la promotion 41, il est au niveau 3 et son matricule est 4115 ; l’année suivante (2009) il passe au niveau 4 ; l’année d’après (2010) il redouble et son matricule biscornu devient 40123 (la promo comptait 122 étudiants).

L’étudiant identifié par EtudiantId = 2 s’appelle Bernard, en 2008 il est lui aussi de la promotion 41, il est au niveau 3 et son matricule est 4150 ; l’année suivante (2009) il passe au niveau 4 ; l’année d’après (2010) il passe au niveau 5.

L’étudiante identifiée par EtudiantId = 9 s’appelle Carole, qui en 2010 est de la promotion 43, au niveau 3 et elle a pour matricule 4317.

Pour l’échantillon la situation est la suivante (si j’ai à peu près compris) :

Code :

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

1
2
3
4
5
6
7
8
9
EtudiantId    Promotion    Niveau    Nom      Annee    Matricule
         1           41         3    Albert    2008         4115
         1           41         4    Albert    2009         4115
         1           40         4    Albert    2010        40123
         2           41         3    Bernard   2008         4150
         2           41         4    Bernard   2009         4150
         2           41         5    Bernard   2010         4150
         9           43         3    Carole    2010         4317

La structure de la table correspondante est la suivante :

T {EtudiantId, Promotion, Niveau, Nom, Annee, Matricule}

On s’accroche. Pour travailler de façon rationnelle, on doit maintenant mettre en évidence les dépendances fonctionnelles à partir des règles de gestion des données et en déduire les clés candidates (approche analytique) :

Un étudiant a exactement un nom, d’où la dépendance fonctionnelle :

DF1 : {EtudiantId} -> {Nom}

Au cours d’une année scolaire un étudiant fait partie d’une seule promotion, d’un seul niveau et il a un seul matricule :

DF2 : {EtudiantId, Annee} -> {Promotion, Niveau, Matricule}

En revanche, comme un étudiant peut redoubler, DF2 n’est pas vérifiée si le déterminant est réduit à {EtudiantId}.
Un étudiant peut changer de matricule, mais seulement s'il change de promotion :

DF3 : {EtudiantId, Promotion} -> {Matricule}

Un matricule permet d’identifier exactement un étudiant :

DF4 : {Matricule} -> {EtudiantId}

En utilisant l’algorithme du seau (dû à Philip Bernstein), on déduit les clés candidates de la table :

K1 = {EtudiantId, Annee}

K2 = {Matricule, Annee}

On peut maintenant montrer que la table ne respecte pas la BCNF.

En effet, les déterminants (parties gauches) de DF1, DF3 et DF4 ne sont pas clés candidates (seule le déterminant de DF2 en est une). On utilise le théorème de Heath pour décomposer la table T selon les tables T1, T2, T3, T4 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
T1 {EtudiantId, Nom} 
    KEY  {EtudiantId} ; 

T2 {EtudiantId, Annee, Promotion, Niveau} 
    KEY {EtudiantId, Annee} ;

T3 {Matricule, EtudiantId} 
    KEY {Matricule} ;

T4 {Matricule, Annee} 
    KEY {Matricule, Annee} ;

Ces tables respectent cette fois-ci la BCNF (et même la 5NF).
La table T1 correspond à votre table Etudiant,
La table T2 correspond à la table que vous appelez de vos vœux (SCOLARITE),
La table T3 est peccamineuse puisque sa seule clé candidate, à savoir {Matricule} est archi significative et modifiable et ne peut donc être retenue comme clé primaire. On va donc doubler la colonne Matricule d’une colonne non significative et invariante maîtrisée seulement par le système, appelons-la MatriculeId. La structure devient :

Code :

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

1
2
3
T3 {MatriculeId, Matricule, EtudiantId} 
    KEY {MatriculeId} 
    KEY {Matricule}

Dans le contexte SQL, {MatriculeId} sera clé primaire et {Matricule} ravalée au rang de clé alternative,
Ce qui est vrai pour la table T3 vaut bien sûr pour la table T4 et pour des raisons de cohérence évidente, cette dernière reprend la colonne MatriculeId tandis que la colonne Matricule y est supprimée :

Code :

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

1
2
T4 {MatriculeId, Annee} 
    KEY {MatriculeId, Annee} ;

Je n’ai pas évoqué les clés étrangères, mais il est évident que la déclaration de T4 est à enrichir :

Code :

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

1
2
3
T4 {MatriculeId, Annee} 
    KEY {MatriculeId, Annee}
    FOREIGN KEY {MatriculeId} REFERENCES T3 {MatriculeId} ON DELETE CASCADE ;

De même que la déclaration de T3 :

Code :

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

1
2
3
4
T3 {MatriculeId, Matricule, EtudiantId} 
    KEY {MatriculeId} 
    KEY {Matricule} 
    FOREIGN KEY {EtudiantId} REFERENCES ETUDIANT {EtudiantId} ON DELETE CASCADE ;

La clause ON DELETE CASCADE signifie que si l’on supprime un étudiant de la table ETUDIANT, la suppression se propage dans T3 puis T4.

J'espère ne pas avoir commis d'erreurs de copier/coller...

Je reviendrai sur les options et les relations avec les profs.

A plus tard

[DaizDev]

Oh un pavé !

Dire que tout ça, c'est à cause d'un dentiste...

Super taff !

[spring.time]

impressionnant

je ne savais pas que la gestion des BD est liée avec les mathématiques et la théorie des ensembles,

ce cours le votre est très interessant, je vais le lire et le comprendre, moi qui espère etre un DBA, je vous remercie beaucoup,
mais quels prérequis mathématiques il faut avoir pour pourvoir suivre ce cours et pouvoir implémenter toutes ces techniques dans les BD?

----
pour l'attribut annee, je lève donc la table annee, je laisse qu'un attribut à saisir manuellement.d'accord
pour la table T3, j'ai une seule clé primaire qui est id_matricule, l'autre: matricule est unique



si seulement, vous pourrez m'aider pour la suite, la relation entre note, etudiant, discipline, moyenneFS, moyenneFM, bulletin, rattrapage, prof


je serais reconnaissante

merci encore une fois

[fsmrel]

Bonsoir,

je ne savais pas que la gestion des BD est liée avec les mathématiques et la théorie des ensembles

Le Modèle Relationnel de Données a bien sûr à voir avec la théorie des ensembles, mais au moins autant, sinon plus ! avec la logique des prédicats du 1er ordre.

Considérons la structure de la table SCOLARITE {EtudiantId, AnneeScolaire, Promotion, Niveau}. Elle représente en fait un prédicat à 4 places, lequel peut prendre une valeur de vérité, à savoir VRAI ou FAUX :

(P1) L’étudiant représenté par EtudiantId, au cours de l’année scolaire AnneeScolaire fait partie de la promotion Promotion au niveau Niveau.

Les lignes de la table représentent alors les propositions qui rendent VRAI le prédicat (hypothèse du monde clos) :

L’étudiant représenté par 1, au cours de l’année scolaire 2008-2009 fait partie de la promotion 41, au niveau 3,
L’étudiant représenté par 1, au cours de l’année scolaire 2009-2010 fait partie de la promotion 41, au niveau 4,
L’étudiant représenté par 1, au cours de l’année scolaire 2010-2011 fait partie de la promotion 40, au niveau 4,
L’étudiant représenté par 2, au cours de l’année scolaire 2008-2009 fait partie de la promotion 41, au niveau 3,
L’étudiant représenté par 2, au cours de l’année scolaire 2009-2010 fait partie de la promotion 41, au niveau 4,
L’étudiant représenté par 2, au cours de l’année scolaire 2010-2011 fait partie de la promotion 41, au niveau 5,
...

Mais attention, supposons qu’on veuille que l’option choisie par un étudiant vienne compléter le prédicat, ce qui fait que celui-ci est désormais à remplacer par un prédicat à 5 places :

(P2) L’étudiant représenté par EtudiantId, au cours de l’année scolaire AnneeScolaire fait partie de la promotion Promotion au niveau Niveau et a choisi l’option Option.

Bernard a atteint le niveau 5 et la proposition suivante est valide :

L’étudiant représenté par 2, au cours de l’année scolaire 2010-2011 fait partie de la promotion 41, au niveau 5 et a choisi l’option 3.

Mais pour sa part, l’étudiant représenté par 1 (Albert lui-même) n’a pas atteint le niveau 5 et donc n’est pas concerné par les options, même si dans sa tête il sait très bien quelle est la spécialité qu’il vise :

L’étudiant représenté par 1, au cours de l’année scolaire 2010-2011 fait partie de la promotion 40, au niveau 4 et il n’a pas choisi d’option.

Aïe ! Le prédicat correspondant est le suivant :

(P3) L’étudiant représenté par EtudiantId, au cours de l’année scolaire AnneeScolaire fait partie de la promotion Promotion au niveau Niveau et n’a pas choisi d’option.

Et l’on conclut que les prédicats P2 et P3 sont différents puisque P2 est à 5 places et P3 à 4 places. Comme nous sommes un peu jeunes pour oser invalider la logique des prédicats de Gottlob Frege, nous pouvons inventer une option factice, disons 0 pour les étudiants n’ayant pas atteint le niveau requis :

L’étudiant représenté par 1, au cours de l’année scolaire 2010-2011 fait partie de la promotion 40, au niveau 4 et a choisi l’option 0.

Mais cela tient quelque part du bricolage. Pour ma part, je suis plus favorable à appeler un chat un chat, ne pas bricoler, donc conserver le prédicat P1 et mettre en œuvre le prédicat supplémentaire suivant :

(P4) L’étudiant représenté par EtudiantId, au cours de l’année scolaire AnneeScolaire a choisi l’option Option.

D’où le MCD (Le prédicat P4 fait l’objet du type d’entité SCOLARITE_A_OPTION) :



Et le MLD




A noter que le type d’entité SCOLARITE_A_OPTION remplace le type d’entité ETUDIANT_A_OPTION qui traduisait la règle de gestion devenue entre temps obsolète : « un étudiant n’a droit en tout et pour tout qu’à une seule option durant son séjour à l’école ».

« mais quels prérequis mathématiques il faut avoir pour pourvoir suivre ce cours et pouvoir implémenter toutes ces techniques dans les BD? »

Les prérequis sont tout à fait basiques. Voulant m’adresser aux praticiens (dont nous faisons partie), j’ai rédigé en cherchant à rester le plus clair possible, éviter l’hermétisme, mais sans tomber non plus dans le laxisme, car le sujet mérite une certaine rigueur dont on ne peut faire l’économie.

Je ne peux que vous engager à commencer la lecture...

Quant à l’application des concepts et techniques, il n’y a pas de secret, c’est à force de pratique que les choses s’éclairent et se mettent en place. La normalisation n’est pas la panacée, elle ne résout pas tout mais elle contribue vraiment à rendre les choses plus claires et les bases de données plus robustes.

pour l'attribut annee, je lève donc la table annee, je laisse qu'un attribut à saisir manuellement

Que voulez-vous dire par lever une table ?

si seulement, vous pourrez m'aider pour la suite, la relation entre note, etudiant, discipline, moyenneFS, moyenneFM, bulletin, rattrapage, prof

Avec de l’aspirine je peux étudier cela, mais il faudrait que vous rassembliez et mettiez en forme ce qui a été écrit à ce sujet, en sorte qu’on y voie clair, sans qu’il faille crapahuter dans la masse des messages...

[spring.time]

(P4) L’étudiant représenté par EtudiantId, au cours de l’année scolaire AnneeScolaire a choisi l’option Option.

j'apprécie beaucoup votre manière d'expliquer, très méthodique


l'entité SCOLARITE_A_OPTION a comme clé primaire: les 2 clés étrangères:
EtudiantId et AnneeScolaireId et une clé étrangère OptionId, si j'ai compris

Que voulez-vous dire par lever une table ?

parce que j'ai remarqué que vous parlez d'attribut annee, il ne s'agit pas d'une table qui a comme attribut id_annee, non?

pour la table SCOLARITE, l'attribut AnneeScolaire, c'est une clé étrangère?

il faudrait que vous rassembliez et mettiez en forme ce qui a été écrit à ce sujet, en sorte qu’on y voie clair, sans qu’il faille crapahuter dans la masse des messages...

sous forme de MCD? de table MLD comme vous le faites?

[fsmrel]

Je viens seulement de voir votre message, je répondrai évidemment plus tard. En attendant :

Retour sur les disciplines.

Je résume... Durant une année scolaire, un étudiant est à un certain niveau. Il suit les disciplines (matières) de ce niveau : à cet effet, on définit une association-type NIVEAU_DISCIPLINE qui permet de connaître l’ensemble des disciplines communes et des disciplines propres aux 4 options du niveau 5. Les types d’entités NIVEAU_DISCIPLINE_COMMUNE et NIVEAU_DISCIPLINE_A_OPTION sont des spécialisations faisant l’objet d’une contrainte de partitionnement (exclusion et totalité) contraignant une discipline du niveau 5 à être soit une discipline commune, soit une discipline d'une option, mais pas les deux en même temps (ça peut paraître un peu du luxe, mais mettre en évidence un maximum de contraintes n'est jamais une mauvaise chose...) L'association entre OPTION et NIVEAU_DISCIPLINE_A_OPTION permet de connaître les disciplines de chaque option. Comme un étudiant de niveau 5 a choisi son option pour l'année scolaire, on connaît donc les matières qu’il suit en fonction de cette option, outre les matières communes qui sont celles du niveau dont il fait partie.

En ce qui concerne les professeurs : pour un niveau et une discipline il n'y a qu'un seul professeur enseignant cette discipline.



MCD




MLD



En SQL, la contrainte de partitionnement (XT) prend la forme d’une assertion (un trigger à défaut).

Dites-moi si cette partie vous convient, peut-être ai-je laissé passer quelque chose...

[spring.time]

Bonjour

En SQL, la contrainte de partitionnement (XT) prend la forme d’une assertion (un trigger à défaut).

Dites-moi si cette partie vous convient, peut-être ai-je laissé passer quelque chose...

oui je comprends, la discipline qui est commune ne doit pas être insérée dans la table pour disciplines liées à des options.

merci fsmrel