Bonjour,

Tu as des régions, des types de projet, des disciplines, des types d'ingénieur, des rôles, des projets et des ingénieurs. 7 entités = 7 tables.

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.

Le modèle serait :

-
Edité par Benzouye 22 mars 2022 à 12:19:17

SAlut, 

Merci beaucoup pour ton retour,

Puis-je avoir STP le lien où t'as tracé ce shéma?

Sinon, j'ai deux autres questions stp:

1)Pour la table "plannification", y'aura-t-il moyen pour l'avoir comme celle-ci ? (je te rappelle que 1 <=> 40 h de travail en semaine ) 

2) Pour les id dans tes tables, à moi de les définir ou quoi ? vu que dans les fichiers excel sur quoi je me base maintenant je n'ai que les autres attributs définis en haut, je n'ai aucun " id" .

et Une deuxième remarque, ma BDD soit être "dynamique", c'est à dire, si par exemple il arrive qu'un projet se décale dans le temps, il faut que tout soit décalé, cette condition a-t-elle un impact suyr le modèle conceptuel ou faudrait-il la voir en phase de traitement? 

Merci beacoup!

-
Edité par BDD_2000 22 mars 2022 à 14:40:07

BDD_2000 a écrit:

Puis-je avoir STP le lien où t'as tracé ce shéma?

Pour faire des MCD "rapides", j'utilise MoCoDo.

Pour faire ce schéma, j'ai "simplement" saisi les éléments suivants :

typeingenieur: id_typeingenieur, libelle
type_ingenieur, 0N typeingenieur, 11 ingenieur
ingenieur: id_ingenieur, nom
regroupe, 0N discipline, 11 ingenieur
discipline: id_discipline, libelle

:
lieu_ingenieur, 11 ingenieur, 0N region
:
:

region: id_region, libelle
lieu_projet, 0N region, 11 projet
participation, 0N role, 0N projet, 0N ingenieur : date_debut, date_fin
role: id_role, libelle

typeprojet: id_typeprojet, libelle
type_projet, 0N typeprojet, 11 projet
projet: id_projet, nom
:

BDD_2000 a écrit:

Pour les id dans tes tables, à moi de les définir ou quoi ?

Tu peux les définir comme entier auto incrémenté, ils s'incrémenteront tout seul du coup. Leur rôle est juste d'assurer l'intégrité référentielle dans les clés étrangères.

BDD_2000 a écrit:

Pour la table "planification", y'aura-t-il moyen pour l'avoir comme celle-ci

Ce que tu montres est de l'ordre de l'affichage, ce n'est pas à la base de données de réfléchir à cela. Si tu ne veux pas de détail (au jour près) mais simplement à la semaine, alors tu peux juste stocker une année et un numéro de semaine avec un nombre (1 ou 0.5) dans la relation participation ...

Pour faire un affichage sous forme de planning, ce sera côté application qu'il faudra le gérer, avec la bibliothèque graphique du langage que tu utilises (Java, Python, C#, PHP, etc.).

BDD_2000 a écrit:

ma BDD soit être "dynamique", c'est à dire, si par exemple il arrive qu'un projet se décale dans le temps, il faut que tout soit décalé

C'est à dire ? Comment détermines-tu qu'un projet se décale dans le temps ?

Bonjour,

Merci beaucoup pour le lien, comme ça je pourrai modifier en fonction du cahier de charges!

Pour ta question, voici un exemple explicatif:

Au début j'ai fait la plannification pour un projet qui était de type forecast, c'est a dire contrat non encore signé, mais au moment de la signature du contrat, le client a précisé que la date de début du projet a changé, et donc, moi je dois adapter ma plannification  à cette modification de date de début de projet, comme s'il doit y avoir une translation dans le temps de la plannificatio effectuée avant la signature de contrat, et du coupe ça doit se faire automatiquement, sans être boligé à tout replanifier, ceci étant dans toutes les disciplines!

Dis moi stp si c'est clair pour toi ou si tu veux d'autres explications!

(P.S. Je vais checker si je dois éventuellement ajouter une table pour le client ou pas.)

BDD_2000 a écrit:

le client a précisé que la date de début du projet a changé

Cela signifie qu'il doit y avoir une colonne date_debut_previsionnelle et date_debut_reelle dans la table projet. Ce n'était pas  précisé au départ ...

