Premiers pas en conception de BDD

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:

http://www.cijoint.fr/cj201012/cijvswEFku.jpg

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)

http://www.cijoint.fr/cj201012/cijYC5w6TP.jpg

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)
http://www.cijoint.fr/cj201012/cijDbr3wAG.jpg

Merci d'avance pour votre aide !

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

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é

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.

Citation:

---

Envoyé par Hildeguard

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."

Citation:

---

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é.

Citation:

---

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 !

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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 !

Citation:

---

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.

Citation:

---

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 ! :aie:
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]

Citation:

---

Envoyé par Hildeguard

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."

Citation:

---

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é.

Citation:

---

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 !

Citation:

---

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.

Citation:

---

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.

Citation:

---

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.

Citation:

---

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 !

Citation:

---

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.

Citation:

---

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 ! :aie:
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%'.

Citation:

---

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... ;)

Citation:

---

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.

Citation:

---

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 !

Bonjour,

Citation:

---

Envoyé par CinePhil

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. :)

Citation:

---

Envoyé par CinePhil

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.

Citation:

---

Envoyé par CinePhil

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.

Citation:

---

Envoyé par CinePhil

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.

Citation:

---

Envoyé par CinePhil

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?

Citation:

---

Envoyé par CinePhil

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 :ccool:
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 :cry:

Citation:

---

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...)

Citation:

---

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.

Citation:

---

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

---

Oui.

Citation:

---

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.

Citation:

---

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é.

Citation:

---

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.

Citation:

---

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 ! 8O
Calque, Rotring et lame de rasoir aussi ? :roll:

Citation:

---

Envoyé par CinePhil

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.

---

Prenons le cas par exemple des dessinateurs tels que Hildeguard, CinePhil, Franquin, Hergé et autres. La modélisation (des données) consiste — à partir des propriétés caractéristiques communes à ces individus — à concevoir une sorte de stencil ou, comme en couture, de patron (à l’origine du mot pattern en anglais), auquel on donne en l’occurrence le nom de Dessinateur. Cette abstraction est décrite par ses propriétés : Nom, Prénom, Pseudonyme, AdresseCourriel, etc. En logique, Dessinateur devient un prédicat :

Le dessinateur Nom prénommé Prénom a pour pseudonyme Pseudonyme et pour adresse de courriel AdresseCourriel

Les objets concrets — ou propositions — se conforment à ce prédicat :

Le dessinateur Leménager prénommé Philippe a pour pseudonyme CinePhil et pour adresse de courriel Philou@xyztuvw.fr
Le dessinateur Franquin prénommé André a pour pseudonyme Fantasio et pour adresse de courriel Gaston@yztuvwx.fr
...

Dans le contexte de Merise, le patron devient un type d’entité ou type d’individu (ou encore entité-type, individu-type) et pour éviter la confusion, l’objet (ou l’individu, l’entité) prend le nom d’occurrence. Voyez par ailleurs la discussion entamée par Jérémy31.

En passant, je fais observer qu’un prédicat ou un patron ou un type d’entité ne sont pas des ensembles. Par exemple, à partir d’un stencil et d’une ronéo, je produis des exemplaires d’articles mais je ne sache pas que le premier contienne ces derniers. En ce sens, j’estime donc incorrect d’écrire :

L'entité-type Personne contiendra par exemple les entités des personnes CinePhil et Hildeguard.

En revanche il est correct d'écrire que CinePhil et Hildeguard sont des personnes (dictinction entre avoir et être).

Bonjour,

Désolé pour cette réponse tardive.
J'ai essayé de tout reprendre depuis le début, en tenant compte des divers commentaires. Mon MCD s'en voit grandement modifié. Cependant je n'ai pas encore étudié plus en détail ton explication suivante CinePhil, car je voulais savoir si j'ai a peu près compris les cardinalités ou non (essentiel pour mettre sous forme de schéma, ce que tu me proposes):

Citation:

---

Envoyé par CinePhil

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é

---

Voilà ce que ça donne pour le moment:

http://www.cijoint.fr/cj201012/cij8PqkoBh.jpg

Liste des changements:

