Besoin d'aide à Jour J moins 5

**souley9** · 24/10/2013, 04h49

Bonjour à tous ,
veuillez m'excuser du dérangement j'aimerai que vous m'aidiez ,car j'ai un sujet de merise à traiter le plus rapidement possible et j'aurai besoin de vos connaissances pour identifier normalement les dépendances fonctionnelles élémentaires ,
la construction du graphe de couverture minimale et bien autres points techniques
En résumé je vous présente le sujet au format .jpg afin que vous puissiez m'aider.

Partie 1 et 2 en dessous

Merci d'avance ...

**fsmrel** · 24/10/2013, 13h10

Bonjour souley9,

Merci de présenter les jpg en clair, à l'affichage.

**fsmrel** · 25/10/2013, 02h34

Bonsoir Aboulaye,

Si je comprends bien, il s’agit de traiter des dépendances fonctionnelles à la sauce merisienne... Si vous ne l'avez pas déjà fait, je vous engage à consulter les articles de Cyril Gruau (Conception d’une base de données, paragraphe 1.3) et de ok.Idriss (Initiation à la conception de bases de données relationnelles avec MERISE).

A noter que tous les deux donnent la même définition de la dépendance fonctionnelle directe et de celle de la dépendance fonctionnelle transitive. En revanche, ils ne donnent pas la même définition de la dépendance fonctionnelle élémentaire (la dépendance fonctionnelle élémentaire d’Idriss est plus proche de celle de la théorie relationnelle), mais comme ceux qui ont inventé Merise furent muets quant aux dépendances fonctionnelles, il n'y a pas de référence à leur sujet et il faudra voir quelle définition a cours dans votre école.

Pour amorcer, comme à un matricule ne correspond qu’un seul nom, un seul prénom et une seule date de naissance, vous avez déjà les dépendances fonctionnelles :

DF01 : Matricule -> Nom
DF02 : Matricule -> Prénom
DF03 : Matricule -> DateNaissance

Si j’ai bien compris, un élève change de classe chaque année, et au cours d’une année donnée, un élève est inscrit dans une seule classe : dans ce qui précède, le mot clé est « seule », ce qui veut dire que pour un élève et une année il n’y a qu’une classe, d’où la dépendance fonctionnelle dont la partie gauche est composée de 2 attributs :

DF04 : Matricule + Année -> Classe

Où le symbole « + » représente l’union au sens de la théorie des ensembles.

Je signale en passant qu’au lieu d’écrire :

Matricule -> Nom

On devrait écrire

{Matricule} -> {Nom}

En effet la partie à gauche (Matricule) et la partie à droite (Nom) de la flèche (« -> ») devraient être des ensembles, mais Merise n’a pas été construite à partir de la théorie des ensembles...

Si j’ai encore bien compris, une classe relève d’une seule filière et d’un seul niveau, auquel cas on met en évidence les dépendances fonctionnelles :

DF05 : Classe -> Filière
DF06 : Classe -> Niveau

Toutes ces dépendances fonctionnelles sont directes. Mais de Matricule + Année -> Classe et Classe -> Filière on infère :

DF07 : Matricule + Année -> Filière

En effet, on démontre que la transitivité vaut pour les dépendances fonctionnelles : DF07 est une dépendance fonctionnelle transitive.

N.B. Un élève a-t-il le droit de redoubler une classe ? Si ça n’est pas permis, il existe la dépendance fonctionnelle :

DF08 : Matricule + Classe -> Année

Question :
Il n’est rien dit de vraiment précis sur les UE, et se contenter de dire que « les UE sont liées aux classes c’est plutôt vague » : De façon très précise, qu’est-ce donc qu’une UE ? vaut-elle pour une seule classe ? Merci de donner des exemples. A vous de voir quelles dépendances fonctionnelles on peut en tirer.

A partir des règles plus ou moins précises qu’on vous a données, il est probable qu’au moment où il faut faire jouer les notations, on aura quelque chose comme :

Au cours de l’année scolaire Année, l’élève de matricule Matricule a obtenu la note Note lors de la session Session de l’UE UE :

Année + Matricule + UE + Session -> Note

De même :

Année + Matricule + UE + Session -> UEvalidée

Sous réserve bien sûr de la définition que vous donnerez de l’UE.

A vous de jouer...

**souley9** · 25/10/2013, 10h00

Envoyé par fsmrel

Bonsoir Aboulaye,