BDD_2000 a écrit:

il doit y avoir une translation dans le temps de la plannificatio effectuée avant la signature de contrat

Cela est une règle applicative qui n'a pas d'impact sur le modèle de données. Pour la transcrire en base tu peux par exemple mettre en place un TRIGGER AFTER UPDATE ON projet qui repousse d'autant que nécessaire (nouvelle date - ancienne date) les "participations" existantes.

Merci pour la clarification,

J'ai une autre question SVP, le schéma ci-haut concerne l'étape de la plannification, il reste une partie où à partir des données saisies, je dois faire quelques calculs, par exemple:

-demande/capacité totale par discilpline / région et sa distribution dans le temps, pour un région donnée, 

-le support des autres régions, c'est-à-dire, les ingenieurs envoyés par les autres régions pour un "centre" donné.

est-ce qu'il y aura un besoin de créer des tables pour chaque élément que je veux calculer? (e.g. deux nouvelles tables pour la demande et la capacité ou suffit-il de les déduire à partir des tables ci-dessus..)

P.S: capacité totale = combien d'ingénieurs sont-ils disponibles dans chaque région/par discipline

demande totale = de combien d'ingenieurs ai-je besoin par discipline/région.

et j'ai une autre remarque, la table finale peut contenir deux régions, une pour le projet et l'autre pour représenter "l'origine de l'ingénieur", est-ce que cela a une influence sur le modèle coneptuel? 

D'alleiurs, il y a 3 centres( GEC ) spéciaux pour le support ( 3 GEC=3 GLOBAL Engineering centers=3 centres= 3 régions), dois-je créer une table "support" spécifique pour eux, ou les laisser inclus dans la table "région"?

Merci beaucoup de votre retour

-
Edité par BDD_2000 24 mars 2022 à 15:17:52

BDD_2000 a écrit:

est-ce qu'il y aura un besoin de créer des tables pour chaque élément que je veux calculer?

Sans plus de détails je pense que le modèle proposé suffit, les calculs sont tout à fait faisable en l'état. Avec des sous-requêtes ou des vues.

BDD_2000 a écrit:

la table finale peut contenir deux régions, une pour le projet et l'autre pour représenter "l'origine de l'ingénieur", est-ce que cela a une influence sur le modèle conceptuel?

La même table (ici région) peut être utilisée plusieurs fois dans la clause FROM d'une même requête, avec des alias différents, pour récupérer la région d'un projet distinctement de celle d'un ingénieur.

BDD_2000 a écrit:

il y a 3 centres( GEC ) spéciaux pour le support ( 3 GEC=3 GLOBAL Engineering centers=3 centres= 3 régions), dois-je créer une table "support" spécifique pour eux

GEC = Globlal engineering center.

Il existe 3 GEC, leur role est de fournir des ingénieurs aux différentes régions, et eux même se trouvent sur 3 régions.

Exemple:

Dans une discipline A, et pour une région B, le GEC C va me donner un nombre précis d'ingénieurs D.

c'est une sorte de support pour lles projets de l'entreprise.

Benzouye a écrit:

Je n'ai pas compris de quoi il s'agit ici ... Un GEC intervient sur plusieurs régions ? Un ingénieur est affecté à un ou plusieurs GEC ?

Un GEC intervient sur plusieurs régions: OUI. (est-il possible qu'il n'intervient sur aucune région? sur une seule région? forcément sur toutes les régions? je ne sais pas, je vais demander au manager)

Un ingénieur est affecté à un ou plusieurs GEC : Non, en effet un ingénieur est affecté à un seul GEC.

-
Edité par BDD_2000 25 mars 2022 à 11:12:32

Donc il faut rajouter une entité GEC avec une relation 1,n vers ingénieur ...

Merci beaucoup,

Puis-je avoir le lien STP?

Et sinon, Pourrais-tu me dire STP comment je peux identifier moi même les tables? c'est-à-dire, comment procède-tu pour faire ton modèle coneptuel?

comme ça je saurais quelle modification faire en cas de besoin.

Tout est dans mon premier message.

Tu identifies les objets (ou entités) avec leurs propriétés (ou attributs), puis tu définis les relations entre elles avec leurs cardinalités.

Tout ça avec des phrases.

Une fois écris le MCD vient tout seul, avec un peu de pratique...

