Bonjour,

suite aux avis des managers, il s'avère que je dois faire des modifications dans le modèle conceptuel , mais avant de m'y lancer, je veux savoir STP :

-dans notre modèle conceptuel où le type de l'ingénieur est une table en relation avec la table de l'ingénieur, est-ce que dans l'affichage je peux afficher une table de l'ingénieur avec le type comme une de ses colonnes? 

- est-ce que je peux ne pas afficher une colonne? (par exemple le boolean "terminé" qui dit si un projet est terminé ou pas)

en fait, voilà pourquoi je demande ça( nouvelles instructions des responsables):

Sachant que j'ai pas clarifie les choses avec le maitre de stage, mais je te dis ce que j'ai en tête:

-je dois ajouter une table nommée " département" ( Un ingenieur appartient à un département, un département regroupe plusieurs ingénieurs, relation 1,N)

-je vais ajouter deux colonnes ( date arrivée et date de départ dans la table de l'ingénieur)

- pour l'appartenance géographique, t'es d'accord que ça correspond à notre table "région" et qu'il suffit de lui changer le nom dans l'affichage ? 

- vu qu'ils demandent 3 tables ( je suppose en affichage), est-ce que notre modèle conceptuel qui contient 8 tables fait l'affaire? 

Finalement j'ai une dernière question, comment je sais si je dois ajouter une colonne ou une table? par exemple pourquoi pas considérer le type d'ingénieur comme une colonne de la table d'ingénieur?

Merci beaucoup pour ton retour

-
Edité par BDD_2000 26 mai 2022 à 3:04:28

Je pense que tu as bien répondu aux demandes.

Ajout de l'entité département, en relation 1,n avec l'entité ingénieur. Si on veut la date de début et de fin, c'est que l'ingénieur va pouvoir faire plusieurs départements dans sa carrière, je ferai préciser par le client si il veut conserver l'historique des départements d'un ingénieur ... dans ce cas, il faudra créer une entité affectation (un peu comme participation), avec une relation 1,n ingénieur, 1,n département, et des attributs date début et date fin. Si le client se fout de l'historique, alors rajouter les dates dans l'entité ingénieur est suffisant, avec une relation 1,n vers département.

La notion de discipline est déjà traitée dans ton modèle.

De même pour le type, dans ce message je proposais quelque chose (un booléen), tu as dû oublier.

Pour l'appartenance géographique, je ne sais pas si c'est la même chose que la région, c'est à faire confirmer par le client. Mais si les éléments sont les mêmes alors tu peux tout à fait utiliser la même entité avec deux noms affichés différents ...

Je crois que tu as oublié la notion de capacité, qui serait un attribut à ajouter dans l'entité ingénieur, par exemple de type nombre à 3 décimales compris entre 0 (0%) et 1 (100%).

Rebonjour, 

Il y avait un changement sur le cahier de charges concernant la table "projet", voilà à quoi elle ressemble dans le fichier source:

en gros, on demande les colonnes suivantes:

• • • client: issu d'une base de données externe nommée 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 départements vus dans le message d'avant)
    • Country of execution ( là j'ai demandé au tuteur, il m'a dit que c'est différence de l'appartenance géographique, par exemple un ingénieur basé (appartenant géographiquement) sur "PARIS", peut travailler sur un projet dont le pays de l'exécution est UK, je sais pas dans ce cas le choix d'une seule table nommée "région" est suffisant ??)
    • Scope ( la seule colonne que j'ai pas bien saisie, mais elle est issue de SF et je pense qu'elle serait une colonne de la table "projet", sinon quelle est à ton avis la question à poser pour savoir si c une colonne ou une table à part, vu que j'arrive pas à bien formuler la quest et on me donne une réponse pas trop claire, genre si j'ai un peu compris, c la partie respo du projet ou qlq chose comme ça)
    • type de projet
    • Award date
    • Tender ITT
    • Tender Submission
    • Feed Start
    • FEED end
    • Exécution Start
    • Exécution Offshore date
    • Exécution End
    • Comments
    • PM
    • PEM
    • 2R Lead
    • PYG lead
    • RPT lead
    • DT lead
    • RPK lead
    • RiSE Lead
    • GSP Lead
    • One GeoTech Lead

pr Tender, Feed et execution, ce sont les phases du projet, et les colonnes ci-haut sont des dates de début et fin de chaque phase

pr les paramètres avec "lead" à la fin, il s'agit des respo du département travaillant sur les projets ( on me demande de donner la possibilité de choisir entre une liste de respo, comme ca on insere pas tout le temps à la main)

pr PM et PEM, ce sont les Project Managers et Project Engineering Managers.

avec ce paramètres là, voilà ce que je propose en terme de tables:

