Discussion :

[LecGaël]

Bonjour,

Dans le cadre de mon alternance je dois développer une base de donnée pour la saisie des pièces remplacées en maintenance.
N'ayant jamais fais de cours sur les BDD ou les SGBD je suis en train d'apprendre et là je bloque...
J'ai Access au travail.

Je voudrais faire une base de données ou je référence toutes les pièces, pour cela j'ai fais un premier champ Lieux pour indiquer ou se trouve la pièce, un champ Famille (condensateur, contacteur, etc), un champ abréviation en clair le nom de l'organe, et la je bloque car pour certaines pièces, on peut remplacer la pièce dans sont intégralité, ou alors juste certains éléments qui composent la pièce. Je ne sais pas comment représenter ça dans une base de donnée.

Car en clair lorsque la personne saisie la pièces dans l'interface(que je développerais en c# je pense), si cette pièces possède des sous ensembles (entière, juste un élément), je veux que le mécanicien puisse choisir et lorsque il y en a pas que ça fonctionne quand même.
Je ne sais pas si j'ai été clair dans mon explication...

Autre question si j'ai une pièce dans deux lieux différents mais qui a le même nom, dans la base j'aurais deux ligne identiques, sauf pour lieux qui sera différents ?

Voila pour l'instant je regarde les cours disponibles sur le forum, et j'organise déjà ma futur base sur Excel.

Merci d'avance, bonne journée.

[CinePhil]

Bonjour,

Vous devez d'abord concevoir votre base de données en réalisant un Modèle Conceptuel de Données.

Pour cela, vous devez écrire les règles de gestion des données à traiter.

Utilisez un logiciel de modélisation pour réaliser votre MCD, tel que JMerise ou DBMain.

Entrons maintenant dans votre domaine à modéliser...

Je voudrais faire une base de données ou je référence toutes les pièces, pour cela j'ai fais un premier champ Lieux pour indiquer ou se trouve la pièce, un champ Famille (condensateur, contacteur, etc), un champ abréviation en clair le nom de l'organe, et la je bloque car pour certaines pièces, on peut remplacer la pièce dans sont intégralité, ou alors juste certains éléments qui composent la pièce. Je ne sais pas comment représenter ça dans une base de donnée.

Il s'agit donc de pièces dont certaines sont composées de plusieurs éléments. Ces pièces appartiennent à des familles et sont situées en des lieux.

Si vous avez lu mon billet de blog sur les règles de gestion, vous aurez compris que j'ai surligné ci-dessus les entité-types que vous devez modéliser et dont vous devez écrire les règles de gestion qui permettrons de dessiner les associations entre elles.

Revenez nous voir avec ces premières règles de gestion et votre première ébauche de MCD.

[LecGaël]

Bonjour,

Tout d'abord merci pour votre réponse.
Est ce que ce travail me permettra par la suite de faire une interface simple qui me permet de questionner ma base de données, à savoir des menus déroulant me permettant dans un premier temps de choisir le lieux, puis la famille de pièces, etc.....
Sachant qu'au travail j'ai Access et C# ?

Je suis complétement perdu pour l'instant... beaucoup de notions à apprendre je ne voudrais pas partir dans la mauvaise direction.

Merci d'avance

Bonne journée.

[escartefigue]

bonjour,

Si vous ne faites pas le travail de conception de la BDD conseillé à juste titre par Cinéphil, quels que soient les efforts apportés à la partie traitements, ceux-ci seront complexes, peu fiables et peu performants.
La simplicité de l'interface, quant à elle, dépend assez peu de la qualité de la modélisation des données, elle dépend surtout du soin apporté à l'ergonomie.
Celà étant, si les données sont mal modélisées, il est probable que des redondances y seront nichées et/ou que vous trouverez des données incohérentes (je pense notamment aux problèmes de typage des données), ce qui nuira à la qualité des traitements et notamment des interfaces

Autre aspect non négligeable : c'est plus facile de corriger les traitements défaillants ou mal conçus que de corriger la BDD, d'où le soin particulier requis pour bien concevoir celle-ci

