Choix de tables SQL

Bonjour,

Je veux construire une table SQL où à chaque projet ( nom, région, type ) j'associe des ingénieurs ( nom, région, type, discipline, role) de différentes disciplines et je fais la plannification hebdomadaire, exemple:

- Le projet (Arras, Paris, forcecast)

Je lui associe les deux ingénieurs : (Anas, USA, interne, informatique, chef )et (SAlim, Africa, contracté, conception, manager)

Anas va travailler sur ce projet de Avril à Mai et Salim de Mars à Juin.

Si une semaine est travaillée : je mets 1 sur la case correspondante, c'est à dire 1 <=> 40 h de travail dans la semaine.

Moi j'ai choisi de faire deux tables: Une pour pour les projets, et une pour les employés, avec les colonnes présentées ci-dessus entre parenthèses, pour faire une jointure entre les deux , mais je n'arrive pas à savoir où mettre la plannification dans ma table SQL.

et ceci doit se faire par discipline, c'est à dire pour une discipline donnée, j'ai le projet, les ingenieurs, et leur plannification, donc je ne sais pas si je dois faire une table que pour les disciplines ou pas!

Merci de votre retour,

Bien cordialement

Bonjour,

Citation:

---

Envoyé par isaac_2000

et ceci doit se faire par discipline, c'est à dire pour une discipline donnée, j'ai le projet, les ingénieurs, et leur planification, donc je ne sais pas si je dois faire une table que pour les disciplines ou pas!

---

Je vois déjà 4 tables ici.

Citation:

---

Je veux construire une table SQL où à chaque projet ( nom, région, type ) j'associe des ingénieurs ( nom, région, type, discipline, rôle) de différentes disciplines

---

La discipline est donc bien nue entité à part entière.
J'y ajouterai aussi la région, le rôle et le(s) type(s). On ne sais pas ici les entités "projet" et "ingénieur" partagent les mêmes types.

Donc pour commencer, j'ai ici 7 tables:

1. Projet
2. Ingénieur
3. Région
4. Type
5. Discipline
6. Planification
7. Rôle

Et pourquoi pas une table calendrier, pour retrouver facilement les dates "libres".

Tatayo.

Pour bien modéliser la BDD, il convient de préciser les règles de gestion.

Par exemple, une même personne peut-elle exercer plusieurs rôles dans un même projet, dans l'affirmative, ces rôles peuvent ils être simultanés ou forcément successifs. Selon les réponses, le modèle n'est pas le même.

Merci de votre message,

je suis en train de completer le dictionnaire des donnés, il y a des attributs où j'ai pas de précision sur leur taille; par exemple, pour le nom des ingénieurs, dans ce cas, faudrait-il que j'mpose une précision moi même ou quoi? ( e.g. mettre nombre de caractères < 20 )

Et si je veux ajouter une colonne où les managers peuvent faire des commentaires sur les ingénieurs ? ( contrat terminé par exemple, congé de maternité .... ) suffit-il d'ajouter un attribut " commantaire" sur l'entité "ingénieur" ?

De même pour des commentaires sur les projets( date de début changée, contrat signé ou pas...) ?

Ou bien, faudrait-il encore une nouvelle table pour les commentaires !?

d'autre part, voici comment est présentée une partie du fichier excel qui regroupe projets et ingénieurs:

Pièce jointe 616363

et quand j'étais en train de me documenter, j'ai trouvé que ceci correpsond à un problème de redondance de données si je me rappelle bien, est-ce que je dois m'en soucier maintenant que je suis sur le modèle conceptuel et physique, ou bien en phase de traitement ?

et pour la partie "summary", qui a le but de lister les ingénieurs par région, faudrait l'attribuer une nouvelle table seule ou bien c'est au niveau de l'affichage que je peux m'en occuper?

Merci beaucoup

Bonjour,

Citation:

---

Envoyé par isaac_2000

