Discussion :

[planeurbret]

Bonjour, je suis en train de réaliser une base de données pour ma future appli de gestion d'entreprise. Cependant je me pose une question.
J'ai les lignes de devis qui seront présentes dans un devis, mais aussi dans un autre document. De ce fait je ne sais pas trop comment faire. J'ai fait ces deux schémas. Pouvez vous me donner vos avis ??

Merci a vous !

BreizhPyro v1.pdf

BreizhPyro V2.pdf

[ZenZiTone]

J'ai les lignes de devis qui seront présentes dans un devis, mais aussi dans un autre document.

Sur le schéma 1 : dans un devis tu as une ou plusieurs lignes. Pour chaque ligne tu as un spectacle et un produit?

[planeurbret]

Sur le schéma 1 : dans un devis tu as une ou plusieurs lignes. Pour chaque ligne tu as un spectacle et un produit?

Dans un devis j'ai généralement plusieurs lignes.

Cependant pour chaque ligne je n'ai pas un spectacle. J'ai un spectacle qui a plusieurs lignes.

Pour chaque ligne j'ai un produit.

[CinePhil]

1) Il est préférable d'écrire les noms des entités types au singulier.
=> Corriger Founisseurs, Lignes, Produits, et Caractéristiques.

2) Il vaut mieux externaliser les propriétés dont les valeurs se répètent.
=> Externaliser la ville et associer l'entité-type ville à Fournisseur, Client et Spectacle. Cela évitera la saisie de la même ville sous plusieurs orthographes.
On eut aussi mettre en cohérence le code postal et la ville pour éviter les erreurs d'adresse mais c'est un peu plus compliqué et éventuellement plus difficile à maintenir (changement de codes postaux, codes pour les cedex...).

3) Puisque le TypeProduit a été externalisé, pourquoi n'avoir pas externalisé sa catégorie ?
=> Créer une entité-type CategorieProduit et l'associer à Produit. À moins que catégorie et type ne soient la même chose ? Auquel cas il faut supprimer la propriété CatégorieProduit.

4) Au passage, pour nommer entités-types (futures tables) et propriétés (futures colonnes), n'utilisez que des lettres non accentuées, des chiffres et le caractère de soulignement. Ça évitera d'éventuels problèmes lors du passage au MLD et à la création automatisée des tables.

5) Un produit ne peut-il être enregistré avant d'avoir été livré une première fois ?
=> Mettre la cardinalité mini à 0 du côté du produit pour l'association Livrer.

6) Un produit peut sans doute être livré plusieurs fois par le même fournisseur.
=> Faire participer la date de livraison à la clé de l'association Livrer.


Venons-en à votre problème...

7) Le schéma 1, qui sépare bien les devis des factures, est évidemment meilleur que le schéma 2 qui mélange tout dans le spectacle.

8) Je crois comprendre que votre processus est le suivant :
Un client demande un devis pour un spectacle puis, une fois le devis accepté, il devient une commande et lorsque le spectacle est réalisé, cela fait l'objet d'une facturation.
Processus classique de n'importe quelle activité commerciale commençant par un devis.

Je pense donc qu'il faut que vous associiez Spectacle à Client et Devis à Spectacle.
Client -0,n----demander----1,1- Spectacle -0,n----engendrer----1,1- Devis

Ensuite, si vous considérez que le devis devient potentiellement une commande facturable sans modification, alors vous pouvez associer directement Devis à Facture.
Client -0,n----demander----1,1- Spectacle -0,n----engendrer----1,1- Devis -0,n----generer----1,1- Facture

Ainsi, les lignes ne sont en association qu'avec le Devis mais sont raccordables au spectacle et à la facture via le Devis.

[ZenZiTone]

Dans un devis j'ai généralement plusieurs lignes.

Cependant pour chaque ligne je n'ai pas un spectacle. J'ai un spectacle qui a plusieurs lignes.

Pour chaque ligne j'ai un produit.

Ah.. Alors si je ne me trompe pas, la conversion en MLD de LIGNE donnera un truc du genre :

LIGNE (PK_NumeroLigne, FK_RefDevis, FK_NumSpectacle, FK_RefProduit).

Du coup il pourrait être mieux de séparer LigneSpectacle et LigneProduit.
LigneProduit serait l'association entre un devis et un produit : [DEVIS]--1,n----(LigneDevis)----0,n--[PRODUIT]
LigneSpectacle serait l'association entre un devis et un spectacle : [DEVIS]--1,n----(LigneSpectacle)----0,n--[SPECTACLE]

