Discussion :

[fab.85]

Bonjour,

je me lance dans un nouveau projet de localisation d'article.

Dans mon entreprise, nous avons plusieurs bâtiments(TBatiments) avec plusieurs pièces( TPieces) et aussi plusieurs emplacements( TEmplacement).

Je compte numéroter les pièces en enfilade de 1 à ... Sans recommencer le compte pour chaque bâtiment.

Soit 1 à 10 (Bâtiment 1)
11 à 14 (Bâtiment 2)
etc...

J'entends par emplacement à l'intérieur de la pièce:

1-Plafond
2-chevet
3-porte
4-Etc...

Mon but est de savoir quel article se trouve à un emplacement précis.Comme par exemple savoir quelle ampoule se trouve dans le plafonnier de la pièce 50.

Je joins ma première idée en espérant avoir vos avis et remarques éventuelles..

D'avance merci pour votre aide.
Fabien.

[marot_r]

Bonjour.

J'aurai fait la même chose.

Il y a juste un point qui m'intrigue tu mentionnes :

quelle ampoule se trouve dans le plafonnier de la pièce 50

Avec ton modèle, si je l'ai bien compris, si la pièce 50 à 4 plafonniers tu ne pourras pas distinguer chaque plafonnier à moins de créer un emplacement par plafonnier.

A+

[fab.85]

Bonsoir marot r,

Tout d'abord merci ça fait plaisir 😊

En effet je pense la même chose, j'avais pour exemple une porte qui dispose de plusieurs articles comme une serrure, des paumelles, un ral de couleur etc.

J'avoue avoir comme seule réponse d'augmenter la liste des emplacements aux risques de s'y perdre...

Si tu as une idée. ..

[marot_r]

Personnellement je pencherai pour l'ajout d'un niveau (optionnel ?) : Numéro emplacement (entier long) ou position emplacement (texte, 255 caratères).
Si tu choisi texte, pour les plafonniers tu pourrais mettre "Nord, Sud, est, Ouest" ou "Au fond à gauche, devant à droite", bref une indication géographique pour localiser le plafonnier.

Une autre approche serai d'identifier les élément avec un numéro unique ex : Porte 23, Plafonnier 154. Ce numéro resterai toujours attaché à l'élément.
Cette solution te permet un inventaire facile (quoi que fastidieux) de tes éléments. Tu pourrais ainsi savoir combien tu as de plaffoniers, de portes ou de chevets.
Je conçois que pour les portes cela présente peu d'intérêt. Il est rare qu'on déplace une porte, mais pour des éléments mobile comme un chevet ça pourrait être utile.
Cette identification unique permet aussi de suivre la vie de tes éléments en ajoutant des informations de date et autre.
Ex : Avec une date d'achat, une date de retrait et un motif de retrait tu pourrais savoir que le plafonnier 154 est mort au bout de 2 ans d'utilisation.

A+

[fab.85]

merci pour cette réponse,

est-ce que ajouter un niveau signifie ajouter une table ou seulement un champ (texte)dans la table TEmplacement?

Pour ce qui est du marquage, un marquage physique est déjà en cours.

Ce qui nous intéresse c'est avant tout "Faire bon du premier coup" en intervenant avec juste le matériel nécessaire.

En plus d'une remarque j'ai aussi pensé à une photo puisque le cas ou il y aurait plusieurs éléments (important) au mêmes endroits est assez rare..

A+

[marot_r]

est-ce que ajouter un niveau signifie ajouter une table ou seulement un champ (texte)dans la table TEmplacement?

Cela dépend un peu du besoin et de la manière dont tu veux le traiter.

Je ne pense pas que ce soit dans TEmplacement qu'il faille le mettre. D'après moi ce n'est pas reliés à l'emplacement, c'est relié a l'objet dans la pièce donc je le metterai dans TLocalisation.

• Si tu souhaites contrôler les "Place géographique" alors une nouvelle table est nécessaire.
• Si tu veux laisser le champ libre à la personne qui saisie, seul un champ est utile dans la table.
• Si tu veux limiter la variété tout en laissant le champ libre, dans le formulaire, tu peux mettre une liste déroulante qui présente les PlaceGeographique déjà saisie.
  Un truc du genre

  Code sql :

  Sélectionner tout - Visualiser dans une fenêtre à part

  select [TLocalisation].[PlaceGeographique] from [TLocalisation] group by [TLocalisation].[PlaceGeographique] order by [TLocalisation].[PlaceGeographique]

  À mettre à jour à chaque réception du focus.
  Comme cela les [PlaceGeographique] déjà saisie seront présentées à l'utilisateur et il pourra s'il ne trouve pas son bonheur ajouter un nouveau.
  La MAJ à réception du focus fait que les nouvelles entrées sont visibles à la prochaine utilisation.
  C'est une solution que j'aime bien car elle ne nécessite pas la gestion d'une table de référence en ayant presque le même résultat.

Un tout petit point à propos de ton modèle comme les pièces ne sont pas reliées aux bâtiments, il est possible que quelqu'un saisissent une pièce qui n'est pas dans le batiment. Ex : pièce 15 dans le bâtiment 1.

Si tu peux vivre avec cela, je pense que tu peux le laisser ainsi. Personnellement je fais confiance à l'intelligence de mes utilisateurs.

