Discussion :

[Hildeguard]

Bonjour,

Dans le cadre de mon travail, je cherche à monter un projet consistant à répertorier des pièces, classées par type de famille, de manière à pouvoir en créer de nouvelles (incrémentation de numéro), en réviser, et faire des recherches selon un ensemble de d'attributs.

J'avais presque réussi à mener à bien ce projet grâce à Excel (j'étais en phase de débug), mais je me suis rendu compte, que ce soft n'est pas vraiment approprié pour ce que je souhaite faire, même si ça restait possible.

Depuis, on nous a installé Access 2007, et un collègue qui a fait des études dans ce domaine, m'a confirmé que ce serait vraiment bien mieux, et simple de le faire avec ça, plutôt qu'Excel.

Malheureusement, ne connaissant pas Access, et encore moins les méthodes type Merise, ou plus simplement les BDD, ce collègue a commencé à m'apprendre quelques bases. Je fais donc des recherches en parallèle, et je suis tombé sur des tutoriaux très interessant sur ce forum.

Je suis actuellement en train d'essayer de concevoir le MCD de mon application avec l'aide de mon collègue. Seulement je viens d'apprendre qu'il vient de se faire hostipaliser pour une durée indéterminée..

C'est pourquoi j'aurais besoin de votre aide, dans un premier temps, pour réussir à terminer mon MCD ci dessous:



Entre autre, je me heurte à 3 problèmes:

- de mon point de vue extérieur, je devrais avoir une notion d'héritage d'attributs sur les entités "Pièces", "Familles simples" et "Familles complexes" qui font références aux entités "Attributs communs" et "Attributs complémentaires". Cependant; sur les cours que j'ai trouvés, ça ne semble pas tout à faire convenir, ou du moins, je n'ai pas du bien comprendre. Comment traiteriez vous ce cas?

- je devrais avoir des attributs pour l'entité "Attributs complémentaires" que je ne pourrai pas déterminer à l'avance. Comment peut-on gérer cela dans un tel schéma? Par exemple, pour une famille de pièces je pourrais avoir comme attributs complémentaires:

Connexion d'entrée
Connexion de sortie
Matière

Pour une autre j'aurais:

Connexion du thermowell
Connxion de l'instrument
Diamètre de la sonde
Longueur de la sonde

Etc

- Mon collègue avait du mal avec ma notion de famille simple ou complexe et se demandait si je devrais, ou non, n'avoir qu'une seule entité "Famille". La raison qui m'a poussé à scinder en 2 parties distinctes les familles, c'est de manière à pouvoir filtrer par "sous familles" lorsque cela s'avère nécessaire (voir ci-dessous). En fait, je vois surtout le résultat final que je souhaite avoir (en tant qu'utilisateur). Comme j'avais déjà créé l'interface en Excel/ VBA, et que je cherche à obtenir la même chose en utilisant Acces, il se peut que ça erronne mon raissonnement.

Ex de famille simple:

chassis mécano-soudés

ex de famille complexe:

Raccords

-> Sous familles:

Vissés
Emboité-soudés
Soudés bout à bout

Lors d'une famille complexe, les sous familles n'auront pas toutes les même attributs complémentaires.

Image de l'interface principale que j'avais créés en Excel / VBA:
(filtré sur une famille de type complexe ici)



Image de l'interface de création de famille (vu qu'on ne peut pas déterminer à l'avance certain attributs de l'entité "Attributs complémentaires", cette interface permettait de créer et définir les attributs de chaque familles)


Merci d'avance pour votre aide !

Source: http://cyril-gruau.developpez.com/merise/

[CinePhil]

Bonjour et bienvenue dans le monde de la modélisation.

Pour commencer, quelques petites bonnes habitudes à prendre...

1) Nomme tes entités avec des noms communs au singulier
Dans ton MCD, ça donnerait plutôt Dessinateur, Plan, Piece...

2) Prend l'habitude, dès le MCD, de poser dans tes entités des identifiants anonymes, propres à la BDD qui deviendront par la suite des clés primaires de type entier auto-incrémenté.
Exemple dans l'entité Dessinateur, ajoute par exemple un attribut 'dsn_id'.

3) Interdis-toi de nommer tes attributs avec des mots du langage SQL
Exemple : Date
Un bon moyen d'y parvenir est de préfixer systématiquement les attributs avec un acronyme pour la table à laquelle ils appartiennent. J'ai donné dsn_id au point précédent, tu peux avoir par exemple dec_date.

4) Au fait, c'est quoi DEC ? Évite les noms dont on a du mal à comprendre ce qu'ils représentent.

5) Dans un MCD, on ne cite que les attributs qui sont propres à l'entité ou portées par l'association mais on n'y fait pas figurer les futures clés étrangères.
Ainsi, plan et dessinateur ne doivent pas figurer dans l'entité DEC.

6) Il manque les cardinalités dans ton MCD !
Par exemple, j'imagine que tu as la règle de gestion suivante :
"Un plan est créé par un seul dessinateur et un dessinateur peut créer plusieurs plans."

De cette règle de gestion, on peut déduire les cardinalités du MCD suivant :
Dessinateur -0,n----Créer----1,1- Plan

7) Utilise un logiciel de modélisation
Il existe par exemple le logiciel open source "Open Modelsphere" qui est assez facile à prendre en main.

Ça nous aiderait à y voir plus clair sur ton histoire d'attributs communs et d'attributs complémentaires, que tu as pour le moment mis à côté du schéma.

8) Les attributs info X m'inquiètent un peu. Si ils représentent de futurs attributs dont tu sais qu'ils existeront mais dont tu ne sais pas encore comment les nommer, ça va. Sinon, externalise ces infos en nombre variable car il faut éviter de devoir modifier le modèles de données après mise en production.

9) Une pièce et une famille, ce n'est pas la même chose.
Je dirais qu'une pièce peut faire partie d'une famille et qu'une famille peut comprendre plusieurs pièces mais il n'y a pas identité sémantique entre les deux.

10) Tu peux choisir deux options pour tes attributs en nombre variable.
a) Classer les pièces par famille et dire qu'à chaque famille correspond certaines caractéristiques.
Piece -1,1----Appartenir----0,n- Famille -1,n----Correspondre----0,n- Caractéristique

b) Faire un ou plusieurs niveaux d'héritage en spécialisant petit à petit les attributs.
Piece -0,1----Etre----(1,1)- Piece_famille_A -0,1----Etre----(1,1)- piece_sous_famille_A_1

Exemple :
Piece -0,1----Etre----(1,1)- Raccord -0,1----Etre----(1,1)- Raccord_vissé

[Hildeguard]

Tout d'abord, bonjour et merci pour ta réponse CinePhil !

Je vais tacher de te répondre dans l'ordre, du moins, la ou je le peux.

1) Je les avais initialement mis au singulier, mais sur le document que je suis (http://cyril-gruau.developpez.com/merise/) il est mentionné de les mettre au pluriel. Mais peu importe, si la convention veut que ce soit au singulier, ce sera au singulier

2) Si je comprends bien, tu me suggères de nommer chaque entité par cet identifiant anonyme (qui me servira plus tard). Mais je suppose que je dois conserver le nom de base. Par exemple: Entité "dsn_id (Dessinateur)" ?

3) C'est clair pour moi, j'en prends bonne note.

4) DEC est un acronyme interne. Je pourrais le définir comme étant une référence de révision. Par exemple, pour un plan que je passerai en indice de révision A, je devrai ouvrir notre fichier excel dec.xls pour y ajouter une ligne avec tous les attributs listés dans l'entité "DEC", ce qui me donnera un numéro de type 12635. Le prochain sera 12636 etc.

Comment le nommer autrement.. pour le moment je ne le sais pas. Néanmoins, il me semble que dans les process du service de la boite ou je travaille, on mentionne bien ce terme, propre à nous. Mais effectivement pour une personne extérieure à mon entreprise, ça n'est pas compréhensible.

Dois-je tout de même le renommer?

5) J'avoue ne pas forcément bien comprendre le pourquoi de la chose, ou du moins, comment cela fonctionnera ensuite, sachant que j'aurai besoin de ces informations. Si tu peux m'en dire un peu plus la dessus, ça m'interesse beaucoup. Cela dit, peut être que ça coulera de source par la suite.

6) Alors, si je ne me trompe pas, lorsque tu parles de cardinalités, tu fais références aux liaisons? Dans ce cas, je ne les ai volontairement pas encore traitées parceque je ne suis pas sur de mes entités / associations.

Par contre merci beaucoup pour ton exemple qui me parait assez clair concernant les cardinalités. Ce que je retiens, c'est de mettre sous forme de phrase chaque entité / association de manière à cerner plus facilement ces liaisons.

7) Malheureusement, sur mon lieu de travail, je ne peux pas installer / utiliser de logiciel à cause des règles du groupe auquel mon entreprise appartien. Je devrai continuer de le faire sous Word.

Alors oui j'ai mis de coté les attributs communs et complémentaires car je n'ai pas la place de les mettre dans leur entité respective.
Les cadres sur fond blanc réprésentent des attributs (attributs au sens de la méthode EA). Le cadre blanc "Attributs communs" sont bien les attributs de l'entité "Attributs communs", et le cadre blanc "Attributs complémentaires" contien bien les attributs de l'entité "Attributs complémentaires".

Est ce un peu plus clair à ce niveau?
J'essaierai tout de même de le refaire mieux.

8) Les attributs info resteront nommés tel quel. Ils nous serviront à ajouter des informations complémentaires sur une pièce comme "obsolète", "ne pas utiliser", "à monter avec la pièce x" etc.

En gros, je me garde 4 champs de texte que l'utilisateur pourra modifier à sa guise.

Par contre, je crois que ta crainte sera justifiée pour les attributs complémentaires, si je t'ai bien compris. Car lors de l'execution de l'interface/userform, nous devrons pouvoir ajouter une nouvelle famille et la définir. Ce qui sous entend que de nouveaux champs seront créés "à chaud".

C'était d'ailleurs la, ou j'avais eu du mal à m'en sortir, car toute l'interface doit être créé dynamiquement. Enfin, la je crois que je m'égare un peu.

9) Je ne sais pas ce qu'est une identité sémantique. (mais je vais rechercher) Pour le reste je suis à peu près d'accord avec toi, ça se joue seulement sur des détails:

Une pièce doit faire partie d'une famille dans mon cas. Petite précision: elle ne peut pas appartenir à plusieurs famille differentes.

Sinon, oui, une famille devrait comprendre plusieurs pièces.

10) Je ne suis pas sur de tout avoir compris, mais ce que je souhaite avoir, c'est ce que tu dis ici:

"Classer les pièces par famille et dire qu'à chaque famille correspond certaines caractéristiques"

C'est pour cela que je parle d'héritage. Puisque, la pièce x appartien à la famille x, elle devra avoir les même caractéristiques (attributs)


Si je ne suis pas clair, sur certain point, n'hésite pas à me le dire et je tacherai de mieux m'expliquer, et de donner des exemples concrets. Je sais que dans mon cas, j'ai du mal, lorsque tout est abstrait.

[CinePhil]

1) Je les avais initialement mis au singulier, mais sur le document que je suis (http://cyril-gruau.developpez.com/merise/) il est mentionné de les mettre au pluriel. Mais peu importe, si la convention veut que ce soit au singulier, ce sera au singulier

Les avis sont partagés... Avant, je nommais aussi au pluriel mais je me suis rangé à l'avis que le singulier est meilleur. Dans les règles de gestion, on se pose la question relativement à une instance de l'entité :
"Un dessinateur peut créer plusieurs plans et un plan est créé par un seul dessinateur."

2) Si je comprends bien, tu me suggères de nommer chaque entité par cet identifiant anonyme (qui me servira plus tard). Mais je suppose que je dois conserver le nom de base. Par exemple: Entité "dsn_id (Dessinateur)" ?

Non ! L'entité s'appelle "Dessinateur" mais l'attribut qui lui sert d'identifiant peut par exemple s'appeler "dsn_id". Et dans un MCD, il faut préciser quel(s) attribut(s) participe(nt) à l'identification de chaque instance de l'entité.

4) DEC est un acronyme interne. Je pourrais le définir comme étant une référence de révision. Par exemple, pour un plan que je passerai en indice de révision A, je devrai ouvrir notre fichier excel dec.xls pour y ajouter une ligne avec tous les attributs listés dans l'entité "DEC", ce qui me donnera un numéro de type 12635. Le prochain sera 12636 etc.

"Revision" serait mieux en effet !

5) J'avoue ne pas forcément bien comprendre le pourquoi de la chose, ou du moins, comment cela fonctionnera ensuite, sachant que j'aurai besoin de ces informations. Si tu peux m'en dire un peu plus la dessus, ça m'interesse beaucoup. Cela dit, peut être que ça coulera de source par la suite.

Parce que c'est comme ça conventionnellement !
Regarde le cours de modélisation Merise de SQLPro ou un autre et tu verras toujours la même chose : pas de clé étrangère dans un MCD ! Elles n'apparaissent qu'au moment où tu déclines le MCD en MLD puis surtout en MPD.

6) Alors, si je ne me trompe pas, lorsque tu parles de cardinalités, tu fais références aux liaisons?

Les cardinalités, ce sont les chiffres placés sur ou à côté des branches des associations.

7) Malheureusement, sur mon lieu de travail, je ne peux pas installer / utiliser de logiciel à cause des règles du groupe auquel mon entreprise appartien. Je devrai continuer de le faire sous Word.

Fais-le chez toi si tu as un ordi !
Word, ce n'est vraiment pas l'outil adéquat pour faire un MCD. Autant le faire à la main sur une feuille de papier. Si on te demande de faire ce boulot, qu'on te permette d'utiliser les moyens qu'il faut, sans aller forcément jusqu'à demander l'achat d'un logiciel de modélisation professionnel tel que Power AMC.

Alors oui j'ai mis de coté les attributs communs et complémentaires car je n'ai pas la place de les mettre dans leur entité respective.

Avec un logiciel de modélisation, tu pourrais !

Les cadres sur fond blanc réprésentent des attributs (attributs au sens de la méthode EA). Le cadre blanc "Attributs communs" sont bien les attributs de l'entité "Attributs communs", et le cadre blanc "Attributs complémentaires" contien bien les attributs de l'entité "Attributs complémentaires".

Est ce un peu plus clair à ce niveau?
J'essaierai tout de même de le refaire mieux.

OK mais je crains que tu fasses fausse route avec ce schéma. Prends en compte ce que j'ai dit à partir du point 8.

8) Les attributs info resteront nommés tel quel. Ils nous serviront à ajouter des informations complémentaires sur une pièce comme "obsolète", "ne pas utiliser", "à monter avec la pièce x" etc.

En gros, je me garde 4 champs de texte que l'utilisateur pourra modifier à sa guise.

C'est une mauvaise manière de faire !
D'abord parce qu'un jour tu risques d'avoir besoin de 5 infos, puis 6... et à chaque fois il faudra modifier ton modèle et les programmes qui l'utilisent.
Ensuite parce que ça ne facilite pas du tout la recherche car les infos peuvent être entrées dans n'importe quel ordre et de n'importe quelle manière et que si tu veux un jour extraire tout ce qui est par exemple "obsolète", il te faudra chercher sur 4 colonne au lieu d'une.
À la limite, il vaut mieux une seule colonne qui sera de type TEXT d

Par contre, je crois que ta crainte sera justifiée pour les attributs complémentaires, si je t'ai bien compris. Car lors de l'execution de l'interface/userform, nous devrons pouvoir ajouter une nouvelle famille et la définir. Ce qui sous entend que de nouveaux champs seront créés "à chaud".

C'était d'ailleurs la, ou j'avais eu du mal à m'en sortir, car toute l'interface doit être créé dynamiquement. Enfin, la je crois que je m'égare un peu.

9) Je ne sais pas ce qu'est une identité sémantique. (mais je vais rechercher) Pour le reste je suis à peu près d'accord avec toi, ça se joue seulement sur des détails:

Une pièce doit faire partie d'une famille dans mon cas. Petite précision: elle ne peut pas appartenir à plusieurs famille differentes.

Sinon, oui, une famille devrait comprendre plusieurs pièces.

10) Je ne suis pas sur de tout avoir compris, mais ce que je souhaite avoir, c'est ce que tu dis ici:

"Classer les pièces par famille et dire qu'à chaque famille correspond certaines caractéristiques"

C'est pour cela que je parle d'héritage. Puisque, la pièce x appartien à la famille x, elle devra avoir les même caractéristiques (attributs)


Si je ne suis pas clair, sur certain point, n'hésite pas à me le dire et je tacherai de mieux m'expliquer, et de donner des exemples concrets. Je sais que dans mon cas, j'ai du mal, lorsque tout est abstrait.[/QUOTE]

[CinePhil]

1) Je les avais initialement mis au singulier, mais sur le document que je suis (http://cyril-gruau.developpez.com/merise/) il est mentionné de les mettre au pluriel. Mais peu importe, si la convention veut que ce soit au singulier, ce sera au singulier

Les avis sont partagés... Avant, je nommais aussi au pluriel mais je me suis rangé à l'avis que le singulier est meilleur. Dans les règles de gestion, on se pose la question relativement à une instance de l'entité :
"Un dessinateur peut créer plusieurs plans et un plan est créé par un seul dessinateur."

2) Si je comprends bien, tu me suggères de nommer chaque entité par cet identifiant anonyme (qui me servira plus tard). Mais je suppose que je dois conserver le nom de base. Par exemple: Entité "dsn_id (Dessinateur)" ?

Non ! L'entité s'appelle "Dessinateur" mais l'attribut qui lui sert d'identifiant peut par exemple s'appeler "dsn_id". Et dans un MCD, il faut préciser quel(s) attribut(s) participe(nt) à l'identification de chaque instance de l'entité.

4) DEC est un acronyme interne. Je pourrais le définir comme étant une référence de révision. Par exemple, pour un plan que je passerai en indice de révision A, je devrai ouvrir notre fichier excel dec.xls pour y ajouter une ligne avec tous les attributs listés dans l'entité "DEC", ce qui me donnera un numéro de type 12635. Le prochain sera 12636 etc.

"Revision" serait mieux en effet !

5) J'avoue ne pas forcément bien comprendre le pourquoi de la chose, ou du moins, comment cela fonctionnera ensuite, sachant que j'aurai besoin de ces informations. Si tu peux m'en dire un peu plus la dessus, ça m'interesse beaucoup. Cela dit, peut être que ça coulera de source par la suite.

Parce que c'est comme ça conventionnellement !
Regarde le cours de modélisation Merise de SQLPro ou un autre et tu verras toujours la même chose : pas de clé étrangère dans un MCD ! Elles n'apparaissent qu'au moment où tu déclines le MCD en MLD puis surtout en MPD.

6) Alors, si je ne me trompe pas, lorsque tu parles de cardinalités, tu fais références aux liaisons?

Les cardinalités, ce sont les chiffres placés sur ou à côté des branches des associations.

7) Malheureusement, sur mon lieu de travail, je ne peux pas installer / utiliser de logiciel à cause des règles du groupe auquel mon entreprise appartien. Je devrai continuer de le faire sous Word.

Fais-le chez toi si tu as un ordi !
Word, ce n'est vraiment pas l'outil adéquat pour faire un MCD. Autant le faire à la main sur une feuille de papier. Si on te demande de faire ce boulot, qu'on te permette d'utiliser les moyens qu'il faut, sans aller forcément jusqu'à demander l'achat d'un logiciel de modélisation professionnel tel que Power AMC.

Alors oui j'ai mis de coté les attributs communs et complémentaires car je n'ai pas la place de les mettre dans leur entité respective.

Avec un logiciel de modélisation, tu pourrais !