Donc commencez par l'étape 1 : la modélisation des données, c'est incontournable

[CinePhil]

L'interface, ça viendra plus tard.

Vous avez Access, soit. Access est loin d'être le meilleur SGBD qui soit. Il est plutôt mono-utilisateur, à installer sur un poste de travail.

Posez-vous donc aussi la question de savoir si votre future application sera utilisée par plusieurs personnes sur des postes de travail différents et si l'application devra être accessible via le réseau de l'entreprise. Si c'est le cas, il vaut mieux éviter de partir sur Access. En restant dans le monde Microsoft, regardez plutôt du côté de SQL Server qui est l'un des meilleurs SGBD du marché. Mais regardez aussi ce qui existe déjà en matière de SGBD dans l'entreprise car vous serez peut-être contraint par une compatibilité avec les outils existants.

Vous dites être en alternance et n'avoir jamais étudié les bases de données. Vous êtes en alternance pour vous former à quel métier ? Quelles études avez-vous faites ? Avez-vous, au sein de l'entreprise, un tuteur compétent en informatique (bases de données et développement logiciel) ?

Je suis complétement perdu pour l'instant... beaucoup de notions à apprendre je ne voudrais pas partir dans la mauvaise direction.

Suivez la méthode que j'ai donnée : règle de gestion puis morceau de MCD, dessiné avec un logiciel de modélisation.
Ne vous lancez pas trop vite sur la réalisation concrète de la BDD et du logiciel ; c'est le meilleur moyen de faire n'importe quoi !

[escartefigue]

Suivez la méthode que j'ai donnée : règle de gestion puis morceau de MCD, dessiné avec un logiciel de modélisation.
Ne vous lancez pas trop vite sur la réalisation concrète de la BDD et du logiciel ; c'est le meilleur moyen de faire n'importe quoi !

+1 ! et ça coutera beaucoup plus cher à tout le monde à l'arrivée

Si la BDD qu'on vous demande n'est pas un simple exercice (peu probable dans le monde professionnel) alors il convient d'y apporter tout le soin nécessaire
- cherchez à savoir s'il existe des sachants qui pourraient vous aider au sein de l'entreprise ou dans votre établissement scolaire
- alertez s'il y a des points durs ou des choses auxquelles vous ne savez pas répondre
- demandez le cas échéant une formation et/ou un tuteur
- à chaque étape, faites valider vos travaux par la maîtrise d'ouvrage en expliquant bien le vocabulaire et en illustrant par des exemples (les incompréhensions sont tellement fréquentes, on utilise les mêmes mots, mais on leur donne un sens différent), n'attendez pas d'avoir fini, ce serait une erreur

[LecGaël]

J'ai réalisé ceci sur JMerise:



A savoir que je me suis peut être mal exprimé, ce que j'appelle une pièce c'est en fait une fonction qui se rattache à une pièce, ce que je veux dire c'est qu'on peut retrouver cette fonction ou pièce dans des lieux différents des noms différents mais il s'agit de la même pièce, c'est son appellation fonctionnelle en quelque sorte.
Pour l'instant ce que je veux c'est faire une base de donnée ou l'on puisse rechercher en fonction du lieux et de la famille la "pièce" ou fonction et sélectionner le ou les éléments si il y en a.
Lieux>Famille>"Pièce">élément(s) sachant que une pièce sans sous éléments possède un numéro de symbole cette fois rattaché à la pièce physique dont dépend la fonction.
Si ma "Pièce" ou fonction a des sous éléments mais qu'on change la pièce il faut pouvoir faire la distinction, et si il y a des sous éléments ils possèdent chacun un numéro de symbole.

Pour ce qui est de la question concernant mon alternance je vous répondrais hors de mon heure de travail et par MP.
Sur le MCD je n'ai pas mis de clef je ne sais pas quoi mettre.
Comme vous pouvez le voir j'ai déjà du mal à exposer mon problème clairement.


Merci pour toutes vos réponses je continue ma lecture.


EDIT: Je viens de voir que les cardinalité 1-1 1-1 sont à éviter, il faut que je trouve autre chose.