Sinon, il va falloir ajouter la [ClefBatiment] à la table des pièces en jointure sur la table des bâtiments et faire une jointure double entre TPiece et TLocalisation sur [ClefBatiment] et [ClefPiece].
Avec cela, seules les pièces du bâtiment pourront être associée dans la table TLocalisation.
Cela donne :

• TBatiment (ClefBatiment) <-> TPiece (ClefBatiment)
• TPiece (ClefBatiment, ClefPiece) <-> TLocalisation (ClefBatiment, ClefPiece)

puisque l'information sur le bâtiment est un attribut de la pièce.

La table TBatiment n'est plus reliée directement à la TLocalisation.

A+

[fab.85]

Bonjour,

l'idée de relier les pièces aux bâtiments m’intéresse même si je serais le seul utilisateur de la base.

Mais j'ai un souci pour effectuer les relations. (je ne savais pas que l'on pouvais relier deux clefs primaires)

Voila ou j'en suis:



J'ai du rater quelque chose...

[marot_r]

Bonjour.

Quand tu dois faire une relation avec une clef composée, il faut mettre tous les champs de la clef composée dans la relation.

A+

[fab.85]

Excuse moi mais je ne comprends pas..

[marot_r]

Bonjour.

Là tu as juste le champ NumPiece dans ta relation.
Comme il manque un morceau de clef, Access ne peut pas activer l'intégrité référentielle.
Il faut ajouter NumBatiment des 2 côtés.

Pour les noms d'objet, il est recommandé de se limiter aux lettres majuscules et minuscules non accentuées, aux chiffres et au souligné (_).
Même si Access accepte à peu prés n'importe quoi comme noms, cela évite des bugs bizarre et sournois.
Si tu as besoin de texte plus agréable pour l'être humain, utilise un formulaire et des étiquettes pour les présenter.

A+

[fab.85]

Ok ca marche.

Juste une petite question puisque c'est nouveau pour moi, une table TPieces_1 vient de se créer dans le schéma mais pas dans la liste des tables.

Je suppose que je dois supprimer TPieces sur mon schéma et garder TPieces_1.

Quid de TPieces dans ma liste?

[fab.85]

Bonjour,

je viens d'importer les tables dans une nouvelle BD et tout me semble OK.

Merci de me confirmer que je peux me lancer dans la creation des requetes, formulaires et autres "divertissements" que propose Access...



A+

[f-leb]

Bonsoir,

Il y a encore quelque chose qui cloche avec les relations, notamment la -1-----1- ...

Soit on identifie la pièce relativement au bâtiment avec le couple (idBatiment, NumPiece) comme clé primaire :

La pièce n°1 du bâtiment 15 est de type "Salle de bain", la pièce n°2 du même bâtiment 15 est de type "Cuisine", la pièce n°1 du bâtiment 23 est de type "salon", etc.

Auquel cas le reste du schéma pourrait être :

Mais il faut coder le processus de numérotation des pièces relativement aux bâtiments.

Soit on identifie la pièce de façon absolue avec un NuméroAuto (idPiece). Certainement la solution la plus simple :


Et le schéma deviendrait :


À voir...

[fab.85]

Bonjour,

merci pour cette proposition, je vais quand même prendre un peu de temps pour tout comprendre...

-Le NuméroAuto (idPiece) est-il strictement obligatoire? car je ne suis pas un grand fan du NuméroAuto surtout lorsque l'on fait beaucoup d'essais.

cordialement,

Fabien.

[fab.85]

Je viens de reproduire le dernier schéma proposer, mais malheureusement la relation entre TBatiments et TPieces reste de 1 à 1.

Comment fait-on pour "forcer" une relation de 1 à plusieurs?

Cordialement,

[f-leb]

Bonjour,

Toutes mes excuses, je viens de corriger les deux derniers schémas de mon message précédent, ils étaient faux

Concernant ton problème, tu as sans doute mis un index "Oui - sans doublons" sur une clé étrangère.

[fab.85]

Merci pour la modif,

j'ai ajouté une table TOrientations car je souhaitais que TLocaliser fonctionne ainsi:

-Pièce 1,Emplacement 1, article 1, avant
-Pièce 1,Emplacement 1, article 1, arrière
-etc..
Il se peut que je dispose de plusieurs plafonniers sur un même plafond.

cela peut-il poser problème par la suite?

merci.

[fab.85]

Voici mon dernier schéma,

Les tables TArticles,TCategorie,TSouscategorie et TClients proviennent d'une autre BD je ne peux donc pas les renommer, je composerais avec les étiquettes dans les formulaires respectifs.

TBatiments est devenue TClients (nous sommes notre propre client).

Puis-je me lancer avec ceci? merci pour vos remarques.



Cordialement,

Fabien.

[f-leb]

Il se peut que je dispose de plusieurs plafonniers sur un même plafond.

On peut voir ça comme autant d'emplacements. 4 plafonniers sur le même plafond=4 emplacements différents.

Si on poursuit la logique, Emplacement-->Pièce--->Bâtiment(Client) :



OrientationEmplacement ou idOrientationEmplacement vers une table.

À voir, c'est selon...

[fab.85]

Bonjour,

merci pour le schéma proposé, je vais commencer avec celui-ci. J'avoue qu'il y a une fameuse gymnastique à faire pour s'y retrouver mais il me semble que ce soit la formule idéale pour ce que je veux faire.

Merci f-leb et marot_r pour votre aide.

Cordialement,

Fabien.