Je suis en train de compléter le dictionnaire des donnés, il y a des attributs où j'ai pas de précision sur leur taille; par exemple, pour le nom des ingénieurs, dans ce cas, faudrait-il que j'impose une précision moi même ou quoi? ( e.g. mettre nombre de caractères < 20 )

---

Si les données sont issues d'un autres système d'informations, on peut conserver la longueur du S.I. d'origine.
Si les données font l'objet d'une codification externe, alors il faut utiliser la longueur imposée par l'organisme enregistreur (INSEE, ISO...)
Sinon, interrogez vos donneurs d'ordre.

Citation:

---

Envoyé par isaac_2000

Et si je veux ajouter une colonne où les managers peuvent faire des commentaires sur les ingénieurs ? (contrat terminé par exemple, congé de maternité...) suffit-il d'ajouter un attribut " commantaire" sur l'entité "ingénieur" ?

---

Attention : dans ce cas précis, il est interdit d'enregistrer dans le S.I. des commentaires (plutôt que commantaire ;)) qui seraient des appréciations des personnes. De nombreuses entreprises ont été condamnées pour cette raison.
Ensuite, le problème d'un commentaire ou d'un bloc notes, c'est qu'on ne sait jamais qui l'a écrit, jusqu'à quand il reste d'actualité et que comme il est par nature non structuré, il manque souvent des infos (évidentes pour le créateur du commentaire, mais pas pour le relecteur).
D'une façon générale, je ne suis pas partisan de ce type d'attributs dans une BDD pour ces raisons.

Citation:

---

Envoyé par isaac_2000

De même pour des commentaires sur les projets (date de début changée, contrat signé ou pas...) ?
Ou bien, faudrait-il encore une nouvelle table pour les commentaires !?

---

Il faut réfléchir au cas par cas
Pour un projet, il est souvent intéressant d'avoir plusieurs dates : la date de début initiale, la date de début révisée, la date de dernière révision (idem pour les dates de fin).
Pour le contrat, il est préférable d'associer une typologie : contrat en instance de signature, signé, annulé, fermé... À défaut, un commentaire étant libre, vous ne saurez pas filtrer efficacement les contrats d'un certain type (à cause des graphies différentes d'un utilisateur à l'autre)

Citation:

---

Envoyé par isaac_2000

et quand j'étais en train de me documenter, j'ai trouvé que ceci correspond à un problème de redondance de données si je me rappelle bien, est-ce que je dois m'en soucier maintenant que je suis sur le modèle conceptuel et physique, ou bien en phase de traitement ?

---

La non redondance des données est assurée par le respect des formes normales et donc la modélisation conceptuelle.
Il est impossible, par traitement, de garantir la non redondance.

Citation:

---

Envoyé par isaac_2000

et pour la partie "summary", qui a le but de lister les ingénieurs par région, faudrait l'attribuer une nouvelle table seule ou bien c'est au niveau de l'affichage que je peux m'en occuper ?

---

Sachant que plusieurs personnes peuvent être dans la même région, il est donc nécessaire d'avoir une entité-type [PERSONNE] et une entité-type [REGION] distinctes (non redondance oblige). Ce faisant, deux tables distinctes également.
C'est par requête utilisant une jointure entre les personnes et les régions qu'on fera la liste par région des différentes personnes.

Citation:

---

Envoyé par escartefigue

Pour bien modéliser la BDD, il convient de préciser les règles de gestion.

Par exemple, une même personne peut-elle exercer plusieurs rôles dans un même projet, dans l'affirmative, ces rôles peuvent ils être simultanés ou forcément successifs. Selon les réponses, le modèle n'est pas le même.

---

A partir d’un certain niveau de complexité de ces règles, il peut être plus prudent de les gérer avec un outil adhoc…
sans parler de la problématique de leur évolution dans le temps.
Cardinalité des rôles d’une personne dans un projet dépendant des dits rôles, dans tous les projets, délégation temporaire, … cela peut vite devenir très complexe…
Donc oui, bien les définir avant de commencer.

MErci pour votre retour,

