Envoyé par
isaac_2000
déjà que voulez vous dire par "transposer"?
"Adapter" plutôt que "transposer"
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.
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
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.
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)
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 ?
Partager