Discussion :

[Geff's]

Bonjour.

J'ai fais plusieurs exercices demandant de réaliser des MCD, plutôt simple au départ et de plus en plus corsés, et je suis arrivé devant un qui me fait me questionner.

Voilà celui ci :

Pour être honnête, le mien n'y ressemblait pas du tout et, en regardant la solution pour essayer de comprendre, et bien... J'ai toujours des blancs !

Ne prêtez pas attentions aux identifiants, c'est un brouillon du coup je ne les ai pas ajouté.


1. Tout d'abord, j'avais inséré "Ville du bien", "département du bien", etc, dans l'Entité "Immeuble", alors qu'elles sont là sous forme d'entité. Y'a - t -il une raison particulière ?

2. Toujours dans ce registre, pourquoi dans l'exemple précédent "rue ou se situe l'immeuble" n'est pas, elle, sous forme d'entité, comme "quartier", "ville" ... ?

3. Idem pour le type de bien. Est-il en Entité pour faire une recherche par "type de bien" ? (Ce qui répondrait du coup à ma question précédente pour les entité Quartiers, Ville, etc, j'y songe seulement en l'écrivant ^^')

4. Simplement pour la compréhension, quelle "phrasé" dites vous pour les cardinalités ville / département par exemple ? Je comprenais ça comme "Une ou plusieurs villes se situent dans un département / Un département est composé de 1 ou plusieurs ville, mais j'avais apparemment faux puisque on est sur du 1 , 1 / 0, n

Voilà, merci d'avance à celles et ceux qui s'arrêteront pour me donner ces quelques éclaircissements

Cordialement

Geff

[CinePhil]

1. Tout d'abord, j'avais inséré "Ville du bien", "département du bien", etc, dans l'Entité "Immeuble", alors qu'elles sont là sous forme d'entité. Y'a - t -il une raison particulière ?

Répéter le nom de la ville ou du département dans la future table enregistrant les immeubles est la source de plusieurs problèmes potentiels :
1) La même ville peut être écrite de plusieurs manières.
Avec ou sans trait d'union, 'Saint' ou 'St', avec une lettre capitale au début de chaque mot composant le nom ou seulement au premier ou sauf les prépositions...
Par exemple, on peut écrire Saint-Étienne ou Saint Etienne ou St. Etienne... Et quand vous chercherez tous les immeubles de Saint-Étienne, vous ne les aurez pas tous.
Au contraire, avec une table des villes et une clé étrangère référençant cette table dans la table des immeubles, les données sont cohérentes, la ville est enregistrée une seule fois et vous trouverez tous les immeubles de Saint-Étienne sans problème.

2) Une ville étant située dans un seul département, répéter la ville et le département dans la table des immeubles est une redondance de données superflue qui peut, en plus, conduire à des incohérences si on se trompe de département. Si vous savez qu'il y a 54 immeubles enregistrés à Saint-Étienne mais que pour certains vous vous êtes trompé de département, quand vous chercherez tous les immeubles de la Loire, vous constaterez, en comptant les immeubles situés à Saint-Étienne qu'il vous en manque.

3) Ça prend moins de place !
La clé étrangère référençant la ville sera un entier, généralement codé sur 4 octets. Toutes les villes ayant un nom de plus de 4 caractères prendront plus de place dans la table des immeubles. Elle sera plus longue à interroger ; la BDD sera moins performante.
Du fait que la ville est associée à un département, vous n'avez pas besoin de prévoir une colonne pour le département dans la table des immeubles. Une colonne de moins, c'est un gain de place et de temps de traitement.

4) Si le nom de la ville ou du département change, vous devriez le faire partout, dans toutes les tables qui utilisent ces informations.
Avec des tables de référence des villes et des départements, vous ne faites la modification qu'à un seul endroit. L'identifiant ne changeant pas, les clés étrangères non plus.

