# Gnral Dveloppement > ALM > Modlisation > Schma >  Choix de tables SQL

## isaac_2000

Bonjour, 

Je veux construire une table SQL o  chaque projet ( nom, rgion, type ) j'associe des ingnieurs ( nom, rgion, type, discipline, role) de diffrentes disciplines et je fais la plannification hebdomadaire, exemple:

- Le projet (Arras, Paris, forcecast)

Je lui associe les deux ingnieurs : (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 travaille : 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 employs, avec les colonnes prsentes ci-dessus entre parenthses, 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 donne, 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

----------


## tatayo

Bonjour,



> et ceci doit se faire par discipline, c'est  dire pour une discipline donne, j'ai le *projet*, les *ingnieurs*, et leur *planification*, donc je ne sais pas si je dois faire une table que pour les *disciplines* ou pas!


Je vois dj 4 tables ici.



> Je veux construire une table SQL o  chaque projet ( nom, *rgion*, *type* ) j'associe des ingnieurs ( nom, *rgion*, *type*, *discipline*, *rle*) de diffrentes disciplines


La discipline est donc bien nue entit  part entire.
J'y ajouterai aussi la rgion, le rle et le(s) type(s). On ne sais pas ici les entits "projet" et "ingnieur" partagent les mmes types.

Donc pour commencer, j'ai ici 7 tables:
ProjetIngnieurRgionTypeDisciplinePlanificationRle
Et pourquoi pas une table calendrier, pour retrouver facilement les dates "libres".

Tatayo.

----------


## escartefigue

Pour bien modliser la BDD, il convient de prciser les rgles de gestion.

Par exemple, une mme personne peut-elle exercer plusieurs rles dans un mme projet, dans l'affirmative, ces rles peuvent ils tre simultans ou forcment successifs. Selon les rponses, le modle n'est pas le mme.

----------


## isaac_2000

Merci de votre message,

je suis en train de completer le dictionnaire des donns, il y a des attributs o j'ai pas de prcision sur leur taille; par exemple, pour le nom des ingnieurs, dans ce cas, faudrait-il que j'mpose une prcision moi mme ou quoi? ( e.g. mettre nombre de caractres < 20 )  

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

De mme pour des commentaires sur les projets( date de dbut change, contrat sign ou pas...) ?

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

d'autre part, voici comment est prsente une partie du fichier excel qui regroupe projets et ingnieurs:



et quand j'tais en train de me documenter, j'ai trouv que ceci correpsond  un problme de redondance de donnes si je me rappelle bien, est-ce que je dois m'en soucier maintenant que je suis sur le modle conceptuel et physique, ou bien en phase de traitement ?

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

Merci beaucoup

----------


## escartefigue

Bonjour,




> Je suis en train de complter le dictionnaire des donns, il y a des attributs o j'ai pas de prcision sur leur taille; par exemple, pour le nom des ingnieurs, dans ce cas, faudrait-il que j'impose une prcision moi mme ou quoi? ( e.g. mettre nombre de caractres < 20 )


Si les donnes sont issues d'un autres systme d'informations, on peut conserver la longueur du S.I. d'origine.
Si les donnes font l'objet d'une codification externe, alors il faut utiliser la longueur impose par l'organisme enregistreur (INSEE, ISO...) 
Sinon, interrogez vos donneurs d'ordre.





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


Attention : dans ce cas prcis, il est interdit d'enregistrer dans le S.I. des comm*e*ntaires (plutt que comm*a*ntaire  :;): ) qui seraient des apprciations des personnes. De nombreuses entreprises ont t condamnes pour cette raison.
Ensuite, le problme 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 crateur du commentaire, mais pas pour le relecteur).
D'une faon gnrale, je ne suis pas partisan de ce type d'attributs dans une BDD pour ces raisons.





> De mme pour des commentaires sur les projets (date de dbut change, contrat sign ou pas...) ?
> Ou bien, faudrait-il encore une nouvelle table pour les commentaires !?


Il faut rflchir au cas par cas
Pour un projet, il est souvent intressant d'avoir plusieurs dates : la date de dbut initiale, la date de dbut rvise, la date de dernire rvision (idem pour les dates de fin).
Pour le contrat, il est prfrable d'associer une typologie : contrat en instance de signature, sign, annul, ferm...  dfaut, un commentaire tant libre, vous ne saurez pas filtrer efficacement les contrats d'un certain type ( cause des graphies diffrentes d'un utilisateur  l'autre)