[CinePhil]

A savoir que je me suis peut être mal exprimé, ce que j'appelle une pièce c'est en fait une fonction qui se rattache à une pièce, ce que je veux dire c'est qu'on peut retrouver cette fonction ou pièce dans des lieux différents des noms différents mais il s'agit de la même pièce, c'est son appellation fonctionnelle en quelque sorte.

Euh... là va falloir nous donner des exemples parce que cette fois c'est moi qui suis perdu !

Réponse plus complète sur le reste plus tard...

[escartefigue]

Quelques remarques d'ordre général :

- nommez vos objets (types d'entité et colonnes) avec des singuliers en évitant les noms réservés SQL (date ou table par exemple) et en évitant les caractères spéciaux (comme "n°" à remplacer par "num" par exemple)
pour éviter toute percussion avec des noms réservés, vous pouvez utiliser un préfixe d'objet. Par exemple LI_LIEU qui contiendra les attributs LI_ident (identifiant technique, voir ci-dessous), LI_code, LI_designation etc.

- pour les associations, un infinitif peut simplifier la nomenclature, par exemple "composer" plutôt que "est composé". Là aussi, ni caractère spécial ni nom réservé SQL

- dans chacune de vos entité-type (pièce, élément, famille, lieux...) ajoutez un identifiant primaire technique de type integer qui sera attribué par le SGBD.
Selon le SGBD c'est un type "sequence" ou "identifier" ou "auto-increment".
Ce choix, plutôt qu'un identifiant fonctionnel comme id primaire, sera une garantie de stabilité et de performance de votre base de données

- les entité-type de typologie comme la famille par exemple (ou également les codes pays, les codes devises, les codes catégories, les unités de mesure...), ont en général une cardinalité minimale de zéro : vous pouvez avoir défini des familles qui n'ont pas de correspondance à un instant "t" parmi vos pièces (anciennes familles, famille prévues pour usage futur, etc.)

Par ailleurs, qu'une pièce puisse être située dans plusieurs lieux est suspect et mérite des explications. Ou alors il s'agit d'un historique des lieux, auquel cas la relation est à date (relation ternaire)

[LecGaël]

Pour "essayer" de faire simple, en clair si je me situe dans un train, j'ai plusieurs blocs moteurs, et bien quand le dépanneur change un relais par exemple, il va choisir le nom de ce relais, appelons le "QQ1", ce QQ1 peut être dans le bloc 1, bloc 2, bloc 3.
Mais pour certaines pièces ce n'est pas le cas ou en tout cas c'est possible qu'elle ne soit que dans un endroit donnée.
C'est pour ça qu'au début je pensais faire une base ou je recopiais mes données en ne changeant que le lieux, mais avec ce que j'ai lu hier concernant la gestion des données avec entités relations....

[escartefigue]

Pour "essayer" de faire simple, en clair si je me situe dans un train, j'ai plusieurs blocs moteurs, et bien quand le dépanneur change un relais par exemple, il va choisir le nom de ce relais

Faut il comprendre qu'un relais, d'un type particulier et portant un numéro de série de fabrication unique, se voit attribuer un nom par le technicien qui l'installe au moment de cette installation ?

[...]il va choisir le nom de ce relais, appelons le "QQ1", ce QQ1 peut être dans le bloc 1, bloc 2, bloc 3.

Oui mais comme évoqué dans ma réponse précédente, à un instant "t" il est dans le bloc1, à l'instant t+1 il peut être démonté pour être installé dans le bloc2, nous somme d'accord ?

C'est pour ça qu'au début je pensais faire une base ou je recopiais mes données en ne changeant que le lieux, mais avec ce que j'ai lu hier concernant la gestion des données avec entités relations....

La difficulté n'est pas tant dans la réalisation du modèle que dans la conceptualisation. Il faut bien comprendre comment les objets métiers interagissent puis rédiger les règles de gestion correspondantes.
Même si pour finir vous gériez votre besoin au moyen d'un simple tableur, cette compréhension est nécessaire.

[LecGaël]

Un relais portant un numéro de série unique peut s'appeler différemment suivant la fonction qu'il réalise ici, mais on me demande de faire une base de données ou on veut pouvoir choisir la fonction en quelque sorte, sa famille, la description de la fonction, le lieu....

"Oui mais comme évoqué dans ma réponse précédente, à un instant "t" il est dans le bloc1, à l'instant t+1 il peut être démonté pour être installé dans le bloc2, nous somme d'accord ?"
Si on réfléchit en terme de relais par exemple oui, mais le nom que l'on désire rentré dans le dépannage ne sera pas le même à part si cette fonction est présente dans les deux blocs.

[CinePhil]

Pour "essayer" de faire simple, en clair si je me situe dans un train,

Vous parlez d'un train en tant qu'exemple fictif ou c'est votre cas réel ?
Si c'est votre cas réel, je suis étonné qu'il n'y ait pas déjà des outils de gestion de maintenance !

j'ai plusieurs blocs moteurs, et bien quand le dépanneur change un relais par exemple, il va choisir le nom de ce relais, appelons le "QQ1", ce QQ1 peut être dans le bloc 1, bloc 2, bloc 3.

Si je comprends bien, la référence "QQ1", c'est la dénomination du relais sur le plan ?

Est-ce la référence QQ1 qui peut se trouver sur le plan de plusieurs blocs ?
Est-ce le relais de marque Truc référence fournisseur XYZ123 qui est utilisé à l'emplacement QQ1 sur tous les blocs ?
Les blocs 1, 2 et 3 sont-ils des blocs identiques, ce qui justifierait qu'ils aient le même plan et donc la même appellation QQ1 ?

Mais pour certaines pièces ce n'est pas le cas ou en tout cas c'est possible qu'elle ne soit que dans un endroit donnée.

Ça ce n'est pas un problème.
Une pièce peut se trouver dans plusieurs endroits, donc dans un seul.


Ce que je comprends de votre domaine...

Un technicien de maintenance va inspecter le train T1.
Il détecte que dans le bloc B1, le relais de l'emplacement QQ1 est défectueux et doit être remplacé.
Ce relais QQ1 est un relais de marque ABB et de référence XYZ123.

Vous devez enregistrer en BDD la composition des blocs sur les trains de manière à avoir toujours sous la main la nomenclature des pièces à changer.

Certaines de ces pièces sont composées d'autres pièces.

À vous de nous dire ce qu'il en est réellement.

[escartefigue]

Un relais portant un numéro de série unique peut s'appeler différemment suivant la fonction qu'il réalise ici, mais on me demande de faire une base de données ou on veut pouvoir choisir la fonction en quelque sorte, sa famille, la description de la fonction, le lieu....

Donc, un même composant, par exemple un relais, propose plusieurs utilisations possibles, dans ce panel, le technicien affecte l'une des utilisations possibles en fonction du contexte

Ceci se modélise sous forme de deux relations qui ont une Contrainte d'Intégrité Fonctionnelle de type "inclusion" : l'utilisation faite par le technicien doit faire partie des utilisations possibles pour le composant

Ce qui se schématise ainsi (désolé je n'ai pas de logiciel de modélisation sous la main donc c'est un peu basique en mode texte , il faut comprendre une flèche allant de "affecter" vers "proposer" avec un "I" en libellé pour matérialiser l'inclusion)

COMPOSANT 1,n --- proposer --- 0,n UTILISATION
........│.....................^........................│
........│.....................(i).......................│
........│......................│........................│
........└------ 0,n --- affecter ------------ 0,n
................................│
TECHNICIEN 0,n ------┘

[LecGaël]

Bonjour,

Je reviens vers vous bien tard...
J'ai continué le développement de cette BDD et j'ai posté quelque chose dans le forum Access je sais pas si c'est le bonne endroit, si vous voulez voir ou j'en suis...
Je me rend compte que j'aurais peut être besoin de faire des relations entre mes tables etc mais je ne sais pas comment m'y prendre...

https://www.developpez.net/forums/d1...csharp-retour/

Bonne journée

[escartefigue]

Comme indiqué à plusieurs reprises, il faut, avant de se préoccuper des tables, rédiger vos règles de gestion, ce sont ces règles qui permettront de savoir comment relier les types d'entités et de savoir s'il y a ou non des tables associatives.
Donc oubliez les tables pour l'instant, relisez les réponses qui précèdent et suivez les conseils qui y sont formulés.

Et aussi, si vous pouvez choisir un autre SGBD, vous serez gagnant : access est très rudimentaire, il respecte mal la norme SQL, n'est pas taillé pour les fortes volumétries... bref à éviter
Il existe plusieurs SGBD parmi lesquels des gratuits autrement plus avancés (SQL server express par exemple)

[LecGaël]

Pour ce qui est d'access je n'ai pas le choix ça m'est imposé... :/

oui je commence à chercher les relations, mais comme je le disais je ne sais même pas comment les faire efficacement sur Access... et aucune aide au boulot.

EDIT: J'ai du mal pour la cardinalité entre l'organe (la pièce) et l'équipement (le lieux ou elle se trouve).

Une pièce peut être à plusieurs endroit différents : Donc Organe --0-n----->Être---------0-n ---->Equipement ?

[escartefigue]

Pour ce qui est d'access je n'ai pas le choix ça m'est imposé... :/

Interrogez votre entourage sur les motifs qui conduisent à ce choix, peut-être que des changements sont possibles

oui je commence à chercher les relations, mais comme je le disais je ne sais même pas comment les faire efficacement sur Access...

Même si Access restera le SGBD que vous serez contraint d'utiliser, vous n'en avez pas besoin à ce stade.
La modélisation conceptuelle se fait avec un logiciel adhoc tel que dbmain (gratuit) ou jmerise (gratuit également en version bridée)

EDIT: J'ai du mal pour la cardinalité entre l'organe (la pièce) et l'équipement (le lieux ou elle se trouve).
Une pièce peut être à plusieurs endroits différents : Donc Organe --0-n----->Être---------0-n ---->Equipement ?

Voilà un début de règle de gestion (la partie que j'ai mise en couleur), il faut compléter avec les autres règles de gestion, puis commencer à modéliser avec DBMain par exemple.

En préalable, on se débarrasse des synomymes et on choisit toujours le même mot pour désigner le même concept.
Par exemple, dans l'extrait ci-dessus, vous parlez à la fois d'"équipement", de "lieu" et d'"endroit"... un seul mot, le plus pertinent, doit être conservé, ici c'est probablement "équipement"

Reprenons votre règle de gestion, ajoutons lui un identifiant et complétons là comme il se doit
R001a : une pièce peut équiper zéro à plusieurs équipements
R001b : un équipement peut être équipé de zéro à plusieurs pièces

Dans votre règle initiale, il manquait le nombre mini d'équipements qu'une pièce pouvait équiper, je l'ai ajouté (Zéro dans mon exemple, à corriger si besoin)
De plus, vous n'aviez donné la règle de gestion que pour aller de "pièce" vers "équipement", il faut également mentionner la règle de gestion dans l'autre sens, c'est ce que j'ai fait avec la règle R001b. Là aussi les cardinalités sont à titre d'exemple, vous devez les adapter à votre contexte.

Si je reprends le mini-MCD que je vous avais proposé dans ma réponse n° 14 du 28 février, on a une relation ternaire. Vu qu'il faut à minima 2 règles de gestion par "patte" d'une relation (une dans chaque sens comme expliqué ci-dessus), ce mini MCD implique à minima 6 règles de gestion.
Il peut y avoir parfois plus de 2 règles par patte, on y reviendra plus tard si nécessaire

[LecGaël]

Merci pour votre réponse aussi rapide, si je comprend bien R001a correspond à 0-n entre Organe et Être et R001b correspond a 0-n entre Etre et Equipement ?

Les règles serait donc:
R002a Une pièce a au minimum 0 Famille et au maximum une (je prends 0 minimum au cas ou on veuille rentrer une pièce et ajouter sa famille plus tard)
R002b une Famille est lié obligatoirement à une pièce.

Pour cette exemple on voit clairement que Famille serait clairement un attribut de la pièce en POO et non pas une entité à part entière car même si il y a une dizaine de familles différentes ce n'est n'y plus ni moins qu'un attribut...

Je ne sais pas si il est nécessaire d'avoir une entité famille .... le seul point commun que je peux y voir c'est être sur que la famille renseignée sur un organe figure bien parmi une liste de famille pré-définie.

Pour ce qui est de OrganeEquipement, il n'y a pas de relation à proprement parlé entre cette table et la table Équipement et la table Organe, à mes yeux cette table est en elle même une relation, elle lie les idOrgane avec les idEquipement.


J'ai tellement de mal à aborder ce principe de relation et d'entités avec les bases de données.

EDIT: D'ailleurs je m'apercois que je me suis trompé, un Organe est obligatoirement dans un Équipement, sinon c'est juste un organe sur le papier qui est nul part... ?

[escartefigue]

Merci pour votre réponse aussi rapide, si je comprend bien R001a correspond à 0-n entre Organe et Être et R001b correspond a 0-n entre Etre et Equipement ?

Oui, on trouve dans les règles de gestion les "individus" concernés par ces règles (les "individus" sont les types d'entité, les rectangles du MCD donc). Ainsi, quand j'écris à titre d'exemple

R001a : une pièce peut équiper zéro à plusieurs équipements : le sujet de R001a est "pièce", le complément d'objet est "équipement" ; "pièce" et "équipement" sont les individus de la relation
R001b : un équipement peut être équipé de zéro à plusieurs pièces : le sujet de R001b est "équipement" et le complément d'objet est "pièce"

R001a permet d'aller de la pièce vers l'équipement
R001b permet d'aller de l'équipement vers la pièce

Mais dans le MCD vous avez choisi un nouveau nom "organe" à la place de pièce , alors que j'expliquais dans ma réponse précédente qu'il faut choisir un et un seul terme pour éviter les confusions...
Si dans la règle, le sujet ou le compélement est la pièce, dans le MCD on modélise un type d'entité "pièce" si vous préférez "Organe" qu'à cela ne tienne, mais utilisez "Organe" partout !

Les règles serait donc:
R002a Une pièce a au minimum 0 Famille et au maximum une (je prends 0 minimum au cas ou on veuille rentrer une pièce et ajouter sa famille plus tard)
R002b une Famille est lié obligatoirement à une pièce.

En général on autorise la création des typologies (codes familles, codes catégories, codes devises, codes unités de mesure...) sans exiger l'existence d'au moins une occurrence rattachée. Ca permet d'anticiper les actions et facilite la vie.

Pour cette exemple on voit clairement que Famille serait clairement un attribut de la pièce en POO et non pas une entité à part entière car même si il y a une dizaine de familles différentes ce n'est n'y plus ni moins qu'un attribut...

Je ne sais pas si il est nécessaire d'avoir une entité famille .... le seul point commun que je peux y voir c'est être sur que la famille renseignée sur un organe figure bien parmi une liste de famille pré-définie.

Si vous utilisez seulement un code famille, sans libellé, ont pourrait imaginer une solution sans créer l'entité-type famille en posant une simple contrainte "check" sur la table "pièce" résultante.
Mais d'une part l'absence de libellé risque de provoquer des erreurs (certains utilisateurs confondront les codes), d'autre part, si un jour vous devez lier la famille à autre chose que les pièces, il y aura probablement d'autres erreurs et une double maintenance de la contrainte check (autant de fois que de tables liées aux familles)
Mauvais idée : conservez l'entité-type "famille"

Pour ce qui est de OrganeEquipement, il n'y a pas de relation à proprement parlé entre cette table et la table Équipement et la table Organe, à mes yeux cette table est en elle même une relation, elle lie les idOrgane avec les idEquipement.

Tout à fait, c'est une table elle n'a donc rien à faire dans un MCD dans lequel ne doivent apparaitre que des types d'entité (ou entités-type) et des relations (ou associations)
Les tables apparaitront quand on génèrera le MLD ou le MPD à partir du MCD, mais on n'en est pas encore là