Mais les commentaires que les managers peuvent utiliser concernent juste les ingénieurs (congé de maternité, démissionner, ....),que pensez vous d'ajouter une table "statut" pour faire ces commentaires (congé, maladie, .. ) ?mais le problème est que ces commentaires ne concernent que quelques ingénieurs, vu que la majorité est disponbile sauf exception rare, donc je ne sais pas si c'est une bonne idee ou bien je peux faire mieux.

Merci beaucoup

En ce cas, ça n'a rien à voir avec des commentaires, il s'agit d'absences.
Les absences se gèrent par période et sont associées à une typologie (maladie, congés payés, RTT, sans solde...)


On peut imaginer un MCD ressemblant à ce qui suit

Pièce jointe 616852

Les absences sont demandées par une personne, avec une date de début et une durée (nombre de jours, décimale possible pour les demi journées)
Ces absences sont validées par une personne différente de celle ayant fait la demande (d'où la contrainte d'exclusion notée (X) entre les deux assos)
Les absences sont typées grâce à une lien vers une typologie d'absence.


Ce qui donne les tables suivantes :

Pièce jointe 616853

Merci pour votre message,

voila en effet a quoi ressemble mon MCD:
Pièce jointe 616855

Donc je crois que votre proposition est un petit peu compliquée pour ma situation, vu que les données sont manipulables par les managers et c'est eux qui marquent les "commentaires" sur les ingénieurs, donc dans votre schema:
-personne validant l'absence=manager
-personne demandant labsence=ingenieur,

Pensez-vous que je dois ajouter une table pr les managers dans ce cas ? et pour la table que vous avez appelé " personne ", êtes vous d'accord qu'elle correspond à ma table "ingénieur"?

MErci

En effet, l'ingénieur comme le manager sont des sous-types d'une personne
On peut utiliser l'héritage pour modéliser ces deux sous-populations.

Ma proposition permet une gestion des absences pour tous les types de personnes, quelle que soit leur qualification ou diplôme.
Si seuls les ingénieurs sont concernés, alors il suffit de transposer ;)

Communiquer le MCD c'est mieux, mais sans les règles de gestion il manque l'argumentaire permettant de le valider.

Par exemple, ce modèle établit un lien entre ingénieur et région d'une part, entre projet et région d'autre part, et enfin, entre ingénieur et projet.
Ce faisant, on peut trouver un ingénieur basé dans la région Normandie, mais affecté à un projet qui lui est associé à la région Rhône-Alpes.
Et on peut trouver un autre ingénieur sur ce même projet mais basé en Alsace...

À argumenter

Citation:

---

Envoyé par escartefigue

En effet, l'ingénieur comme le manager sont des sous-types d'une personne
On peut utiliser l'héritage pour modéliser ces deux sous-populations.

Ma proposition permet une gestion des absences pour tous les types de personnes, quelle que soit leur qualification ou diplôme.
Si seuls les ingénieurs sont concernés, alors il suffit de transposer ;)]

---

déjà que voulez vous dire par "transposer"?
sinon, pour moi, "manager" sera affiché dans le "rôle" de l'ingénieur, vu que sur les projets il y a que les ingénieurs qui bossent, et les managers sont comptés sur les doigts, donc j'ai opté pour ce choix, je l'ai discuté avec le manager il l'a validé, pourtant, je veux bien savoir votre avis concernant ce point.


Pour l'autre partie que je n'ai pas su comment la mettre en citation :), voila la réponse:

Oui, effectivement, la "premiere" région concerne "l'origine" de l'ingénieur, c'est-à-dire il vient de quelle region pour travailler sur un projet, mais la "deuxième" illustre "le centre d'execution" du projet, donc finalement je vais juste créer des alias pour les distinguer.

J'espère que cela soit convaincant pour vous, et merci de m'avoir posé cette question, ça m'aide effectivement à mieux argumenter mon choix, si vous avez d'autres questions, je vous prie de bien vouloir me les poser.


sinon voici les regles de gestion établies:

