Bonsoir lilpayton,
Si une maintenance se comporte comme une commande classique, c'est-à-dire si elle fait toujours l’objet d’un devis, d’une facture (j’en sais quelque chose à propos de la maintenance de ma chaudière dont il a fallu changer des pièces...), et toutes ces sortes de choses, la mise en œuvre de l’entité-type TYPE_COMMANDE convient.
Entité-type COMMANDE
Par convention, l’attribut Commande_Id est artificiel (non significatif, créé par le système, en principe caché à la vue de l’utilisateur). Mais l’entreprise ne gère-t-elle pas ses propres numéros de commande que par contraste on dira naturels (à l’usage de l’utilisateur, même si vous demandez au système de les générer eux aussi) ?
La présence d’un attribut Commande_quantite est suspecte... Que compte-t-on ?
Entité-type LIGNE_COMMANDE
L’attribut Ligne_commande_qte est manifestement redondant avec l’attribut Article_qte de l’association Concerner. Si tel est le cas, l’un des deux doit disparaître (au hasard Article_qte, ça fera plaisir à csik78
).
Le montant (attribut Ligne_commande_montant) est-il hors taxe ? Doit-il être égal au montant défini pour l’entité-type ARTICLE (à date, au cas où l'on gèrerait un historique des prix HT des articles) ?
FACTURE
Pas de numéro de facture ? (Mêmes remarques que pour le numéro de commande).
L’ajout de l’entité-type LIGNE_FACTURE est
a priori correct. Mais je n’ai pas formulé ma question de façon suffisamment complète... En effet, s’il doit y avoir égalité entre les lignes de facture et les lignes de commande (ce qui paraît assez sain dans notre monde cartésien !), on sait alors inférer les lignes de facture : dans ce cas-là, on peut revenir à la situation initiale et ne pas modéliser l’entité-type LIGNE_FACTURE (désolé pour ce qui ressemble à un contre-ordre..) Qu’en est-il ?
TVA
Prévoyez-vous de suivre la date d’application des taux de TVA, sachant par exemple que début 2014 on s’en prendra plein la g... ? A titre d’exemple :
Au niveau SQL :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
| CREATE TABLE TVA (
TvaId INT NOT NULL,
TvADateDepuis DATETIME NOT NULL,
TvaTaux INT NOT NULL,
CONSTRAINT TVA_PK PRIMARY KEY (TvaId),
CONSTRAINT TVA_AK UNIQUE (TvaTaux)
) ;
CREATE TABLE TVA_HISTO (
TvaId INT NOT NULL,
TVADateDurant DATETIME NOT NULL,
TVATaux INT NOT NULL,
CONSTRAINT TVA_HISTO_PK PRIMARY KEY (TvaId, TVADateDurant),
CONSTRAINT TVA_HISTO_TVA_FK FOREIGN KEY (TvaId)
REFERENCES TVA (TvaId)
) ;
CREATE TABLE ARTICLE (
ArticleId INT NOT NULL,
TvaId INT NOT NULL,
ArtReference VARCHAR(150) NOT NULL,
AetDesignation VARCHAR(150) NOT NULL,
ArtPrixHt INT NOT NULL,
ArtQteStock INT NOT NULL,
Constraint ARTICLE_PK PRIMARY KEY (ArticleId),
CONSTRAINT ARTICLE_TVA_FK FOREIGN KEY (TvaId)
REFERENCES TVA (TvaId)
) ; |
Mode de paiement
Le mode de paiement pourrait faire l’objet d’une entité-type à laquelle ferait référence la facture.
ADRESSE
Vous pouvez éventuellement établir une association directement entre PERSONNE et ADRESSE et par conséquent supprimer les liens CLIENT - ADRESSE et FOURNISSEUR -ADRESSE. Un inconvénient toutefois : selon votre MCD, un fournisseur a seulement une adresse, alors qu’avec la modification proposée, il peut en avoir plusieurs. Toutefois, on peut assurer la contrainte au niveau SQL au moyen d’un trigger.
J’ai encore quelques remarques à faire, mais essayons déjà de stabiliser ce qu’on vient de traiter...
Projet d'étude gestion commerciale d'une petite entreprise
Répondre avec citation
Envoyé par csik78
.
Partager