L'entité Plan à disparu, car après réflexion elle ne m'apporte rien dans mon application. A aucun moment les plans n'interviendront. En revanche, je m'interesse uniquement à la gestion / création / révision de pièces faites par les dessinateurs.
Cela te parait il être correct dans mon raisonnement?

Ensuite j'ai simplifié la modélisation des entités "Attribut commun" et "Attribut complémentaire"

Pour le moment je n'ai pas regroupé les entités "Famille simple" et "Famille complexe" mais j'ai représenté grâce à un rectangle en pointillé, qu'a ce niveau de conception, je pense que ça devrait être réuni en une seule et même entité "Famille". Idem, qu'en penses tu?

J'ai modifié les attributs de manière à supprimer les clés étrangères.
J'ai rajouté dsn_id pour l'entité "Dessinateur". Je n'en ai volontairement pas rajouté pour l'entité "Révision" car l'attribut "no_dec" est un entier auto-incrémenté unique qui, si je ne me trompe pas, pourrait servir de clé primaire.
La seule chose qui m'embête un peu, puisqu'un attribut sera ensuite un champs de la table "Révision", c'est que ce champs devrait faire référance à une colonne d'un fichier excel extérieur à la BDD. Est ce un problème à ce niveau?

J'ai terminé en ajoutant les cardinalités en posant les questions suivantes:

Citation:

---

Un dessinateur peut créer combien de pièces ?
Entre 1 et plusieurs (1,n)

Une pièce peut être créée par combien de dessinateur ?
Un seul (1,1)

Un dessinateur peut réviser combien de pièces ?
Entre 1 et plusieurs (1,n)

Une pièce peut être réviser par combien de dessinateur ?
Un seul (1,1)

Une pièce peut appartenir à combien de familles ?
Entre 1 et plusieurs (1,1)

Une famille peut contenir combien de pièces ?
Entre 1 et plusieurs (1,n)

Une famille peut contenir combien d’attributs communs?
Un seul (1,1)

Une famille peut contenir combien d’attributs complémentaires ?
Entre 1 et plusieurs (1,n)

Un attribut commun peut appartenir à combien de familles?
A toutes (n,n)

Un attribut complémentaire peut appartenir à combien de familles?
A toutes (n,n)

---

Y vois tu des erreurs / incohérences?
J'avoue avoir du mal avec pas mal d'exemples quant à la cardinalité 0:

Citation:

---

Envoyé par http://cyril-gruau.developpez.com/merise

La seule difficulté pour établir correctement les cardinalités est de se poser les questions dans le bon sens. Autour de l'association commander, par exemple :


côté clients, la question est « un client peut commander combien d'articles ? » et la réponse est « entre 1 et plusieurs » ;
côté articles, la question est « un article peut être commandé par combien de client ? » et cette fois-ci, la réponse est « entre 0 et plusieurs ».

---

La première question et sa réponse me semblent logique, car du moment ou on commande, on a forcément au minimum 1 article, et on peut en commander plusieurs.

Mais la 2ème question selon moi ne suit pas la même logique. En effet, si un article est commandé, c'est qu'il devrait y avoir au minimum 1 client et au maximum, soit 1 soit plusieurs... tout dépend de si on parle la d'un seul et même article (dans ce cas 1) ou si on parle d'un type d'article (dans ce cas n). Je ne sais pas si je suis clair, alors je vais l'illustrer avec l'exemple suivant:

Admettons que je commande un dvd du Seigneur des anneaux, l'exemplaire que je recevrai, il n'y a que moi qui pourrait l'avoir.
Cependant, d'autres clients pourront recevoir d'autres exemplaires identiques à celui que j'ai reçu.

Citation:

---

Envoyé par CinePhil

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 ?

---

Il doit rester une boite de Rotring qui traine quelque part, et j'ai gardé, en titre de souvenir d'une époque que je n'ai pas connue, une boite de lame de rasoir :mouarf:
Plus sérieusement, je travaille avec des personnes qui sont très bonnes techniquement, mais qui sont peut etre un peu réfractère au changement quelque fois, mais surtout, qui estiment que leurs outils actuels leurs suffisent pour travailler, et ne cherchent pas à améliorer les choses. C'est pour cela que nous nous trainons encore des choses qui ne devraient plus exister. :cry:

Maintenant que tout le monde ne jure plus que par le nouveau système de management, ça me fait une bonne raison de mener ce genre de projet.