Un projet est sur une région, et une région peut contenir plusieurs projets. Relation 1,n = clé étrangère dans la table projet.
Un projet est d'un type de projet, et un type de projet peut regrouper plusieurs projets. Relation 1,n = clé étrangère dans la table projet.
Un ingénieur a une discipline (?) et une discipline regroupe plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur a un type et un type regroupe plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur est sur une région, et une région peut contenir plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingénieur. Relation n,n = table de relation.
Un GEC propose des ingénieurs et un ingenieurne peut être proposé que par un seul GEC , relation 1,n=clé étrangere dans la table ingenieur.

P.S. Un GEC= Global engineering center, son role est le support des régions par les ingénieurs, mais vu que je devrais calculer combien d'ingenieurs ont donné les GEC pour les régions, j'ai choisi de le mettre seul en table, sachant qu'il y a 3 GEC.

Pd'ailleurs, il y a d'autres types de support, le GEC n'en est qu'un exemple, mais en effet, un support présente le taux des ingénieurs donnés par des " régions " à une autre, voici un extrait du fichier source pr bien comprendre:
Pièce jointe 616902

dans ce cas, alsace serait une " région source" d'un ingénieur, comme paris, les contract sont les ingénieurs contractés, et other support présente le support des autres régions pour une région donnée.

êtes vous d'accord que tout ca est faisable sans avoir à faire une nouvelle table pr le support?

Même pr le GEC, je crois qu'on peut le deduire directement( en faisant par exemple un condition where, vu qu'il y a 3 GEC, WHERE région = "alsace" OR ... OR... ) ou vaut mieux créer une table specifique comme t'as fait en haut?

Merci beaucoup

Citation:

---

Envoyé par isaac_2000

déjà que voulez vous dire par "transposer"?

---

"Adapter" plutôt que "transposer" ;)

Citation:

---

Envoyé par isaac_2000

sinon, pour moi, "manager" sera affiché dans le "rôle" de l'ingénieur, vu que sur les projets il y a que les ingénieurs qui bossent, et les managers sont comptés sur les doigts, donc j'ai opté pour ce choix, je l'ai discuté avec le manager il l'a validé, pourtant, je veux bien savoir votre avis concernant ce point.

---

Si on a besoin de connaître la signalétique (nom, prénom etc.) de toutes les personnes, ingénieurs comme managers, alors un type d'entité [PERSONNE] se justifie et éventuellement des sous-types (héritage) si seuls les managers peuvent valider des absences ou si certaines associations ne concernent que l'un ou l'autre des sous-types.
Si au contraire, seuls les attributs des ingénieurs nous intéressent, alors un type d'entité unique suffit, on pourra l'appeler "ingenieur" si on est certains qu'aucun autre type de personne n'intervient dans le projet, sinon "personne" est préférable.

Citation:

---

Envoyé par isaac_2000

Pour l'autre partie que je n'ai pas su comment la mettre en citation :), voila la réponse:

---

Après avoir utilisé le bouton "répondre avec citation", il suffit de copier coller autant de fois que nécessaire les balises de début et de fin de citation pour encadrer les parties de réponses sur lesquelles on souhaite réagir ;)

Citation:

---

Envoyé par isaac_2000

Oui, effectivement, la "premiere" région concerne "l'origine" de l'ingénieur, c'est-à-dire il vient de quelle region pour travailler sur un projet, mais la "deuxième" illustre "le centre d'execution" du projet, donc finalement je vais juste créer des alias pour les distinguer.

---

Je ne sais pas quel est l'intérêt de connaitre la région d'origine de l'ingénieur, mais si toutefois cet intérêt est légitime, peut-être faut il le gérer à date, l'ingénieur pouvant déménager en cours de mission.

Citation:

---

Envoyé par isaac_2000

sinon voici les regles de gestion établies:

Un projet est sur une région, et une région peut contenir plusieurs projets. Relation 1,n = clé étrangère dans la table projet.
Un projet est d'un type de projet, et un type de projet peut regrouper plusieurs projets. Relation 1,n = clé étrangère dans la table projet.
Un ingénieur a une discipline (?) et une discipline regroupe plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur a un type et un type regroupe plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur est sur une région, et une région peut contenir plusieurs ingénieurs. Relation 1,n = clé étrangère dans la table ingénieur.
Un ingénieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingénieur. Relation n,n = table de relation.
Un GEC propose des ingénieurs et un ingenieurne peut être proposé que par un seul GEC , relation 1,n=clé étrangere dans la table ingenieur.

---

Pour les règles de gestion, je recommande de leur attribuer un identifiant, ça facilite grandement la discussion ici sur ce forum, mais aussi dans la vraie vie avec vos donneurs d'ordre. C'est plus facile de dire "à propos de votre règle R001, je pense que..." plutôt que de devoir redonner tout le libellé de la règle ;)
Par ailleurs il est préférable d'utiliser le même verbe dans les deux sens de chaque règle, verbe qui sera repris pour nommer l'association correspondante dans le MCD.
Enfin, la notion de clef étrangère n'a rien à faire dans les règles de gestion. Les règles de gestion sont à faire valider par la maîtrise d'ouvrage, elle décrivent les interactions entre les acteurs de votre univers. Les clefs étrangères sont des notions techniques relative au "comment mettre en oeuvre dans la base de données"

Ce qui donne par exemple pour votre première règle de gestion

Un projet est sur une région, et une région peut contenir plusieurs projets. Relation 1,n = clé étrangère dans la table projet.

devient

R001 : un projet concerne une région, et une région est concernée par plusieurs projets. Relation 1,n = clé étrangère dans la table projet.

Dans le MCD, l'association correspondante s'appellera (concerner) :)

Citation:

---

Envoyé par isaac_2000

P.S. Un GEC= Global engineering center, son role est le support des régions par les ingénieurs, mais vu que je devrais calculer combien d'ingenieurs ont donné les GEC pour les régions, j'ai choisi de le mettre seul en table, sachant qu'il y a 3 GEC. [...]

---

Pour tout ce qui concerne les GEC, j'avoue ne pas être certain de comprendre le besoin.
Faut il comprendre que les ingénieurs sont rattachés à une région, mais qu'ils peuvent être détachés sur un projet d'une autre région et que c'est ce nombre de détachements qu'il faut suivre ?

Citation:

---

Envoyé par escartefigue

Je ne sais pas quel est l'intérêt de connaitre la région d'origine de l'ingénieur, mais si toutefois cet intérêt est légitime, peut-être faut il le gérer à date, l'ingénieur pouvant déménager en cours de mission.

---

Le but est de gérer la charge et la capacité de manière locale et globale, pour cela je dois savoir pour une région donnée combien ai-je besoin d'ingénieurs? si j'ai un exces ou un défaut?... Une région exprime en effet un "centre" de l'entreprise.

Citation:

---

Envoyé par escartefigue

Pour tout ce qui concerne les GEC, j'avoue ne pas être certain de comprendre le besoin.
Faut il comprendre que les ingénieurs sont rattachés à une région, mais qu'ils peuvent être détachés sur un projet d'une autre région et que c'est ce nombre de détachements qu'il faut suivre ?

---

Je vais essayer de détailler un petit peu comment ça fonctionne:
il y a une charge de travail, qui correspond au nombre d' ingénieurs auquel on a besoin, et la capacité, qui représente le nombre d'ingénieurs disponbiles.
D'autre part, il y a différentes sortes de support en terme d'ingénieurs; soit par des GEC, soit des contractés, soit le support "interne":

GEC=GLobal Engineering center, son role est le support des différentes régions par des ingénieurs en différentes disciplines.( il y en 3 )
Contactés= des ingénieurs qu'on paie pour des projets mais ils sont pas comptés en tant qu'ingénieurs de l'entreprise
Support interne= imagine qu'on a 3 régions, deux régions ont un exces d'ingénieurs (vu la charge dans une periode donnée), alors ils vont proposer des ingénieurs à la région 3, donc c'est un support interne.

