Discussion :

[soundary123]

Bonjour,

Pour mes cours d'informatique en fac, je dois réaliser une base de données afin de gérer une aut-école.

J'ai essayé de réaliser les tables pour réussir la table et j'aimerai bien avoir des conseils et des aides sur ce qui pourrait aller ou ne pas aller, ce qui manque,...



TABLE ELEVES : N° Inscription ; Nom ; Prénom ; Date d'inscription ; Date de naissance ; Adresse 1 ; Code Postal ; Ville ; Téléphone ; Obtention du code (Oui/Non) ; #N° Paiement ; #Code permis

TABLE LECONS : N° Leçon ; Type leçon ; Date ; Heure début ; Heure fin ; #N° Moniteur ; #N° Inscription ; #N° Voiture

TABLES MONITEURS : N° Moniteur ; Nom ; Prénom ; Date d'embauche ; Date obtention BAFM ; Date de naissance ; Adresse ; Code Postal ; Ville ; Téléphone ;

TABLES PERMIS : Code Permis ; Libellé du permis ; Forfait Code ; Prix d'une leçon

TABLES VEHICULES : N° Véhicule ; Type véhicule ; Modèle ; Marque ; Année d'achat ; N° Immatriculation ; Etat

TABLE PAIEMENTS : N° Paiement ; Type de paiement ; Montant



Voila, si pouviez me dire ce que vous en pensez. Je vous remercie.

J'utilise Access 2007 au fait.

[noobiewan kenobi]

Bonjour,

Personnellement, je procèderais de cette façon (enfin dans l'idée) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
TABLE PERSONNES : PersonneID ; Nom ; Prénom ; Date de naissance ; Adresse ; Code Postal ; Ville ; Téléphone ;
 
TABLE ELEVES : EleveID ; N° Inscription ; #PersonneID ; #ObtentionCodeID ;
 
TABLE LECONS : LeçonID ; N° Leçon ; Type leçon ; Date ; Heure début ; Heure fin ; #N° Moniteur ; #N° Inscription ; #N° Vehicule
 
TABLE MONITEURS : MoniteurID ; N° Moniteur ; #PersonneID ; Date d'embauche ; Date obtention BAFM ;
 
TABLE PRIX_CODE : PrixCodeID ; Forfait Code ; Prix à la séance ; 
 
TABLE OBTENTION_CODE : ObtentionCodeID ; Obtenu (oui ou non) ; Validité du Code ;
 
TABLE PERMIS : PermisID ; Code Permis ; Libellé du permis ; Prix d'une leçon
 
TABLE ELEVES_OBTENTION_CODE : ID ; #EleveID ; #ObtentionCodeID ; 
 
TABLE ELEVES_PRIX_CODE : ID ; #EleveID ; #PrixCodeID ;
 
TABLE PERSONNES_PERMIS : ID ; #PersonneID ; #PermisID ;
 
TABLE VEHICULES : VehiculeID ; N° Véhicule ; Type véhicule ; Modèle ; Marque ; Année d'achat ; N° Immatriculation ; Etat
 
TABLE PAIEMENTS : PaiementID ; N° Paiement ; Type de paiement ; Montant 
 
TABLE VERSEMENTS : VersementID ; #EleveID ; #PaiementID ; Sujet (code ou permis) ;

La table PERSONNES_PERMIS permettrait de connaître quels sont les permis que la personne pourrait avoir, car une personne peut avoir plusieurs permis (que ce soit un élève ou un moniteur).

La table VERSEMENTS permettrait de prendre en compte le fait de payer en plusieurs fois une leçon, un permis ou le code.


J'ai essayé de prendre en compte le code, puisque pour une auto-école, ils doivent pouvoir le gérer. J'ai pris en compte le fait qu'un élève ait pu passer plusieurs fois son code, et s'il l'a obtenu, comme de tant est-il valable pour passer un autre permis.

Tout ceci n'est qu'une base de réflexion. J'essaierais de me pencher dessus un peu plus tard quand j'aurais plus de temps.

Bon courage.

NoobieWan Kenobi

[Lou Pitchoun]

Salut,

Il y a pleins de petites erreurs.

Tel que ton modèle est créé, tu ne peux pas :

• associer plusieurs leçons à un élève
• affecter plusieurs paiements à un élève
• un élève ne peut passer qu'un seul permis

Eleves : N° Inscription ; Nom ; Prénom ; Date d'inscription ; Date de naissance ; Adresse 1 ; Code Postal ; Ville ; Téléphone ; Obtention du code (Oui/Non)

Cours : N°cours ; Date ; Heure début ; Heure fin ; #N° Moniteur ; #N° Inscription ; #N° Voiture ; n°lecon

Lecons : N° Leçon ; Type leçon

TABLES MONITEURS : N° Moniteur ; Nom ; Prénom ; Date d'embauche ; Date obtention BAFM ; Date de naissance ; Adresse ; Code Postal ; Ville ; Téléphone ;

TABLES PERMIS : Code Permis ; Libellé du permis ; Forfait Code ; Prix d'une leçon

PasserPermis : N° Inscription ; Code permis

TABLES VEHICULES : N° Véhicule ; Type véhicule ; Modèle ; Marque ; Année d'achat ; N° Immatriculation ; Etat

TABLE PAIEMENTS : N° Paiement ; Type de paiement ; Montant ; N°inscription


Voilà quelques modifs qui m'ont sauté aux yeux.

Sinon, quelques questions à se poser :
Est-il utile de stocker le prix d'une leçon dans la table permis ? Ne serait pas plutôt dans la table leçon.
Ne faudrait-il pas associer des leçons à un permis pour obtenir le prix total de celui-ci ?
Tout cela doit être défini soit dans l'énoncé si tu en as un, soit à définir par toi même en se basant sur une logique.


Je te suggère de lire cet article sur les conventions typographiques (nommage des tables, champs etc...) qui t'éviteras certains désagréments lors du développement de ton application.

[soundary123]

Je vous remercie, je vais essayer avec ce que vous m'avez proposé.

[Invité]

Bonjour

Juste une petite remarque que je fais souvent.

Ayant travaillé 13 ans dans l'envoi de mailings, je vous conseille fortement de toujours déporté les codes postaux et les villes dans une table Annexe, de rajouter une clé primaire (attention, le code postal ne peut être pris comme clé), et de la lier à votre table des identités.

Tout simplement, même si ce n'est pas le cas ici, lorsque vous voulez gérer des mailings, vous avez des tarifs préférentiels possibles en fonction de la qualité de votre fichier, et entre autre la bonne correspondance des noms de ville et de codes postaux. Le fait d'avoir une entrée unique (la table annexe) facilite grandement les mises à jour, croyez en mon expérience, car certaines sociétés peuvent vous faire payer très cher la mise en conformité de votre fichier.

Philippe

[Jeannot45]

Pour ma part, je vous conseillerai la lecture des deux tutos ci-dessous afin de bien cerner les problèmes concernant la conception et la mise en place de relations entre les tables.

Conception
Relations et jointures

Comme on a pu le préciser dans les différentes réponses ci-dessus, de la bonne réalisation des tables dépendra la qualité de l'application.

Bonne lecture et bon développement