IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Deux tables identiques


Sujet :

Schéma

  1. #1
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut Deux tables identiques
    Bonjour,

    J'espère que vous allez bien,

    je suis en train de créer 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 différentes tables, parmi elles on trouve: "ingénieur", "appartennance géographique", "département", "sous équipe"...

    Le problème est que dans l'entreprise il y a 6 départements, pour 5 d'eux, l'appartenance géographique = sous-équipe, c'est-à-dire, un ingénieur qui se trouve à Paris, appartient à la sous-équipe de Paris, et dans ce cas, appartenance géo = sous-equipe= paris.

    Mais chez le 6ème département, les deux champs sont bien différents, on a la notion de l'appartenance géo, outre l'entité "sous équipe".

    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.

    MErci de votre retour,

    Cordialement

  2. #2
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    La bonne démarche est de collecter les règles de gestion auprès du métier (MOA, gestionnaires), de les rédiger, leur attribuer un identifiant (un numéro) et de les faire valider par votre donneur d'ordre (la MOA le plus souvent).

    Une fois que c'est fait, vous pourrez créer le modèle conceptuel des données en conséquence, MCD dont on pourra discuter ici au vu des règles de gestion.

    Une fois le MCD validé, les tables seront créées en un clic

    En résumé, il ne faut pas réfléchir au "comment" (combien de tables...) mais au "qui" et au "quoi", le "comment" n'est qu'une conséquence du "quoi".

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

  3. #3
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut
    Bonjour,

    Merci pour votre message,

    en effet voilà le cahier de charges donné par le reponsable,
    Nom : 30.png
