Discussion :

[youcef16dz]

Salam alaikoum tous le monde,
Actuellement, je développe une application de gestion de la formation en 2ème et 3ème cycle.
Je rencontre quelque difficultés de conception de la base donnée.
1. dans mon application, j'ai des étudiants en 3ème cycle qui sont, en même temps, des enseignants (soit dans notre établissement ou dans un autre établissement).
2. certains enseignants étais des étudiants en 1er, 2ème et/ou 3ème cycles.
3. un étudiants ou enseignant peut avoir 1 ou plusieurs N° téléphone ou adresse email. dans j'ai créer une table téléphone et une table émail, ces deux tables sont, évidement, donc
j'ai les tables :
Tab_enseignants (Mat_enseignant,Nom_enseignant,Prénom_enseignant,......)
Tab_étudiants (Mat_étudiant, nom_étudiants, Prénom_étudiants,......)
Tab_Téléphone (Id_tph, num_tph,mat_enseignant,mat_étudiant)
Tab_émail (id_émail, adr_émail, mat_enseignant,mat_étudiant)

les deux matricules (enseignants et étudiants) se répète aussi comme dans les tables Tab_Téléphone et Tab_émail, dans d'autre tables de ma base de donnée.

Je fait appel a votre éxperience pour vous demander, est ce que je garde les tables (tab_enseignants et Tab_étudiants), comme ils sont ou bien fusionné ces deux tables et crée une table catégorie (tab_catégorie) relier a ma nouvelle table, cette table contient sois la catégorie enseignant, ou étudiants.

je vous remercie d'avance pour tous conseil que vous me ferrais.

Cordialement

[tbc92]

Une table individus.
Au moins, tu n'auras pas de surprise, un individu reste un individu. Et l'idendifiant d'un individu va rester valable année après année.

Et une table qui donnera la fonction occupée par chaque individu, pour une année donnée. Pour cette table là, il y a plein de choix.

Pour un individu, et pour une année universitaire, on peut avoir une seule information (l'individu est simplement étudiant), ou bien plusieurs (l'individu est étudiant et prof ...)

[Voroltinquo]

Bonjour,
Un petit ajout, à la remarque de tbc92. S'il y a de nombreuses données spécifiques "Étudiant" et "Professeur" peux éventuellement créer des tables héritées de ta table "Individu" les données telles que l'état civil seront dans Individu et les données spécifiques seront dans "Étudiant" ou "Professeur" en fontion des cas. La PK de étudiant et celle de professeur sera alors la PK de Individu.
Par ailleurs je ne comprend pas l'utilités des tables Télephone et Mail.

[serendib]

3. un étudiants ou enseignant peut avoir 1 ou plusieurs N° téléphone ou adresse email. dans j'ai créer une table téléphone et une table émail, ces deux tables sont, évidement, donc
Tab_Téléphone (Id_tph, num_tph,mat_enseignant,mat_étudiant)
Tab_émail (id_émail, adr_émail, mat_enseignant,mat_étudiant)
Cordialement

Une seule table devrait suffire (Tél.+EMail) avec Clef individu avec doublons.

[tbc92]

Un individu peut avoir 2 n° de télephone, + 1 email
Et pourquoi pas un compte linkedin (ou FB ou...), qu'on pourrait considérer comme une 3ème voire 4ème méthode.
Du coup, je verrais toutes ces informations dans une table externe :
Id_Individu
Type_contact (un mot clé parmi TELEPH, EMAIL, FB, LINKED ...) ou un identifiant 1=Téléph 2=Email 3=FB ...
Le n° de tel, ou l'email , ou ...

Si un individu a 2 téléph et 1 email, il aurait donc 3 lignes dans cette table.

[youcef16dz]

Salam alaikoum,
Merci a tous pour vos réponse.
à vrais dire les tables étudiants et enseignants continent pratiquement presque les mêmes informations, sauf pour quelque détails, par exemple un enseignant a un grade (Maitre assistant, Maitre de conférences, Professeur, Chargé de recherche, Maitre de recherche et Directeur de recherche).
Pour étudiant j'ai besoin de savoir, pour les statistiques et la couverture social, s'il est travail ou pas et ou il travail le cas échéant.
Nous avons des cas ou certain étudiants en 3ème cycle sont des enseignant dans notre établissement (Maitre assistant).
1. Du fait que nous avons un système d'immatriculation des étudiants (que je ne peut pas changer) est différent de ceux des enseignants, ne faut t'il pas crée deux enregistrement pour une personne qui étudiant et qui est enseignant ?
2. un enseignant peut être un enseignant proprement dit ou un chercheur dans un centre de recherche ou un hospitalo-universitaire dans un hôpital.
3. certain des individus ont plusieurs email, mais pour les étudiants nous utilisons que leurs email professionnel mis a leur disposition par notre établissement.
4. l'idée de fusionné les tables email et téléphone, je trouve qu'elle est intéressante, juste ajouter un une table type coordonnée (Tél., email,.....)
5. l'individu enseignant peut encadré un ou plusieurs étudiants, ou ne pas encadré du tous, ou être membre du jury de soutenance.

[Jon Shannow]