Si je comprends bien, il s’agit de traiter des dépendances fonctionnelles à la sauce merisienne... Si vous ne l'avez pas déjà fait, je vous engage à consulter les articles de Cyril Gruau (Conception d’une base de données, paragraphe 1.3) et de ok.Idriss (Initiation à la conception de bases de données relationnelles avec MERISE).

A noter que tous les deux donnent la même définition de la dépendance fonctionnelle directe et de celle de la dépendance fonctionnelle transitive. En revanche, ils ne donnent pas la même définition de la dépendance fonctionnelle élémentaire (la dépendance fonctionnelle élémentaire d’Idriss est plus proche de celle de la théorie relationnelle), mais comme ceux qui ont inventé Merise furent muets quant aux dépendances fonctionnelles, il n'y a pas de référence à leur sujet et il faudra voir quelle définition a cours dans votre école.

Pour amorcer, comme à un matricule ne correspond qu’un seul nom, un seul prénom et une seule date de naissance, vous avez déjà les dépendances fonctionnelles :

DF01 : Matricule -> Nom
DF02 : Matricule -> Prénom
DF03 : Matricule -> DateNaissance

Si j’ai bien compris, un élève change de classe chaque année, et au cours d’une année donnée, un élève est inscrit dans une seule classe : dans ce qui précède, le mot clé est « seule », ce qui veut dire que pour un élève et une année il n’y a qu’une classe, d’où la dépendance fonctionnelle dont la partie gauche est composée de 2 attributs :

DF04 : Matricule + Année -> Classe

Où le symbole « + » représente l’union au sens de la théorie des ensembles.

Je signale en passant qu’au lieu d’écrire :

Matricule -> Nom

On devrait écrire

{Matricule} -> {Nom}

En effet la partie à gauche (Matricule) et la partie à droite (Nom) de la flèche (« -> ») devraient être des ensembles, mais Merise n’a pas été construite à partir de la théorie des ensembles...

Si j’ai encore bien compris, une classe relève d’une seule filière et d’un seul niveau, auquel cas on met en évidence les dépendances fonctionnelles :

DF05 : Classe -> Filière
DF06 : Classe -> Niveau

Toutes ces dépendances fonctionnelles sont directes. Mais de Matricule + Année -> Classe et Classe -> Filière on infère :

DF07 : Matricule + Année -> Filière

En effet, on démontre que la transitivité vaut pour les dépendances fonctionnelles : DF07 est une dépendance fonctionnelle transitive.

N.B. Un élève a-t-il le droit de redoubler une classe ? Si ça n’est pas permis, il existe la dépendance fonctionnelle :

DF08 : Matricule + Classe -> Année

Question :
Il n’est rien dit de vraiment précis sur les UE, et se contenter de dire que « les UE sont liées aux classes c’est plutôt vague » : De façon très précise, qu’est-ce donc qu’une UE ? vaut-elle pour une seule classe ? Merci de donner des exemples. A vous de voir quelles dépendances fonctionnelles on peut en tirer.

A partir des règles plus ou moins précises qu’on vous a données, il est probable qu’au moment où il faut faire jouer les notations, on aura quelque chose comme :

Au cours de l’année scolaire Année, l’élève de matricule Matricule a obtenu la note Note lors de la session Session de l’UE UE :

Année + Matricule + UE + Session -> Note

De même :

Année + Matricule + UE + Session -> UEvalidée

Sous réserve bien sûr de la définition que vous donnerez de l’UE.

A vous de jouer...

Wouah !! tout d'abord je tiens a vous remercier pour votre spontanéité Mr fsmrel (Expert Confirmé Sénior ),j'aimerai répondre à votre question concernant l'UE , en fait c'est l'Unité d'Enseignement qui correspond à ce que l'on appelait auparavant la « matière » ou « module » et a mon avis elle vaut pour une classe,et qu'on a 2 années pour la valider en cas d’échec à la première année.

Au plaisir de vous lire .

**fsmrel** · 25/10/2013, 11h10

Si UE est synonyme de matière et si « informatique de gestion » est une matière, cela vaut normalement pour plus d’une classe dans une école (disons d’informatique). Autrement dit dans ce cas-là il n’y a pas de dépendance fonctionnelle UE -> Classe. Si UE est synonyme de « module », exemple « programmation SQL », il est probable qu’on n’a toujours pas de dépendance fonctionnelle. Confirmez-vous ?

Si effectivement il n’y a pas de DF (dépendance fonctionnelle) UE -> Classe, alors qu’on va à la pêche à ces fichues DF, il faut s’échiner à en trouver malgré tout au moins une à laquelle participent UE et Classe ce que sous-entend la phrase « On suppose également que les UE enseignées sont liées aux classes... » On fera donc comme Philip Bernstein dans « Synthesizing Third Normal Form Relations from Functional Dependencies », on introduit un attribut factice, bidon (dummy) θ tel que :

Classe + UE -> θ

Attribut qu’on éliminera quand la modélisation de la base de données sera achevée.

Quelle est votre réponse à la question :

Envoyé par fsmrel

N.B. Un élève a-t-il le droit de redoubler une classe ? Si ça n’est pas permis, il existe la dépendance fonctionnelle :
DF08 : Matricule + Classe -> Année

Où en êtes-vous dans votre compréhension de l’exercice et de la rédaction qui s’ensuit ? Avez-vous commencé à représenter le graphe demandé ? Quoi qu’il en soit, la suite des opérations dépend complètement de la mise au jour de ces fichues DF, c'est quitte ou double...

N.B. N’oubliez pas de voter pour les réponses qui ont pu vous être utiles.

**souley9** · 25/10/2013, 13h03

Envoyé par fsmrel

Si UE est synonyme de matière et si « informatique de gestion » est une matière, cela vaut normalement pour plus d’une classe dans une école (disons d’informatique). Autrement dit dans ce cas-là il n’y a pas de dépendance fonctionnelle UE -> Classe. Si UE est synonyme de « module », exemple « programmation SQL », il est probable qu’on n’a toujours pas de dépendance fonctionnelle. Confirmez-vous ?

Si effectivement il n’y a pas de DF (dépendance fonctionnelle) UE -> Classe, alors qu’on va à la pêche à ces fichues DF, il faut s’échiner à en trouver malgré tout au moins une à laquelle participent UE et Classe ce que sous-entend la phrase « On suppose également que les UE enseignées sont liées aux classes... » On fera donc comme Philip Bernstein dans « Synthesizing Third Normal Form Relations from Functional Dependencies », on introduit un attribut factice, bidon (dummy) θ tel que :

Classe + UE -> θ

Attribut qu’on éliminera quand la modélisation de la base de données sera achevée.

Quelle est votre réponse à la question :

Où en êtes-vous dans votre compréhension de l’exercice et de la rédaction qui s’ensuit ? Avez-vous commencé à représenter le graphe demandé ? Quoi qu’il en soit, la suite des opérations dépend complètement de la mise au jour de ces fichues DF, c'est quitte ou double...

N.B. N’oubliez pas de voter pour les réponses qui ont pu vous être utiles.

Bien avant d'entamer le graphe et la suite ,j'aimerai revenir à la DF04 que vous avez établi à la phrase "A chaque début d'année scolaire ,elle(la secrétaire) précisera dans le logiciel, la classe dans laquelle chaque étudiant est inscrit".

j'ai eu l'idée de procéder de la sorte :

Année ->Inscription
Matricule + Classe ->Inscription

Qu'en pensez-vous ?

et aussi si DF06 : Classe -> Niveau et que DF04 : Matricule + Année -> Classe

alors Matricule + Année -> Niveau ? comme en DF07 ?

**fsmrel** · 25/10/2013, 17h08

si DF06 : Classe -> Niveau et que DF04 : Matricule + Année -> Classe alors Matricule + Année -> Niveau ? comme en DF07 ?

Oui, en vertu de la propriété de transitivité que possèdent les DF.

Année ->Inscription

Cela veut dire que pour une année donnée il ne peut pas y avoir plus d’une inscription, toutes classes et tous élèves confondus, ce qui est dand même un peu limite...

Matricule + Classe ->Inscription

Peut-être, mais il faut aussi penser aux valeurs qu’on donne aux données, réfléchir à l’aspect sémantique. Par exemple, si l’élève Raoul a le matricule 1234, ça je le conçois. Qu’il soit inscrit en 2013 dans la classe c2, je le conçois aussi. Mais que l’élève Raoul de matricule 1234, passe partie de la classe c2 avec l’inscription 21, je ne sais pas quel sens donner à « 21 » : un n° d’inscription ? Le jour de l’inscription ? Qu’en est-il pour vous ?

A mon sens, « inscrire » est un verbe qui sert seulement à la construction de la phrase dont le sujet est la paire {Année, Matricule} et le complément d’objet le singleton {Classe}, Le verbe « inscrire » donne la signification de la relation entre le sujet et le complément :

