Discussion :

[tp2415]

Bonjour à tous,

Je suis artisan dans le domaine du bois et je cherche à remettre à plat une solution de calcul rapide de chiffrage pour des travaux d'agencement. Actuellement, nous utilisons un ensemble de classeurs Excel liés entre eux qui comprennent chacun plusieurs tableaux. Au regard de la somme d'information, inutile de dire que c'est une usine à gaz. Je pensais donc mettre tout ça au propre grâce à Access.

La première question que je me pose et pour laquelle je sollicite votre avis concerne le "catalogue" article.

Actuellement (Excel) j'ai un tableau par famille d'articles (Bois massif, panneaux, quincaillerie, finition, chants, verre ...) cette liste est (peut-être) susceptible d'évoluer dans le temps. Chaque famille a ses spécificités : par exemple les panneaux sont fournis dans des dimensions standards et donc comptabilisés en m2 alors que le bois massif est comptabilisé en m3. Les chants sont en mètres linéaires, la quincaillerie est comptabilisée à l'unité. Donc les unités ne sont pas les mêmes en fonction des catégories.

Par défaut, il me semble logique de créer une seule table pour les matériaux comportant l'ensemble des dimensions ou quantités possibles (taille panneaux, longueur, largeur, épaisseur ...) . Elle serait lié à une table catégorie selon la relation :

"Catégorie" 1->N "Materiaux"

Au minimum, j'aurais aussi besoin d'une table "Formats panneaux" qui contiendrait la liste des formats de panneaux standards (2440x1220, 2800x2070, 3050x1530 ....) susceptibles d'évoluer
Je formule la liaison de la façon suivante : " Un materiaux peut avoir 0 (ce n'est pas un panneau) à 1 format et un format peut appartenir à 0 ou plusieurs matériaux"

Donc la liaison serait :

"Materiaux" 0->N "Formats panneaux"

On peut imaginer aussi une table pour la longueur des rouleaux de chants, le volumes des bidons de finitions ... mais je ne trouve pas ça très utiles puisque ce sont des données évidentes à mémoriser lors de la création des articles.

Ci-joint une première ébauche des relations :



Cette conception vous semble-t-elle correcte ou vaut-il mieux garder la logique multitables ?
Est-il correct d'envisager de construire une requête par famille de matériaux afin de construire les formulaires adaptés à chaque famille (par exemple ML pour les chants mais m² pour le verre).