5) Ça permet d'enregistrer davantage d'informations.
Dans la table des départements, vous pouvez avoir le numéro du département et son nom.
Dans la table des villes, vous pouvez avoir son code INSEE. Dans certains cas, ça peut être utile.

2. Toujours dans ce registre, pourquoi dans l'exemple précédent "rue ou se situe l'immeuble" n'est pas, elle, sous forme d'entité, comme "quartier", "ville" ... ?

Ça dépend de la granularité de l'information dont on a besoin.
Au vu du MCD, il s'agit de modéliser des annonces ou des transactions immobilières. Autant vous pouvez chercher un logement à louer dans tel quartier de telle ville, autant il est rare qu'un acheteur ou un locataire potentiel soit exigeant au point où il demandera une rue spécifique.
Et le référentiel de toutes les rues du pays est plus difficile à gérer que le référentiel des villes.
Dans beaucoup de bases de données, la précision du quartier ne sera pas nécessaire.

3. Idem pour le type de bien. Est-il en Entité pour faire une recherche par "type de bien" ?

Voilà ! Vous commencez à comprendre.
Là aussi, la table de référence est utile pour y stocker d'autres informations relatives aux types, telles qu'un code, des dates de validité du type, des sous-types...

4. Simplement pour la compréhension, quelle "phrasé" dites vous pour les cardinalités ville / département par exemple ? Je comprenais ça comme "Une ou plusieurs villes se situent dans un département / Un département est composé de 1 ou plusieurs ville, mais j'avais apparemment faux puisque on est sur du 1 , 1 / 0, n

À ce sujet, je vous invite à lire mon billet de blog sur les règles de gestion des données.
Dans le cas que vous donnez, la règle est la suivante : Une ville est située dans un seul département et un département peut situer plusieurs villes.

