Bonjour,

J'espère que vous alllez bien,

Voici mes règles de gestion pour un projet, mais j'ai un problème dans leur traduction en MCD sur MOCODO( vu que je n'ai pas accès à Looping):

On a des ingénieurs, équipes, départements, appartenance géographique, disciplines, types d’ingénieurs, projets, winit scenario, seniority, client, pays d'exectution, phases, participation, department lead, division, division lead.

16 entités= 16 tables.

R001 : UN ingénieur est lié à UN type d’ingénieur, et UN type peut être lié à PLUSIEURS ingénieurs. ( relation 1,n =  clé étrangère dans table ingénieur)

R002 : UN ingénieur appartient à UNE sous équipe et UNE sous-équipe regroupe plusieurs ingénieurs (Relation 1,n =  clé étrangère dans table ingénieur)

R003 : Un ingénieur a UNE appartenance géographique, et Une appartenance géographique regroupe Plusieurs ingénieurs (Relation 1,n)

R004 : Un ingénieur a UNE discipline, et Une discipline regroupe plusieurs ingénieurs (relation 1,n)

R005 : Un ingénieur a UNE seniority, Une seniority regroupe plusieurs ingénieurs (relation 1,n)

R006 : Un ingénieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingénieurs ( n,n = table de relation )

R007 : Un projet est proposé par un client, un client peut proposer plusieurs projets ( 1,n)

R008 : Un projet appartient à un pays d’execution, et un pays d’execution regroupe plusieurs projets (1,n)

R009 : Un projet a plusieurs phases, et une phase concerne plusieurs projets (n,n= table de relation)

R010: UNE participation est liée à UN seul ingénieur, UN ingénieur peut être lié à plusieurs participations.

R011 : UNE participation est liée à UNE seule seniority, UNE seniority peut être liée à plusieurs participations.

R012 : Une participation est liée à une discipline, et une disciple est liée à plusieurs participations.

R013 : UNE participation est liée à UN seul projet, et UN projet peut être lié à plusieurs participations.

R014 : Une sous-équipe appartient à un département, un département contient plusieurs sous-équipes. (1,n)

R015 : Un projet a UN winit scenario, et un Winit scenario regroupe plusieurs projets ( 1,n)

R016 : Un departement peut avoir plusieurs department lead, et un department lead peut être le chef de plusieurs département (1,1)

R017 : Un department lead est le responsable de plusieurs projets, un projet a plusieurs  department lead. (n,n = table de relation)

R018 : Un ingénieur a un department lead, et un department lead est le respo de plusieurs ingénieurs ( 1,n )

R019 : Un département appartient à une division, une division englobe plusieurs départements (1,n)

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

R021 : Un projet est lié à un type de projet, et un type de projet est lié à plusieurs projets.(1,n)

R022 : Une division a un « division lead », et un « division lead » peut être le chef de plusieurs divisions.(1,n)

Mais voilà ce qu'il m'affiche dans mon premier essai:

Moi je veux désigner une relation entre ingénieur et appartenance geographique, mais lui il le traduit en relation entre discipline et appartenanceGeo.

Pouvez-vous m'aider SVP?

MErci d'avance

-
Edité par BDD_2000 28 juin 2022 à 11:01:20

Bonjour,

C'est parce que tu mets tout sur la même ligne ... du coup les traits se chevauchent ...

Essaye de faire une retour à la ligne après discipline.

Merci,

j'ai un petit soucis avec la règle R020 : Un department lead est le chef de plusieurs équipes, une équipe peut avoir plusieurs  department lead.(n,n)

en effet, je sais qu'il faudrait avoir une table de relation, mais je ne sais pas quoi faire exactement,

moi j'ai mis comme tables:

-equipe: id_equipe,libelle

-departementlead: id_departementlead, nom

il me reste la table de relation je ne sais pas comment la nommer ni ses attributs si vous avez une idée SVP.

Merci beaucoup

-
Edité par BDD_2000 28 juin 2022 à 13:50:28

Je suppose que un "department lead" est une personne, un ingénieur non ?

oui c'est une personne, mais pas un ingénieur, il est le chef de département, disons le manager.

(Déjà le terme "ingénieur" va être modifié par la suite pour devenir "ressource", et dans les ressources t'auras effectivement le manager-department lead- parmi elles, donc je sais si cette info influe sur le choix de mes tables et ma dernière question sur la table de relation, si tu lis les règles de gestion, tu trouveras une différence 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 idée il me semble)

-
Edité par BDD_2000 29 juin 2022 à 9:30:25

Si l'on remplace le mot "ingénieur" par "ressource" et "type ingénieur" par type "type ressource" alors le modèle pourrait être :

Pour moi, la R018 est inutile puisque induite par R016. Mais si un département peut avoir plusieurs lead la R016 implique une relation n,n (contrairement à ce que tu as écris), et R018 et R016 deviennent incompatibles ...

Merci beaucoup,

Puis-je avoir STP tes lignes de code sur MOCODO pour avoir ce MCD, pour que je puisse y ajouter les autres tables?

(sinon t'as raison, le (1,1) est une erreur de ma part) 

Là je veux juste me rassurer que j'ai bien compris, dans la photo ci-jointe pour toi la ressource est le department lead, mais le problème est qu'il y a forcément une relation entre department lead et ingénieur, vu que c 'est le department lead qui fait la plannification des ressources (ingénieurs) dans les projets, et il faut qu'un ingénieur X ne soit plannifié que par le (les) department lead de SON département,

si je suis dans le departement X, le departement lead du département Y ne doit pas pouvoir m'utiliser comme ressource.

est-ce que cela n'influe pas sur ce que t'as mis?

-
Edité par BDD_2000 29 juin 2022 à 10:16:55

division: id_division, libelle
englobe, 11 departement, 0N division
departement: id_departement, libelle
contient, 11 equipe, 0N departement
equipe: id_equipe, libelle

:
pilote, 11 division, 0N ressource
lead_departement, 0N departement, 0N ressource
travaille, 11 ressource, 0N equipe

type_ressource: id_type_ressource, libelle
est, 11 ressource, 0N type_ressource
ressource: id_ressource, libelle
maitrise, 0N discipline, 11 ressource
discipline: id_discipline, libelle

appartenance_geo: id_appartenance_geo, libelle
regroupe, 11 ressource, 0N appartenance_geo

Attention, avec ce modèle, un ingénieur est une ressource (on peut imaginer que c'est un élément dans type de ressource).

BDD_2000 a écrit:

il faut qu'un ingénieur X ne soit plannifié que par le (les) department lead de SON département

ça, c'est une règle applicative. Il faudra que ton app gère cela en n'affichant à un lead que les ressources de son(ses) département(s).

Merci, 

pour la seniority, qui est juste un champ pour décrire la séniority de l'ingénieur (lead, junior,senior...), puis-je la mettre en colonne dans la table "ingénieur" ou faut-il la laisser en table ?

Merci beaucoup

Je créerai quand même une table seniority avec une relation 1,n vers ressource ... C'est plus facile à maintenir.

OK THANKS,

Là j'ai pas mis la relation directe entre ingénieur et projet (R006) vu que si je l'ajoute ça créé je crois un cycle entre ingénieur-projet-partcicipation, je sais pas si omettre cette règle n'influe pas sur la BDD,  parce qu'en pratique, on définit lex projets, puis les ingénieurs qui vont bosser dessus, puis on fait l'affectation via la table participation (distribution dans le temps), donc qu'en penses-tu stp?

Merci beaucoup

-
Edité par BDD_2000 30 juin 2022 à 10:09:55

Tu peux créer des participations "vierges" qui sont t juste là pour affecter les ressources aux projets, puis compléter plus tard semaine et utilisation...

Bien sûr, il y aura une relation 1,n "travaille dans" et une relation 1,n (ou n,n) "pilote".

Merci,

que penses-tu de ce MCD?

Sachant que les règles de gestion ( version finale) sont les suivantes:

R001: ONE engineer is linked to ONE type of engineer, and ONE type can be linked to SEVERAL engineers.

R002: ONE engineer belongs to ONE team, and ONE team consists of several engineers.

R003: An engineer has ONE geographic appartunance, and A geographic appartunanceincludes Several engineers.

R004: An engineer has ONE discipline, and A discipline groups several engineers.

R005: An engineer has ONE seniority, A seniority includes several engineers.

R006: A project is proposed by a client, a client can propose several projects.

R007: A project belongs to a country of execution, and a country of execution groups several projects.

R008: A project has several phases, and a phase concerns several projects.

R009: ONE participation is linked to ONE engineer, ONE engineer can be linked to several participations.

R010: ONE participation is linked to ONE discipline, and ONE discipline can be linked to several participations.

R011: ONE participation is linked to only ONE project, and ONE project can be linked to multiple participations.

R012: A team belongs to a department, a department contains several teams.

R013: A project has ONE winit scenario, and a Winit scenario corresponds to several projects.

R014: A department may have several department leads, and a department lead may be the head of several departments.

R015: A department belongs to a division, a division encompasses several departments.

R016: A project is linked to a type of project, and a type of project is linked to several projects.

R017: A division lead can be the leader of several divisions, and a division can have several division leads.

Je n'ai pas ajouté l'ancienne R006 (Un ingénieur travaille sur plusieurs projets et un projet fait travailler plusieurs ingénieurs ), vu que comme t'as dit on peut créer des participations "vierges" juste pour faire l'affectation, mais en pratique, on sélectionne notre projet, puis on y affecte un ingénieur, ensuite on fait sa plannification via la table participation, ça change rien le suivi de cet ordre tel que je l'ai décrit?

Merci beaucoup

ça me paraît bien, juste dans participation je rajouterai l'année en plus de la semaine.

Petit détail, en anglais en modélisation on dira "MANY" plutôt que "SEVERAL" et tu verras des relations "one to many" (1,n) ou "many to many" (n,n).

OK bien vu, merci beaucoup.

STP j'ai une question à propos des outputs, par exemple, la charge de chaque ingénieur par semaine:

suis-je censé ajouter une table dans le MCD pr dire que "un ingénieur a plusieurs charges et une charge correspond à un ingénieur" ou ça serait à gérer en phase de traitement? 

sinon j'ai plusieurs outputs qui doivent s'afficher par semaine (capacité, support .....), t'as une idée comment y arriver stp? et ces différentes grandeurs-outputs- dois-je les coder dans la phase du modèle physique de la BDD ou après en phase de création de l'interface  graphique? vu que je sais que SQL permet de faire mal de calcul, mais je ne sais pas exactement quand l'utiliser.

disons que j'ai besoin de votre aide pour savoir quels outputs faire avec le langage de programmation en traitement, et lesquels que je peux faire avec SQL lors de création du modèle physique.

Merci beaucoup

Je ne suis pas sûr de comprendre comment les choses se présentent.

Si ce que tu appelles la charge c'est la somme des utilisations par semaine et par ingénieur, alors c'est un simple calcul que tu peux faire en SQL. Sinon, il faut m'expliquer ce que c'est ...

Pour les outputs, comme je le comprends, ce sont pour moi des attributs de l'entité participation. Mais là encore il faudrait expliquer un peu plus de quoi l'on parle ...

pour être plus clair:

en input on a: des projets, des ingénieurs et des participations; pour simplifier disons qu' une participation désigne combien de temps passe un ingénieur sur un projet.

à partir des différentes participations d'un ingénieur sur les différents projets, on va déduire sa charge hebdomadaire, exemple:

dans la semaine W1, David travaille la moitié (1/2) de la semaine sur un projet X et l'autre moitié (1/2) de la même semaine sur un projet Y, donc dans la charge on va mettre 1 dans la semaine W1, peut être 0,5 dans la semaine W2....donc cela représente combien il travaille par semaine. donc c'est un output déduit des diffréntes participations.

pour les autres outputs, ce sont les différentes valeurs déduites également des différentes participations, par exemple pour une région X combien j'ai utilisé de ressources par semaine, pour un projet Y combien j'ai utilisé d'ingénieur par semaine, pour une région Z combien j'avais de support par semaine....

Disons que les outputs sont des pourcentages à calculer en fonction des inputs.

Voilà un exemple d'outputs:

forcast est un type de projet, donc cette table traduit le pourcentage de ce type par charge; par exemple pour la semaine W46, 51% de charge de travail était prise par le forcast.

et je ne sais pas si ce "filtrage" hebdomadaire, ou soi-disant ces différents calculs sont à faire dans le modèle physique ou dans quelle étape.

c'est si comme je demande: maintenant que j'ai le modèle physique généré par MOCODO, est-ce que je peux passer à ces calculs déduits des inputs, qui seront sous forme de requêtes SQL il me semble.

Merci beaucoup pour ton aide.

OK, pour moi, tout ce que tu décris ici sont des calculs, que tu pourras faire directement en SQL,à partir des données saisies dans la table participation.

Je pense que l'on ne parle pas ici de million ou même de dizaines de milliers de projets, donc les temps de calculs (sommes, moyennes, etc.) seront insignifiants,  et pourront êtres faits au besoin a chaque affichage par le biais d'une requête SQL.

Dans le cas contraire, il faudra imaginer des tables pour stocker les résultats des calculs qui seront exécutés périodiquement, mais cela ne remet pas en cause le modèle actuel.

Merci beaucoup, 

sinon j'ai un problème avec MOCODO, je voulais ajouter deux tables, mais je fais le shift ou le alt + le symbole pour trouver le MCD sans intersection, il me supprime le modèle relationnel et me fait cette erreur:

voici les lignes du code:

::

country_of_execution: id_countryexecution, libelle

client: id_client, libelle

:::::

::

project_location, 11 project, 0N country_of_execution

propose, 11 project, 0N client

:::::

type_of_project: id_typeofproject, libelle

have1, 11 project, 0N type_of_project

project: id_projet, name, scope, awardDtae, comments, MH_eCTR

concern, 11 project, 0N winitscenario

winitscenario: id_winitscenario, libelle

type_resource: id_type_ressource, libelle

:::

phase: id_phase,libelle

phase_project, 0N project, 0N phase: id_phase, datephase

concern1, 0N project, 11 participation

participation: id_participation, week, month, year, utilization

participate, 0N resource, 11 participation

have2, 11 resource, 0N type_resource

division_lead, 0N division, 0N resource

division: id_division, libelle

:

::

linked, 0N discipline, 11 participation

seniority: id_seniority, libelle

own, 11 resource, 0N seniority

resource: id_ressource, first_name, last_name, capacity, arrival_date, departure_date

belong3, 11 resource, 0N geographic_appartunance

geographic_appartunance: id_appartenance_geo, libelle

belong, 11 departement, 0N division

:::

discipline: id_discipline, libelle

master, 0N discipline, 11 resource

work, 11 resource, 0N team

departement_lead, 0N departement, 0N resource

departement: id_departement, libelle

:

::::

team_lead, 0N resource, 0N team

team: id_team, libelle

belong1, 11 team, 0N departement

::

"support_locally, 0N country_of_execution, 0N team: support

MH_forecast: id_MHForcast, MH, scope

commit, 11 MH_forecast, 0N resource

allocated,  11 MH_forecast, 0N project"

les 4 dernières lignes entre guillemets sont ce que je voulais ajouter, i.e, ce qui est avant ces 4 lignes marche bien et donne le MCD que j'ai déjà envoyé.

Merci de ton aide.

Peux-tu poster ton code Mocodo dans la balise code, en utilisant le bouton </> de l'éditeur de message ?

Car là on ne voit pas clairement les sauts de lignes et les espaces ...

Je sais que c'est compliqué pour toi, mais dès que le modèle grossi, le mieux reste quand même d'installer un logiciel de modélisation. Je te conseille Looping MCD.

-
Edité par Benzouye 8 juillet 2022 à 20:06:30

::
country_of_execution: id_countryexecution, libelle
client: id_client, libelle
:::::

::
project_location, 11 project, 0N country_of_execution
propose, 11 project, 0N client
:::::

type_of_project: id_typeofproject, libelle
have1, 11 project, 0N type_of_project
project: id_projet, name, scope, awardDtae, comments, MH_eCTR
concern, 11 project, 0N winitscenario
winitscenario: id_winitscenario, libelle
type_resource: id_type_ressource, libelle
:::

phase: id_phase,libelle
phase_project, 0N project, 0N phase: id_phase, datephase
concern1, 0N project, 11 participation
participation: id_participation, week, month, year, utilization
participate, 0N resource, 11 participation
have2, 11 resource, 0N type_resource
division_lead, 0N division, 0N resource
division: id_division, libelle
:

::
linked, 0N discipline, 11 participation
seniority: id_seniority, libelle
own, 11 resource, 0N seniority
resource: id_ressource, first_name, last_name, capacity, arrival_date, departure_date
belong3, 11 resource, 0N geographic_appartunance
geographic_appartunance: id_appartenance_geo, libelle
belong, 11 departement, 0N division

:::
discipline: id_discipline, libelle
master, 0N discipline, 11 resource
work, 11 resource, 0N team
departement_lead, 0N departement, 0N resource
departement: id_departement, libelle
:

::::
team_lead, 0N resource, 0N team
team: id_team, libelle
belong1, 11 team, 0N departement
::

support_locally, 0N project, 0N team: support
:
allocated,  11 MH_forecast, 0N project
MH_forecast: id_MHForcast, MH, scope
commit, 11 MH_forecast, 0N resource
:

-
Edité par BDD_2000 11 juillet 2022 à 8:51:03

ça fonctionne pour moi :

:
:
country_of_execution: id_countryexecution, libelle
client: id_client, libelle
:
:
:
:
:

:
:
project_location, 11 project, 0N country_of_execution
propose, 11 project, 0N client
:
:
:
:
:

type_of_project: id_typeofproject, libelle
have1, 11 project, 0N type_of_project
project: id_projet, name, scope, awardDtae, comments, MH_eCTR
concern, 11 project, 0N winitscenario
winitscenario: id_winitscenario, libelle
type_resource: id_type_ressource, libelle
:
:
:

phase: id_phase,libelle
phase_project, 0N project, 0N phase: id_phase, datephase
concern1, 0N project, 11 participation
participation: id_participation, week, month, year, utilization
participate, 0N resource, 11 participation
have2, 11 resource, 0N type_resource
division_lead, 0N division, 0N resource
division: id_division, libelle
:

:
:
linked, 0N discipline, 11 participation
seniority: id_seniority, libelle
own, 11 resource, 0N seniority
resource: id_ressource, first_name, last_name, capacity, arrival_date, departure_date
belong3, 11 resource, 0N geographic_appartunance
geographic_appartunance: id_appartenance_geo, libelle
belong, 11 departement, 0N division

:
:
:
discipline: id_discipline, libelle
master, 0N discipline, 11 resource
work, 11 resource, 0N team
departement_lead, 0N departement, 0N resource
departement: id_departement, libelle
:

:
:
:
:
team_lead, 0N resource, 0N team
team: id_team, libelle
belong1, 11 team, 0N departement
:
:

:
support_locally, 0N project, 0N team: support
:
allocated,11 MH_forecast,0N project
MH_forecast: id_MHForcast, MH, scope
commit, 11 MH_forecast, 0N resource
:
:
:
:

oui, mais c'est mal présenté:

ce qui marche pas c'est le alt + 

qui permet d'enlever les intersections.

si tu fais cette commande tu auras l'erreur "MCD est vide"

Tu vois?

Si je fais ALT clic sur les flèches, j'obtiens le code suivant :

country_of_execution: id_countryexecution, libelle
client: id_client, libelle
project_location, 11 project, 0N country_of_execution
propose, 11 project, 0N client
type_of_project: id_typeofproject, libelle
have1, 11 project, 0N type_of_project
project: id_projet, name, scope, awardDtae, comments, MH_eCTR
concern, 11 project, 0N winitscenario

winitscenario: id_winitscenario, libelle
type_resource: id_type_ressource, libelle
phase: id_phase,libelle
phase_project, 0N project, 0N phase: id_phase, datephase
concern1, 0N project, 11 participation
participation: id_participation, week, month, year, utilization
participate, 0N resource, 11 participation
have2, 11 resource, 0N type_resource

division_lead, 0N division, 0N resource
division: id_division, libelle
linked, 0N discipline, 11 participation
seniority: id_seniority, libelle
own, 11 resource, 0N seniority
resource: id_ressource, first_name, last_name, capacity, arrival_date, departure_date
belong3, 11 resource, 0N geographic_appartunance
geographic_appartunance: id_appartenance_geo, libelle

belong, 11 departement, 0N division
discipline: id_discipline, libelle
master, 0N discipline, 11 resource
work, 11 resource, 0N team
departement_lead, 0N departement, 0N resource
departement: id_departement, libelle
team_lead, 0N resource, 0N team
team: id_team, libelle

belong1, 11 team, 0N departement
support_locally, 0N project, 0N team: support
allocated,11 MH_forecast,0N project
MH_forecast: id_MHForcast, MH, scope
commit, 11 MH_forecast, 0N resource
:::

Et si je génère le modèle j'obtiens :

Cela fonctionne ... Mais le modèle est encore pire que ton point de départ ...

Si tu veux ajuster le modèle, fais le à la main en déplaçant les entités voulues dans le code.