# Gnral Dveloppement > ALM > Modlisation > Schma >  Deux tables identiques

## isaac_2000

Bonjour,

J'espre que vous allez bien,

je suis en train de crer le MCD de ma BDD, et j'ai un soucis; il s'agit en effet d'une BDD pour gestion de ressources humaines en projets, il y a diffrentes tables, parmi elles on trouve: "ingnieur", "appartennance gographique", "dpartement", "sous quipe"...

Le problme est que dans l'entreprise il y a 6 dpartements, pour 5 d'eux, l'appartenance gographique = sous-quipe, c'est--dire, un ingnieur qui se trouve  Paris, appartient  la sous-quipe de Paris, et dans ce cas, appartenance go = sous-equipe= paris.

Mais chez le 6me dpartement, les deux champs sont bien diffrents, on a la notion de l'appartenance go, outre l'entit "sous quipe".

Dans ce cas l, je suppose que je dois crer deux tables diffrentes, mais est-ce que par la suite je peux imposer que les 5 dpartements ne saisissent pas de valeur pour les sous-quipes pour viter la redondance? sinon y' a-t-il une autre solution SVP?

j'espre que c'est clair,sinon je peux donner plus de dtails si vous voulez.

MErci de votre retour,

Cordialement

----------


## escartefigue

Bonjour,

La bonne dmarche est de collecter les rgles de gestion auprs du mtier (MOA, gestionnaires), de les rdiger, leur attribuer un identifiant (un numro) et de les faire valider par votre donneur d'ordre (la MOA le plus souvent).

Une fois que c'est fait, vous pourrez crer le modle conceptuel des donnes en consquence, MCD dont on pourra discuter ici au vu des rgles de gestion.

Une fois le MCD valid, les tables seront cres en un clic  ::P: 

En rsum, il ne faut pas rflchir au "_comment_" (combien de tables...) mais au "_qui_" et au "_quoi_", le "_comment_" n'est qu'une consquence du "_quoi_".

Vous pouvez consulter les autres sujets ouverts dans ce forum pour y trouver des exemples  :;): 
Par exemple ICI

----------


## isaac_2000

Bonjour,

Merci pour votre message,

en effet voil le cahier de charges donn par le reponsable, 