Affichages : 128
Taille : 18,3 Ko

    - une table "Projet" ayant 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)
    pays d'execution
    Scope (juste une colonne de la table projet)
    type de projet
    winiit scenario ( stratégie du 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


    - 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 ingénieurs, équipes, départements, appartenance géographique, disciplines, types d’ingénieurs, projets, winit scenario, seniority, client, pays d'execution, phases, participation, department lead(chef de département), division, division lead(chef de division).

    En effet, la table "phase" permet de regrouper les éléments suivants:
    Tender ITT
    Tender Submission
    Feed Start
    FEED end
    Exécution Start
    Exécution Offshore date
    Exécution 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 "ingénieurs+departement lead+division lead" dans une seule table appelée "ressource", mais le problème est que ça affecte les règles de gestion et je ne sais si c'est une bonne idée)

    Voilà les règles de gestion confirmées par les responsables:

    R001 : UN ingénieur est lié à UN type d’ingénieur, et UN type peut être lié à PLUSIEURS ingénieurs.

    R002 : UN ingénieur appartient à UNE équipe et UNE équipe regroupe plusieurs ingénieurs

    R003 : Un ingénieur a UNE appartenance géographique, et Une appartenance géographique regroupe Plusieurs ingénieurs

    R004 : Un ingénieur a UNE discipline, et Une discipline regroupe plusieurs ingénieurs

    R005 : Un ingénieur a UNE seniority, Une seniority regroupe plusieurs ingénieurs

    R006 : Un ingénieur travaille sur plusieurs projets, et un projet fait travailler plusieurs ingénieurs

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

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

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

    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.

    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 département

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

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

    R019 : Un département appartient à une division, une division englobe plusieurs départements

    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 règles de gestion, pour moi je veux plutôt SVP votre avis sur le choix des tables, si vous faites attention aux règles de gestion, vous trouverez 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)

    Merci beaucoup

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    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'intéresser aux tables, les tables, c'est le "comment", le cahier des charges devrait décrire le besoin fonctionnel, le "quoi". Ce sont les règles de gestion qui décrivent le "quoi", elles sont présentes et c'est tant mieux. Reste à vérifier qu'elles sont complètes et claires (je le ferai dès que j'aurai un peu de dispo ).

    Dans l'ordre
    1. collecte des règles de gestion auprès du métier
    2. ébauche du modèle conceptuel conformément aux règles
    3. génération du modèle tabulaire (MLD et/ou MPD) à partir du modèle conceptuel

    Les étapes 1 et 2 sont itératives, 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 règles de gestion, et de nombreuses questions se posent :

    • aucune précision n'est donnée sur l'affectation d'un ingénieur à une équipe, je suppose que
      - un ingénieur peut changer d'équipe
      - à un instant "t" un ingénieur n'est affecté qu'à une seule équipe
      C'est bien le cas ?
    • aucune relation n'est faite entre équipe et projet
      faut-il comprendre que des ingénieurs d'une même équipe peuvent travailler sur des projets différents ?
    • Les deux questions qui précèdent pourraient laisser supposer que l'équipe n'est finalement pas un objet de gestion,
      peut-être est-ce simplement le fait que deux ingénieurs travaillent sur le même projet fait qu'ils sont dans la même équipe
      mais ce serait contradictoire avec la règle R002, du coup je m'y perds
      Vérifiez si la notion d'équipe comporte des attributs, si oui lesquels, ce qui permettra de le confirmer ou infirmer.
    • R006 : un ingénieur peut-il travailler sur plusieurs projets simultanément ou successivement ?
    • Certains termes méritent des explications, par exemple Seniority et Participation, il faut donner des exemples de cas et des attributs les caractérisant pour plus de clarté

  5. #5
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    Voici une première ébauche partielle de MCD basée sur les règles de gestion fournies et sur quelques suppositions (notamment relatives à la temporalité de certaines associations, voir mes questions qui précedent).

    Nom : Ingénieurs_projets_V01.jpg
Affichages : 120
Taille : 116,4 Ko

    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 déjà 8 E.T. concernées (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 (décliné ici pour SQL server) et donc les tables :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    81
    82
    83
    84
    85
    86
    87
    88
    89
    90
    91
    92
    93
    94
    95
    96
    97
    98
    99
    100
    101
    102
    CREATE TABLE TYI_type_inge(
       TYI_ident INT IDENTITY,
       TYI_code CHAR(2) NOT NULL,
       TYI_libelle VARCHAR(50) NOT NULL,
       TYI_debval DATE NOT NULL,
       TYI_finval DATE NOT NULL,
       PRIMARY KEY(TYI_ident),
       UNIQUE(TYI_code)
    );
     
    CREATE TABLE EQU_equipe(
       EQU_ident INT IDENTITY,
       EQU_code CHAR(4) NOT NULL,
       EQU_libelle VARCHAR(50) NOT NULL,
       PRIMARY KEY(EQU_ident),
       UNIQUE(EQU_code)
    );
     
    CREATE TABLE PRO_projet(
       PRO_ident INT IDENTITY,
       PRO_code CHAR(6) NOT NULL,
       PRO_libelle VARCHAR(100) NOT NULL,
       PRO_dtdeb DATE NOT NULL,
       PRIMARY KEY(PRO_ident),
       UNIQUE(PRO_code)
    );
     
    CREATE TABLE SEN_seniority(
       SEN_ident INT IDENTITY,
       SEN_xxxx VARCHAR(50) NOT NULL,
       PRIMARY KEY(SEN_ident)
    );
     
    CREATE TABLE GEO_app_geo(
       GEO_ident VARCHAR(50),
       GEO_code CHAR(4) NOT NULL,
       GEO_libelle VARCHAR(50) NOT NULL,
       PRIMARY KEY(GEO_ident),
       UNIQUE(GEO_code)
    );
     
    CREATE TABLE DIS_discipline(
       DIS_ident INT IDENTITY,
       DIS_code CHAR(4) NOT NULL,
       DIS_libelle VARCHAR(50) NOT NULL,
       PRIMARY KEY(DIS_ident),
       UNIQUE(DIS_code)
    );
     
    CREATE TABLE ING_ingenieur(
       ING_ident INT IDENTITY,
       ING_matricule CHAR(8) NOT NULL,
       ING_nom VARCHAR(50) NOT NULL,
       ING_prenom VARCHAR(50) NOT NULL,
       ING_ddn DATE NOT NULL,
       DIS_ident INT NOT NULL,
       TYI_ident INT NOT NULL,
       PRIMARY KEY(ING_ident),
       UNIQUE(ING_matricule),
       FOREIGN KEY(DIS_ident) REFERENCES DIS_discipline(DIS_ident),
       FOREIGN KEY(TYI_ident) REFERENCES TYI_type_inge(TYI_ident)
    );
     
    CREATE TABLE PAR_participation(
       PAR_ident INT IDENTITY,
       PAR_xxxx VARCHAR(50) NOT NULL,
       SEN_ident INT NOT NULL,
       PRO_ident INT NOT NULL,
       ING_ident INT NOT NULL,
       PRIMARY KEY(PAR_ident),
       FOREIGN KEY(SEN_ident) REFERENCES SEN_seniority(SEN_ident),
       FOREIGN KEY(PRO_ident) REFERENCES PRO_projet(PRO_ident),
       FOREIGN KEY(ING_ident) REFERENCES ING_ingenieur(ING_ident)
    );
     
    CREATE TABLE AFF_affecter(
       ING_ident INT,
       CAL_date DATE,
       AFF_dtfin DATE NOT NULL,
       EQU_ident INT NOT NULL,
       PRIMARY KEY(ING_ident, CAL_date),
       FOREIGN KEY(ING_ident) REFERENCES ING_ingenieur(ING_ident),
       FOREIGN KEY(EQU_ident) REFERENCES EQU_equipe(EQU_ident)
    );
     
    CREATE TABLE TRA_travailler(
       ING_ident INT,
       PRO_ident INT,
       CAL_date DATE,
       TRA_dtfin VARCHAR(50) NOT NULL,
       PRIMARY KEY(ING_ident, PRO_ident, CAL_date),
       FOREIGN KEY(ING_ident) REFERENCES ING_ingenieur(ING_ident),
       FOREIGN KEY(PRO_ident) REFERENCES PRO_projet(PRO_ident)
    );
     
    CREATE TABLE R003(
       ING_ident INT,
       GEO_ident VARCHAR(50),
       PRIMARY KEY(ING_ident, GEO_ident),
       FOREIGN KEY(ING_ident) REFERENCES ING_ingenieur(ING_ident),
       FOREIGN KEY(GEO_ident) REFERENCES GEO_app_geo(GEO_ident)
    );

    Edit : pour la règle R003, j'ai fait une coquille dans le MCD, c'est bien 1,1 côté ingénieur

  6. #6
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut
    Bonjour,

    Merci pour votre message, en effet:

    Citation Envoyé par escartefigue Voir le message
    aucune précision n'est donnée sur l'affectation d'un ingénieur à une équipe, je suppose que
    - un ingénieur peut changer d'équipe
    - à un instant "t" un ingénieur n'est affecté qu'à une seule équipe
    C'est bien le cas ?
    la réponse est oui (pour les deux questions).

    Citation Envoyé par escartefigue Voir le message
    aucune relation n'est faite entre équipe et projet
    faut-il comprendre que des ingénieurs d'une même équipe peuvent travailler sur des projets différents ?
    là également la réponse est oui.

    Citation Envoyé par escartefigue Voir le message
    Vérifiez 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 départements, une équipe est un regroupement de régions ( pr ex. l'équipe de USA regroupe BRASIL et CANADA, EASTERN pour dire UK, FRANCE..)
    pour un seul département, une équipe n'a pas la désignation précédente.

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

    Citation Envoyé par escartefigue Voir le message
    R006 : un ingénieur peut-il travailler sur plusieurs projets simultanément ou successivement
    Pour simultanément, 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 réponse est positive, sinon j'attends votre explication du mot.)

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

    Pour participation, c'est principalement cette table:
    Nom : 32.PNG
Affichages : 118
Taille : 2,4 Ko

    elle comme attribut "semaine" (peut être année) 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 ?

    Nom : 34.PNG
Affichages : 121
Taille : 80,7 Ko


    Merci beaucoup pour votre aide

  7. #7
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par isaac_2000 Voir le message
    la réponse est oui (pour les deux questions).
    En ce cas, il faut reformuler la règle de gestion R002 qui devient par exemple
    R002 : un ingénieur est affecté à une seule équipe à un instant "t" et peut changer d'équipe à "t+1" et à une équipe sont affectés plusieurs ingénieurs
    Et il faut revoir le MCD pour établir une relation ternaire comme je l'ai fait dans le mien, avec la flèche en direction d'équipe qui symbolise la contrainte d'unicité de l'équipe pour un ingénieur et une date
    à noter : il est préférable d'utiliser le verbe de la règle de gestion (ici affecter) comme nom d'association


    Citation Envoyé par isaac_2000 Voir le message
    Pour simultanément, 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 réponse est positive, sinon j'attends votre explication du mot.)
    Simultanément : l'ingénieur I1 peut, sur la même période, travailler à la fois sur le projet P1 et le projet P2
    Successivement : l'ingénieur 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 proposée dans mon schéma est une adaptation de la règle R006 qui permet de connaitre l'historique des associations entre ingénieurs et projets.
    Mais je vois que dans votre MCD, il n'y a aucun lien direct entre ingénieur 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.


    Citation Envoyé par isaac_2000 Voir le message
    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'entités et d'associations, et le modèle tabulaire, MLD ou MPD dans lequel les entités et certaines associations deviennent des tables.


    Citation Envoyé par isaac_2000 Voir le message
    Sinon voilà ce que j'ai mis comme MCD, pourriez-vous me donner votre avis SVP ?
    Comme indiqué, il y a au moins une différence entre R006 et le modèle, et il y a aussi la ternaire à mettre pour ce qui concerne l'équipe, peut-être y a-t-il d'autres erreurs, à vérifier une fois que les règles seront bien stabilisées

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

  8. #8
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut
    Merci pour votre retour

    Citation Envoyé par escartefigue Voir le message
    En ce cas, il faut reformuler la règle de gestion R002 qui devient par exemple
    R002 : un ingénieur est affecté à une seule équipe à un instant "t" et peut changer d'équipe à "t+1" et à une équipe sont affectés plusieurs ingénieurs
    Et il faut revoir le MCD pour établir une relation ternaire comme je l'ai fait dans le mien, avec la flèche en direction d'équipe qui symbolise la contrainte d'unicité de l'équipe pour un ingénieur et une date
    Désolé, je me suis trompé, je crois il n'y a pas de notion de "changement" d'équipe, il y a plutôt "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.

    Simultanément : l'ingénieur I1 peut, sur la même période, travailler à la fois sur le projet P1 et le projet P2
    Successivement : l'ingénieur 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 proposée dans mon schéma est une adaptation de la règle R006 qui permet de connaitre l'historique des associations entre ingénieurs et projets.
    Pouvez-vous développer davantage SVP? pourquoi mon MCD ne permet pas à un ingénieur de travailler simultanément sur un projet? i.e. pourquoi ai-je besoin de cette relation ternaire?

    MErci beaucoup de votre aide

  9. #9
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    Je n'ai pas dit que votre MCD ne permettait pas à un ingénieur de travailler simultanément sur plusieurs projets.
    Il le permet, mais ne met pas en relation directement l'ingénieur et le projet, il faut passer par l'entité type [PARTICIPATION]
    Du coup, la règle de gestion R006 n'est pas modélisée.

    Donc soit la R006 ne se justifie pas, auquel cas votre modèle est correct sur ce point.
    Soit la R006 est justifiée (ce qui signifie qu'un ingénieur peut être rattaché à un projet sans passer par une participation) auquel cas il manque une asso entre [INGENIEUR] et [PROJET]. Si on veut connaître 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 vérifier par la maîtrise d'ouvrage si l'on conserve seulement R010 (lien ingénieur/participation), seulement R006 (lien ingénieur/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 justifiées, il faut savoir si des contrôles de cohérence sont à prévoir 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 créer un "cycle" comme expliqué dans l'autre fil de discussion

  10. #10
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut
    Merci,

    en pratique, on définit lex projets, puis les ingénieurs qui vont bosser dessus, ensuite on fait la plannification de ces ingénieurs aux différents 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-ingénieur ou ce que j'ai fait là est suffisant, notamment avec le provlème de cycle que vous avez relevé!

    Je crois on peut créer au début des participations "vierges" pour faire l'affectation des ing aux projet, puis compléter semaine et utilisation plus tard... donc pas besoin de mettre la relation ingénieur-projet.

    qu'en pensez-vous SVP?

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

    Merci beaucoup

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    S'il n'y a pas de lien direct entre département et équipe, alors la règle R020 doit être évacuée du cahier des charges.

  12. #12
    Nouveau membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Février 2022
    Messages
    50
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 24
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : Enseignement

    Informations forums :
    Inscription : Février 2022
    Messages : 50
    Points : 26
    Points
    26
    Par défaut
    Bonjour,

    Merci pour votre message,

    j'ai besoin SVP d'un logiciel-site pour schématiser les spécifications fonctionnelles de l'application à créer.

    Avez-vous une proposition SVP?

    Merci d'avance

  13. #13
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 129
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : Mars 2010
    Messages : 10 129
    Points : 38 542
    Points
    38 542
    Billets dans le blog
    9
    Par défaut
    Les spécifications fonctionnelles sont surtout de la littérature, à ce titre, n'importe quel traitement de texte convient.

Discussions similaires

  1. SQL sur deux tables identiques
    Par roman33 dans le forum Requêtes et SQL.
    Réponses: 6
    Dernier message: 07/06/2009, 20h33
  2. Additionner deux tables identiques
    Par roman33 dans le forum Requêtes et SQL.
    Réponses: 3
    Dernier message: 22/04/2009, 15h02
  3. Requete sur deux table identiques donne des doublons
    Par mimilamite dans le forum Langage SQL
    Réponses: 12
    Dernier message: 20/11/2008, 14h32
  4. Fusionner deux tables identiques
    Par sami_c dans le forum Langage SQL
    Réponses: 7
    Dernier message: 27/08/2008, 10h21
  5. Réponses: 5
    Dernier message: 15/10/2007, 15h49

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo