Discussion :

[Snake7345]

Bonjour à tous,

Tout d'abord, je suis désolé du gros blabla que je vais faire mais c'est pour bien vous expliquer le projet.

Pour mon épreuve de fin d'année, je voudrais présenter une application de gestion de vente de voiture de marque X avec son garage et les garages/magasins associés.
L'application ne gère pas les magasins/garages franchisés.
L'entreprise ouvre du lundi au samedi de 8h00 jusqu'à 17h00 et ne prends en charge que les clients résidant en Belgique.
Je vais faire l'application en Java.

Les fonctions que je souhaite :

- Gestion des nouvelles voitures dans le garage -> Facture si vendue
- Gestion des voitures personnalisés
- Gestion des clients avec gestion de leur voiture
- Gestion des pièces voitures
- Gestion du personnel
- Gestion commande/réservation
- Commande des pièces
- Gestion des interventions sur la voiture (entretien, contrôle technique, réparation,...)
- Gestion des rendez-vous

La facture sera sortie en PDF que ca soit pour commander une voiture, pour commander des pièces ou pour une intervention
Contraintes/ Règles (pour le moment) :

- On ne gère pas le budget de la boite
- Une commande ne peut contenir que zéro ou une voiture.
Une voiture = Une facture
- Les utilisateurs iront du simple garagiste au gérant en passant par le chef garagiste, vendeur,...
- Un utilisateur(vendeur, gérant) pourra effectuer une commande pour un client et le facturer.
- Un utilisateur(vendeur, gérant) pourra encoder une nouvelle voiture, ou un numéro de châssis
NB : En effet, si une voiture est de stock (en général le modèle de base), elle aura déjà son numéro de châssis.
Mais, si jamais la voiture est personnalisé avec les pièces, alors la voiture sera mise dans la base de donnée sans numéro de châssis. A la réception de la voiture, le numéro de châssis sera encodé.
- Un utilisateur(Chef-garagiste, vendeur, gérant) pourra prendre les appels en charge et donc encoder un rendez-vous en vue d'une intervention chez un chef-garagiste ou un garagiste
- Un utilisateur (garagiste, Chef-garagiste) pourra encoder ses interventions.
- Le client qui a acheté une voiture de la marque X mais qui l'a pas acheté dans notre concession et/ou magasins/garages de notre entreprise sera encodé dans notre base de données pour qu'il ait sa fiche et sa voiture sera également encodé.
- Le gérant encodera des nouveaux utilisateurs.

Problèmes/Demandes :

Tout d'abord je souhaite vous soumettre mon schéma pour avoir un avis général, car je trouve qu'il y a énormément de lien et je ne suis pas sur que cela respecte les formes normales, maintenant je trouve que tous les liens sont nécessaires.
Si il y a possibilité d'améliorer le truc je suis preneur, néanmoins on m'a toujours dit à propos des relations ternaires qu'il fallait les évitez à tout prix.
Et ici, j'ai un énorme problème c'est avec les prix car je suis pas sur qu'il se transmette du coup à la facture/commande et ainsi de suite.
Pouvez-vous m'aiguiller un peu là-dessus.
Car je vois des soucis au niveau de modèle et de options car le modèle transmettrait sa clé à options et à commande et donc on aurait pas le prix des options dans la commande donc j'ai déjà un problème.
Ensuite pour intervention et facture, c'est la facture qui transmet sa clé à intervention hors que ça devrait être l'inverse.



Merci à vous,

[CinePhil]

Bonjour,

Voilà un projet à aspect multiples.

Comme je ne sais pas de combien de temps je dispose pour répondre, je vais répondre en vrac à votre MCD, quitte à revenir plus tard sur votre description.

1) Les entités-types "Utilisateur" et "Client" ont les mêmes propriétés.
Il s'agit donc de personnes physiques et il conviendrait de faire un héritage d'une entité-type "Personne_physique" vers "Utilisateur" et "Client".
Il est d'ailleurs étonnant que le client ait un "IdUtilisateur" ! Le client est-il utilisateur de votre future application ? Je n'ai pas lu ça dans votre description.

2) Que seront, concrètement, les permissions accordées aux rôles ?
Vous avez prévu des colonnes "Creer", "Lire", "Modif" et "Supp". Je suppose donc que chaque ligne concernera une fonctionnalité de l'application ?

3) Une commande comprend en principe un numéro de commande.
Ce numéro est différent de l'identifiant technique de la base de données. Il est souvent formaté, par exemple avec l'année suivie d'un numéro d'ordre dans l'année. Si votre projet est un cas concret, je vous invite à vous renseigner sur cet aspect auprès du concessionnaire.

4) C'est plutôt le client qui "passe" commande et l'utilisateur qui la "saisit"

5) Toujours sur la commande, le prix total est-il hors taxes ou TTC ?
Et je ne vois pas le détail des prix permettant d'aboutir à ce prix total. Y aura t-il une liaison vers le logiciel de comptabilité pour ces aspects ? En ce cas, la commande et la facture ne sont-elles pas déjà présentes dans la comptabilité ? Votre MCD ne comprend-il que des informations partielles importées de la comptabilité pour les commandes et factures ?

Je verrais par contre bien la notion de devis dans cette application à caractère commercial.

6) Une pièce est souvent munie d'une référence.
Par ailleurs, il n'est pas rare que les pièces soient incluses dans des ensembles non décomposables à la vente.

7) Si vos utilisateurs sont tous des employés de la concession, y en a t-il qui travaillent dans aucun bâtiment ?
Vous avez mis une cardinalité "0,1" entre "Utilisateur" et "travaille".

8) Comment savoir quelles options sont présentes sur la voiture commandée par le client ?
Certes, une voiture représente un seul modèle mais ce modèle peut disposer de plusieurs options. Lesquelles sont finalement choisies ?

9) Il y a un problème de boucle qu'il faudra résoudre par des contraintes d'intégrité fonctionnelle.
Avec votre premier MCD, un client peut se rendre à un rendez-vous concernant des interventions qui concernent une voiture... qu'il n'a pas commandée !
Et comme un rendez-vous peut concerner plusieurs interventions, celles-ci peuvent concerner plusieurs voitures de clients différents.

Passons à vos demandes...

néanmoins on m'a toujours dit à propos des relations ternaires qu'il fallait les évitez à tout prix.

Elles sont parfois nécessaires et je ne vois pas pourquoi il faudrait les éviter !

Et ici, j'ai un énorme problème c'est avec les prix car je suis pas sur qu'il se transmette du coup à la facture/commande et ainsi de suite.

C'est effectivement ce que j'ai souligné au point 5.
Il y a des difficultés supplémentaires avec les prix :
- Pour un élément muni d'un prix, ce dernier peut varier dans le temps : la pièce A825 coûte aujourd'hui 50 € et peut coûter 47 € demain.
- On peut aussi accorder une ristourne à un client, voire prendre en charge telle pièce en garantie ou par geste commercial, donc prix pour le client = 0.
- Au gré des lois, le taux des taxes peut varier. Pour un même prix hors taxes, le prix TTC peut changer.
- Une commande et une facture, représentant un total théorique de 5625,12 € peut faire l'objet d'une remise commerciale pour arrondir le prix à 5500 €.

Il faut donc enregistrer les prix réels vendus pour chaque ligne de la commande/facture, ainsi que le prix total hors taxes et TTC.

Prenez quelques exemples de factures réelles chez votre concessionnaire ; rencontrez les comptables pour voir de quoi ils ont besoin.

Car je vois des soucis au niveau de modèle et de options car le modèle transmettrait sa clé à options et à commande et donc on aurait pas le prix des options dans la commande donc j'ai déjà un problème.

C'est ce que j'ai souligné au point 8.
Une voiture commandée est un modèle avec un certain nombre d'options. Il faut donc associer la voiture aux options choisies, avec une contrainte d'intégrité indiquant que les options commandées doivent être celles du modèle de la voiture.

Ensuite pour intervention et facture, c'est la facture qui transmet sa clé à intervention hors que ça devrait être l'inverse.

Toute intervention implique t-elle une facture ? Une intervention en garantie fera t-elle l'objet d'une facture à 0 € ou pas de facture ?
Une intervention en cours n'est pas encore facturée donc n'est pas encore associée à une facture. Pourtant, il me semblerait utile que l'intervention soit enregistrée comme à faire afin de suivre sa réalisation.
Au passage, ne devez-vous pas enregistrer qui va faire l'intervention ?


Vous avez déjà pas mal bossé ; bon courage pour la suite !

[Snake7345]

Bonjour,

Voilà un projet à aspect multiples.

Comme je ne sais pas de combien de temps je dispose pour répondre, je vais répondre en vrac à votre MCD, quitte à revenir plus tard sur votre description.

1) Les entités-types "Utilisateur" et "Client" ont les mêmes propriétés.
Il s'agit donc de personnes physiques et il conviendrait de faire un héritage d'une entité-type "Personne_physique" vers "Utilisateur" et "Client".
Il est d'ailleurs étonnant que le client ait un "IdUtilisateur" ! Le client est-il utilisateur de votre future application ? Je n'ai pas lu ça dans votre description.

2) Que seront, concrètement, les permissions accordées aux rôles ?
Vous avez prévu des colonnes "Creer", "Lire", "Modif" et "Supp". Je suppose donc que chaque ligne concernera une fonctionnalité de l'application ?

3) Une commande comprend en principe un numéro de commande.
Ce numéro est différent de l'identifiant technique de la base de données. Il est souvent formaté, par exemple avec l'année suivie d'un numéro d'ordre dans l'année. Si votre projet est un cas concret, je vous invite à vous renseigner sur cet aspect auprès du concessionnaire.

4) C'est plutôt le client qui "passe" commande et l'utilisateur qui la "saisit"

5) Toujours sur la commande, le prix total est-il hors taxes ou TTC ?
Et je ne vois pas le détail des prix permettant d'aboutir à ce prix total. Y aura t-il une liaison vers le logiciel de comptabilité pour ces aspects ? En ce cas, la commande et la facture ne sont-elles pas déjà présentes dans la comptabilité ? Votre MCD ne comprend-il que des informations partielles importées de la comptabilité pour les commandes et factures ?

Je verrais par contre bien la notion de devis dans cette application à caractère commercial.

6) Une pièce est souvent munie d'une référence.
Par ailleurs, il n'est pas rare que les pièces soient incluses dans des ensembles non décomposables à la vente.

7) Si vos utilisateurs sont tous des employés de la concession, y en a t-il qui travaillent dans aucun bâtiment ?
Vous avez mis une cardinalité "0,1" entre "Utilisateur" et "travaille".

8) Comment savoir quelles options sont présentes sur la voiture commandée par le client ?
Certes, une voiture représente un seul modèle mais ce modèle peut disposer de plusieurs options. Lesquelles sont finalement choisies ?

9) Il y a un problème de boucle qu'il faudra résoudre par des contraintes d'intégrité fonctionnelle.
Avec votre premier MCD, un client peut se rendre à un rendez-vous concernant des interventions qui concernent une voiture... qu'il n'a pas commandée !
Et comme un rendez-vous peut concerner plusieurs interventions, celles-ci peuvent concerner plusieurs voitures de clients différents.

Passons à vos demandes...

Elles sont parfois nécessaires et je ne vois pas pourquoi il faudrait les éviter !


C'est effectivement ce que j'ai souligné au point 5.
Il y a des difficultés supplémentaires avec les prix :
- Pour un élément muni d'un prix, ce dernier peut varier dans le temps : la pièce A825 coûte aujourd'hui 50 € et peut coûter 47 € demain.
- On peut aussi accorder une ristourne à un client, voire prendre en charge telle pièce en garantie ou par geste commercial, donc prix pour le client = 0.
- Au gré des lois, le taux des taxes peut varier. Pour un même prix hors taxes, le prix TTC peut changer.
- Une commande et une facture, représentant un total théorique de 5625,12 € peut faire l'objet d'une remise commerciale pour arrondir le prix à 5500 €.

Il faut donc enregistrer les prix réels vendus pour chaque ligne de la commande/facture, ainsi que le prix total hors taxes et TTC.

Prenez quelques exemples de factures réelles chez votre concessionnaire ; rencontrez les comptables pour voir de quoi ils ont besoin.


C'est ce que j'ai souligné au point 8.
Une voiture commandée est un modèle avec un certain nombre d'options. Il faut donc associer la voiture aux options choisies, avec une contrainte d'intégrité indiquant que les options commandées doivent être celles du modèle de la voiture.


Toute intervention implique t-elle une facture ? Une intervention en garantie fera t-elle l'objet d'une facture à 0 € ou pas de facture ?
Une intervention en cours n'est pas encore facturée donc n'est pas encore associée à une facture. Pourtant, il me semblerait utile que l'intervention soit enregistrée comme à faire afin de suivre sa réalisation.
Au passage, ne devez-vous pas enregistrer qui va faire l'intervention ?


Vous avez déjà pas mal bossé ; bon courage pour la suite !

Bonjour CinePhil,

J'ai bien lu attentivement ton message et je pense que grâce a toi et a certains ami j'ai rectifié certaines choses dans mon schéma, je vais poster ça sous peu et dire les modifications faites car je passe en coupe-vent.

Merci encore,

Je vais poster ça ce soir ou demain dans la journée

[Snake7345]

Coucou à tous, pardon gros gros retard vu la quantité de boulot que j'avais pas su faire autrement.

Alors voila donc mon schéma actuel, je le trouve beaucoup plus logique avec toutes ces modifications grace a toi CinePhil aussi
Petite chose : Mon professeur a considérer donc que piece et fabricant était en trop et que les tables présentes me suffisait néanmoins les tables qui sont supplémentaires ici sont assez explicites.
Néanmoins j'ai encore un ptit doute avec la relation Commande-Facture et Facture-Intervention.
En effet, Une facture correspond à une et une seule commande SAUF dans ce cas car une facture vu que j'ai décidé de relier intervention et commande à la table Facture.
Donc dans la logique ça serait Commande 0-1, 0-1 Facture et Facture 0-1, 0-1 Intervention.

Maintenant est ce que je dois opter pour la solution des relations 0-1 ou faire une table différente pour les factures concernant les interventions et une autre table concernant les factures pour les commandes? Quel est ici la meilleur solution?

Je mettrais dans la soirée une mise à jour de mon cahier des charges