Etant donné que ce sont deux choses différentes, il me semble plis cohérent de les séparer. (sinon on aurait des lignes de produits et de spectacle dans LIGNE alors qu'il n'y ne s'agit pas du même "métier")

[planeurbret]

2) Il vaut mieux externaliser les propriétés dont les valeurs se répètent.
=> Externaliser la ville et associer l'entité-type ville à Fournisseur, Client et Spectacle. Cela évitera la saisie de la même ville sous plusieurs orthographes.

Je vais le faire, mais il est vrai que cela est mieux et plus simple. Du coup, il faut que je "relie" chaque table ayant une ville et un CP ?

3) Puisque le TypeProduit a été externalisé, pourquoi n'avoir pas externalisé sa catégorie ?
=> Créer une entité-type CategorieProduit et l'associer à Produit. À moins que catégorie et type ne soient la même chose ? Auquel cas il faut supprimer la propriété CatégorieProduit.

En fait l'entité typeProduit c'est la catégorie dans lequel il est rattaché (Bombe, chandelle, ...) Tandis que la catégorie dans la table produits c'est la catégorie de dangerosité en gros.

4) Au passage, pour nommer entités-types (futures tables) et propriétés (futures colonnes), n'utilisez que des lettres non accentuées, des chiffres et le caractère de soulignement. Ça évitera d'éventuels problèmes lors du passage au MLD et à la création automatisée des tables.

Merci pour l'info, mais ce schéma est juste un exemple visuel, je ne le réutilise pas par la suite.

5) Un produit ne peut-il être enregistré avant d'avoir été livré une première fois ?
=> Mettre la cardinalité mini à 0 du côté du produit pour l'association Livrer.

6) Un produit peut sans doute être livré plusieurs fois par le même fournisseur.
=> Faire participer la date de livraison à la clé de l'association Livrer.

Je vais corriger. MErci

Venons-en à votre problème...

7) Le schéma 1, qui sépare bien les devis des factures, est évidemment meilleur que le schéma 2 qui mélange tout dans le spectacle.

C'est justement ce que je me demandais. Merci pour votre point de vue, je suis plus sur de mon choix.

8) Je crois comprendre que votre processus est le suivant :
Un client demande un devis pour un spectacle puis, une fois le devis accepté, il devient une commande et lorsque le spectacle est réalisé, cela fait l'objet d'une facturation.
Processus classique de n'importe quelle activité commerciale commençant par un devis.

Je pense donc qu'il faut que vous associiez Spectacle à Client et Devis à Spectacle.
Client -0,n----demander----1,1- Spectacle -0,n----engendrer----1,1- Devis

Ensuite, si vous considérez que le devis devient potentiellement une commande facturable sans modification, alors vous pouvez associer directement Devis à Facture.
Client -0,n----demander----1,1- Spectacle -0,n----engendrer----1,1- Devis -0,n----generer----1,1- Facture

Ainsi, les lignes ne sont en association qu'avec le Devis mais sont raccordables au spectacle et à la facture via le Devis.

C'est tout à fait cela. Mais une question me bloque en fait. Dans un spectacle on a un programme dans lequel on a pour chaque ligne du devis en fait, un temps de top départ. Comment faire ?
Peut etre rajouter une table programme ?

[CinePhil]

2) Il vaut mieux externaliser les propriétés dont les valeurs se répètent.
=> Externaliser la ville et associer l'entité-type ville à Fournisseur, Client et Spectacle. Cela évitera la saisie de la même ville sous plusieurs orthographes.

Je vais le faire, mais il est vrai que cela est mieux et plus simple. Du coup, il faut que je "relie" chaque table ayant une ville et un CP ?

Oui, c'est ce que j'ai écrit.

En fait l'entité typeProduit c'est la catégorie dans lequel il est rattaché (Bombe, chandelle, ...) Tandis que la catégorie dans la table produits c'est la catégorie de dangerosité en gros.

Alors il est préférable d'externaliser ces catégories de dangerosité. Au passage, appeler l'entité-type de référence Dangerosite plutôt que Categorie, ce sera plus clair.

C'est tout à fait cela. Mais une question me bloque en fait. Dans un spectacle on a un programme dans lequel on a pour chaque ligne du devis en fait, un temps de top départ. Comment faire ?
Peut etre rajouter une table programme ?

Si ce top départ est systématique pour chaque ligne du devis, pourquoi ne pas simplement ajouter une propriété TopDepart dans Ligne ?
Si ce n'est pas systématique, alors on fait une association :
Ligne -0,1----demarrer----1,1- TopDepart

[planeurbret]

Oui, c'est ce que j'ai écrit.

Je voulais en être sur. Merci.

Alors il est préférable d'externaliser ces catégories de dangerosité. Au passage, appeler l'entité-type de référence Dangerosite plutôt que Categorie, ce sera plus clair.

Même si il n'y a que 3 catégorie de dangerosité ?

Si ce top départ est systématique pour chaque ligne du devis, pourquoi ne pas simplement ajouter une propriété TopDepart dans Ligne ?
Si ce n'est pas systématique, alors on fait une association :
Ligne -0,1----demarrer----1,1- TopDepart

Ok. Donc comme j'ai fait ce sera top. Je fais la modif et vous le renvoie dans la soirée.

Merci encore pour votre aide !

[planeurbret]

Voici le nouveau schéma revu

BreizhPyroV1.1.pdf

[ZenZiTone]

J'aurais une question sur la partie DEVIS - LIGNE - PRODUIT : une même référence produit peut-elle apparaitre dans plusieurs ligne d'un devis?

[planeurbret]

Oui

[CinePhil]

Alors il est préférable d'externaliser ces catégories de dangerosité. Au passage, appeler l'entité-type de référence Dangerosite plutôt que Categorie, ce sera plus clair.

Même si il n'y a que 3 catégorie de dangerosité ?

Oui, parce que demain il peut y en avoir 4 , 5, 10..., parce que, comme pour les villes, ça évite l'incident de la même dangerosité écrite de plusieurs manières et ça prend moins de place en BDD.

Voici le nouveau schéma revu

1) DateLivraison ne participe toujours pas à la clé de l'association Livrer.

2) Qu'entendez-vous par INSEE comme clé dans l'entité-type CodePostal ?
Il vaut mieux une clé non signifiante qui deviendra une clé primaire auto-incrémentée dans la table de la BDD.
On peut même améliorer en faisant une association entre CodePostal et Ville :
CodePostal -1,n----couvrir----1,n- Ville

Puis on transforme l'association en entité-associative pour pouvoir l'associer aux autres entités-types :
CodePostal -1,n----Couvrir----(1,1)- CPVille -(1,1)----Coder----1,n- Ville
Fournisseur -1,1----Résider----0,n--------|
Artificier -1,1----Habiter----0,n--------------|
Client -1,1----Habiter----0,n------------------|
Spectacle -1,1----Situer----0,n-------------|

3) Vous avez oublié d'associer CodePostal à Spectacle.

4) Du fait de vos cardinalités des associations en rapport avec CodePostal, un fournisseur, un client, un artificier peuvent maintenant avoir plusieurs adresses.
Est-ce volontaire ?
Peut-être faudrait-il alors typer les adresses, ce qui peut s'avérer pertinent pour les fournisseurs (adresse de siège social, de facturation...)

5) Il manque la cardinalité de l'association Tirer, côté Spectacle.
Je suppose que c'est 0,n ?

6) Il risque d'y avoir incohérence entre les montants totaux du devis et le total des lignes du devis.
Normalement, on ne stocke pas de colonne calculable.

[hors sujet] Du coup je me pose une question comptable, n'étant pas spécialiste :
Lorsqu'il y a plusieurs taux de TVA dans un devis et que je fais une remise, ça se passe comment ?
Total HT + Total TVA - Remise sans taux de TVA ? [/hors sujet]

[planeurbret]

Oui, parce que demain il peut y en avoir 4 , 5, 10..., parce que, comme pour les villes, ça évite l'incident de la même dangerosité écrite de plusieurs manières et ça prend moins de place en BDD.



1) DateLivraison ne participe toujours pas à la clé de l'association Livrer.

Oui, je ne l'ai pas rajouter comme cela je n'y arrivais pas, mais elle est noté.

2) Qu'entendez-vous par INSEE comme clé dans l'entité-type CodePostal ?
Il vaut mieux une clé non signifiante qui deviendra une clé primaire auto-incrémentée dans la table de la BDD.
On peut même améliorer en faisant une association entre CodePostal et Ville :
CodePostal -1,n----couvrir----1,n- Ville

Puis on transforme l'association en entité-associative pour pouvoir l'associer aux autres entités-types :
CodePostal -1,n----Couvrir----(1,1)- CPVille -(1,1)----Coder----1,n- Ville
Fournisseur -1,1----Résider----0,n--------|
Artificier -1,1----Habiter----0,n--------------|
Client -1,1----Habiter----0,n------------------|
Spectacle -1,1----Situer----0,n-------------|

Qu'est ce que cela va apporter ?

3) Vous avez oublié d'associer CodePostal à Spectacle.

Je vais donc le corriger =)

4) Du fait de vos cardinalités des associations en rapport avec CodePostal, un fournisseur, un client, un artificier peuvent maintenant avoir plusieurs adresses.
Est-ce volontaire ?
Peut-être faudrait-il alors typer les adresses, ce qui peut s'avérer pertinent pour les fournisseurs (adresse de siège social, de facturation...)

Je n'ai pas vraiment fait attention aux cardinalité. Cependant il est vrai que ce n'est pas mal pour avoir plusieurs adresses (pour les clients mais aussi pour les fournisseurs)

5) Il manque la cardinalité de l'association Tirer, côté Spectacle.
Je suppose que c'est 0,n ?

C'est [1,n] Car il faut obligatoirement que 1 artificier soit rattaché à un spectacle. En fait non, c'est bien o,n

6) Il risque d'y avoir incohérence entre les montants totaux du devis et le total des lignes du devis.
Normalement, on ne stocke pas de colonne calculable.

Pourquoi il y aurait il une incohérence entre ces données ? C'est calculé après l'ajout des lignes dans la table ..
Lors de mes cours, on ne m'a jamais appris que les données calculables ne devaient être stockées...

[hors sujet] Du coup je me pose une question comptable, n'étant pas spécialiste :
Lorsqu'il y a plusieurs taux de TVA dans un devis et que je fais une remise, ça se passe comment ?
Total HT + Total TVA - Remise sans taux de TVA ? [/hors sujet]

Il n'y a qu'un seul taux de TVA dans un Devis.

[CinePhil]

2) Qu'entendez-vous par INSEE comme clé dans l'entité-type CodePostal ?
Il vaut mieux une clé non signifiante qui deviendra une clé primaire auto-incrémentée dans la table de la BDD.
On peut même améliorer en faisant une association entre CodePostal et Ville :
CodePostal -1,n----couvrir----1,n- Ville

Puis on transforme l'association en entité-associative pour pouvoir l'associer aux autres entités-types :
CodePostal -1,n----Couvrir----(1,1)- CPVille -(1,1)----Coder----1,n- Ville
Fournisseur -1,1----Résider----0,n--------|
Artificier -1,1----Habiter----0,n--------------|
Client -1,1----Habiter----0,n------------------|
Spectacle -1,1----Situer----0,n-------------|

Qu'est ce que cela va apporter ?

C'est juste une question de rigueur. Avec votre modèle, vous allez fatalement avoir plusieurs fois certaines villes, qui seront alors potentiellement écrites avec plusieurs orthographes, ce qui peut poser problème lors des recherches ou des statistiques par ville.

Je n'ai pas vraiment fait attention aux cardinalité. Cependant il est vrai que ce n'est pas mal pour avoir plusieurs adresses (pour les clients mais aussi pour les fournisseurs)

Alors pensez peut-être à typer vos adresses, sinon, comment savoir quelle adresse concerne telle opération ?

Pourquoi il y aurait il une incohérence entre ces données ? C'est calculé après l'ajout des lignes dans la table ..
Lors de mes cours, on ne m'a jamais appris que les données calculables ne devaient être stockées...

Parce que, loi de Murphy oblige, rares sont les programmes entièrement fiables !
Il suffit qu'un jour, un cas particulier se présente et qu'une mise à jour d'un prix dans une ligne de devis ne se reporte pas sur le calcul du total du devis et vous aurez des erreurs.
Encore une fois, c'est une question de rigueur.

Il n'y a qu'un seul taux de TVA dans un Devis.

Alors pourquoi, là aussi, stocker la TVA pour chaque ligne du devis ?
Ne mettez que les prix unitaires hors taxes dans les lignes et enregistrez le taux de TVA dans le devis.
Montant TTC du devis = SUM(Ligne.PrixUnitHT * Ligne.QuantiteLigne) + (SUM(Ligne.PrixUnitHT * Ligne.QuantiteLigne) * Devis.TauxTVA)