Accessoirement j'ai trouvé cette explication qui me semble pertinente pour mon usage mais je ne suis pas sur d'avoir tout compris (création d'une table pour les différentes caractéristiques ? ) : https://merise.developpez.com/faq/?p...s-d-une-entite

Merci d'avance pour vos conseils éclairés.

[hyperion13]

Bonjour,
La contrainte de partition est une bonne approche.
Toute occurrence de l'entité générique tblMateriaux appartiendra à au moins l'un des sous-types (tblPanneau, tblBoismassif, etc.)
Toute occurrence de l'entité générique devra appartenir qu'à un seul des sous-types
tblMateriau(idMat, libelle, ?encollage?, idTypeMat#, unite, etc.)
tblPanneau(idMat, description, largeur, longueur, etc.)
tblBoismassif(idMat, description, largeur, hauteur, profondeur, etc.)

[marot_r]

Bonjour.

Il y a plusieurs approches pour ce probleme.

• La plus directe est d'avoir une table par type d'article (ex : une table des panneaux, une table des tuyeau, une table des bois massif).
  Chacune de ces tables ayant ses champs particuliers.
  
• Une autre est d'avoir une table "commune" qui regroupe les informations communes a tous les materiaux (ex : unite de facturation, nom) et une table de detail selon le type de materiaux qui contient des champs specifiques (ex longeur pour les tuyeaux, longeur et largeur pour les panneaux).
  
• Et, il y a la solution "one size fit all" (ou taille unique) qui avec une seule table permet de gerer tous les types de materiaux quite a avoir des champs intiles.
  Donc par exemple tu as les 3 champs longuer, hauteur, largeur et pour
  
  1. le bois massif tu utilises Longeur, Largeur et Hauteur,
  2. pour les paneaux Longueur et largeur
  3. pour les tuyeaux : longueur seulement.
  
  
  Les champs inutilises restent a 0 ou vide.
• La solution "Liste de proprieties"
  Cette option consites a avoir essentiellement 2 tables :
  Une tables d'identification et une table des "propriete" des chacuns des types.
  Cela resssemble a ce que tu vois quand tu concois un ecran Access, tu as des controles (textebox, listbox, etc) et chaque controle a sa liste de proprietes qui varient.

Il n'y a pas de solution parfaite mais voici mon avis sur la question.

• Le modele une table par type est a mon avis viable seulement si le nombre de types est limites et surtout peut susceptibles d'augmenter.
  Il presente le gros defaut, selon moi, que si tu veux une liste des tous tes materiaux, il faut faire une union de toutes tes tables.
  
• Le modele commun <-> specificite permet d'avoir de l'information particuliere (ex : quelque chose qui est vraiment uniquement utilise que par un article) tout en pernettant facilement des trucs comme "quelle est la liste de mes articles ?", que me fourni X comme articles.
  
• Enfin la solution de la taille unique est a considerer si tu a peux de champs inutiles. C-a-d que la plus part du temps tu vas te server d'une grande parties des champs et occasionnelement de certains.
  Son gros avantage est la simplicite du modele. Quand tu as besoin d'une information elle est la sous la main pas besoin de savoir dans quelle table la chercher.
  De plus il est elativement facile de cacher ou d'interdire l'usage de certains champs en function du type donc, eventuellement avec un seul formulaire tu peux gerer TOUS tes articles.
  
• La solution avec les proprietes est SUPER souple mais peut etre un peu difficile a comprendre pour un humain "standard" et fait des interfaces qui sont une serie de listes.

La solution taille unique est ma preferee car elle est simple a mettre en oeuvre et a vivre. Pas de jointures compliquees, juste un jeux de cache cache pour que l'utilisateur ait l'illusion qu'il y a plusieurs tables articles.
La solution Commun<-> Specicite est mon second choix, souple mais precises. Elle necessite plus de travail car elle oblige a avoir des ecrans specifiques pour chaque type.
La 1ere solution une table par type est a mon avis seulement theorique car elle est assez contraignante pour la vie reelle.
La solution par liste de propretes, peut etre un peu demandante et contre intuitive. Je la recommanderai seulement aux informaticiens :-).

Je pense que la 1ere etape est d'etablir a quel point les cracateristiques de tes articles sont differents les un des autres
Aussi a quel point ces caracteristiqes peuvent evoluer (aurais-je besoin de plus d'information pour tel article (ex : qualite des panneaux, resistantce au feu).
Puis de la tu auras une meilleur idee de quelle est la solution la mieux adaptee.

A+

[tp2415]

Hyperion, Je ne suis pas sur de comprendre la notion de partition. Certaines infos dans la table générique puis les compléments dans des tables "satellites" ? La solution table unique pour les matériaux et une table propriétés me semble être le Graal en terme de qualité de conception mais c'est vrai que c'est l'usine à gaz pour les requêtes. Je vais opter pour une table matériaux avec des champs pouvant être NULL. Après, je gérerai avec différents formulaires en fonction des matériaux en laissant accessible les champs correspondant ... Simplicité et je pense mère d'efficacité. Merci pour vos orientations

[hyperion13]

Dans votre 1er post, dernier paragraphe, vous indiquez qu'une solution pertinente pourrait convenir dans le développement de votre SI.
MERISE 2, au niveau MCD, a proposé une nouvelle approche pour représenter le plus fidèlement possible la réalité d'un SI.
Dans votre cas et pour la modélisation de votre SI, on mettrait en évidence une contrainte de spécialisation, la contrainte de partition (xT)
Rien ne vous oblige à construire votre SI avec de telles contraintes.