Edit: je viens de me rendre compte que j'ai oublié d'ajouter des champs de clés primaires pour les entités "Attribut commun" et "Attribut complémentaire". J'ai modifié le MCD en conséquence.

Citation:

---

L'entité Plan à disparu, car après réflexion elle ne m'apporte rien dans mon application. A aucun moment les plans n'interviendront. En revanche, je m'interesse uniquement à la gestion / création / révision de pièces faites par les dessinateurs.
Cela te parait il être correct dans mon raisonnement?

---

Moi j'aurais plutôt pensé qu'un dessinateur crée ou révise un plan de pièce qu'une pièce !
<mode humour on>
Finalement, tu as remplacé le rotring et la lame de rasoir par une caisse à outils ? :P
<mode humour off>

Pour le haut de ton MCD, les règles de gestion ne seraient-elle pas plutôt celles-ci ?
1) Un dessinateur peut créer plusieurs plans (de pièces) et un plan (de pièce) est créé par un seul dessinateur.
2) Un dessinateur peut réviser plusieurs plans (de pièces) et un plan (de pièce) peut être révisé par plusieurs dessinateurs.

Ce qui donnerait plutôt ce MCD :
Dessinateur -0,n----Créer----1,1- Plan
|-------------------0,n----Réviser----0,n--|

Rien n'empêche de mettre la référence de la pièce dans les attributs du plan si le but n'est pas de gérer les pièces mais les plans. Notamment, je ne pense pas que le numéro de série soit important, à moins qu'une pièce puisse garder la même référence si à partir d'une série on modifie son plan.

Citation:

---

Pour le moment je n'ai pas regroupé les entités "Famille simple" et "Famille complexe" mais j'ai représenté grâce à un rectangle en pointillé, qu'a ce niveau de conception, je pense que ça devrait être réuni en une seule et même entité "Famille". Idem, qu'en penses tu?

---

Ne voyant pas bien quelle nuance il y a entre famille simple et famille complexe, j'aurais tendance à dire oui.

Citation:

---

Ensuite j'ai simplifié la modélisation des entités "Attribut commun" et "Attribut complémentaire"

---

Ça reste quand même flou.
Si tous les attributs communs sont des attributs qui doivent être renseignés pour tous les plans (pièces dans ton MCD), alors met ces attributs dans l'entité Plan (Pièce).

Ensuite, puisque, d'après ce que j'ai compris, certains plans (pièces) ont des attributs complémentaires, fait juste une association entre les attributs complémentaires et les plans (pièces).

D'ailleurs, autant pour les attributs communs que pour les attributs complémentaires, s'agit-il d'attributs des pièces ou des plans ? La sémantique a quand même une certaine importance quand on conçoit les choses sinon on risque de se perdre plus tard à essayer de comprendre de quoi on parle.

Citation:

---

Cependant je n'ai pas encore étudié plus en détail ton explication suivante CinePhil, car je voulais savoir si j'ai a peu près compris les cardinalités ou non (essentiel pour mettre sous forme de schéma, ce que tu me proposes):

Citation:

---

Envoyé par CinePhil

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é

---

---

On peut imaginer que toutes les pièces auront une référence, un prix de base hors-taxes.
Ce qui donnerait la table suivante :
Piece (pce_id, pce_reference, pce_prix_base_ht)

Parmi ces pièces, certaines sont des raccords qui ont tous les attributs numériques "diamètre" et "longueur" ainsi qu'un attribut booléen "flexible".

Ça donnerait le MCD suivant :
Raccord -(1,1)----Etre----0,1- Piece

Il en découlerait la table suivante :
Raccord (rcd_id_piece, rcd_diametre, rcd_longueur, rcd_flexible)

J'ai fait ici un héritage qui classifie automatiquement les pièces de type Raccord sans avoir besoin d'une famille Raccord.
Mais ce modèle peut devenir lourd si tu as beaucoup de familles de pièces car il faut une table par famille.

L'autre méthode consiste, comme tu l'as fait, à classer les pièces dans des familles et à dire que telle famille a tel(s) attribut(s) complémentaire(s) par rapport aux autres attributs communs à toutes les pièces.

On aurait donc d'abord le MCD suivant :
Piece -1,1----Classer----0,n- Famille -0,n----Avoir----0,n- Attribut (complémentaire)

Ce qui donne les tables suivantes :
Piece (pce_id, pce_reference, pce_prix_base_ht)
Famille (fam_id, fam_libelle)
Attribut (atr_id, atr_libelle)
Attribut_famille (af_id_attribut, af_id_famille, af_valeur_par_defaut...)

Maintenant, il faut compléter le MCD pour donner les vraies valeurs des attributs de la pièce.
Piece -1,1----Classer----0,n- Famille -0,n----Avoir----0,n- Attribut (complémentaire)
|----------0,n----Valoriser------------------------------------------0,n------|

Ce qui ajoute une table :
Piece_attribut (pa_id_piece, pa_id_attribut, pa_valeur)

Il faudra prévoir aussi un trigger lors de l'implémentation de la BDD pour valider le fait que le couple {famille de la pièce, attribut} de la table Piece_attribut soit bien présent dans la table Attribut_famille. Mais tu n'en es pas encore là et ce n'est plus l'objet de ce forum.

Cette seconde modélisation permet d'ajouter autant de familles que tu veux sans toucher au modèle de données mais en interrogeant la BDD il faudra transtyper les valeurs numériques car le type de la colonne pa_valeur sera de type VARCHAR, sauf si tous les attributs sont numériques.

Bonjour,

Pour revenir sur les entités "Plan" et "Pièce", dans le programme, nous n'aurons qu'une notion de pièce. Car la finalité est de rechercher et gérer les pièces. Néanmoins, une pièce aura toujours un plan qui lui est associé. L'indice de révision du plan sera toujours identique à celui de la pièce, ainsi que le numéro de plan etc. En gros, un plan et une pièce sont indissociables.

Citation:

---

Envoyé par CinePhil

Pour le haut de ton MCD, les règles de gestion ne seraient-elle pas plutôt celles-ci ?
1) Un dessinateur peut créer plusieurs plans (de pièces) et un plan (de pièce) est créé par un seul dessinateur.
2) Un dessinateur peut réviser plusieurs plans (de pièces) et un plan (de pièce) peut être révisé par plusieurs dessinateurs.

Ce qui donnerait plutôt ce MCD :
Dessinateur -0,n----Créer----1,1- Plan
|-------------------0,n----Réviser----0,n--|

---

Merci pour cet exemple. Par rapport à mon soucis de compréhension avec la cardinalité 0, je crois comprendre que dans la règle de gestion si on utilise le verbe "pouvoir", alors on utilisera la cardinalité 0, si on utilise le verbe "devoir", on utilisera la cardinalité 1, et si on a l'adverbe "plusieurs", alors on aura la cardinalité n.

C'est surement incomplet ou incorrect, mais pour le moment c'est comme ça que je vois la chose. Comme tu le vois j'essaie de traduire "votre langage" ;)

Citation:

---

Envoyé par CinePhil

Rien n'empêche de mettre la référence de la pièce dans les attributs du plan si le but n'est pas de gérer les pièces mais les plans. Notamment, je ne pense pas que le numéro de série soit important, à moins qu'une pièce puisse garder la même référence si à partir d'une série on modifie son plan.

---

En fait, lorsqu'on réalise le plan d'une pièce, on y intègre tous les attributs de la pièce. Après le terme "numéro de série" t'as induit en erreur car on ne l'utilise pas correctement :mrgreen:.

Pour nous, ce S/N fait référence a un numéro de job. Un job, est un assemblage de pièces qui permet de former une machine complète. Donc le S/N nous interesse dans certain cas ou on a des pièces spéciales à une affaire.

Citation:

---

Envoyé par CinePhil

Ne voyant pas bien quelle nuance il y a entre famille simple et famille complexe, j'aurais tendance à dire oui.

---

Pour que ce soit plus concret je vais t'expliquer comment j'ai modélisé cette notion de familles simples / complexes sous excel. D'ailleurs ça va empièter sur ce que tu me dis plus loin ;)

- Chaque famille était un fichier excel different, indépendament qu'elle soit simple ou complexe.
- Une famille complexe avait la particularité de de se décomposer une plusieurs feuilles. Chaque feuille faisait référence à une "sous" famille.