> et quand j'tais en train de me documenter, j'ai trouv que ceci correspond  un problme de redondance de donnes si je me rappelle bien, est-ce que je dois m'en soucier maintenant que je suis sur le modle conceptuel et physique, ou bien en phase de traitement ?


La non redondance des donnes est assure par le respect des formes normales et donc la modlisation conceptuelle.
Il est impossible, par traitement, de *garantir* la non redondance.




> et pour la partie "summary", qui a le but de lister les ingnieurs par rgion, 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 mme rgion, il est donc ncessaire d'avoir une entit-type [PERSONNE] et une entit-type [REGION] distinctes (non redondance oblige). Ce faisant, deux tables distinctes galement.
C'est par requte utilisant une jointure entre les personnes et les rgions qu'on fera la liste par rgion des diffrentes personnes.

----------


## JeitEmgie

> Pour bien modliser la BDD, il convient de prciser les rgles de gestion.
> 
> Par exemple, une mme personne peut-elle exercer plusieurs rles dans un mme projet, dans l'affirmative, ces rles peuvent ils tre simultans ou forcment successifs. Selon les rponses, le modle n'est pas le mme.


A partir dun certain niveau de complexit de  ces rgles, il peut  tre plus prudent de les grer avec un outil adhoc
sans parler de la problmatique de  leur volution dans le temps.
Cardinalit des rles dune personne dans un projet dpendant des dits rles, dans tous les projets, dlgation temporaire,  cela peut vite devenir trs complexe
Donc oui, bien les dfinir avant de commencer.

----------


## isaac_2000

MErci pour votre retour,

Mais les commentaires que les managers peuvent utiliser concernent juste les ingnieurs (cong de maternit, dmissionner, ....),que pensez vous d'ajouter une table "statut" pour faire ces commentaires (cong, maladie, .. ) ?mais le problme est que ces commentaires ne concernent que quelques ingnieurs, 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

----------


## escartefigue

En ce cas, a n'a rien  voir avec des commentaires, il s'agit d'absences.
Les absences se grent par priode et sont associes  une typologie (maladie, congs pays, RTT, sans solde...)


On peut imaginer un MCD ressemblant  ce qui suit



Les absences sont demandes par une personne, avec une date de dbut et une dure (nombre de jours, dcimale possible pour les demi journes)
Ces absences sont valides par une personne diffrente de celle ayant fait la demande (d'o la contrainte d'exclusion note (X) entre les deux assos)
Les absences sont types grce  une lien vers une typologie d'absence.


Ce qui donne les tables suivantes :

----------


## isaac_2000

Merci pour votre message,

voila en effet a quoi ressemble mon MCD: 


Donc je crois que votre proposition est un petit peu complique pour ma situation, vu que les donnes sont manipulables par les managers et c'est eux qui marquent les "commentaires" sur les ingnieurs, 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 "ingnieur"?

MErci

----------


## escartefigue

En effet, l'ingnieur comme le manager sont des sous-types d'une personne
On peut utiliser l'hritage pour modliser ces deux sous-populations.

Ma proposition permet une gestion des absences pour tous les types de personnes, quelle que soit leur qualification ou diplme.
Si seuls les ingnieurs sont concerns, alors il suffit de transposer  :;): 

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

Par exemple, ce modle tablit un lien entre ingnieur et rgion d'une part, entre projet et rgion d'autre part, et enfin, entre ingnieur et projet.
Ce faisant, on peut trouver un ingnieur bas dans la rgion Normandie, mais affect  un projet qui lui est associ  la rgion Rhne-Alpes.
Et on peut trouver un autre ingnieur sur ce mme projet mais bas en Alsace...

 argumenter

----------


## isaac_2000

> En effet, l'ingnieur comme le manager sont des sous-types d'une personne
> On peut utiliser l'hritage pour modliser ces deux sous-populations.
> 
> Ma proposition permet une gestion des absences pour tous les types de personnes, quelle que soit leur qualification ou diplme.
> Si seuls les ingnieurs sont concerns, alors il suffit de transposer ]


dj que voulez vous dire par "transposer"?
sinon, pour moi, "manager" sera affich dans le "rle" de l'ingnieur, vu que sur les projets il y a que les ingnieurs qui bossent, et les managers sont compts 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 rponse:

Oui, effectivement, la "premiere" rgion concerne "l'origine" de l'ingnieur, c'est--dire il vient de quelle region pour travailler sur un projet, mais la "deuxime" illustre "le centre d'execution" du projet, donc finalement je vais juste crer des alias pour les distinguer.