Bonjour,
Perso, je ferais une table "personnes" dans lequel il y aurait aussi bien les enseignants que les étudiants.
Puis une table "enseignants" qui pointerait sur la table "personnes" et contiendrait les éléments propres au statut d'enseignant (comme le grade, ou s'il est membre du jury de soutenance, ...)
Une autre table "etudiants" qui pointerait également sur la table "personnes" et contiendrait les éléments propres au statut d'étudiant.
Ensuite pour les tables téléphones, mails, ... toutes ces tables (quelle que soit la solution utilisée - une table avec un type d'information ou une table pour chaque type de données), elles pointent toutes vers "personnes"

Voilà mon avis, il vaut ce qu'il vaut.

JS

[Voroltinquo]

On peut envisager un truc du style

1-On crée l'individu
2-Lorsque l'Individu "devient" Enseignant ou Etudiant, on récupère la PK de individu et on l'affecte à la table correspondante.

[tbc92]

Partant de la proposition de Voroltinquo :
- On a une table individu. Nom, prénom, date de naissance. Cet individu peut être dans nos tablettes pendant 10 ans, successivement comme étudiant puis comme prof, ces informations ne changeront pas.

- On doit aussi stocker quelque part ce que fait cet individu. Est-il étudiant , prof , autre .... ?
Et là, la situation peut changer. Un individu peut être étudiant pendant une année, puis prof pendant l'année suivante.
Et on a probablement envie d'avoir quelque part dans nos fichiers l'historique de chaque individu : X a été étudiant dans telle section , puis prof dans telle autre section.

On va supposer que le niveau 'Année' suffit, c'est à dire que la situation de chaque individu ne change pas en cours d'année.

Pour chaque individu, il faut donc identifier :
- quelles informations sont permanentes.
- quelles informations peuvent changer, mais on s'intéresse uniquement à la dernière situation. Et dans ce cas, on assimile ça à des informations permanentes.
- pour quelles informations on veut avoir l'historique.

Et du coup, dans les tables 'Etudiant' et 'prof', j'ajouterais une colonne 'Année scolaire'.

[frenchsting]

Bonjour,

J'irai même plus loin dans le raisonnement : un individu peut être étudiant (4ème année de droit) et prof (de td en 1ère année de droit).

[youcef16dz]

l'analyse est plus clair maintenant
pour des raisons d'assurance social (assurance maladie) s'il travail pour pas
est si l'étudiant pour raison de statistique il me faut connaitre :
- est ce que il enseigne (dans notre établissement ou ailleurs)
- son sexe
- sa nationalité

[youcef16dz]

Pour l'historique, je prévois une table inscription pour l'étudiant
dans la table inscription il est mentionnée le diplôme préparé, an d'inscription (1ère année, 2ème année,.....), l'année universitaire, spécialité, et option.
le cursus de l'étudiant s’arrête à la soutenance (magister, doctorat)
exemple étudiant inscrit en Magister (2ème année) pour l'année universitaire 2020/2021, s'il soutien par exemple le 15 mars 2021, a partir de cet date il n'est pas étudiant en magister.
Il pourra s'inscrire en 1ère année doctorat dans notre établissement ou dans un autre, s'il le désire, pour l'année universitaire suivante (2021/2022)

[Voroltinquo]

l'analyse est plus clair maintenant
pour des raisons d'assurance social (assurance maladie) s'il travail pour pas
est si l'étudiant pour raison de statistique il me faut connaitre :
- est ce que il enseigne (dans notre établissement ou ailleurs)
- son sexe
- sa nationalité

Je pense que le problème auquel tu es confronté est la partie "est ce que il enseigne".

[Enfonçage de porte ouverte]
Un individu enseigne s'il est Enseignant.
[Enfonçage de porte ouverte]

C'est à dire que la clause

Code sql :

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

1
2
3
4
5
6
7
 
Individu.PK_Individu IN (
				SELECT 
					Enseignant.PK_FK_Enseignant AS PK_FK_Enseignant
				FROM 
					Enseignant
				)

est vraie.
Un CASE WHEN est tout indiqué
REQ_Statut:

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
 
SELECT 
	Individu.PK_Individu AS PK_Individu,	
	Individu.NDX_NomIndividu AS NDX_NomIndividu,	
	Individu.NDX_Sexe AS NDX_Sexe,	
	Pays.AK_NomPays AS AK_NomPays,
		CASE 
		WHEN Individu.PK_Individu IN (
									SELECT 
										Enseignant.PK_FK_Enseignant AS PK_FK_Enseignant
									FROM 
										Enseignant
									) THEN 1
		ELSE 0
	END AS EstProf,
		CASE 
		WHEN Individu.PK_Individu IN (
									SELECT 
										Etudiant.PK_FK_Etudiant AS PK_Etudiant
									FROM 
										Etudiant
									) THEN 1
		ELSE 0
	END AS EstEtudiant
FROM 
	Pays,	
	Individu
WHERE 
	Pays.PK_Pays = Individu.FK_Pays

Remarque
Si on veut uniquement savoir si un étudiant précis enseigne, on peut utiliser le fait que lors de la création d'un Etudiant ou d'un Enseignant, leur PK est celle de l'individu. Donc un Etudiant est Enseignant s'il y a un tuple de Enseignant dont la PK est celle de l'étudiant concerné.
Dans ce cas, il est intéressant d'avoir le nombre de tuple concernés (0 ou 1) le Nombre d'enregistrement se "transforme" alors en booléen
REQ_EstProf :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT 
	COUNT(Etudiant.PK_FK_Etudiant) AS EstProf
FROM 
	Etudiant,
	Enseignant
WHERE 
	Etudiant.PK_FK_Etudiant = Enseignant.PK_FK_Enseignant
	AND
	Etudiant.PK_FK_Etudiant={pEtudiant}
	GROUP BY 
	Etudiant.PK_FK_Etudiant

[youcef16dz]

Si on veut uniquement savoir si un étudiant précis enseigne, on peut utiliser le fait que lors de la création d'un Etudiant ou d'un Enseignant, leur PK est celle de l'individu. Donc un Etudiant est Enseignant s'il y a un tuple de Enseignant dont la PK est celle de l'étudiant concerné.
Dans ce cas, il est intéressant d'avoir le nombre de tuple concernés (0 ou 1) le Nombre d'enregistrement se "transforme" alors en booléen
REQ_EstProf :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT 
	COUNT(Etudiant.PK_FK_Etudiant) AS EstProf
FROM 
	Etudiant,
	Enseignant
WHERE 
	Etudiant.PK_FK_Etudiant = Enseignant.PK_FK_Enseignant
	AND
	Etudiant.PK_FK_Etudiant={pEtudiant}
	GROUP BY 
	Etudiant.PK_FK_Etudiant

Mais fait éliminer tous les étudiants qui ont fini leur cursus, pour ça j'ai prévue un champs dans l'enregistrement étudiant, qui indique sa situation, (en cours de formation, fin de cursus, abondons, décès)
Aussi il faut sélectionner les étudiants qui ne travail pas, pour les déclaré à la caisse d'assurance sociale.

[Voroltinquo]

il faut ajouter ces condition à ta requête principale. (e.g. une colonne DateDiplôme ou une colonne nDX_Inscrit, une colonne employeur etc ..)
Inscrit pourra passer à faux une fois le diplôme obtenu. Avec la colonne employeur, on n'a plus à vérifier s'il est prof
On ne sait pas si tu veux une liste ou le statut d'un étudiant. La sous requête de ma remarque n'est valable que pour un étudiant (du moins le cast vers booléen).

[youcef16dz]

Salam alaikoum tous le monde.
Messieurs je vous remercie pour vos conseils.
ça étais un plaisir de partager avec vous ce file de discutions.
Cordialement