Avis sur relations BDD

Re,

difficilement visible ton image...

Et sans connaître exactement le cahier des charges, difficile !

Mais, je te le redis comme déjà fait (dans une autre discussion), on ne "met pas à jour un stock" en table, le contenu du stock doit être calculé au moment M.

A priori, manque un type 1,N entre la table commande et la table Fournisseur (et mettre en clé primaire le nom du fournisseur n'est pas la meilleure idée), et quelle différence entre id_fournisseur et code_fournisseur dans la table article ?

Aussi, à quoi sert la table mvt_art ?

Et différences entre les prix (je ne reviendrai pas sur le TTC...) des tables ligne_commande et article ?

A+

Salut,

quand tu donnes un article à un service, on va dire par exemple un toner pour Copieur Ricoh 1515MF au service Paie, est-ce important pour toi de savoir si c'est un toner acheté à un fournisseur en particulier ou pas et à quel prix il a été acheté à l'époque ?

A+

SDalut,
je suis d'accord avec les remarques qui ont été faites mais là on n'a qu'un MCD sans le reste.
Il m'apparaît qu'il y a plusieurs sous-tables qui n'ont pas lieu d'être.
Par exemple les entités "commandes" et "lignes commandes" quelles différences?
Pour les identifier on peut mettre la date à la seconde près en supposant qu'aucune commande ne peut être fait à la même seconde et pour régler ce problème possible rajouter le client en identifiant(clé étrangère sur le MLD).

Donc avant tout vos étapes 2 et 3 de l'analyse n'ont pas été respectées alors pas possible de faire des regroupement d'entités qui corresponde à quelque chose de réel.

Dans la règle de l'analyse (étape regroupement en entité):Une entité c'est un regroupements de données/informations qui ne peuvent exister indépendamment l'une de l'autre.
Comment peut on avoir une commande qui n'a pas de ligne de commande? Est ce une demande spécifique ou une erreur d'analyse?
Les contraintes et relations sont là pour mettre en évidence des relations (qui serons reprises par le programme)et non multiplier les possibilités(qui compliqueront le développement comme la maintenance et même l'utilisation dans certains cas).

Concrètement un article définit par son ID peut faire partie d'une commande.
Donc une commande à une idée.
Si on veut différencier des lignes dans cette commande (pourquoi?, une commande du même client du même article peut donner lieu à différente commande(date ou id si la commande est le même jour) le reste comme la quantité est une donnée calculable donc n'a rien à faire dans des entités/tables).

C'est le problème si on utilise un logiciel de modélisation directement, la tentation de passer outre es éléments de l'analyse apparaît et cela fausse tout.

Même remarque par exemple pour service et imprimantes:
Dans votre modèle un service est uniquement lié à l'entité imprimante. Donc on peut supposer que le service peut être enregistré dans l'entité imprimante et cela n'empêchera pas de pouvoir retrouver quel service a utilisé quelle imprimante ni que plusieurs services puissent utiliser la même imprimante et un seul service utiliser plusieurs imprimantes... tout en retenant l'information(les 2 deviennent alors identifiants et on peut retrouver pour une imprimante toute les fois où celle ci est utilisée par un service comme les autres possibilités).

Ma question et ta réponse, servent à comprendre une partie des contraintes, donc du modèle que tu devras mettre en place.

Avec ta réponse négative, ton MCD me parait être, désolé de le dire, une usine à gaz.

Un truc impossible à maintenir et à développer.

Dois tu impérativement gérer les prix d'achat ? Et que viennent foutre là les budgets ???? Si tu ne tiens pas compte des prix (ta réponse), quel lien feras tu ?? (exemple, tu refourgues à un service un Toner acheté au rabais à l'occasion de la liquidation totale d'un fournisseur, tu vas imputer quel prix à quel service ?). Soit tu gères un stock en nombre de pièces, soit en terme de budget, ce qui n'a rien à voir à modéliser.

Je pense qu'au lieu de nous mettre un MCD ici, donnes EXACTEMENT tout ce que l'on te demande.

A+

re,

mais quel incidence sur les budgets ? Quand tu achètes, tu imputes cela sur le budget d'un service, même s'il ne consomme pas ????

Sinon, j'ai un peu de mal à suivre !

Quand je dis que "tu veux réinventer la roue", c'est que tu veux gérer en définitive un stock, et que des dizaines d'exemples sont dispos. Donc tu as l'air de t'éloigner de ce qui t'est demandé, et que tu inventes une roue carrée alors que l'on (ton employeur j'imagine) demande juste de faire avancer le carrosse... Et ce n'est pas péjoratif !!!!

A+

"qu'il y a l'histoire des budgets à prendre en compte..."

le budget est lié à la commande... donc il faut pas le séparer:
une commande peut elle exister sans budget?

Pour calculer un budget c'est la même chose qu'avoir le total du prix des articles d'une commande ou en tout cas(si budget supérieur ou inférieur) ce budget doit être retenu par commande(et ainsi être propre à chaque commande, ce qui résout le cas d'une famille qui peut changer de budget sans que l'on diove refaire le programme xd), c'est pour ça que je dit que le dictionnaire des données n'est pas complet et que les phases de recoupements ont été bâclées:

_ce qui est calculable doit être décomposé en ses composants
_les doublons doivent être supprimés

Ce n'est clairement pas le cas

Re,

personne n'a dit que tu étais borné, mais on découvre au fur et à mesure tes besoins, difficile de tout piger, et deviner, dès le premier message (surtout vu le mcd).

OK, compris pour le budget. Mais ta base ne fait pas doublon avec la compta ?

Et pourquoi ne pas gérer un contrat (que tu 'achètes') comme un article ?

Car, et d'après ce que tu as indiqué, tu 'gères' un toner (une charge en compta) de la même manière qu'un imprimante (normalement, une immobilisation).

Toi qui es "dans la partie", nos questions peuvent sembler bizarres, mais on ne connaît pas du tout le fonctionnement de ta boîte et ce que vous voulez vraiment. En gros, on est en train d'effectuer un "audit" en ce moment, pour ne rien oublier.

Mais, et pour résumer, si tu as :
Article (toner, contrat, imprimante...) acheté auprès de potentiellement différents fournisseurs à un prix donné le jour J pour un fournisseur F
Prix de cet article imputé à un budget (il va falloir penser au budget de départ, et sont-ils cumulables d'année en année)
Mise à dispo (don, enfin appelle cela comme tu veux) de cet article à un service (sans gestion du budget du service)

et bien ton MCD du début du thread me parait bien complexe.

A te lire...

A+

Nous ne sommes pas ici pour juger, mais pour t'aider, et pour aider, il faut comprendre... On a mis le temps (nécessaire), mais on y arrive doucement mais sûrement à priori !!! Vu ton MCD du départ, j'ai cru (et d'autres je pense, sans préjuger des facultés de chacun à analyser) à une gestion bien plus compliqué que celle qui s'est dégagée au fur et à mesure de tes réponses.

Je n'ai rien pris pour une critique, et je pense que les autres intervenants non plus, sinon, on n'aurait rien à faire sur un forum d'entraide, et je ne te répondrai pas à cette heure du soir...

Maintenant que les hostilités sont posées, revenons à ton souci.

Tu as beaucoup de tables inutiles pour ce projet (en gardant à l'esprit ce que l'on pourrait te demander dans 1 an, 10 ans)...

La seule question, avant d'avancer + en avant, est : tu as un budget par année, mais si non consommé, tu en fais quoi ? Et si consommé avant le bouclage N, quoi ?

Je pense que l'on va maintenant pouvoir avancer avec tes futures réponses.

A+