Discussion :

[adnbasse]

Bonjour à tous,
je travaille dans une association, et je suis en train de créer une base de données pour celle-ci, j'ai déjà réussi à prendre en compte tous les actes que nous faisons avec nos usagers, mais j'ai un problème concernant la gestion de stock.

j'ai pour l'instant plusieurs tables :
USAGERS : IdUsager, Sexe, Annéenaissance, ...
PASSAGE USAGERS : N°Passage, Date, IdUsager, Acte1, ...

PARTENAIRES : IdPartenaire, Adresse, Tel, ...
PASSAGE PARTENAIRES : N°PassagePartenaire, Date, Idpartenaire, ...

FESTIF : N°Festif, Date, Lieu, NbPersonnes, ...

MATERIEL : IdMatériel, Description, Catégorie

AUTOMATE : N°PassageAutomate, Ville, Date, Kits, ...

Nous avons donc les usagers et les partenaires qui peuvent prendre du matériel lors de leurs passages, nous donnons également du matériel lors du festif, et nous avons des automates qui peuvent donner seulement un type de matériel.
Nous sortons également plusieurs matériels, lorsque nous faisons des kits (exemple : objet1 + objet2 = objet 3) et lorsque certains matériels sont périmés ou cassés. nous reapprovisionnons aussi le matériel.

Quelles tables devrais-je créer afin de pouvoir relier les différents "endroits" de sorties pour gerer notre stock et avoir un inventaire par exemple pour connaitre l'état du stock à un moment T ?

J'espere ne pas etre trop brouillon dans mes explications.
Merci d'avance
Ben

[marot_r]

Pour simplifier je te recommande d'avoir une table des emprunteurs qui va regrouper tous les types d'emprunteurs et avoir tous les champs nécessaires pour chacun des emprunteurs.

Table Emprunteur
ClefEmprunteur
ClefTypeEmprunteur
InfoPourEmprunteur_TOUS
InfoPourSpecifiqueEmprunteur_PARTENAIRES
InfoPourSpecifiqueEmprunteur_USAGERS
InfoPourSpecifiqueEmprunteur_FESTIF
InfoPourSpecifiqueEmprunteur_AUTOMATE

Table TypeEmprunteur
ClefTypeEmprunteur
CodeTypeEmprunteur
LibelleTypeEmprunteur

À l'affichage tu masques les champs qui ne sont pas utiles pour un type d'emprunteur donné. Même si ce n'est pas 'Troisième Forme Normal', c'est plus facile que d'avoir les infos pour chaque type d'emprunteur dans une table séparée.

Ensuite tu as une table pour le matériel

Table Materiel
ClefMateriel
Autres infos sur materiel

Table MouvemenStock
ClefMouvement
ClefEmprunteur 'Null pour les entrées de stock, obligatoire pour les sorties
ClefTypeMouvement
ClefMateriel
DateMouvement

table TypeMouvement
ClefTypeMouvement
CodeTypeMouvement
LibelleTypeMouvement

Les types sont :

• Achat
• Vente
• Emprunt
• Mise au rebut

A+

[adnbasse]