je suppose que pr la partie en bas ( à partir de PM  jusqu'à One geotech lead), il s'agit simplement de colonnes de la table département 2R, en effet, je compte ajouter une colonne à la table "département" nommée "department lead", mais il y a un prob pr PM et PEM, vu que en fait disons qu'il y a une division globale nommée PMT (voir table en image) et des sous divisions (dont 2R est une ), pr être plus précis, un projet aura un PM et PEM, et eux ils distribueront les roles aux autres divisions, dont 2R est une, et 2R va préciser les chefs de ses départements ( one Geotech lead, GSP lead...)

donc je sais pas comment structurer ça!

pr les phases, je suppose que ce sont juste des colonnes que je dois peut etre regrouper par phase comme données en table Excel ci-haut, non?

le client, c juste une colonne

pr le nom, vu qu'll y a deux, un ecrit manuellement et l'autre issu de SF, je fais une seule colonne appelée "nom de projet" que je nomme après avec SQL différemment, c'est ça?

pr le scope, je suppose que c une colonne, mais je crois je vais m'en renseigner encore,

Merci beaucoup pr ton retour,

Meilleures salutations

Bonjour,

Il semblerait que de nombreuses informations proviennent de logiciels extérieurs ... SF notamment (je suppose SalesForce).

Il faut clairement définir ce que sera la donnée maître. Il n'est pas forcément judicieux de "dupliquer" les informations de SF vers ton application, autant simplement les consulter et les afficher sans les stocker de ton côté ...

Il va falloir différencier :

• les données à récupérer de SF pour initialiser ton appli et qui seront ensuite gérées dans ton appli et plus dans SF
• les données qui seront toujours gérées dans SF et seulement en consultation dans ton appli (qui n'y seront pas modifiées)

en effet, il s'agit pas de "duppliquer", le nom de projet de SF est tjrs là, mais les managers veulent bien définir leur propre nom, donc ils prennent le nom de SF et ils le modifient.

le reste n'est pas modifiable, je parle surtt de çette table ( à part 2R name), 

donc ce qui vient de SF c'est cette table là, le reste c manuel.

sinon, que penses-tu stp de ma proposition:

je veux bien stp ton avis avant de me lancer en MCD.

Merci beaucoup

-
Edité par BDD_2000 8 juin 2022 à 10:58:36

Si ce n'est pas clair pour toi ce ne peut l'être pour moi ...

De toute façon, cela n'a pas vraiment d'impact sur le MCD. Rajouter/Déplacer des colonnes c'est anecdotique au final ...

Merci,

m

Bonjour,

je veux savoir svp si c'est possible de faire une seule colonne appelée "nom projet", mais lui donner deux noms différents avec SQL en affichage.

MErci

L'affichage ce n'est pas SQL qui le gère ... Donc tu fais bien ce que tu veux avec ton app ...

Merci,

sinon je compte regrouper ces phases en une seule table dans mon modèle, appelée " phase" par exemple:

Le problème est que les 3 phases n'ont pas le même nombre de colonnes, donc je ne sais pas quoi mettre comme colonnes de ma table.

Merci beaucoup 

Encore une fois, les cardinalités ... Un projet peut avoir plusieurs phases, et une phase peut apparaître sur plusieurs projets => relation n,n donc table de relation :

• projet ( id_projet [pk], etc. )
• phase ( id_phase [pk], libelle )
• phase_projet ( id_projet [fk], id_phase [fk], date_phase )

Ensuite c'est à ton app de gérer l'affichage comme tu le souhaites ...

ok merci, 

sinon j'ai un problème, entre " appartenance géographique " et " sous-équipe", en effet, il y a 6 départements, 5 utilisent juste l'apartenance géographique pour désigner également une sous équipe( pr exemple: pr un département X, l'ingénieur situé à paris, peut-être considéré commen membre de la sous-équipe de paris) mais il y a un problème au niveau d'un département, il utilise deux champs différents, une sous-équipe et une appartenance géographique.

Dans ce cas là, je suppose que je dois créer deux tables différentes, mais est-ce que par la suite je peux imposer que les 5 départements ne saisissent pas de valeur pour les sous-équipes pour éviter la redondance? sinon y' a-t-il une autre solution SVP?

j'espère que c'est clair,sinon je peux donner plus de détails si vous voulez.

Sinon comme je suis en train d'établir les règles de gestion et les cardinalités, J'ai une question sur ce que t'avais mentionné ici:

Peux-tu me confirmer stp que, dès que j'ai :

-une relation n,n, cela implique la présence d'une table de relation.

-une relation 1,n, cela implique la présence d'une clé étrangère. ( je suppose qu'il en est de même que pour 0,n )

MErci beaucoup

-
Edité par BDD_2000 16 juin 2022 à 14:06:54