http://www.cijoint.fr/cj201012/cijYC5w6TP.jpg

Ensuite, sur l'interface utilisateur que tu peux voir ci dessus, le filtre "Famille de pièce" allait récupérer un index de famille, et lors d'une sélection dans ce filtre, j'allais ouvrir le fichier (table) de la famille sélectionnée.

En fonction de la famille sélectionnée, je venais regarder la page de garde créé pour chaque famille afin de savoir si j'avais à faire à une famille simple ou complexe.

Si elle était de type simple, alors je n'avais pas le filtre "Type" mais j'avais directement mes attributs. Au passage, tous les filtres étaient créés dynamiquement en fonction des diverses sélections effectuées.

Dans le cas d'une famille complexe, j'ajoutais le filtre "Type". Cette combobox était alimentée par l'ensemble des feuilles excel composant le fichier de la famille sélectionnée. (ici on est sur la feuille "Socket" du fichier "Bushing.xls")

Si je venais à changer le filtre "Type" , la liste des attributs (juste en dessous) changeait en conséquence. Les attributs étaient des colonnes de l'excel. Comme quoi, c'était peut être pas si mal fait, en comparaison avec ce que je vois d'un MCD ;)

Pour revenir plus à cette notion de familles simples et complexes. Une famille complexe intègre un nombre n de "sous familles" , alors qu'une famille simple ne peux pas comporter de sous familles.

Quelques exemples:

Vis (complexe) -> CHC, H, FHC.
Ces 3 types (ou sous familles) sont bien tous des vis. Mais ils sont physiquement tous differents. De plus leur codification, et attributs peuvent être different.

Vannes (complexe) -> Boisseau sphérique, Opercule, etc
Idem, ces differents types de vannes, sont toutes differentes physiquement, ainsi que la cofification et les attributs.

Cornières (simple)
On a qu'un seul type. Bien que dans les catalogues tu peux trouver à ailes égales, inégales, on aura le même modele (jsute les cotes qui changent), ce sera codifié de la même manière, et on aura les même attributs.

Tube (simple)
Idem que pour les cornières.

[quote="CinePhil"]Ensuite, puisque, d'après ce que j'ai compris, certains plans (pièces) ont des attributs complémentaires, fait juste une association entre les attributs complémentaires et les plans (pièces). [quote]

Pour être un peu plus précis toutes les pièces (plan) auront au moins un attribut complémentaire.
Si je comprends bien, je devrais donc relier les entités "Attribut" aux entités "Famille" et "Pièce"? Dans ce cas je serai d'accord sur le principe. Bien que, selon moi, on perdrait la notion "d'héritage" d'attributs. En effet, les attributs d'une pièce dépendent forcément de la famille (ou sous famille dans le cas d'une famille complexe) à laquelle elle appartient. Et en faisant comme tu me le proposes je l'interprete comme ceci:

Une pièce peut avoir des attributs, indépendament de la famille à laquelle elle appartient. Et inversement, une famille pourra avoir des attributs differents d'une pièce qu'elle contient.

Si mon interpretation est correcte, alors ce n'est pas ce que je recherche.

Citation:

---

Envoyé par CinePhil

D'ailleurs, autant pour les attributs communs que pour les attributs complémentaires, s'agit-il d'attributs des pièces ou des plans ? La sémantique a quand même une certaine importance quand on conçoit les choses sinon on risque de se perdre plus tard à essayer de comprendre de quoi on parle.

---

Peut etre qu'avec ce que je t'ai dit plus haut, ça doit être plus clair pour toi? Si on dissocie "pièce" et "plan" (chose que je ne souhaite pas faire) , il s'agit donc d'attributs de pièces. Et ces attributs devraient provenir (à mon avis) de la famille à laquelle la pièce appartient.

En ce qui consiste quelle méthode choisir. Je continue d'y réfléchir. Mais peut être qu'avec les informations que j'apporte avec ce message, tu me diras qu'une des 2 s'imposera plus que l'autre.

Encore merci pour ta précieuse aide !!!

Citation:

---

Envoyé par CinePhil

<mode humour on>
Finalement, tu as remplacé le rotring et la lame de rasoir par une caisse à outils ?
<mode humour off>

---