En 2013, le matricule 1234 est inscrit dans la classe c2.

Autre chose : quelle est votre réponse à la question que j’avais posée : « Un élève a-t-il le droit de redoubler une classe ? »

**souley9** · 25/10/2013, 18h39

Envoyé par fsmrel

Oui, en vertu de la propriété de transitivité que possèdent les DF.

Cela veut dire que pour une année donnée il ne peut pas y avoir plus d’une inscription, toutes classes et tous élèves confondus, ce qui est dand même un peu limite...

Peut-être, mais il faut aussi penser aux valeurs qu’on donne aux données, réfléchir à l’aspect sémantique. Par exemple, si l’élève Raoul a le matricule 1234, ça je le conçois. Qu’il soit inscrit en 2013 dans la classe c2, je le conçois aussi. Mais que l’élève Raoul de matricule 1234, passe partie de la classe c2 avec l’inscription 21, je ne sais pas quel sens donner à « 21 » : un n° d’inscription ? Le jour de l’inscription ? Qu’en est-il pour vous ?

A mon sens, « inscrire » est un verbe qui sert seulement à la construction de la phrase dont le sujet est la paire {Année, Matricule} et le complément d’objet le singleton {Classe}, Le verbe « inscrire » donne la signification de la relation entre le sujet et le complément :

En 2013, le matricule 1234 est inscrit dans la classe c2.

Autre chose : quelle est votre réponse à la question que j’avais posée : « Un élève a-t-il le droit de redoubler une classe ? »

Je suis tout à fait d'accord avec vous, concernant l'aspect sémantique

alors DF04 : Matricule + Année -> Classe

pour la question : Oui un élève a le droit de redouble une classe .

Autre chose en considérant UE comme une matière alors UE -> Classe ,tient toujours ?

**fsmrel** · 25/10/2013, 18h47

Autre chose en considérant UE comme une matière alors UE -> Classe ,tient toujours ?

Donnez quelques exemples de matières.

**souley9** · 25/10/2013, 19h53

Envoyé par fsmrel

Donnez quelques exemples de matières.

exemples de matières : PHYSIQUE DES DISPOSITIFS ,LANGAGE C,ELECTRONIQUE D'INSTRUMENTATION ...

**fsmrel** · 25/10/2013, 23h54

PHYSIQUE DES DISPOSITIFS ,LANGAGE C,ELECTRONIQUE D'INSTRUMENTATION ...

Est-ce que la physique des dispositifs peut être enseignée dans plus d'une classe ?

Est-ce que le langage C peut être enseigné dans plus d'une classe ?

Est-ce que l'électronique d'instrumentation peut être enseignée dans plus d'une classe ?

Plus généralement existe-t-il une UE qui peut être enseignée dans plus d'une classe ?

Si oui, il n'y a pas de dépendance fonctionnelle UE -> Classe ;

Sinon il existe la dépendance fonctionnelle UE -> Classe.

Qu'en est-il ?

**souley9** · 26/10/2013, 23h48

Envoyé par fsmrel

Est-ce que la physique des dispositifs peut être enseignée dans plus d'une classe ?

Est-ce que le langage C peut être enseigné dans plus d'une classe ?

Est-ce que l'électronique d'instrumentation peut être enseignée dans plus d'une classe ?

Plus généralement existe-t-il une UE qui peut être enseignée dans plus d'une classe ?

Si oui, il n'y a pas de dépendance fonctionnelle UE -> Classe ;

Sinon il existe la dépendance fonctionnelle UE -> Classe.

Qu'en est-il ?

Généralement il n'y existe pas une une UE qui peut être enseignée dans plus d'une classe : alors je suppose qu'on aura UE -> Classe

Donc en résumé :

DF01 : Matricule -> Nom

DF02 : Matricule -> Prénom

DF03 : Matricule -> DateNaissance

DF04 : Matricule + Année -> Classe

DF05 : Classe -> Filière

DF06 : Classe -> Niveau

DF07 : Matricule + Année -> Filière (transitive)

aussi : Année + Matricule + UE + Session -> UEvalidée

DF08 : Matricule + Classe -> Année , n'est plus valide car un étudiant a le droit de reprendre une classe . Qu'en pensez vous ?

Année + Matricule + UE + Session -> Note (je la garde aussi ?)

Année + Matricule + UE + Session -> UEvalidée ???

j'y suis presque grâce à vous Merci infiniment Mr fsmrel

**fsmrel** · 28/10/2013, 03h36

Bonsoir Aboulaye,

Généralement il n'y existe pas une UE qui peut être enseignée dans plus d'une classe : alors je suppose qu'on aura UE -> Classe

Ce « généralement » laisse planer un doute, mais vous assumez la dépendance fonctionnelle UE -> Classe : d’accord, on va faire comme ça... Espérons que le correcteur n’aura pas le point de vue contraire... A votre décharge, l’énoncé qu’on vous a donné est trop flou.

DF08 : Matricule + Classe -> Année , n'est plus valide car un étudiant a le droit de reprendre une classe. Qu'en pensez vous ?

Si vous savez qu’un élève peut redoubler (voire plus !), alors cette dépendance fonctionnelle n’existe pas.

DF07 : Matricule + Année -> Filière (transitive)

Certes, mais la dépendance fonctionnelle Matricule + Année -> Niveau va être jalouse si vous ne la mentionnez pas...

Année + Matricule + UE + Session -> Note (je la garde aussi ?)

Oui, sinon comment pourrez-vous traiter la Question 9 ? Nommons cette DF :

DF09 : Année + Matricule + UE + Session -> Note

Année + Matricule + UE + Session -> UEvalidée ???

Oui, sinon comment pourrez-vous traiter la Question 11 ?

A propos de la question 9, je note la présence de l’adverbe « respectivement ». Cela signifie qu’il est sous-entendu qu’il existera une table —appelons-la AUS — permettant d’héberger les triplets <Année, UE, Session> et une autre table — appelons-la MAUSN — permettant d’héberger les quintuplets <Matricule, Année, UE, Session, Note>. Si la table MAUSN est une conséquence de la dépendance fonctionnelle DF09, pour sa part la table AUS n’est la conséquence d’aucune DF (sauf peut-être à dire que, puisqu’il y a exactement deux sessions, l'on définira deux DF : UE -> S1 et UE -> S2, mais ça fait mesquin, car le jour il y aura trois ou quatre sessions par année, ce montage sera en échec...) Pour obtenir une DF, on peut (comme déjà signalé) s’inspirer de la technique de Philip Bernstein et introduire un attribut factice qu’on éliminera au cours de la modélisation :

Année + UE + Session -> θ

Mais on peut aussi imaginer un attribut DateSession correspondant à la date de la session...

Année + UE + Session -> DateSession

Ça vaut ce que ça vaut, mais si je tenais celui qui a rédigé l’exercice, je le soumettrais volontiers s à la question...

En tout cas, en ajoutant quelques attributs tels que le nom de la classe, le nom de l’UE, vous devriez aboutir à un code SQL de définition des tables du genre de celui-ci :

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
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
CREATE TABLE ANNEE 
(
   Annee                Int                  Not null,
   CONSTRAINT ANNEE_PK PRIMARY KEY (Annee),
   CONSTRAINT ANNEE_BORNES CHECK (Annee > 2010)   -- Exemple de contrôle de borne inf.
) ;
 
CREATE TABLE CLASSE 
(
   ClasseNo             Int                  Not null,
   ClasseNom            Varchar(64)          Not null,
   CONSTRAINT CLASSE_PK PRIMARY KEY (ClasseNo)
) ;
 
CREATE TABLE ELEVE 
(
   Matricule            Char(10)             Not null,
   Nom                  Varchar(64)          Not null,
   Prenom               Varchar(64)          Not null,
   DateNaissance        Date                 Not null,
   CONSTRAINT ELEVE_PK PRIMARY KEY (Matricule)
) ;
 
CREATE TABLE MAC 
(
   Matricule            Char(10)             Not null,
   Annee                Int                  Not null,
   ClasseNo             Int                  Not null,
   CONSTRAINT MAC_PK PRIMARY KEY (Matricule, Annee),
   CONSTRAINT MAC_ELEVE_FK FOREIGN KEY (Matricule) REFERENCES ELEVE,
   CONSTRAINT MAC_CLASSE_FK FOREIGN KEY (ClasseNo) REFERENCES CLASSE,
   CONSTRAINT MAC_ANNEE_FK FOREIGN KEY (Annee) REFERENCES ANNEE
) ;
 
CREATE TABLE UE 
(
   UEId                 Int                  Not null,
   ClasseNo             Int                  Not null,
   UElibelle            Varchar(64)          Not null,
   CONSTRAINT UE_PK PRIMARY KEY (UEId),
   CONSTRAINT UE_CLASSE_FK FOREIGN KEY (ClasseNo) REFERENCES CLASSE
) ;
 
CREATE TABLE AUS 
(
   Annee                Int                  Not null,
   UEId                 Varchar(32)          Not null,
   SessionNo            Int                  Not null,
   SessionDate          Varchar(64)          Not null,
   CONSTRAINT AUS_PK PRIMARY KEY (Annee, UEId, SessionNo),
   CONSTRAINT AUS_UE_FK FOREIGN KEY (UEId) REFERENCES UE,
   CONSTRAINT AUS_ANNEE_FK FOREIGN KEY (Annee)
      REFERENCES ANNEE
) ;
 
CREATE TABLE MAUSN 
(
   Matricule            Char(10)             Not null,
   Annee                Int                  Not null,
   UEId                 Varchar(32)          Not null,
   SessionNo            Int                  Not null,
   Note                 Varchar(64)          Not null,
   UEvalidee            Varchar(64)          Not null,
   CONSTRAINT MAUSN_PK PRIMARY KEY (Matricule, Annee, UEId, SessionNo),
   CONSTRAINT MAUSN_MAC_FK FOREIGN KEY (Matricule, Annee) REFERENCES MAC,
   CONSTRAINT MAUSN_AUS_FK FOREIGN KEY (Annee, UEId, SessionNo) REFERENCES AUS
) ;

Encore bon courage...

**fsmrel** · 28/10/2013, 17h32

Pour vérifier si ça marche...

Exemple d‘insertion d’une ligne relative à un élève :

Code SQL :

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

INSERT INTO ELEVE (Matricule, Nom, Prenom, DateNaissance) VALUES ('123456', 'Volfoni', 'Paul', '1916-01-16') ;

Modifier le prénom de l’élève :

Code SQL :

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

1
2
UPDATE ELEVE 
    SET Prenom = 'Raoul' WHERE Matricule = '123456' ;

Créer une classe :

Code SQL :

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

INSERT INTO CLASSE (ClasseNo, ClasseNom) VALUES (1, 'Math Géné') ;

Créer deux années :

Code SQL :

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

1
2
INSERT INTO ANNEE (Annee) VALUES (2013) ;
INSERT INTO ANNEE (Annee) VALUES (2014) ;

Inscrire un élève dans une classe :

Code SQL :

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

INSERT INTO MAC (Matricule, Annee, ClasseNo) VALUES ('123456', 2013, 1) ;

Classe auxquelles un élève a été inscrit au fil des ans :

Code SQL :

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

1
2
SELECT * FROM MAC
WHERE Matricule = '123456' ;

Créer des UE :

Code SQL :

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

1
2
INSERT INTO UE (UEId, ClasseNo, UElibelle) VALUES (1, 1, 'Théorie des ensembles') ;
INSERT INTO UE (UEId, ClasseNo, UElibelle) VALUES (2, 1, 'Théorie relationnelle') ;

Créer des liens entre deux UE et une session 1 :

Code SQL :

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

1
2
INSERT INTO AUS (Annee, UEId, SessionNo, SessionDate) VALUES (2012, 1, 1, '2012-12-15') ;
INSERT INTO AUS (Annee, UEId, SessionNo, SessionDate) VALUES (2012, 2, 1, '2012-12-15') ;

Moyenne des notes d’un élève donné pour une session donnée d’une année donnée :

Code SQL :

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

1
2
3
SELECT AVG(Note) AS Moyenne
FROM   MAUSN 
WHERE Matricule = '123456' ;

UE non validées par Raoul en 2012 pour la session 1 :

Code SQL :

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

1
2
3
4
5
6
SELECT *
FROM   MAUSN
WHERE  Matricule = '123456'
  AND  SessionNo = 1 
  AND  Annee = 2012 
  AND  UEvalidee <> 'validé' ;

**souley9** · 28/10/2013, 22h12

Merci à tous de m'avoir aidé en particulier Mr fsmrel ...

**fsmrel** · 29/10/2013, 00h10

Bonne route Aboulaye

**souley9** · 29/10/2013, 07h58

Bonjour Mr fsmrel ,

Je me suis mis à la résolution de la question 2 ,Déduire des dépendances fonctionnelles précédentes ,le graphe de couverture minimale correspondant au système d'information décrit ci-dessus.
alors j'ai construit mon graphe ,j'aimerai savoir s'il est correct et comment construire le MCD correspondant à partir du graphe de couverture ,et aussi traduire ce MCD dans le modèle relationnel ?

**fsmrel** · 29/10/2013, 20h43

Bonsoir Aboulaye,

Elaboration du MCD

Sans qu’on vous ait sans doute expliqué pourquoi, vous devez considérer les DF qui ne donnent lieu à aucune DF transitive, par exemple :

DF01 : Matricule -> Nom

a) D’en prendre une photo pour en faire une entité-type, en l’occurrence ELEVE_NOM.
b) D’ôter du graphe le dépendant (partie droite de la DF), à savoir l’attribut Nom.
c) De faire de la partie gauche de la DF l’identifiant de la nouvelle entité-type. En l’occurrence cet identifiant est composé du singleton {Matricule}, souligné dans l’image ci-dessous :

Vous considérez ensuite la 2e DF :

DF02 : Matricule -> Prénom

a) Vous en prenez la photo pour en faire une entité-type ELEVE_PRENOM.
b) Vous gommez le dépendant dans le graphe, à savoir l’attribut Prénom.
c) Une fois de plus la partie gauche de la DF devient l’identifiant de l’entité-type.

Vous considérez la 3e DF :

DF03 : Matricule -> DateNaissance

=>

Ces 3 entités-types sont évidemment les projections d’une seule entité-type ELEVE, que vous retrouvez en procédant à la jointure des 3 projections (ça se démontre, à condition de disposer des outils) :

On conserve donc ELEVE et on met à la poubelle ELEVE_NOM, ELEVE_PRENOM, ELEVE_NAISSANCE.

Reprenons votre graphe initial :

Après la mise en œuvre de l’entité-type ELEVE et gommage des dépendants dans les DF, le graphe devient le suivant :

A leur tour, les DF suivantes ne donnent lieu à aucune DF transitive :

DF05 : Classe -> Filière
DF06 : Classe -> Niveau

On peut donc en inférer l’entité-type CLASSE :

Et faire le ménage dans le graphe :

La DF DF04 : Matricule + Année -> Classe ne donne plus lieu à DF transitive, on infère donc l’entité-type MAC, en notant que, comme précédemment, la partie gauche de la DF {Matricule, Année} donne lieu à l’identifiant de l’entité-type :

Et le graphe devient :

Il faut maintenant procéder à une alchimie savante : Merise n’aime pas les redondances, or l’attribut Matricule apparaît deux fois, une 1re fois dans l’entité-type ELEVE, en tant qu’identifiant, une 2e fois dans l’entité-type MAC : de façon empirique, selon la recette merisienne (Merise 1re génération), si par hypothèse ELEVE est vraiment une entité-type, alors MAC est une association sur laquelle est branchée l’entité-type ELEVE. L'attribut Classe apparaît lui aussi deux fois, une 1re fois dans l’entité-type CLASSE, en tant qu’identifiant, une 2e fois dans l’entité-type MAC, donc là aussi MAC est à prendre comme une association sur laquelle est branchée l’entité-type CLASSE. A ce stade de la réflexion, la situation évolue ainsi :

MAC est une association, porteuse de l’attribut Année, mais les merisiens pur sucre n’admettent pas qu’un attribut porté par une association y soit identifiant : il faut donc expulser l’attribut Année et mettre en œuvre ex nihilo une entité-type pour l’héberger (où Année est de facto identifiant) :

Reste à définir les cardinalités. Un élève a pu fréquenter l’école plusieurs années et dans différentes classes, la patte connectant ELEVE et MAC est donc 1,N. Une année a vu plusieurs classes et plusieurs élèves, la patte connectant ANNEE et MAC est donc 1,N (ou plutôt 0,N si on voit large). Une classe est composée de plusieurs élèves et vit généralement plus d’un an, la patte connectant CLASSE et MAC est donc 1,N :

Mais dans cette histoire, on a perdu la DF DF04 : Matricule + Année -> Classe... Qu’à cela ne tienne, on dispose de ce qu’on appelle la CIF (contrainte d'intégrité fonctionnelle), qui permet de s’en souvenir (je vous renvoie par exemple à l’AGL WinDesign qui gère cela très bien). Il y a plusieurs façons de représenter une CIF, aussi utiliserai-je ce qu’il y a de plus simple, à savoir ajouter une pointe de flèche (rappelant la DF) sur la patte connectant CLASSE et MAC :

A vous de jouer pour ce qu’il reste du graphe et correspond aux DF :

DF09 : Année + Matricule + UE + Session -> Note
DF10 : Année + Matricule + UE + Session -> UEvalidée

**fsmrel** · 30/10/2013, 04h42

Bonsoir Aboulaye,

Jai l’impression que ce qu’il reste du graphe ne vous inspire pas outre mesure...

Allons-y quand même. On va utiliser une nouvelle recette, façon Masterchef.

Tout d’abord, de DF09 et DF10 on peut inférer la DF :

DF11 : Année + Matricule + UE + Session -> Note, UEvalidée

J’ai appliqué ici la règle d’union inférée des axiomes d’Armstrong (qu’on ne vous a peut-être pas enseignés...)

Ensuite, on va dire que ce qu’il reste du graphe représente en fait une association entre les attributs composant la partie gauche de la DF DF11. Ça n’est pas très scientifique comme approche, mais les MCD à la Merise ne se prêtent que très modérément à l’approche analytique qui vous a été imposée (modéliser en partant des dépendances fonctionnelles). Bref, appelons MAUSN cette association et faisons la figurer dans le graphe :

Comme Merise autorise que les associations soient porteuses d’attributs, on rapatrie la partie droite de la DF DF11 dans MAUSN :

Et on loge chacun des attributs Matricule, Année, UE, Session dans une entité-type :

Toutefois l’entité-type Matricule fait double emploi avec l’entité-type ELEVE qui va donc la remplacer. De même, l’entité-type Année existe déjà.

En renommant l’attribut Session en SessionId et l’attribut UE en UEId, en ajoutant le libellé de l’UE (attribut UElibelle) et en mettant tout dans la marmite, on obtient le MCD :

Et là, je me rends compte qu’en partant de votre graphe initial, j’ai oublié d'y prendre la DF UE -> Classe ! Pas grave, on ajoute dans le MCD l’association correspondante connectant UE et CLASSE, nommons-la UEC :

Notez que la cardinalité maxi portée par la patte connectant l’entité-type UE et l’association UEC est 1, par respect de la DF.

Notez encore que le script SQL de création des tables fait mention d’une table AUS qui n’est pas directement inférable du MCD, mais le point 9 comporte la phrase : « Donner des exemples de requêtes SQL permettant [respectivement] d’enregistrer une session d’examen concernant une UE (et une année scolaire) [...] », ce qui sous-entend que le tricot {UE, session, année} préexiste aux passages des examens par les élèves, d’où AUS. Si j’en avais tenu compte au stade du MCD, l'élaboration de ce dernier aurait été rendue trop compliquée et aurait nécessité le déguisement d’associations en entités-types, ainsi que l’utilisation de l’identification relative et vous seriez parti en courant car ça fait beaucoup... Mais après tout, peut-être êtes vous au fait de l’identification relative ? Quoi qu’il en soit, que l’on vous fasse construire un MCD à partir d’un ensemble de dépendances fonctionnelles n’est pas raisonnable, il faut construire le MCD à partir des règles de gestion, avec la technologie adéquate, par exemple l’héritage, concept qui échappe complètement à la méthode consistant à construire un graphe puis un MCD à partir des dépendances fonctionnelles.

Par ailleurs il existe une contrainte qu’il faudra faire figurer au niveau SQL (en Merise c’est un beau défi...) :

Un élève ne doit pas être noté pour une UE ne concernant pas la classe dans laquelle il se trouve actuellement.

N.B. Construire un MCD en partant des DF nécessite le plus souvent de connaître à fond la théorie des DF (à commencer par les axiomes d’Armstrong). Ainsi, ne vous lancez pas dans l’entreprise de construction du MCD avec la méthode du graphe si l’ensemble des DF est le suivant (exemple dû à Jeff Ullman) :

A,B -> C
C -> A
B,C -> D
A,C,D -> B
D -> E
D -> G
B,E -> C
C,G -> B
C,G -> D
C,E -> A
C,E -> G

Avec quelques couvertures minimales à la clé...

**souley9** · 30/10/2013, 12h43

Vous etes formidable tout parait si facile avec vous Mr fsmrel,je suis satisfait, j’ai plus de questions.moi qui trouvait cette discipline un peu ennuyante. Je vais m'y interesser de plus pres, sachant que j'ai du chemin à faire ahahah n'es ce pas?

Besoin d'aide à Jour J moins 5

Merise

Discussions similaires

Partager

Partager