Le document "Conception BDD" dans ma signature est pas mal pour faire le tour de tout ça.

Okay, thanks!

sinon pour le modèle que t'as proposé, on n'a pas besoin de faire une normalisation ?

Mon modèle respecte les 3 premières formes normales.

Que voulais-tu normaliser ?

Ok, je viens de lire la partie sur la normalisation en effet.

Sinon, je suis en train de completer le dictionnaire des donnés, il y a des attributs où j'ai pas de précision sur leur taille; par exemple, pour le nom des ingénieurs, dans ce cas, faudrait-il que j'mpose une précision moi même ou quoi? ( e.g. mettre nombre de caractères < 20 )  

BDD_2000 a écrit:

il y a des attributs où j'ai pas de précision sur leur taille; par exemple, pour le nom des ingénieurs, dans ce cas, faudrait-il que j'mpose une précision moi même

Oui, mais il faut le faire intelligemment, en imaginant les valeurs possibles. Pour un nom par exemple, je pense qu'une limite de 20 caractères c'est un trop petit ... Il me semble avoir vu quelque part qu'une valeur maximale admise pour les noms de famille est 50 caractères (en France). Tu peux chercher un peu sur le net tu trouveras des discussions de cet ordre je pense.

Okaay, thanks,

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

De même pour des commentaires sur les projets( date de début changée, contrat signé ou pas...) ?

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

d'autre part, voici comment est présentée une partie du fichier excel qui regroupe projets et ingénieurs:

de plus, quand j'étais en train de me documenter, j'ai trouvé que ceci correpsond à un problème de redondance de données si je me rappelle bien, est-ce que je dois m'en soucier maintenant que je suis sur le modèle conceptuel et physique, ou bien en phase de traitement ?

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

Merci beaucoup!

-
Edité par BDD_2000 29 mars 2022 à 12:50:31

BDD_2000 a écrit:

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

La simplicité serait en effet de rajouter une colonne de type TEXT dans la table ingénieur.

On pourrait par contre réfléchir à une entité "Statut", qui listerait les différents statuts possible pour un ingénieur (disponible, congés annuel, congés parental, maladie, etc.) avec une relation 1,n vers l'entité ingénieur.

On pourrait même pousser la logique avec une entité "Indisponibilité", ayant deux attributs date de début et date de fin, pour stocker les changements de statut de chaque ingénieur ...

BDD_2000 a écrit:

De même pour des commentaires sur les projets( date de début changée, contrat signé ou pas...) ?

Même remarque que précédemment ...

BDD_2000 a écrit:

ceci correpsond à un problème de redondance de données si je me rappelle bien

Je ne suis pas sûr de comprendre ce que tu dis, mais avec le modèle proposé, l'origine de l'ingénieur est portée sur l'entité ingénieur, et induite par la table de relation "participation", il n'y aura pas de répétition de cette donnée (ou redondance) dans la table projet.

BDD_2000 a écrit:

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

Le modèle proposé permet de lister les ingénieurs par région, donc rien à rajouter au niveau du modèle.

Merci,

En effet, j'ai demandé à l'entreprise d'installer "MOCODO" pour faire le schema conceptuel, mais l'équipe de cyber sécurité a rejeté la demande pour des raisons de sécurité.

Y a-t-il un logiciel qu'on accepte à l'entreprise, i.e qui ne pose pas de problème au niveau de la sécurité même s'il est gratuit?

Sinon, est-ce qu'il y a un risque de sécurité si je choisis de le faire en ligne? et est-il préférable de le faire via un logiciel ou bien en ligne est suffisant ?

Merci

Pour moi le meilleur c'est Looping MCD.

https://www.looping-mcd.fr/

SAlut chef,

Il s'avère qu'un GEC donne forcément des ingénieurs à chaque région, du coup il faut que ca soit 1,N dans ton schema plutot que 0,N, parce qu'on est sur que pour toute région on a des ingénieurs de la part de GEC, mais dans ce cas une relation 1,N avec les ingénieurs est-elle suffisante ou faudrait encore une relation avec la table des regions?

d'ailleurs, il y a d'autres types de support, le GEC n'en est qu'un exemple, mais en effet, un support présente le taux des ingénieurs donnés par des " régions  " à une autre, voici un extrait du fichier source pr bien comprendre:

dans ce cas, alsace serait une " région source" d'un ingénieur, comme paris, les contract sont les ingénieurs contractés, et other support présente le support des autres régions pour une région donnée.

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

Même 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 région = "alsace" OR  ... OR... ) ou vaut mieux créer une table specifique comme t'as fait en haut?

Merci beaucoup

-
Edité par BDD_2000 7 avril 2022 à 9:56:51

BDD_2000 a écrit:

il faut que ca soit 1,N dans ton schema plutot que 0,N

En théorie oui tu as raison et c'est plus rigoureux, mais ... en pratique la cardinalité 1,n est impossible à respecter car il faudrait que le GEC soit créé exactement en même temps que le premier ingénieur ...

Dans les faits, on crée d'abord le GEC, on obtient ainsi son ID, et il n'a donc aucun ingénieur (0) associé à ce moment là. Puis l'on crée l'ingénieur par la suite, donc pendant une période inconnue, le GEC n'a pas d'ingénieur associé ... C'est un détail sans importance, mais voilà ...

BDD_2000 a écrit:

il y a d'autres types de support, le GEC n'en est qu'un exemple, mais en effet, un support présente le taux des ingénieurs donnés par des " régions  " à une autre

Je ne suis pas sûr de comprendre, mais j'ai l'impression que la table nommé GEC aujourd'hui pourrait être renommée "support", et qu'il faudrait créer une nouvelle table "type_support" en relation 1,n (ou 0,n ) avec support. Dans la table type il y aurait GEC, mais aussi les autres types de support ...

Après je suis sûrement à côté de la plaque ... peux-tu clarifier un peu, peut-être avec des exemples de données ?

Pour moi, il y a trois notions bien différentes :

• le GEC d'appartenance de l'ingénieur
• la région d'appartenance de l'ingénieur
• le statut interne/externe de l'ingénieur

Le GEC d'appartenance est déjà porté par l'entité ingénieur. Idem pour la région.

Selon moi, il suffirait donc juste de rajouter un attribut booléen (0 ou 1) nommé externe sur l'entité ingénieur. Si 0 alors interne, si 1 alors externe.

Pour la partie support, dans la requête SELECT, si la région de l'ingénieur est différente de la région du projet auquel il participe alors il est dit "support".

-
Edité par BDD_2000 12 avril 2022 à 9:33:47

Je pense que tu te perds là ...

Reprenons le modèle proposé dans mon message plus haut :

La relation n,n "participation" lie des ingénieurs à un projet. Un projet est lié à une région (relation lieu_projet), et un ingénieur est lié à une région (relation lieu_ingenieur). Donc tu peux savoir si un ingénieur participe à un projet d'une région qui n'est pas la sienne ... et vice versa ... point !

BDD_2000 a écrit:

Il faudrait poster le texte du modèle pour voir ce qui ne vas pas ... ma visiblement une relation (association) est mal définie.

Ok, mais s'il change de région alors qu'il est déjà affecté à un projet? est-ce que ce cas de figure est permis avec ton MCD?

Un ingénieur qui change de région, c'est "juste" la valeur du champ ingenieur.id_region qui change. Dans ce cas là, l'ingénieur aura de toute façon son code région, et le projet également ...

A moins de vouloir conserver l'historique des changements de région des ingénieurs le modèle pour moi est correct.

Mais, encore une fois, c'est seulement toi qui sais où tu veux aller ...

salut, 

merci, 

Donc pr la partie de "support", tu penses que la dernière version avec "GEC" comme table est mieux, ou bien on laisse la première vesion, i.e celle-ci :

vu que les différents supports peuvent être tirés comme tu l'as expliqué ici:

"Le GEC d'appartenance est déjà porté par l'entité ingénieur. Idem pour la région.

Selon moi, il suffirait donc juste de rajouter un attribut booléen (0 ou 1) nommé externe sur l'entité ingénieur. Si 0 alors interne, si 1 alors externe.

Pour la partie support, dans la requête SELECT, si la région de l'ingénieur est différente de la région du projet auquel il participe alors il est dit "support"."

-
Edité par BDD_2000 26 avril 2022 à 9:04:59

Tu sembles dire que GEC et Région sont la même chose ?

Si c'est le cas, alors oui, inutile de rajouter une entité GEC ... région suffit ...