J'espre 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 rgion, et une rgion peut contenir plusieurs projets. Relation 1,n = cl trangre 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 trangre dans la table projet.
Un ingnieur a une discipline (?) et une discipline regroupe plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
Un ingnieur a un type et un type regroupe plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
Un ingnieur est sur une rgion, et une rgion peut contenir plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
Un ingnieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingnieur. Relation n,n = table de relation.
Un GEC propose des ingnieurs 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 rgions par les ingnieurs, mais vu que je devrais calculer combien d'ingenieurs ont donn les GEC pour les rgions, 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 prsente le taux des ingnieurs donns par des " rgions  "  une autre, voici un extrait du fichier source pr bien comprendre:


dans ce cas, alsace serait une " rgion source" d'un ingnieur, comme paris, les contract sont les ingnieurs contracts, et other support prsente le support des autres rgions pour une rgion donne.

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

Mme 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 rgion = "alsace" OR  ... OR... ) ou vaut mieux crer une table specifique comme t'as fait en haut?

Merci beaucoup

----------


## escartefigue

> dj que voulez vous dire par "transposer"?


"Adapter" plutt que "transposer"  :;): 





> sinon, pour moi, "manager" sera affich dans le "rle" de l'ingnieur, vu que sur les projets il y a que les ingnieurs qui bossent, et les managers sont compts 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 connatre la signaltique (nom, prnom etc.) de toutes les personnes, ingnieurs comme managers, alors un type d'entit [PERSONNE] se justifie et ventuellement des sous-types (hritage) 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 ingnieurs nous intressent, 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 prfrable.





> Pour l'autre partie que je n'ai pas su comment la mettre en citation , voila la rponse:


Aprs avoir utilis le bouton "rpondre avec citation", il suffit de copier coller autant de fois que ncessaire les balises de dbut et de fin de citation pour encadrer les parties de rponses sur lesquelles on souhaite ragir  :;): 





> Oui, effectivement, la "premiere" rgion concerne "l'origine" de l'ingnieur, c'est--dire il vient de quelle region pour travailler sur un projet, mais la "deuxime" illustre "le centre d'execution" du projet, donc finalement je vais juste crer des alias pour les distinguer.


Je ne sais pas quel est l'intrt de connaitre la rgion d'origine de l'ingnieur, mais si toutefois cet intrt est lgitime, peut-tre faut il le grer  date, l'ingnieur pouvant dmnager en cours de mission. 





> sinon voici les regles de gestion tablies:
> 
> Un projet est sur une rgion, et une rgion peut contenir plusieurs projets. Relation 1,n = cl trangre 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 trangre dans la table projet.
> Un ingnieur a une discipline (?) et une discipline regroupe plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
> Un ingnieur a un type et un type regroupe plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
> Un ingnieur est sur une rgion, et une rgion peut contenir plusieurs ingnieurs. Relation 1,n = cl trangre dans la table ingnieur.
> Un ingnieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingnieur. Relation n,n = table de relation.
> Un GEC propose des ingnieurs et un ingenieurne peut tre propos que par un  seul GEC , relation 1,n=cl trangere dans la table ingenieur.


Pour les rgles 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 rgle R001, je pense que..." plutt que de devoir redonner tout le libell de la rgle  :;): 
Par ailleurs il est prfrable d'utiliser le mme verbe dans les deux sens de chaque rgle, verbe qui sera repris pour nommer l'association correspondante dans le MCD.
Enfin, la notion de clef trangre n'a rien  faire dans les rgles de gestion. Les rgles de gestion sont  faire valider par la matrise d'ouvrage, elle dcrivent les interactions entre les acteurs de votre univers. Les clefs trangres sont des notions techniques relative au "comment mettre en oeuvre dans la base de donnes"

Ce qui donne par exemple pour votre premire rgle de gestion
_Un projet est sur une rgion, et une rgion peut contenir plusieurs projets. Relation 1,n = cl trangre dans la table projet._devient
_R001 : un projet concerne une rgion, et une rgion est concerne par plusieurs projets. Relation 1,n = cl trangre dans la table projet._Dans le MCD, l'association correspondante s'appellera (concerner)  ::): 





> P.S. Un GEC= Global engineering center, son role est le support des rgions par les ingnieurs, mais vu que je devrais calculer combien d'ingenieurs ont donn les GEC pour les rgions, 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 ingnieurs sont rattachs  une rgion, mais qu'ils peuvent tre dtachs sur un projet d'une autre rgion et que c'est ce nombre de dtachements qu'il faut suivre ?

----------


## isaac_2000

> Je ne sais pas quel est l'intrt de connaitre la rgion d'origine de l'ingnieur, mais si toutefois cet intrt est lgitime, peut-tre faut il le grer  date, l'ingnieur pouvant dmnager en cours de mission.


Le but est de grer la charge et la capacit de manire locale et globale, pour cela je dois savoir pour une rgion donne combien ai-je besoin d'ingnieurs? si j'ai un exces ou un dfaut?... Une rgion exprime en effet un "centre" de l'entreprise.




> Pour tout ce qui concerne les GEC, j'avoue ne pas tre certain de comprendre le besoin.
> Faut il comprendre que les ingnieurs sont rattachs  une rgion, mais qu'ils peuvent tre dtachs sur un projet d'une autre rgion et que c'est ce nombre de dtachements qu'il faut suivre ?


Je vais essayer de dtailler un petit peu comment a fonctionne:
il y a une charge de travail, qui correspond au nombre d' ingnieurs auquel on a besoin, et la capacit, qui reprsente le nombre d'ingnieurs disponbiles.
D'autre part, il y a diffrentes sortes de support en terme d'ingnieurs; soit par des GEC, soit des contracts, soit le support "interne":

GEC=GLobal Engineering center, son role est le support des diffrentes rgions par des ingnieurs en diffrentes disciplines.( il y en 3 )
Contacts= des ingnieurs qu'on paie pour des projets mais ils sont pas compts en tant qu'ingnieurs de l'entreprise
Support interne= imagine qu'on a 3 rgions, deux rgions ont un exces d'ingnieurs (vu la charge dans une periode donne), alors ils vont proposer des ingnieurs  la rgion 3, donc c'est un support interne.

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

Merci

----------


## escartefigue

Le rattachement des ingnieurs aux rgions est donc justifi, mais il faut certainement le grer  date (relation ternaire entre ingnieur, rgion et date)
Il y a sans doute des cas o un ingnieur change de rgion de rattachement alors qu'il est dj affect  un projet.
Ce faisant, il faut bien entendu connatre la date de dbut et de fin effective du projet pour pouvoir comparer la rgion du projet et celle de chaque ingnieur sur toute la dure du projet.

Pour utiliser correctement les citations, relisez bien ma rponse n12 et utilisez le bouton "prvisualisation" avant de valider le message  :;):

----------


## isaac_2000

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 ingnieur ?

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

Merci beaucoup

----------


## escartefigue

Non  : c'est une relation ternaire entre [rgion], [ingnieur] et une nouvelle entit-type dite "fictive" [calendrier], pour savoir de quand  quand chaque ingnieur rside dans chaque rgion.
"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 ingnieur ne peut pas changer de rgion ni revenir dans une rgion, c'est trs restrictif !
Il faudra aussi ajouter une CIF pour qu' un instant "t", un ingnieur ne rside que dans une seule rgion

----------


## isaac_2000

Merci,

Mais La relation n,n "participation" lie des ingnieurs  un projet. Un projet est li  une rgion (relation lieu_projet), et un ingnieur est li  une rgion (relation lieu_ingenieur). Donc on peut savoir si un ingnieur participe  un projet d'une rgion 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 ingnieur change de rgion, on va faire une modification dans la base de donnes, 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

----------


## escartefigue

Cas de figure suivant :

Projet P1 rattach  la rgion R1 pour toute la dure du projet, soit du 01-01-2021 au 31-12-2022
L'ingnieur I1 habite en rgion R1, il est affect au projet P1
Cet ingnieur I1 dmnage le 15-01-2021 pour s'installer dans la rgion R2
Ce mme ingnieur dmnage  nouveau le 31-12-2021 pour s'installer dans la rgion R3

Le cas ci-dessus ncessite un modle [REGION] 0,n --- habiter --- 1,n[INGENIEUR]
L'association (habiter) sera porteuse d'une date de dbut, permettant de savoir o rside l'ingnieur  un instant "t"

Si je complique le cas ci-dessus, pour permettre  un ingnieur de revenir dans une rgion qu'il a dj habite (bon ok il a la bougeotte, mais a peut se produire, surtout si la dure du projet est importante) :
Ce mme ingnieur dmnage encore le 20-04-2022 pour revenir dans la rgion R1

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

La flche en direction de l'entit-type [rgion] matrialise la contrainte selon laquelle pour un ingnieur,  une date, il n'y a qu'une seule rgion de rsidence

Si on fait comme vous le proposez en changeant simplement l'identifiant de rgion cot ingnieur, alors on n'a aucune ide des dures respectives de rsidence dans chaque rgion tout au long du projet. Vous ne pourrez donc pas calculer vos ratios.

----------

