Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Candidat au Club
    Homme Profil pro
    Artisan
    Inscrit en
    octobre 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Artisan
    Secteur : Bâtiment

    Informations forums :
    Inscription : octobre 2018
    Messages : 2
    Points : 2
    Points
    2

    Par défaut Conception base de gestion d'un atelier d'agencement

    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 :

    Nom : base.PNG
Affichages : 90
Taille : 12,0 Ko

    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.

  2. #2
    Membre expérimenté Avatar de hyperion13
    Homme Profil pro
    Calot120 - Enseignant Post Bac
    Inscrit en
    octobre 2007
    Messages
    1 120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Calot120 - Enseignant Post Bac
    Secteur : Enseignement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 120
    Points : 1 726
    Points
    1 726

    Par défaut

    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.)
    "Le savoir est la seule matière qui s'accroit quand on la partage" (Socrate)
    GMT+4 - 21°19'18" S - 055°25'32" E
    Inutile de me contacter par MP
    Merci de cliquer sur si la réponse est pertinente. N'oubliez pas svp de clôturer le sujet en cliquant sur

  3. #3
    Modérateur

    Homme Profil pro
    Inscrit en
    octobre 2005
    Messages
    12 561
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations forums :
    Inscription : octobre 2005
    Messages : 12 561
    Points : 19 141
    Points
    19 141

    Par défaut

    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+
    Vous voulez une réponse rapide et efficace à vos questions téchniques ?
    Ne les posez pas en message privé mais dans le forum, vous bénéficiez ainsi de la compétence et de la disponibilité de tous les contributeurs.
    Et aussi regardez dans la FAQ Access et les Tutoriaux Access. C'est plein de bonnes choses.

  4. #4
    Candidat au Club
    Homme Profil pro
    Artisan
    Inscrit en
    octobre 2018
    Messages
    2
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Artisan
    Secteur : Bâtiment

    Informations forums :
    Inscription : octobre 2018
    Messages : 2
    Points : 2
    Points
    2

    Par défaut

    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

  5. #5
    Membre expérimenté Avatar de hyperion13
    Homme Profil pro
    Calot120 - Enseignant Post Bac
    Inscrit en
    octobre 2007
    Messages
    1 120
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Calot120 - Enseignant Post Bac
    Secteur : Enseignement

    Informations forums :
    Inscription : octobre 2007
    Messages : 1 120
    Points : 1 726
    Points
    1 726

    Par défaut

    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.
    "Le savoir est la seule matière qui s'accroit quand on la partage" (Socrate)
    GMT+4 - 21°19'18" S - 055°25'32" E
    Inutile de me contacter par MP
    Merci de cliquer sur si la réponse est pertinente. N'oubliez pas svp de clôturer le sujet en cliquant sur

Discussions similaires

  1. [AC-2007] Aide conception base gestion des Charges de production
    Par rch05 dans le forum Modélisation
    Réponses: 12
    Dernier message: 16/06/2011, 16h30
  2. conception base gestion de stock
    Par lambac dans le forum Modélisation
    Réponses: 6
    Dernier message: 12/09/2008, 11h04
  3. Conception base de gestion maison de retraite
    Par NATH02 dans le forum Modélisation
    Réponses: 12
    Dernier message: 08/09/2008, 14h31
  4. [Conception] base de données pour gestion de salles
    Par lydia99 dans le forum PHP & Base de données
    Réponses: 3
    Dernier message: 29/05/2007, 22h56
  5. [conception] Base de Gestion de stock
    Par mytika dans le forum Modélisation
    Réponses: 1
    Dernier message: 18/01/2007, 12h32

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo