Problème de conception

**dev-linus** · 20/04/2012, 12h59

Salut tout le monde,
e travaille sur le développement d'une plateforme web de gestion des projets réalisés en 1ère, 2ème et 3ème année ingénieur et 1ère et 2ème année Master. afin de surveiller et d'évaluer l'avancement des différents groupes de projets. j'ai commencé par la conception de la base de données on respectant les contraintes suivantes:

-les groupes de projets sont formés de 2 jusqu'a 4 élèves.
-un groupe peut avoir plusieur projets à la fois(et par suite plusieur encadrant).
-un encadrant peut encadrer plusieur groupe à la fois.

j'ai fini par élaborer le modèle suivant:

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
CREATE TABLE etudiant (

  id               int(10) unsigned NOT NULL AUTO_INCREMENT,
  nom_utilisateur  varchar(32)  NOT NULL,
  mot_de_passe     char(40)     NOT NULL,
  adresse_email    varchar(128) NOT NULL,
  hash_validation  char(32)     NOT NULL,
  niveau 		   int(1)       NOT NULL,
  --Le champ hash_validation contient le hash de validation (un MD5) tant que le membre n'a pas validé son compte via l'e-mail qui lui a été envoyé. En gros, si ce champ est vide, le compte est validé ; sinon il n'est   pas validé.
  date_inscription date NOT     NULL,
  avatar           varchar(128) NOT NULL DEFAULT '',

  PRIMARY KEY (id),
  UNIQUE KEY nom_utilisateur (nom_utilisateur),
  UNIQUE KEY adresse_email (adresse_email),
  KEY mot_de_passe (mot_de_passe)  
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;

CREATE TABLE encadrant(
 id               int(10) unsigned NOT NULL AUTO_INCREMENT,
 nom_encadrant varchar(32)  NOT NULL,
 mot_de_passe     char(40)     NOT NULL,
 adresse_email    varchar(128) NOT NULL,
 hash_validation  char(32)     NOT NULL,
--Le champ hash_validation contient le hash de validation (un MD5) tant que le membre n'a pas validé son compte via l'e-mail qui lui a été envoyé. En gros, si ce champ est vide, le compte est validé ; sinon il n'est   pas validé.

 PRIMARY KEY (id),
 UNIQUE KEY nom_encadrant (nom_encadrant),
 UNIQUE KEY adresse_email (adresse_email),
 KEY mot_de_passe (mot_de_passe),
 date_inscription date NOT     NULL,
 avatar           varchar(128) NOT NULL DEFAULT '',
)


CREATE TABLE projet(
nom_projet        varchar(128) NOT NULL,
date_publication  date NOT     NULL,
date_remise       date NOT     NULL,
nombre_max_membre int(1) NOT NULL,
nombre_min_membre int(1) NOT NULL
nom_responsable   varchar(128) NOT NULL, --le responsable est l'un des encadrants 
)

CREATE TABLE groupeEncadrantProjet(
nom_projet		    varchar(128) NOT NULL,   
nom_membre_un 		varchar(32)  NOT NULL,
nom_membre_deux		varchar(32)  NOT NULL,
nom_membre_trois 	varchar(32)  NOT NULL,
nom_membre_quatre 	varchar(32)  NOT NULL,
nom_encadrant	    varchar(32)  NOT NULL,

CONSTRAINT fk_to_encadrant FOREIGN KEY (nom_encadrant)
  REFERENCES encadrant(nom_encadrant),

CONSTRAINT fk_to_projet FOREIGN KEY (nom_projet)
  REFERENCES projet(nom_projet),
  
CONSTRAINT fk_to_etudiant FOREIGN KEY (nom_binome_un)
  REFERENCES etudiant(nom_utilisateur),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (nom_binome_deux)
  REFERENCES etudiant(nom_utilisateur),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (nom_binome_trois)
  REFERENCES etudiant(nom_utilisateur),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (nom_binome_quatre)
  REFERENCES etudiant(nom_utilisateur)
)

sachant que je suis débutant,je veux savoir est ce que ce schéma relationnel est-il correcte ? (ie: est ce que je ne vais pas trouver des difficultés quand il s'agit de la manipuler avec PHP ?).

Merci

.

**punkoff** · 20/04/2012, 13h26

Bonjour,

Pour des problèmes de conception il vaut mieux analyser un MCD et non un MPD.
Utilisez un logiciel de conception, il fera la transcription MCD => MPD automatiquement et vous évitera des erreurs.

Concernant votre implémentation il y a un problème avec les clef étrangère.

Une clef étrangère, dans votre cas, va référencer une clef primaire d'une autre table et non un "nom".

Ensuite, partons du MCD :

Il manque des règles de gestion :
- On ne se sait pas si un projet peut être réalisé par différent groupe.
- On ne sait pas si un élève peut appartenir à plusieurs groupe différent.
- On ne sait pas si un groupe Projet peut être encadré par différent Encadrant.

donc quand vous écrivez vos RG, faites le dans les deux sens. Par exemple :
- Un élève peut appartenir à plusieurs groupe projet
- Un groupe projet est constitué de 2 à 4 élèves (ici le 2 est difficile à modélisé, c'est pour celà que je prend une cardinalité de 0 dans le MCD)

=> Ceci va impacter le MPD.

Sinon,
Eleve-0,n------Appartient-------0,4-groupeProjet
Encadrant-0,n-------Encadre-----0,n-groupeProjet

Au choix :
Projet-0,1------Réalisé-------0,n-groupeProjet
ou
Projet-0,n------Réalisé-------0,n-groupeProjet

Ceci va ce transformer, niveau MPD :
=> colonne soulignée = PK, un # devant une colonne = FK

Eleve(ele_id, ......)
Encadrant(enc_id, ....)
groupeProjet(grp_id, ....)
Projet(prj_id, ...)

A_ele_grp(#ele_id, #grp_id)
=> il faudrai mettre en place une contrainte check pour vérifier qu'il n'y a pas plus de 4 élèves dans un group. Mais il me semble que Mysql ne le gère pas

A_enc_grp(#enc_id, #grp_id)
A_prj_grp(#prj_id, #grp_id)

Une autre personne pourra avoir un avis différent du mien sur cette modélisation.

**dev-linus** · 20/04/2012, 18h45

oui,effectivement:
-un projet peut être réalisé par différent groupe.
-un élève peut appartenir à plusieurs groupe différent(avec des projets différents bien sur ).
-un groupe Projet peut être encadré par différent Encadrant.
- Un élève peut appartenir à plusieurs groupe de projet différent.

donc si je comprend bien,la conception de la base de donnée va étre comme ça:

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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
--Eleve(ele_id, ......)
CREATE TABLE etudiant (

  etudiant_id      int(10) unsigned NOT NULL AUTO_INCREMENT,
  nom_utilisateur  varchar(32)  NOT NULL,
  mot_de_passe     char(40)     NOT NULL,
  adresse_email    varchar(128) NOT NULL,
  hash_validation  char(32)     NOT NULL,
  niveau 		   int(1)       NOT NULL,
  --Le champ hash_validation contient le hash de validation (un MD5) tant que le membre n'a pas validé son compte via l'e-mail qui lui a été envoyé. En gros, si ce champ est vide, le compte est validé ; sinon il n'est   pas validé.
  date_inscription date NOT     NULL,
  avatar           varchar(128) NOT NULL DEFAULT '',

  PRIMARY KEY (id),
  UNIQUE KEY nom_utilisateur (nom_utilisateur),
  UNIQUE KEY adresse_email (adresse_email),
  KEY mot_de_passe (mot_de_passe)  
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
--Encadrant(enc_id, ....)
CREATE TABLE encadrant(
 encadrant_id    int(10) unsigned NOT NULL AUTO_INCREMENT,
 nom_encadrant varchar(32)  NOT NULL,
 mot_de_passe     char(40)     NOT NULL,
 adresse_email    varchar(128) NOT NULL,
 hash_validation  char(32)     NOT NULL,
--Le champ hash_validation contient le hash de validation (un MD5) tant que le membre n'a pas validé son compte via l'e-mail qui lui a été envoyé. En gros, si ce champ est vide, le compte est validé ; sinon il n'est   pas validé.

 PRIMARY KEY (id),
 UNIQUE KEY nom_encadrant (nom_encadrant),
 UNIQUE KEY adresse_email (adresse_email),
 KEY mot_de_passe (mot_de_passe),
 date_inscription date NOT     NULL,
 avatar           varchar(128) NOT NULL DEFAULT '',
)

--Projet(prj_id, ...)
CREATE TABLE projet(
projet_id         int(10) unsigned NOT NULL AUTO_INCREMENT,
nom_projet        varchar(128) NOT NULL,
date_publication  date NOT     NULL,
date_remise       date NOT     NULL,
nombre_max_membre int(1) NOT NULL,
nombre_min_membre int(1) NOT NULL
nom_responsable   varchar(128) NOT NULL, --le responsable est l'un des encadrants 
)
--groupeProjet(grp_id, ....)
CREATE TABLE groupeProjet(
groupe_id           int(10) NOT NULL,   
membre_un_id        int(10)  NOT NULL,
membre_deux_id		int(10)  NOT NULL,
membre_trois_id 	int(10)  NOT NULL,
membre_quatre_id 	int(10)  NOT NULL,
  
CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_un_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_deux_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_trois_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_quatre_id)
  REFERENCES etudiant(id)
)

--A_ele_grp(#ele_id, #grp_id)

CREATE TABLE A_etudiant_groupe(
etudiant_id int(10),
groupe_id	int(10),

CONSTRAINT fk_to_etudiant FOREIGN KEY (etudiant_id)
  REFERENCES etudiant(id),
CONSTRAINT fk_to_groupeProjet FOREIGN KEY (groupe_id)
  REFERENCES (groupe_id)
)
--A_enc_grp(#enc_id, #grp_id)
CREATE TABLE A_encadrant_groupe(
encadrant_id int(10),
groupe_id	 int(10),

CONSTRAINT fk_to_encadrant FOREIGN KEY (encadrant_id)
  REFERENCES etudiant(id),
CONSTRAINT fk_to_groupeProjet FOREIGN KEY (groupe_id)
  REFERENCES groupeProjet(groupe_id)
)
--A_prj_grp(#prj_id, #grp_id)

CREATE TABLE A_projet_groupe(
projet_id    int(10),
groupe_id	 int(10),

CONSTRAINT fk_to_Projet FOREIGN KEY (groupe_id)
  REFERENCES (projet_id),
CONSTRAINT fk_to_groupeProjet FOREIGN KEY (groupe_id)
  REFERENCES groupeProjet(groupe_id)
)

**punkoff** · 20/04/2012, 20h21

Niveau implémentation oui.

Niveau conception non.

Concernant cette table :

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
 
CREATE TABLE groupeProjet(
groupe_id           int(10) NOT NULL,   
membre_un_id        int(10)  NOT NULL,
membre_deux_id		int(10)  NOT NULL,
membre_trois_id 	int(10)  NOT NULL,
membre_quatre_id 	int(10)  NOT NULL,
 
CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_un_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_deux_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_trois_id)
  REFERENCES etudiant(id),
  CONSTRAINT fk_to_etudiant FOREIGN KEY (membre_quatre_id)
  REFERENCES etudiant(id)
)

Les informations dedans sont redondante avec la table A_etudiant_groupe (et ca n'a pas lieu d'être)

Cette table groupeProjet, vous l'avez dénormalisée.
Les liens entre etudiant et groupeProjet ce font dans la table A_etudiant_groupe.

Il vous faut donc choisir, soit la dénormalisation (dans ce cas la table A_etudiant_groupe disparait), soit la normalisation (dans ce cas les attributs de la table groupeProjet disparaissent)

Je part du principe que l'on garde la formule normée :

La table groupeProjet n'aura donc qu'un seul attribut... sa primary key.
On pourrai cependant rajouter une date de création, ou autre attribut utile.

Vu les nouvelles RG, le reste est ok.

**dev-linus** · 21/04/2012, 01h06

Ok, donc pour déterminer les membres d'un groupe pour un projet donné, en envoie une requête qui cherche dans la table A_etudiant_groupe les étudiant qui ont le même id_groupe.
J’adopte donc votre solution,
Merci énormément pour votre aide,je peux commencer maitenant

Problème de conception [MLD]

Schéma

Discussions similaires

Partager

Partager