Les cadres sur fond blanc réprésentent des attributs (attributs au sens de la méthode EA). Le cadre blanc "Attributs communs" sont bien les attributs de l'entité "Attributs communs", et le cadre blanc "Attributs complémentaires" contien bien les attributs de l'entité "Attributs complémentaires".

Est ce un peu plus clair à ce niveau?
J'essaierai tout de même de le refaire mieux.

OK mais je crains que tu fasses fausse route avec ce schéma. Prends en compte ce que j'ai dit à partir du point 8.

8) Les attributs info resteront nommés tel quel. Ils nous serviront à ajouter des informations complémentaires sur une pièce comme "obsolète", "ne pas utiliser", "à monter avec la pièce x" etc.

En gros, je me garde 4 champs de texte que l'utilisateur pourra modifier à sa guise.

C'est une mauvaise manière de faire !
D'abord parce qu'un jour tu risques d'avoir besoin de 5 infos, puis 6... et à chaque fois il faudra modifier ton modèle et les programmes qui l'utilisent.
Ensuite parce que ça ne facilite pas du tout la recherche car les infos peuvent être entrées dans n'importe quel ordre et de n'importe quelle manière et que si tu veux un jour extraire tout ce qui est par exemple "obsolète", il te faudra chercher sur 4 colonne au lieu d'une.
À la limite, il vaut mieux une seule colonne qui sera de type TEXT dans la table (MEMO je crois chez Access) et sur laquelle tu peux faire toutes les recherches que tu veux avec LIKE '%ce que tu recherches%'.

Par contre, je crois que ta crainte sera justifiée pour les attributs complémentaires, si je t'ai bien compris. Car lors de l'execution de l'interface/userform, nous devrons pouvoir ajouter une nouvelle famille et la définir. Ce qui sous entend que de nouveaux champs seront créés "à chaud".

Tu commences à comprendre le principe on dirait...

9) Je ne sais pas ce qu'est une identité sémantique. (mais je vais rechercher) Pour le reste je suis à peu près d'accord avec toi, ça se joue seulement sur des détails:

Une pièce doit faire partie d'une famille dans mon cas. Petite précision: elle ne peut pas appartenir à plusieurs famille differentes.
Sinon, oui, une famille devrait comprendre plusieurs pièces.

Donc la règle de gestion est :
Une pièce fait partie d'une seule famille et une famille peut accueillir plusieurs pièces.

10) Je ne suis pas sur de tout avoir compris, mais ce que je souhaite avoir, c'est ce que tu dis ici:

"Classer les pièces par famille et dire qu'à chaque famille correspond certaines caractéristiques"

C'est pour cela que je parle d'héritage. Puisque, la pièce x appartien à la famille x, elle devra avoir les même caractéristiques (attributs)

Ce sont deux choses différentes... Comme j'ai écrit, tu as deux façon de modéliser cela.

Je vais prendre un autre exemple qui est celui que je mets en oeuvre actuellement...

Dans mes données, j'ai des personnes. Certaines sont des utilisateurs. Certains des utilisateurs sont des étudiants. Tous les utilisateurs sont d'un certain type, chaque type d'utilisateur a accès à certaines fonctions du logiciel.

MCD :
Personne -0,1----Etre----(1,1)- Utilisateur -0,1----Etre----(1,1)- Etudiant
Type_utilisateur -0,n----Typer----1,1-|

Il y a ici deux niveaux d'héritage et un typage. Tu vois, on peut même mélanger les deux !

[Hildeguard]

Bonjour,

Les avis sont partagés... Avant, je nommais aussi au pluriel mais je me suis rangé à l'avis que le singulier est meilleur. Dans les règles de gestion, on se pose la question relativement à une instance de l'entité :
"Un dessinateur peut créer plusieurs plans et un plan est créé par un seul dessinateur."

C'est noté et modifié à ce niveau.

Non ! L'entité s'appelle "Dessinateur" mais l'attribut qui lui sert d'identifiant peut par exemple s'appeler "dsn_id". Et dans un MCD, il faut préciser quel(s) attribut(s) participe(nt) à l'identification de chaque instance de l'entité.