Dites-moi si c'est clair pr vous ou bien si vous voulez plus de détails.

Merci

Le rattachement des ingénieurs aux régions est donc justifié, mais il faut certainement le gérer à date (relation ternaire entre ingénieur, région et date)
Il y a sans doute des cas où un ingénieur change de région de rattachement alors qu'il est déjà affecté à un projet.
Ce faisant, il faut bien entendu connaître la date de début et de fin effective du projet pour pouvoir comparer la région du projet et celle de chaque ingénieur sur toute la durée du projet.

Pour utiliser correctement les citations, relisez bien ma réponse n°12 et utilisez le bouton "prévisualisation" avant de valider le message ;)

Pour les dates, elles sont gerees par la relation "participation" dans mon MCD.

Donc, pour la relation ternaire de quoi vous parlez, serait-elle entre projet, participation et ingénieur ?

Et si c'est possible, merci de m'indiquer les 3 regles de gestion que traduit cette relation.

Merci beaucoup

Non : c'est une relation ternaire entre [région], [ingénieur] et une nouvelle entité-type dite "fictive" [calendrier], pour savoir de quand à quand chaque ingénieur réside dans chaque région.
"Fictive" car cette entité-type ne deviendra pas une table, elle ne sert qu'à ajouter la date comme composante de la PK de la table associative.
Faute de date dans l'association et avec la cardinalité 1,1, un ingénieur ne peut pas changer de région ni revenir dans une région, c'est très restrictif !
Il faudra aussi ajouter une CIF pour qu'à un instant "t", un ingénieur ne réside que dans une seule région

Merci,

Mais La relation n,n "participation" lie des ingénieurs à un projet. Un projet est lié à une région (relation lieu_projet), et un ingénieur est lié à une région (relation lieu_ingenieur). Donc on peut savoir si un ingénieur participe à un projet d'une région qui n'est pas la sienne ... et vice versa ...

Je ne comprends pas bien dans quel cas de figure mon MCD ne marche pas!

Si un ingénieur change de région, on va faire une modification dans la base de données, et c'est "juste " la valeur de champ ingenieur.id_region qui change, et c'est faisable avec mon MCD, sauf si je n'ai pas bien saisi votre point, ou si vous pouvez SVP me montrer un exemple de cette relation ternaire dont vous parlez!

Merci beaucoup

Cas de figure suivant :

Projet P1 rattaché à la région R1 pour toute la durée du projet, soit du 01-01-2021 au 31-12-2022
L'ingénieur I1 habite en région R1, il est affecté au projet P1
Cet ingénieur I1 déménage le 15-01-2021 pour s'installer dans la région R2
Ce même ingénieur déménage à nouveau le 31-12-2021 pour s'installer dans la région R3

Le cas ci-dessus nécessite un modèle [REGION] 0,n --- habiter --- 1,n[INGENIEUR]
L'association (habiter) sera porteuse d'une date de début, permettant de savoir où réside l'ingénieur à un instant "t"

Si je complique le cas ci-dessus, pour permettre à un ingénieur de revenir dans une région qu'il a déjà habitée (bon ok il a la bougeotte, mais ça peut se produire, surtout si la durée du projet est importante) :
Ce même ingénieur déménage encore le 20-04-2022 pour revenir dans la région R1

En ce cas le modèle devient :
[REGION] 0,n <-- habiter --- 1,n[INGENIEUR]
............................│
[CALENDRIER]-0,n -┘

La flèche en direction de l'entité-type [région] matérialise la contrainte selon laquelle pour un ingénieur, à une date, il n'y a qu'une seule région de résidence

Si on fait comme vous le proposez en changeant simplement l'identifiant de région coté ingénieur, alors on n'a aucune idée des durées respectives de résidence dans chaque région tout au long du projet. Vous ne pourrez donc pas calculer vos ratios.