Merci, mais j'aurais voulu savoir si j'aurais pu lier des tables de stock au tables déjà existantes (car les tables sont très différentes et ne regroupent pas les mêmes informations, et j'ai déjà fait les requètes qui vont avec), et par quelles tables ceci pourrait etre possible.
Bonne journée
Ben

[marot_r]

Si tu tiens à garder des tables séparées alors regarde ici :

Héritage dans une base de données Access

http://warin.developpez.com/tutoriel...onnees-access/

C'est exactement ta problématique.

A+

[mumen]

Salut

Si tu tiens à garder des tables séparées alors regarde ici :

Héritage dans une base de données Access

http://warin.developpez.com/tutoriel...onnees-access/

C'est exactement ta problématique.

A+

Tu vois, René, en plus de vingt cinq ans de métier, j'ai développé des tas de logiciels de gestion, dont une gestion de librairies, une gestion de Vépéciste, une gestion de couvreur qui avaient toutes les trois une gestion de stock bien gratinée.

Et ben je dois dire que ce doc, j'aimerai bien y comprendre quelque chose... J'ai loupé quelque chose, tu crois ?

Heu, je veux dire que c'est sans doute prendre un marteau pour enfoncer une punaise, qu'il y a sans doute une autre façon de dire les choses

[marot_r]

Désolé mais j'ai trouvé cela très clair donc peux-tu préciser ce qui te pose un problème ?

A+

[mumen]

Désolé de ne pas m'être montré clair. De plus, j'ai laissé transparaître une irritation de manière sans doute déplacée. Que tu ne t'y laisse pas prendre en me donnant un espace de discussion est à mettre à ton crédit. Pour ma défense, je cite le fait que je ne connais pas encore suffisamment les us et coutumes du lieu et que je peux m'emballer un peu facilement dans des situations que je crois reconnaître, parfois à tort. De bonnes surprises m'attendent ici dirait-on.

Le tutoriel que tu montres fait référence à des techniques évoluées, qui font appel à un vocabulaire à la pointe de l'analyse de gros projets. Comprendre ce texte pour une personne non initiée telle que moi, et je postule peut être à tort, par l'auteur de la question requiert un engagement disproportionné pour la résolution du problème, il m'a semblé.

Quand je suis devant un problème tel que soulevé ici, je cherche des solutions de manière intuitive qui sont peut être les mêmes que me diront la théorie de l'héritage. Je n'en sais rien. Le cas échéant, j'aurais été intéressé de comparer mes solutions intuitives au résultat de l'analyse théorique plutôt que d'être confronté d'emblée à un texte d'une telle complexité pour moi.

Je suis certain de la pertinence de ta contribution ("C'est exactement ta problématique") dans le problème posé, mais peut être n'a tu pas envisagé que la personne à laquelle tu réponds soit dans le même état d'esprit que moi et puisse se sentir écrasée par la hauteur de la réponse ?

[marot_r]

Pas de problème. Il m'arrive en effet de faire de réponses un peu sèches. J'ai beaucoup de difficultés à expliquer ce qui est pour moi une évidence.

Revenons à ton problème qui n'est pas simple en lui-même.

Tu as plusieurs entités étéroclytes que tu veux gérer de façon uniforme. C'est typiquement un problème qui se résoud facilement avec une modélisation Objet (le sujet de tutoriel). Évidement si tu n'as jamais abordé ce mode de modélisation la marche est haute (je sais je l'ai mangée dans les dents il y a environ 15 ans :-).

L'autre problème c'est que les bases de données relationnelles ne sont vraiment bien adaptées pour modéliser facilement des objets et qu'il faut pas mal bricoler pour y arriver.

Pour faire un exemple très simple : tu as des singes, des lions et des hypocampes et ce sont tous des animaux ... et ce que tu veux gérer ce sont des animaux mais tu souhaites tout de même savoir que ton animal est un singe, un lion ou hypocampte.

La 1ère solution que je t'avais décrite est la plus simple techniquement. C'est d'avoir une table Animal où tu mets toutes les caractéristiques de tous tes animaux. Evidement la salinité de l'eau ne sert à rien pour les lions ou les singes et le fait que les singes mangent des bananes intresse peu l'hypocampe. Bref, cette solution fait que tu perds de la place de stockage.

L'autre solution est d'avoir une table par entité (ce qui est normalement la "bonne" façon de modéliser).

Comme tu as beaucoup investi dans ce modèle, je te suggère de créer une

table Emprunteur :
ClefEmprunteur
NomTableSourceEmprunteur
ClefTableSourceEmprunteur

Et la table Emprunt :
ClefEmprunt
ClefEmprunteur
ClefElement
DateEmprunt
Autres infos sur emprunt

Si tu veux afficher le détail d'un emprunteur il te faudra faire un test sur le champ NomTableSourceEmprunteur.

Et tu ne peux pas avoir de rélation d'intégrité référentielle entre tes emprunteurs et tes divers tables de type d'emprunteur. Ce qui veut dire que si tu supprimes un emprunteur dans sa table spécifique il pourrait toujours exister dans la table 'générique'.

Note qu'avec Access 2010 et ses macros de données ce problème peut être résolu par programmation.

J'espère que c'est plus clair maintenant mais n'hésite pas à poser d'autres questions si tu as besoin.

A+

[adnbasse]

Voici où j'en suis dans les relations de ma base de données. (voir piece jointe)
Grace à votre tuto j'ai pu créer la table Commande et la relier avec mes autres tables.
C'est vrai que le tuto est conséquent mais je pense l'avoir compris vaguement et il m'a permis de reflechir autrement, vous me direz si l'idée est là.
Après par rapport au contenu de mes tables Détail commande et Matériel , je ne sais pas si c'est suffisant ou même si cela est convenable.
Merci de vos conseils.
En tout cas il me semble me rapprocher de la fin...

[marot_r]

Ça parait pas mal.

J'espère que tu n'auras pas de nouvelle catégorie car sinon il va falloir modifier ta table commande.

Dans ta fenêtre de relation essaye d'éviter de croiser les fils (les relations) cela rend le diagramme plus lisible.

A+

[adnbasse]

Merci de votre aide, pour la modélisation c'est ok, il me reste à attaquer les requêtes inhérentes.

Sinon pourquoi devrais-je modifier ma table commande si j'ai une nouvelle catégorie ?

Merci

[marot_r]

Sinon pourquoi devrais-je modifier ma table commande si j'ai une nouvelle catégorie ?

Désolé mon erreur, je devais penser à une nouvelle table pour les types d'éléments.

A+