Sur ce point, j'aimerais connaitre la règle (s'il en existe une) qui permette de déterminer quel(s) attribut(s) participe(nt) à l'identification de chaque instance de l'entité.

De plus, lorsque tu parles de "chaque instance de l'entité", je ne suis pas sur de ce que ca signifie:

Dans mon MCD, j'ai une entité "Dessinateur". Dans l'entité "Révision", j'ai l'attribut "Dessinateur" (enfin dsn_id).
Est ce que cet attribut est considéré comme étant une instance de l'entité "Dessinateur"?

Désolé pour les questions bêtes, mais je préfère que ce soit le plus clair possible.

Parce que c'est comme ça conventionnellement !
Regarde le cours de modélisation Merise de SQLPro ou un autre et tu verras toujours la même chose : pas de clé étrangère dans un MCD ! Elles n'apparaissent qu'au moment où tu déclines le MCD en MLD puis surtout en MPD.

Pourrais tu me donner une définition d'une "clé étrangère"?
Même si ça reste encore un peu flou pour moi, je crois comprendre que je suis rentré trop vite dans le détail des attributs pour un MCD.

Fais-le chez toi si tu as un ordi !
Word, ce n'est vraiment pas l'outil adéquat pour faire un MCD. Autant le faire à la main sur une feuille de papier. Si on te demande de faire ce boulot, qu'on te permette d'utiliser les moyens qu'il faut, sans aller forcément jusqu'à demander l'achat d'un logiciel de modélisation professionnel tel que Power AMC.

Je vais être un peu hors sujet, mais une petite explication s'impose. Nous sommes entièrement d'accord pour dire que Word n'est pas adapté, mais je n'ai que ça à disposition. J'avais fait cette ébauche de MCD sur papier, mais je voulais qu'il soit au propre pour le mettre sur ce forum, mais aussi lorsque je le présenterai, si besoin est.

En fait, on ne me demande pas de faire ce travail. Je suis dessinateur industriel, donc on me demande de faire des plans. Mais, de mon propre chef, de manière à améliorer notre quotidien, je prends la liberté, lorsque le temps me le permet, de nous développer des outils adaptés. En l'occurence, à l'heure actuelle, nous utilisons de vieux classeurs. Autant te dire que pour rechercher une pièce...

Mais ça, les patrons n'en ont que faire, c'est notre "sauce". Je dois donc faire avec les moyens du bord. Et encore, avec les policies du groupe, je n'ai pas le droit de faire de développement ou de bdd...

Bref, pour revenir un peu plus sur le sujet, j'ai tenté d'installé le soft que tu me proposes chez moi, mais il semblerait que je doive installer des composants Java. Ce qui est fort dommage car j'espérais avoir une version portable que j'aurais pu utiliser au boulo grâce à mon disque externe.. J'essaierai tout de même de l'utiliser chez moi.

OK mais je crains que tu fasses fausse route avec ce schéma. Prends en compte ce que j'ai dit à partir du point 8:

8) Les attributs info X m'inquiètent un peu. Si ils représentent de futurs attributs dont tu sais qu'ils existeront mais dont tu ne sais pas encore comment les nommer, ça va. Sinon, externalise ces infos en nombre variable car il faut éviter de devoir modifier le modèles de données après mise en production.

Je comprends bien la problématique. En revanche, je ne comprends pas ce que tu veux dire par externaliser les infos en nombre variable. Ou plutot, comment le représenterais tu dans le MCD?

C'est une mauvaise manière de faire !
D'abord parce qu'un jour tu risques d'avoir besoin de 5 infos, puis 6... et à chaque fois il faudra modifier ton modèle et les programmes qui l'utilisent.
Ensuite parce que ça ne facilite pas du tout la recherche car les infos peuvent être entrées dans n'importe quel ordre et de n'importe quelle manière et que si tu veux un jour extraire tout ce qui est par exemple "obsolète", il te faudra chercher sur 4 colonne au lieu d'une.
À la limite, il vaut mieux une seule colonne qui sera de type TEXT dans la table (MEMO je crois chez Access) et sur laquelle tu peux faire toutes les recherches que tu veux avec LIKE '%ce que tu recherches%'.

A la place de mes 4 attributs "info", je pourrais m'en sortir avec un seul attribut "info". Si tel est le cas, même si j'ai du mal à voir comment j'arriverai à m'en sortir ensuite, l'idée me plait et m'arrange bien sur.


Pour les 2 derniers points, je fini d'étudier tout ça en revenant de la pause déjeuner. Encore merci pour ces informations
J'espère réussir à terminer ce MCD cet après midi, mais je n'y crois pas trop. Il me reste encore un peu trop de zones d'ombres à éclaircir

[CinePhil]

Sur ce point, j'aimerais connaitre la règle (s'il en existe une) qui permette de déterminer quel(s) attribut(s) participe(nt) à l'identification de chaque instance de l'entité.

Chaque entité du MCD donnera une table dans la BDD.
Chaque table doit avoir un identifiant appelé clé primaire et permettant de distinguer de manière unique chaque ligne de la table.
Pour des raisons, entre autres, de performances, les clés de type entier auto-incrémenté sont meilleures.
Il est donc préférable de prévoir, dès la réalisation du MCD ces identifiants artificiels.

Dans certains cas, plusieurs colonnes de la table composent la clé primaire.
- Dans le cas où la table est issue d'une association du MCD, la clé primaire est composée des identifiants des entités participant à l'association.
Exemple : Personne -0,n----Travailler----0,n- Projet
La table travailler aura pour clé primaire (trv_id_personne, trv_id_projet).

- Dans le cas d'une identification relative partielle, la clé primaire accueillera l'identifiant de l'entité forte.
Exemple : Hotel -1,n----Avoir----(1,1)- Chambre
Chambre (ch_id_hotel, ch_numero...)

De plus, lorsque tu parles de "chaque instance de l'entité", je ne suis pas sur de ce que ca signifie:

fsmrel emploie le terme d'entité-type pour désigner ce qui est représenté par un rectangle dans le MCD et qui décrit la structure d'une entité.
Dans son langage, L'entité-type Personne contiendra par exemple les entités des personnes CinePhil et Hildeguard.
Dans mon langage, comme je trouve le terme entité-type un peu lourd et long, je préfère dire que l'entité Personne contiendra par exemple les instances CinéPhil et Hildeguard. Un peu comme une instance de classe est aussi appelée objet.

Dans mon MCD, j'ai une entité "Dessinateur".

Oui.

Dans l'entité "Révision", j'ai l'attribut "Dessinateur" (enfin dsn_id).

Il ne devrait pas y être dans le MCD. C'est une clé étrangère qui n'apparaîtra qu'au moment de la génération du MLD.

Est ce que cet attribut est considéré comme étant une instance de l'entité "Dessinateur"?

Non. Voir plus haut.
ce que j'appelle une instance de l'entité d'un MCD est assimilable à une ligne de la future table issue de l'entité.

Pourrais tu me donner une définition d'une "clé étrangère"?

Une clé étrangère est une colonne d'une table de la BDD qui fait référence à la clé primaire d'une autre table qui lui est associée.
MCD :
Dessinateur -0,n----Créer----1,1- Plan

Tables :
Dessinateur (dsn_id, dsn_nom, dsn_prenom...)
Plan (pln_id, pln_id_createur, pln_titre...)
pln_id_createur est une clé étrangère faisant référence à dsn_id de la table dessinateur et matérialise ainsi l'association existant dans le MCD entre dessinateur et plan.

Je comprends bien la problématique. En revanche, je ne comprends pas ce que tu veux dire par externaliser les infos en nombre variable. Ou plutot, comment le représenterais tu dans le MCD?

Deux possibilités :
1) Chaque info est propre à une pièce
Piece -0,n----Avoir----1,1- Info

2) La même caractérise plusieurs pièces, éventuellement avec des valeurs différentes
Piece -0,n----Avoir(valeur)----0,n- Info

Bon courage !
Je suis un peu sidéré de voir un bureau d'études travailler encore avec des classeurs de plans sur support papier !
Calque, Rotring et lame de rasoir aussi ?