Oui, je les ai remplacé par un mulot. :mouarf:

Citation:

---

Envoyé par Hildeguard

Merci pour cet exemple. Par rapport à mon soucis de compréhension avec la cardinalité 0, je crois comprendre que dans la règle de gestion si on utilise le verbe "pouvoir", alors on utilisera la cardinalité 0, si on utilise le verbe "devoir", on utilisera la cardinalité 1, et si on a l'adverbe "plusieurs", alors on aura la cardinalité n.

C'est surement incomplet ou incorrect, mais pour le moment c'est comme ça que je vois la chose. Comme tu le vois j'essaie de traduire "votre langage" ;)

---

Oui en gros c'est ça.
Si tu écris tes règles de gestion de cette manière, le MCD vient tout seul ensuite. Bref ça applique la phrase en bleu de ma signature ! ;)

Citation:

---

Quelques exemples:

Vis (complexe) -> CHC, H, FHC.
Ces 3 types (ou sous familles) sont bien tous des vis. Mais ils sont physiquement tous differents. De plus leur codification, et attributs peuvent être different.

Vannes (complexe) -> Boisseau sphérique, Opercule, etc
Idem, ces differents types de vannes, sont toutes differentes physiquement, ainsi que la cofification et les attributs.

Cornières (simple)
On a qu'un seul type. Bien que dans les catalogues tu peux trouver à ailes égales, inégales, on aura le même modele (jsute les cotes qui changent), ce sera codifié de la même manière, et on aura les même attributs.

Tube (simple)
Idem que pour les cornières.

---

Donc tu as simplement des familles dont certaines peuvent avoir des sous-familles.
Les sous-familles peuvent avoir des sous-sous-famille ? Combien de niveaux de familles au maximum ?

Citation:

---

En effet, les attributs d'une pièce dépendent forcément de la famille (ou sous famille dans le cas d'une famille complexe) à laquelle elle appartient

---

Citation:

---

. Et en faisant comme tu me le proposes je l'interprete comme ceci:

Une pièce peut avoir des attributs, indépendament de la famille à laquelle elle appartient. Et inversement, une famille pourra avoir des attributs differents d'une pièce qu'elle contient.

Si mon interpretation est correcte, alors ce n'est pas ce que je recherche.

---

Je reprends mon modèle et la précision que j'ai donnée pour garder la dépendance des attributs de la pièce à ceux de la famille :

Citation:

---

Envoyé par CinePhil

Piece -1,1----Classer----0,n- Famille -0,n----Avoir----0,n- Attribut (complémentaire)
|----------0,n----Valoriser------------------------------------------0,n------|

Il faudra prévoir aussi un trigger lors de l'implémentation de la BDD pour valider le fait que le couple {famille de la pièce, attribut} de la table Piece_attribut soit bien présent dans la table Attribut_famille.

---

J'ai justement donné hier un exemple de trigger pour MySQL sur un cas du même genre (Un étudiant ne peut subir un contrôle que pour une UV à laquelle il est inscrit).
Tu y vois la modélisation de la contrainte et son implémentation par un trigger en base de données, avec la particularité pour MySQL que la gestion d'erreur fait appel à une procédure et à une table d'erreur car MySQL ne connaît pas RAISE ERROR, mais là on sort du sujet qui te préoccupe pour le moment et du cadre de ce forum.

Citation:

---

En ce qui consiste quelle méthode choisir. Je continue d'y réfléchir. Mais peut être qu'avec les informations que j'apporte avec ce message, tu me diras qu'une des 2 s'imposera plus que l'autre.

---

Si tu as beaucoup de familles et sous-familles, je pense que l'héritage sera trop lourd et qu'il vaut mieux utiliser la modélisation par famille décrite ci-dessus.

Bonjour :)

Citation:

---

Envoyé par CinePhil

Donc tu as simplement des familles dont certaines peuvent avoir des sous-familles.
Les sous-familles peuvent avoir des sous-sous-famille ? Combien de niveaux de familles au maximum ?

---

Nous ne pourrons pas avoir d'autres niveaux que ce que j'ai décrit plus haut.
Une famille, peut avoir des sous-familles. Mais jamais de sous-sous-familles.

Pour le reste j'y réfléchis, et regarde comment faire :)

Merci !