- une table *"Projet"* ayant les colonnes suivantes: 
client: issu d'une base de donnes externe nomme SF
SF name: nom du projet issu de SF
2R Name   documenter  la main par 2R ( noter que 2R est la nom de la division qui englobe les dpartements vus dans le message d'avant)
pays d'execution
Scope (juste une colonne de la table projet)
type de projet
winiit scenario ( stratgie du projet)
Award date
Tender ITT
Tender Submission
Feed Start
FEED end
Excution Start
Excution Offshore date
Excution End
Comments
PM
PEM
2R Lead
PYG lead
RPT lead
DT lead
RPK lead
RiSE Lead
GSP Lead
One GeoTech Lead


- une *"Participation"* (gantt chart) avec les colonnes suivantes:
semaine
utilisation de la ressource (entre 0-X%)

voil ce que je propose pour les tables:

*On a des ingnieurs, quipes, dpartements, appartenance gographique, disciplines, types dingnieurs, projets, winit scenario, seniority, client, pays d'execution, phases, participation, department lead(chef de dpartement), division, division lead(chef de division).*

En effet, la table *"phase"* permet de regrouper les lments suivants:
Tender ITT
Tender Submission
Feed Start
FEED end
Excution Start
Excution Offshore date
Excution End

Vu que ce sont des dates de phases projet.

et *" division lead"* regroupe:
PM
PEM
2R lead

et* "departement lead"*:
PYG lead
RPT lead
DT lead
RPK lead
RiSE Lead
GSP Lead
One GeoTech Lead

pourriez-vous me confirmer le choix des tables SVP?

(j'ai des doutes sur le regroupement de "ingnieurs+departement lead+division lead" dans une seule table appele "ressource", mais le problme est que a affecte les rgles de gestion et je ne sais si c'est une bonne ide) 

Voil les rgles de gestion confirmes par les responsables:

R001 : UN ingnieur est li  UN type dingnieur, et UN type peut tre li  PLUSIEURS ingnieurs. 

R002 : UN ingnieur appartient  UNE quipe et UNE quipe regroupe plusieurs ingnieurs 

R003 : Un ingnieur a UNE appartenance gographique, et Une appartenance gographique regroupe Plusieurs ingnieurs 

R004 : Un ingnieur a UNE discipline, et Une discipline regroupe plusieurs ingnieurs 

R005 : Un ingnieur a UNE seniority, Une seniority regroupe plusieurs ingnieurs 

R006 : Un ingnieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingnieurs 

R007 : Un projet est propos par un client, un client peut proposer plusieurs projets 

R008 : Un projet appartient  un pays dexecution, et un pays dexecution regroupe plusieurs projets 

R009 : Un projet a plusieurs phases, et une phase concerne plusieurs projets 

R010: UNE participation est lie  UN seul ingnieur, UN ingnieur peut tre li  plusieurs participations.

R011 : UNE participation est lie  UNE seule seniority, UNE seniority peut tre lie  plusieurs participations.

R012 : Une participation est lie  une discipline, et une disciple est lie  plusieurs participations.

R013 : UNE participation est lie  UN seul projet, et UN projet peut tre li  plusieurs participations.

R014 : Une sous-quipe appartient  un dpartement, un dpartement contient plusieurs sous-quipes. 

R015 : Un projet a UN winit scenario, et un Winit scenario regroupe plusieurs projets 

R016 : Un departement peut avoir plusieurs department lead, et un department lead peut tre le chef de plusieurs dpartement 

R017 : Un department lead est le responsable de plusieurs projets, un projet a plusieurs  department lead. 

R018 : Un ingnieur a un department lead, et un department lead est le respo de plusieurs ingnieurs 

R019 : Un dpartement appartient  une division, une division englobe plusieurs dpartements 

R020 : Un department lead est le chef de plusieurs quipes, une quipe peut avoir plusieurs  department lead.

R021 : Un projet est li  un type de projet, et un type de projet est li  plusieurs projets.

R022 : Une division a un  division lead , et un  division lead  peut tre le chef de plusieurs divisions.

(Ne donnez pas trop d'importance  la "formulation" des rgles de gestion,  pour moi je veux plutt SVP votre avis sur le choix des tables, si vous faites attention aux rgles de gestion, vous trouverez une diffrence entre la relation entre "ingenieur" et "departement", et "departement" et "departement lead", c'est pour cela je pense les regrouper dans une seule table n'est pas une bonne ide)

Merci beaucoup

----------


## escartefigue

Bonjour,

Je n'ai pas le temps de regarder a de suite, mais j'y reviendrai, c'est promis.

Quoi qu'il en soit, le cahier des charges ne devrait pas s'intresser aux tables, les tables, c'est le "comment", le cahier des charges devrait dcrire le besoin fonctionnel, le "quoi". Ce sont les rgles de gestion qui dcrivent le "quoi", elles sont prsentes et c'est tant mieux. Reste  vrifier qu'elles sont compltes et claires (je le ferai ds que j'aurai un peu de dispo  :;): ).

Dans l'ordre 
collecte des rgles de gestion auprs du mtierbauche du modle conceptuel conformment aux rglesgnration du modle tabulaire (MLD et/ou MPD)  partir du modle conceptuel
Les tapes 1 et 2 sont itratives, on fait souvent plusieurs allers-retours avant d'avoir la version finale du MCD  :;): 

*EDIT* j'ai pris un peu de temps pour regarder les rgles de gestion, et de nombreuses questions se posent :

aucune prcision n'est donne sur l'affectation d'un ingnieur  une quipe, je suppose que
- un ingnieur peut changer d'quipe
-  un instant "t" un ingnieur n'est affect qu' une seule quipeC'est bien le cas ?aucune relation n'est faite entre quipe et projet
faut-il comprendre que des ingnieurs d'une mme quipe peuvent travailler sur des projets diffrents ?Les deux questions qui prcdent pourraient laisser supposer que l'quipe n'est finalement pas un objet de gestion,
peut-tre est-ce simplement le fait que deux ingnieurs travaillent sur le mme projet fait qu'ils sont dans la mme quipe
mais ce serait contradictoire avec la rgle R002, du coup je m'y perds
Vrifiez si la notion d'quipe comporte des attributs, si oui lesquels, ce qui permettra de le confirmer ou infirmer.R006 : un ingnieur peut-il travailler sur plusieurs projets simultanment ou successivement ?Certains termes mritent des explications, par exemple Seniority et Participation, il faut donner des exemples de cas et des attributs les caractrisant pour plus de clart

----------


## escartefigue

Voici une premire bauche partielle de MCD base sur les rgles de gestion fournies et sur quelques suppositions (notamment relatives  la temporalit de certaines associations, voir mes questions qui prcedent).



On voit en un seul coup d'il qu'il y aura bien plus que 3 tables : tous les types d'entit (rectangles) deviennent des tables (sauf les E.T. "fictives") ainsi que toutes les associations n-aires.
Pour ce MCD partiel, on a dj 8 E.T. concernes (CAL_calendrier est fictive, elle ne deviendra pas une table) et 2 assos n-aires, soit 10 tables.