[Geff's]

Bonjour,

tout d'abord merci à vous pour votre temps.

Déjà, c'est parfait pour les explications, ce n'était pas clair pour moi, maintenant oui.

Ensuite, j'ai lu et mis de côté le billet que vous m'aviez linké, c'est par-fait.

J'avais quelques soucis de cardinalités mais avec le guide ("peut", "est xxx", ...) j'ai pu assimiler et corriger d'autres exercices, c'est vraiment un outil de compréhension formidable pour le coup.

Une dernière question, l'entité date, parfois je la place en tant qu'entité alors que c'est un attribut, parfois c'est l'inverse. Y a-t-il aussi un moyen mnémotechnique pour ça ?

Cdt

[CinePhil]

Une dernière question, l'entité date, parfois je la place en tant qu'entité alors que c'est un attribut, parfois c'est l'inverse. Y a-t-il aussi un moyen mnémotechnique pour ça ?

D'une manière générale, une date n'est qu'une date en tant qu'information de base : date de naissance, date de création de modification de mise à jour, date de début d'un projet, date de commande, date de réception d'un courrier...

Là où ça devient intéressant d'avoir une table de dates est l'utilisation d'un calendrier. Par exemple pour gérer des réservations de chambres d'hôtel, de salles de réunion, de véhicules de location... ou bien un planning de travail, de congés, d'astreintes... Ou encore quand on gère des séries statistiques en fonction des dates et qu'on doit représenter les dates qui n'ont pas de données associées.

Pour reprendre mon premier exemple de réservations de chambres d'hôtel, il est nécessaire de savoir à quelles dates les chambres sont disponibles, donc connaître toutes les dates potentielles, si ce sont des jours de week-end, des périodes de fermeture de l'hôtel, des périodes de haute saison où le prix est plus cher...

En réponse à votre question, il n'y a pas vraiment de moyen mnémotechnique, si ce n'est la notion de planning ou de calendrier. Si j'ai besoin de gérer un planning ou un calendrier => entite-type date. Dans le cas contraire : propriétés de type date.

Je vois dans votre MCD qu'il y a une entité-type Date associée aux visites. Il est en effet intéressant que l'agence immobilière gère son planning de visites et tienne compte, pour fixer un rendez-vous à un client, des dates de disponibilité des agents, des jours de fermeture de l'agence, des congés, des jours fériés.

Vous pouvez lire l'article de SQLPro au sujet des notions temporelles. fsmrel vous indiquera peut-être aussi quelque documentation sur les considérations temporelles

[fsmrel]

l'entité date, parfois je la place en tant qu'entité alors que c'est un attribut, parfois c'est l'inverse. Y a-t-il aussi un moyen mnémotechnique pour ça ?

Pour aller dans le sens de CinePhil, la date peut faire l’objet d’une entité-type authentique, quand sémantiquement cela est justifié : planning, calendrier et concepts apparentés. Sinon, comme dit CinePhil « en tant qu'information de base : date de naissance, date de création de modification de mise à jour, date de début d'un projet, date de commande, date de réception d'un courrier », une date n’est qu’un attribut d’une entité-type. Mais, dans le cas de Merise, et selon l’AGL (PowerAMC, DB-MAIN, etc.), on peut être amené à mettre en oeuvre une entité-type DATE pour un motif non plus sémantique, mais purement technique, entité-type qui contrairement à un planning ou un calendrier, ne fera pas l’objet d’une table, l’AGL dégageant la date (sous forme d’attribut) dans la clé de la table issue de l’association à laquelle l’entité-type DATE participe. Voyez ici.

Pour résumer : Une entité-type DATE est authentique quand elle a un sens sémantique, tel qu’un planning ou un calendrier, autrement elle n’est qu’un artifice technique imposé par l’AGL et disparaît au stade MLD. Si par exemple l’AGL est PowerAMC, on est dans ce cas. S’il s’agit de DB-MAIN, cet artifice technique est inutile dès le stade MCD.

[Geff's]

C'est très clair, merci à vous deux.

Je dois faire la partie dictionnaire de donnée / MCD / MPD en solo avant de commencer une formation, et il est vrai que quand on a pas de prof ou de référent à qui poser des questions, on bloque parfois sur des choses "simples" !

Merci en tout cas pour vos lumières !

[CinePhil]

Donc votre discussion est ?

[Geff's]

Bonjour, je me permet de "dérésoudre" la conversation, pour ne pas créer un nouveau topic pour une question sur le même sujet.

Projet2.pdf

Voici un MCD - sans les cardinalités et quelques entité non remplies - et le cachier des charges qui va avec (page 8)

J'ai passé une longue partie de la journée dessus à essayer de comprendre, retirer et ajouter des entités, et je ne sais pas du tout si je suis en train de faire fausse route ou non. Pourriez vous jetez un oeil, mon but n'étant pas tant d'avoir la solution que de comprendre ce que je rate, si c'est le cas. J'étais bien parti et ça me semble de plus en plus "décousu".

Mon association "intervenir", porteuse de donnée, ne m'inspire pas confiance par exemple.

Ou encore ai-je bien fait de créer des entités chef de projet, responsable d'études,... ou aurais-je dû les laisser dans l'entité fonction?

Je dois admettre que Merise est toujours obscure, de mon côté.

Cordialement

Geff

[fsmrel]

Bonsoir Geff’s,

Selon le document auquel vous faites référence, un collaborateur peut changer de fonction dans le temps, mais à une date donnée, il ne peut exercer qu’une seule fonction. Avec PowerAMC vous vous retrouvez dans la situation où vous devez modéliser une entité-type DATE factice pour un motif purement technique et non pas sémantique, avec mise en œuvre obligée d’une association ternaire :

Mais vous devez mettre en place une CIF (contrainte d’intégrité fonctionnelle), pour effectivement garantir qu’à une date donnée, un collaborateur n’exerce qu’une seule fonction. PowerAMC ne permettant pas de représenter les CIF pour des associations ternaires, on doit donc gribouiller à la main pour les symboliser, ce que j’ai fait ici en coloriant la patte connectant FONCTION et EXERCER (option format pour la patte) et en demandant (poliment) à PowerAMC d’ajouter une pointe de flèche.

Ce que permet PowerAMC : éviter la génération d’une table pour l’entité-type factice, en décochant la case qui va bien :

Lors du passage au MLD, il y aura génération d’une table EXERCER de schéma {collabMatricule, collabDateFonction, fonctionId}, et de clé primaire {collabMatricule, collabDateFonction, fonctionId} :

A notre charge d’éjecter l’attribut fonctionId de la clé :

Cliquer sur la table EXERCER, puis : onglet Clés > cliquer sur identifiant1 > onglet Colonnes, sélectionner fonctionId :

Et supprimer cet attribut, pour que la clé primaire soit réduite à {collabMatricule, collabDateFonction} :

[fsmrel]

Ayant survolé votre PDF, je pense que la modélisation de la participation aux projets pourrait prendre une tournure du genre de celle qui suit, mais il faudra qu’avec les collègues CinePhil et escartefigue (qui ont peut-être un point de vue plus pertinent), on relise le PDF de près. En attendant, préparez vos questions, ce que je propose peut vous paraître sibyllin (par exemple l’utilisation (lourde de sens !) de l’identification relative (cardinalité 1,1 mise entre parenthèses)).

Il est tard, donc « à plus » !

[Geff's]

Bonjour,

tout d'abord désolé du temps de réponse, boulot la journée
Il est temps de se replonger dans les cours d'info, j'avais fait des modifs sur le MCD avant de voir la réponse dans la nuit, je le poste avec ce message.

Du coup, pour la première remarque c'est compris, j'avais fais une entité date au départ, mais l'ai retiré en pensant avoir fait une erreur en ne la mettant pas dans une association. Je vais retourner vers cela. Du coup, l'idée de faire une asso porteuse de donnée "date de début / fin" ne fonctionne pas dans ce cas ?
(Par contre il ne faut pas de cardinalité x - 1 / x - n ou X = 1 pour une CIF ?)

Cette histoire de fleches rouge complique les choses, j'associais en pensant que PowerAMC gérerait le reste, du coup si je le lie avec une association de façon normale sur le logiciel, ça va donner quoi (comme sur l'exemple que je joins avec ce poste en liant Colla / date / fonction) ?

Pour l'identification relative, si j'ai bien compris après recherches, ça veut dire que l'entité Etape ne pas pas exister sans l'entité Projet, et va devenir une "composante de sa clé primaire" ? (je ne sais pas ce que signifie cette derniere partie signifie par contre.)
Pour les questions, je voulais déjà savoir si mon tableau avait une construction correcte selon vous, j'essaie de chopper la "logique MCD". J'apprends à faire des MCD et a les transformer avant de coder, et j'ai du mal à me projeter comme vous. Par exemple, pourquoi avoir choisi, du coup, cette fameuse identification relative dans ce cas ?

Autre chose interessante, je me suis beaucoup demandé si Chef de Projet ou Responsable d'études devaient être inséré en tant qu'entités où considéré comme appartenant à "Collaborateur". Je vois que vous avez mis Collaborateur > Dirige > Projet, pourquoi ce choix ?

En vous remerciant pour vos explications, je sais que la place du petit nouveau qui pose trop de questions est peu enviable mais...

[fsmrel]

j'avais fais une entité date au départ, mais l'ai retiré en pensant avoir fait une erreur en ne la mettant pas dans une association

Que se passe-t-il si l’on n’utilise pas d’entité-type DATE et qu’on se contente de la représentation graphique suivante ?

La façon normale d’interpréter cette représentation (je vous renvoie au meilleur ouvrage sur Merise, à savoir celui de D. Nanci (RIP) et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001) :

Le collaborateur collabMatricule exerce la fonction fonctionId à la date exercerDate

Mais, on peut alors se permettre d’instancier cet énoncé (qu’on appelle encore un prédicat) avec les propositions suivantes :

— Au 28/06/2018, le collaborateur Raoul exerce la fonction de développeur

— Au 28/06/2018, le collaborateur Raoul exerce la fonction d’analyste responsable d’application

Autrement dit, l’énoncé n’est pas assez contraignant, puisqu’on peut être pris en flagrant délit vis-à-vis de la règle selon laquelle « Un collaborateur ne peut cumuler plusieurs fonctions en même temps ».

Au stade MCD, on doit impérativement faire apparaître cette règle, or avec PowerAMC (contrairement à DB-MAIN), ça n’est pas possible, sauf à mettre en oeuvre une association ternaire et surcharger manuellement celle-ci, comme je l’ai fait, avec une grosse CIF bien rouge.

Du coup, l'idée de faire une asso porteuse de donnée "date de début / fin" ne fonctionne pas dans ce cas ?

En vertu de ce qui précède : si vous pensez à une association binaire, ça ne fonctionne pas.
En passant, évitez les apocopes, écrivez « association » et non pas « asso ».

il ne faut pas de cardinalité x - 1 / x - n ou X = 1 pour une CIF ?

Pour une CIF binaire, certes, bien qu’il y ait alors redondance de concept : « x,1» impliquant CIF et réciproquement (même si certains puristes (à l’excès) prétendent le contraire). Par contre, pour une CIF ternaire, chaque patte d’association doit être porteuse d’une cardinalité x,N.

Par exemple, le diagramme suivant déroge à cette règle :

Il est à interpréter ainsi (voyez aussi aux pages 133, 134 de l’ouvrage de Nanci et Espinasse) :

(a) Chez son employeur, un collaborateur ne peut pas exercer plus d’une fonction
(b) Chez son employeur, un collaborateur ne peut pas exercer à deux dates différentes.

(En notant que PowerAMC se vautre lamentablement lors du passage au MLD, en confondant 1,1 et 1,N).

Autrement dit, conceptuellement, le diagramme de la figure 8 est équivalent à celui qui suit, pas franchement celui qu’on attend :

Cette histoire de fleches rouge complique les choses, j'associais en pensant que PowerAMC gérerait le reste, du coup si je le lie avec une association de façon normale sur le logiciel, ça va donner quoi (comme sur l'exemple que je joins avec ce poste en liant Colla / date / fonction) ?

La flèche rouge peut vous perturber, mais un MCD est un diagramme, donc on dessine, et quand PowerAMC ne propose pas ce dont on a besoin, comme je l’ai déjà dit, on fait avec les moyens du bord, on utilise des mickeys pour attirer l’attention. Je vous renvoie à l’ouvrage de Nanci et Espinasse, vous y trouverez des tombereaux d’exemples de CIF et autres contraintes.

Dans votre MCD, vous avez défini une association ternaire selon laquelle un collaborateur peut exercer plus d’une fonction à la même date.
PowerAMC générera consciencieusement le MLD suivant (vérifiez par vous-même !) :

Pour que soit respectée la règle de gestion des données selon laquelle un collaborateur ne peut pas exercer simultanément plus d’une fonction, vous devrez donc procéder comme je vous l’ai indiqué dans mon message précédent (cf. figures 1 à 5).

Alternative il y a : transformer l’association EXERCER en entité-type et l’identifier relativement à COLLABORATEUR et COLLAB_DATE_FONCTION :

En procédant ainsi, l’identifiant de l’entité-type EXERCER est implicitement composé des identifiants de COLLABORATEUR et de COLLAB_DATE_FONCTION (héritage). A condition de demander à PowerAMC de ne pas générer de table pour COLLAB_DATE_FONCTION (cf. figure 2 de mon précédent message), cette fois-ci le MLD produit est exactement celui de la figure 5, sans qu’on ait donc à le retoucher.

je sais que la place du petit nouveau qui pose trop de questions est peu enviable mais...

... mais quand il a enfin la réponse à ses questions, qu’il le fasse bien savoir en votant...

[fsmrel]

Pour l'identification relative, si j'ai bien compris après recherches, ça veut dire que l'entité Etape ne peut pas exister sans l'entité Projet

De fait, on peut considérer qu’une étape est à un projet ce qu’est une ligne de commande à une commande : une étape n’est pas autonome, elle n’a de sens que par rapport à un projet.

et va devenir une "composante de sa clé primaire" ?

Tout comme un projet, une étape doit être identifiée (attention, dans un MCD on parle d’identifiant, ça n’est qu’au stade du MLD qu’on parle de clé). L’identifiant d’une étape est celui de son projet, plus un attribut permettant de distinguer chaque étape au sein d’un projet, tout comme on doit distinguer les lignes d’une commande à l’aide d’un numéro de ligne de commande.

Dans le tableau ci-dessous, pour les projets P1 d’identifiant projetId = p1 et P2 d’identifiant projetId = p2 :

 
PROJET {projetId    projetNom    ...}
        p1          Projet P1    ...
        p2          Projet P2    ...

On a par exemple les étapes, identifiées par la paire {projetId, etapeId} :

ETAPE  {projetId    etapeId     ...}
        p1          1           ...
        p1          2           ...
        p1          3           ...
        p2          1           ...
        p2          2           ...

Chaque étape a son identifiant permettant de la sélectionner (par exemple au moment de la participation des collaborateurs aux étapes des projets) :

<p1, 1>
<p1, 2>
<p1, 3>
<p2, 1>
<p2, 2>

Identifier les étapes veut dire que pour un projet donné, la valeur de l’identifiant de deux étapes ne peut pas être la même : interdiction d’avoir par exemple plus d’une fois la valeur <p1, 1>.
Bien entendu, on retrouvera le même mécanisme au stade du MLD où l’on ne parle plus d’identifiant mais de clé (primaire).

je voulais déjà savoir si mon tableau avait une construction correcte

Je suppose qu’il s’agit du MCD. Reconnaissez qu’il est copieux et donc compliqué : on avancera au fur et à mesure des parties qui le composent. C’est ainsi qu’on procède dans le métier : on traite du sujet partie par partie, mais pas en bloc. Imaginez que vous soyez face à un MCD de plus de mille entités-types... Une bonne approche est celle de l’urbanisation : voyez par exemple la progression d’aras-vbo, à partir d’ici.

pourquoi avoir choisi, du coup, cette fameuse identification relative dans ce cas ?

Sémantiquement parlant, Ligne_de_commande n’est pas autonome, c’est une entité-type « faible » (weak entity-type) par rapport à l’entité-type Commande, en fait une propriété multivaluée de Commande ; de même Engagement_sur_ligne_de_commande est une entité-type faible par rapport à Ligne_de_commande, etc. Quand on connaît bien Merise, on utilise l’identification relative pour exprimer la sémantique relative à la « faiblesse » de certaines entités-types. En outre, procéder ainsi permet souvent de résoudre les problèmes du genre contrainte de chemin, sujet dont on aura peut-être à parler, et qui plus est, arrivé au stade SQL, on gagnera en performance pour avoir procédé ainsi, mais il s’agit là d’un chapitre qui concerne le DBA (voyez par exemple ici)...

je me suis beaucoup demandé si Chef de Projet ou Responsable d'études devaient être inséré en tant qu'entités où considéré comme appartenant à "Collaborateur". Je vois que vous avez mis Collaborateur > Dirige > Projet, pourquoi ce choix ?

Il est probable que vous confondez « être » et « avoir ». Un chef de projet n’appartient pas à COLLABORATEUR, un chef de projet est un collaborateur : il a un nom, un matricule, un nom, un prénom, une adresse, etc. comme tous les collaborateur. Alors pourquoi mettre en oeuvre une entité-type CHEF_DE_PROJET ? Il faudra que cette entité-type soit dotée de tous les attributs de COLLABORATEUR... Vous me direz qu’on pourrait spécialiser COLLABORATEUR, mais cela suppose qu’un chef de projets l’est a priori à vie dans l’entreprise. Je vous renvoie à nouveau à l’ouvrage de Nanci et Espinasse.

[Geff's]

Bonjour,

En faisant des recherches sur les différents post du forum, j'avais commencez l'ouvrage "Parlez vous Merise", mais j'ajoute celui de Nanci et Espinasse.

Pour ce qui est de l'entité date, c'est compris. Pour le traitement des associations ternaires via PowerAMC aussi. Idem pour l'indentification relative je pense.

Une bonne approche est celle de l’urbanisation : voyez par exemple la progression d’aras-vbo, à partir d’ici.

Il est vrai que c'est assez brouillon comparé à celui que vous envoyez, je vais essayer de corriger ça en l'organisant par partie.

[escartefigue]

Bonjour,
Je n'ai pas participé au sujet, il est suivi à la fois par Cinephil et FSMRel, autant dire qu'il est entre de bonnes mains

Toutefois, en parcourant le document joint je suis tombé sur cet extrait contre lequel je m'insurge :
Pièce jointe 393905

Monsieur s'abrège "M." et Mademoiselle (qui n'est plus utilisé dans les formulaires administratifs) s'abrège "Mlle".
De plus, il faut penser aux pluriels : mesdemoiselles s'abrège Mlles soit 5 caractères !

Il existe des abréviations officielles, faciles à trouver dans à peu près tous les dictionnaires papier ou en quelques clics sur la toile, et on trouve encore de nos jours des spécifications avec ce genre d'abréviations hasardeuses !
Par exemple ici : http://www.les-abreviations.com/civilite.html

Ce genre de tables est utilisé dans beaucoup d'applications, mal les concevoir ou mal les alimenter a donc des conséquences importantes.
A (faire) corriger !

[fsmrel]

Salve Capitaine,


Dans le même paragraphe, à savoir 3.7, on lit ceci :

"Le sexe M correspond obligatoirement au code civil M."

L'anglicisme "MR" a l'air de valoir pour la cuisine interne, au même titre que "F" (type de projet = "forfait"), mais néanmoins, comme dirait al1_24 : "saimal "...

[escartefigue]

Effectivement et ce paragraphe est particulièrement gratiné : on y apprend d'une part que tous les identifiants sont uniques, c'est sympa pour la gestion des FK et d'autre part que "M.", "Mme" et "Mlle" sont ... des codes civils !

[fsmrel]

Dorénavant on devra modéliser avec le Dalloz sous la main...

[fsmrel]

Je dois admettre que Merise est toujours obscure, de mon côté

Vous avez proposé un MCD sans fournir les règles de gestion des données, or la construction du MCD est la conséquence de ces règles : comme dit CinePhil, « règle de gestion bien écrite => modélisation des données facile ». Un corollaire est évidemment : règle de gestion approximative => modélisation des données délicate et douteuse...

Commençons à énumérer. Au paragraphe 3.2 de votre cahier des charges, on lit (je prends l’initiative de numéroter les règles) :

RG01 - Un collaborateur n’interviendra jamais sur 2 projets simultanément

RG02 - Un collaborateur peut intervenir sur un projet avec une fonction n’étant pas encore la sienne

RG03 - Un collaborateur ne peut cumuler plusieurs fonctions en même temps

Il est évident que ces règles doivent figurer dans le référentiel des règles (le thésaurus, pour le moment bien vide...)

Mais quand les règles sont ambiguës ou entrent en collision, gare ! Je n’ai jamais connu de projet en entreprise où le thésaurus ne fut pas à corriger et compléter.

Par exemple, au paragraphe 3.3 :

« Le responsable des études a besoin de l’historique des différentes interventions des collaborateurs par rapport à leur(s) fonction(s) sur les différentes étapes des projets. »

On en déduit qu’il doit exister une association entre COLLABORATEUR, ETAPE et FONCTION. Toutefois, la règle ne précise pas si un collaborateur peut exercer plusieurs fonctions au cours d’une étape donnée. On pourrait invoquer la règle RG03 pour conclure qu’un collaborateur ne peut exercer qu’ne seule fonction au cours d’une étape, ce à quoi on pourrait opposer : à la lecture de la règle RG03, que signifie "en même temps" ? Le même jour ? Pendant une certaine période (le temps que le fût du canon se refroidisse) ? Le temps d’une étape ? Qu’est-ce qui interdit qu’un collaborateur change de fonction au cours d’une étape ? Par conséquent, du point de vue de la modélisation, dans la figure 6, devrait-on conserver la pointe de la flèche rouge connectant PARTICIPER et FONCTION ?

2e exemple :

Intuitivement (ou sous l’influence de la règle RG01), on a le réflexe d’établir une association, nommons-la AFFECTER entre COLLABORATEUR et PROJET, parce que des collaborateurs sont affectés aux projets :

Et l’on complétera le diagramme de la figure 6 en conséquence.

D’un autre côté, nommons RG04 la règle suivante, reprise elle aussi du paragraphe 3.3 :

RG04 - « Les collaborateurs sont associés par le chef de projet au fur et à mesure de leurs interventions sur les étapes du projet ».

L’association INTERVENIR de la figure 6 est impliquée par cette règle. Mais alors, on peut se poser la question de la nécessité de la mise en oeuvre de l’association AFFECTER. En effet, si le chef de projet associe chaque collaborateur à une étape d’un projet, on sait automatiquement à quel projet un collaborateur est affecté. Un doute plane cependant concernant la date d’affectation (cf. entité-type COLLAB_DATE_PROJET de la figure 12).

De même, la règle suivante peut inciter à conserver l’association AFFECTER :

RG05 - « Les collaborateurs peuvent être amenés à titre d’essai à intervenir sur un projet avec une fonction n’étant pas encore la leur »

Règle qui fait comprendre qu’on ne peut a priori inférer ce genre d’affectation à partir de l’association INTERVENIR, servant pour les collaborateurs vraiment opérationnels, et non pas pour les collaborateurs en période d’essai.

L’alternative est donc la suivante : conserver ou supprimer l’association AFFECTER. S’il faut la conserver, on peut envisager qu’elle ne concerne après tout que les collaborateurs en période d’essai. Sinon, si elle concerne aussi les opérationnels, alors il y a redondance des données entre INTERVENIR et AFFECTER et il faudra mettre en oeuvre ne contrainte d’inclusion (évidemment rendue opérationnelle au stade SQL !) selon laquelle chaque paire <collabMatricule, projetId> appartenant à INTERVENIR est valide seulement si cette paire appartient aussi à AFFECTER.

Il y a encore pas mal de points du dossier AFPA à « commenter », le Capitaine ne me démentira certainement pas...

[Geff's]

Ce genre de tables est utilisé dans beaucoup d'applications, mal les concevoir ou mal les alimenter a donc des conséquences importantes.
A (faire) corriger !

C'est remonté !

règle de gestion approximative => modélisation des données délicate et douteuse...

C'était, je pense, un de mes problèmes. Je vais refaire tout ça proprement. Idem pour le dictionnaire de données, je le faisais avant au départ, puis au fil des exercices je modélisais directement et récupérais le dinctionnaire de donnée à partir du MCD établi. Mais maintenant que je tombe sur quelque chose de plus "corsé"... Je crois que je saute des étapes.

« Les collaborateurs sont associés par le chef de projet au fur et à mesure de leurs interventions sur les étapes du projet »

"Chef de projet" appartient toujours à collaborateur dans cette règle, et n'est pas une entité ? Je suis du coup ce qui est dit plus haut "Un chef de projet n’appartient pas à COLLABORATEUR, un chef de projet est un collaborateu", mais il est vrai qu'instinctivement, en lisant cette regle de gestion, j'ai fais l'erreur de penser ça tel que trois entités qui devaient être associées (chef de projet > associe collaborateur > etape du projet).

(C'est moi où démarrer par Merise n'est pas des plus simple !?)