Et on obtient automatiquement le script suivant (dclin ici pour SQL server) et donc les tables :



```

```


*Edit* : pour la rgle R003, j'ai fait une coquille dans le MCD, c'est bien 1,1 ct ingnieur

----------


## isaac_2000

Bonjour,

Merci pour votre message, en effet:




> aucune prcision n'est donne sur l'affectation d'un ingnieur  une quipe, je suppose que
> - un ingnieur peut changer d'quipe
> -  un instant "t" un ingnieur n'est affect qu' une seule quipe
> C'est bien le cas ?


la rponse est oui (pour les deux questions).




> aucune relation n'est faite entre quipe et projet
> faut-il comprendre que des ingnieurs d'une mme quipe peuvent travailler sur des projets diffrents ?


l galement la rponse est oui.




> Vrifiez si la notion d'quipe comporte des attributs, si oui lesquels, ce qui permettra de le confirmer ou infirmer.


elle a un nom, c'est son seul attribut, l je crois vous aurez du oublier mon premier message, en effet,
pour 5 dpartements, une quipe est un regroupement de rgions ( pr ex. l'quipe de USA regroupe BRASIL et CANADA, EASTERN pour dire UK, FRANCE..)
pour un seul dpartement, une quipe n'a pas la dsignation prcdente.

mais finalement il s'agit bien d'une entit.




> R006 : un ingnieur peut-il travailler sur plusieurs projets simultanment ou successivement


Pour simultanment, oui, cependant, que voulez-vous dire par successivement? et pourriez-vous m'expliquer SVP qu'est ce que cela change dans le MCD( si vous voulez dire: quand un projet se termine, il va travailler sur un nouveau, dans ce cas la rponse est positive, sinon j'attends votre explication du mot.)

Pour seniority, elle permet en fait de dire si un ingnieur est senior, junior, lead...  

Pour participation, c'est principalement cette table:


elle comme attribut "semaine" (peut tre anne) et les chiffres que vous regardez l, ils traduisent en effet la charge hebdomadaire de l'ingenieur sur un projet donn ( 1 <=> 1semaine ) 

Sinon voil ce que j'ai mis comme MCD, pourriez-vous me donner votre avis SVP ?




Merci beaucoup pour votre aide

----------


## escartefigue

> la rponse est oui (pour les deux questions).


En ce cas, il faut reformuler la rgle de gestion R002 qui devient par exemple 
R002 : un ingnieur est affect  une seule quipe  un instant "t" et peut changer d'quipe  "t+1" et  une quipe sont affects plusieurs ingnieurs
Et il faut revoir le MCD pour tablir une relation ternaire comme je l'ai fait dans le mien, avec la flche en direction d'quipe qui symbolise la contrainte d'unicit de l'quipe pour un ingnieur et une date
 noter : il est prfrable d'utiliser le verbe de la rgle de gestion (ici affecter) comme nom d'association





> Pour simultanment, oui, cependant, que voulez-vous dire par successivement? et pourriez-vous m'expliquer SVP qu'est ce que cela change dans le MCD( si vous voulez dire: quand un projet se termine, il va travailler sur un nouveau, dans ce cas la rponse est positive, sinon j'attends votre explication du mot.)


Simultanment : l'ingnieur I1 peut, sur la mme priode, travailler  la fois sur le projet P1 et le projet P2
Successivement : l'ingnieur I1 ne peut travailler sur le projet P2 que s'il a fini de travailler sur le projet P1. Il ne travaille jamais sur deux projets  la fois.
La relation ternaire que j'ai propose dans mon schma est une adaptation de la rgle R006 qui permet de connaitre l'historique des associations entre ingnieurs et projets.
Mais je vois que dans votre MCD, il n'y a aucun lien direct entre ingnieur et projet, il faut passer par l'entit-type [PARTICIPATION] pour aller de l'un vers l'autre
Donc soit le MCD est correct et en ce cas la R006 est  supprimer, soit il ne l'est pas et il faut ajouter cette association.





> Pour participation, c'est principalement cette table


Attention : pour qu'il n'y ait pas d'quivoque, il faut bien distinguer le MCD dans lequel la notion de table n'existe pas, on n'y parle que d'entits et d'associations, et le modle tabulaire, MLD ou MPD dans lequel les entits et certaines associations deviennent des tables.





> Sinon voil ce que j'ai mis comme MCD, pourriez-vous me donner votre avis SVP ?


Comme indiqu, il y a au moins une diffrence entre R006 et le modle, et il y a aussi la ternaire  mettre pour ce qui concerne l'quipe, peut-tre y a-t-il d'autres erreurs,  vrifier une fois que les rgles seront bien stabilises  :;): 

Dans un premier temps, il n'est pas ncessaire de positionner tous les attributs.

----------


## isaac_2000

Merci pour votre retour




> En ce cas, il faut reformuler la rgle de gestion R002 qui devient par exemple 
> R002 : un ingnieur est affect  une seule quipe  un instant "t" et peut changer d'quipe  "t+1" et  une quipe sont affects plusieurs ingnieurs
> Et il faut revoir le MCD pour tablir une relation ternaire comme je l'ai fait dans le mien, avec la flche en direction d'quipe qui symbolise la contrainte d'unicit de l'quipe pour un ingnieur et une date


Dsol, je me suis tromp, je crois il n'y a pas de notion de "changement" d'quipe, il y a plutt "la mise  disposition d'une ressource  une quipe qui n'est pas son equipe d'origine"(voil ce que m'a dit le reponsable  la lettre), donc je crois pas besoin de mettre la relation ternaire.




> Simultanment : l'ingnieur I1 peut, sur la mme priode, travailler  la fois sur le projet P1 et le projet P2
> Successivement : l'ingnieur I1 ne peut travailler sur le projet P2 que s'il a fini de travailler sur le projet P1. Il ne travaille jamais sur deux projets  la fois.
> La relation ternaire que j'ai propose dans mon schma est une adaptation de la rgle R006 qui permet de connaitre l'historique des associations entre ingnieurs et projets.


Pouvez-vous dvelopper davantage SVP? pourquoi mon MCD ne permet pas  un ingnieur de travailler simultanment sur un projet? i.e. pourquoi ai-je besoin de cette relation ternaire?

MErci beaucoup de votre aide

----------


## escartefigue

Je n'ai pas dit que votre MCD ne permettait pas  un ingnieur de travailler simultanment sur plusieurs projets.
Il le permet, mais ne met pas en relation directement l'ingnieur et le projet, il faut passer par l'entit type [PARTICIPATION]
Du coup, la rgle de gestion R006 n'est pas modlise.

Donc soit la R006 ne se justifie pas, auquel cas votre modle est correct sur ce point.
Soit la R006 est justifie (ce qui signifie qu'un ingnieur peut tre rattach  un projet *sans passer par une participation*) auquel cas il manque une asso entre [INGENIEUR] et [PROJET]. Si on veut connatre l'historique de ces rattachements directs, il faut une asso ternaire, si on n'a pas besoin de l'historique, une asso binaire suffit.

Il faut donc faire vrifier par la matrise d'ouvrage si l'on conserve seulement R010 (lien ingnieur/participation), seulement R006 (lien ingnieur/projet) ou bien les deux. Si R006 est maintenue, il faudra leur demander si on a besoin de conserver l'historique. Si R010 et R006 sont toutes deux justifies, il faut savoir si des contrles de cohrence sont  prvoir entre l'une et l'autre.

Attention : si R006 et R010 sont maintenues toutes les deux, l'ajout de la nouvelle asso pour R006 peut ventuellement crer un "cycle" comme expliqu dans l'autre fil de discussion

----------


## isaac_2000

Merci,

en pratique, on dfinit lex projets, *puis* les ingnieurs qui vont bosser dessus, *ensuite* on fait la plannification de ces ingnieurs aux diffrents projets via la table participation (distribution dans le temps), donc je ne sais pas franchement si je suis oblig  mettre la relation directe entre projet-ingnieur ou ce que j'ai fait l est suffisant, notamment avec le provlme de cycle que vous avez relev!

Je crois on peut crer au dbut des participations "vierges" pour faire l'affectation des ing aux projet, puis complter semaine et utilisation plus tard... donc pas besoin de mettre la relation ingnieur-projet.

qu'en pensez-vous SVP?

et Pour la rgle R020, je ne l'ai pas mise dans mon MCD, parce que je crois elle est dduite par transitivit, en effet, un departement lead est le reponsable d'un dpartement et un departement contient une quipe, dans R020 est dduite directement. votre avis SVP? 

Merci beaucoup

----------


## escartefigue

S'il n'y a pas de lien direct entre dpartement et quipe, alors la rgle R020 doit tre vacue du cahier des charges.

----------


## isaac_2000

Bonjour,

Merci pour votre message,

j'ai besoin SVP d'un logiciel-site pour schmatiser les spcifications fonctionnelles de l'application  crer.

Avez-vous une proposition SVP?

Merci d'avance

----------


## escartefigue

Les spcifications fonctionnelles sont surtout de la littrature,  ce titre, n'importe quel traitement de texte convient.

----------

