Discussion :

[h4cktaas]

Bonjour, je me permet de faire ce topic car je n'ai pas réussis a trouvé la réponse dans un autre...

Donc voila, je suis sensé faire une base de données pour un club de sport le soucis c'est que si cette base de données devait simplement référencer les cours et les membres participant, elle doit désormais ajouter les jours de cours, les heures sous forme de planning, les présences et les absence pour pouvoir faire un % de participation a chaque cour chaque mois et ajouter en plus les abonnements de façon claire par date+Membre+le(s) cour(s) suivi. La difficulté survient dans la durée des abonnements, les prix qui ne sont différent, qu'il faudrait un message pour signaler la fin de l'abonnement...

J'avoue être un petit peu perdu... En gros j'aurais besoin de votre aide pour :

Gérer les présences/absences et faire le calcul et %
Gérer les paiements (a savoir qu'il y a des abonnements (53 différents qui ont des durées différentes) + un montant fixe pour l'assurance a payé).
Gérer les abonnements (Validité + payé oui/non pour chaque membre).
Gérer les stages qui sont différents des membres et qui ont aussi un abonnement différent non compris dans les abonnements déjà encodé...

Et pour finir, je suis débutant, je connais les bases mais la j'ai trop de choses a gérer d'un seul coup et je me disperse de trop de plus que je ne sais pas comment m'y prendre pour faire les choses notée ci dessus... Ajouter à ça, j'ai presque chaque jours des nouveautés à ajouter que mon patron me donne...

Si vous aviez quelques tuyaux, je vous en serais très reconnaissant

Merci


Ps: Si vous avez besoin de plus d'informations je peux vous en donner plus, j'ai essayé de clarifier le plus possible mon problème mais ce n'est pas forcément evident...

Bien à vous.

[marot_r]

Ajouter à ça, j'ai presque chaque jours des nouveautés à ajouter que mon patron me donne...

Pas cool, les architectures de base de données n'apprécient pas forcément cela et une bonne structure dans un cas peut s'avérer un handicap dans un autre.

Pourrais-tu convenir avec ton patron pour "geler" les spécifictaions et aussi le prévenir qu'avec tout ce qu'il te demande cela va prendre du temps à réaliser. Pour le gelage tu pourrais proposer de prendre les demandes jusqu'à la fin de la semaine ou du mois puis à partir de là commencer l'analyse).

Bon d'habitude ici on donne le poisson mais dans ton cas je pense qu'il est mieux que tu apprennes à pécher :-).

Une règle assez simple quand on débute est de ne pas se lancer dans le développement de la base immédiatement mais de faire une petite modélisation sur papier avant. Le but de la modélisation est d'indentifier les tables et leurs relations donc quelques rectangles et des traits les reliants devraient suffires.

Une autre règle est qu'une information ne devrait être que dans une seule table et que si tu as besoin d'elle tu t'y référes par son identifiant.

Par exemple pour tes membres, tu devrais avoir une table des membres qui te donnes un numéro unique d'indetification, son nom, son prénom, etc. Quand tu veux faire référence au membre tu vas utiliser son identifiant unique, et si tu veux son nom tu iras le prendre, via une jointure dans une requête (une jointure est l'association établies entre deux tables dans une requête), dans la table des membres.

Pour identifier les tables, une bonne approche est de repérer les noms dans tes spécifications. Généralement un nom correspond à une table.

Fait une première passe avec cela puis voit si il ne te manque rien puis trace des traits entre tes noms (tables), par exemple la table membre sera probablement en relation avec la table abonnement.

Ceci est le modèle conceptuel de données (donc à haut niveau idépendament de la BD utilisée).

Une fois tes associations de tables identifiées, voit si ces associations devraient avoir des informations spécifiques.

Par exemple l'association entre membre (la liste des) et abonnement (la liste des) devrait avoir une date de début, une date de fin, un indicateur de paiement et peut-être un montant si tous les membres qui souscrivent un abonnement ne payent pas le même prix.

Si ils payent le même prix il te faudras sans doute faire une table des tarifs d'abonnement et gader une historique des prix.

ATTENTION : Le processus d'analyse est itératif, c'est à dire que tu vas sans doute revenir plusieurs fois (ajouter des tables, créé des relations, supprimer des tables ou des relations, regrouper des tables que tu avais séparées ...). Même avec de l'expérience on l'a rarement juste du premier coup si la BD est complexe. On peut le voir comme un puzzle, tu mets en place les pìèces que tu sais aller à telle place puis tu ajoutes les autres enfin tu bouches les trous.

Une fois que tu sens que tu as trouvé la grande majorité de tes tables et relation (en gros si cela fait plusieurs fois que tu relis ton modèle et que tu n'y vois plus rien à ajouter) tu vas pouvoir commencer ta BD en Access.

1. Une table dans le modèle logique devient une table dans la BD (modèle physique de données)
2. Une association qui ne porte pas d'information devient une relation (avec intégrité relationnelle pour éviter les données orphelines)
3. Une association qui porte des données peut devenir selon le cas une table d'association ou un champ dans l'une des tables en relation.
   
   
   Elle devient une table si tu as plusieurs éléments de chacune des tables qui est en relation avec plusieurs (on parle de cardinalité N x N).
   Un exemple type pourrait être la relation entre les membres et les abonnements : un membre peut souscrire plusieurs abonements et un abonnement peut être souscrit par plusieurs membres.
   
   Elle devient un champ si tu une relation avec une cardinalité de 1 à N.
   Par exemple dans une relation père-fils bilogique, un père peut avoir plusieurs enfants mais un enfant n'a qu'un seul père bilogique.
   Dans ce cas la table Enfant aura un champ Père qui contiendra l'identifiant unique du père.

Note qu'il n'y a pas non plus de modèle parfait. Il y peut y voir plusieurs solutions qui répondent à tes besoins.

Dernier point, ne commence pas la création des formulaires et autres éléments d'interface ou de logique tant que tu n'as pas le sentiment que ton modèle de données physique est assez stable. Modifier le modèle physque de données est assez facile, changer tous les éléments qui en dépendent peut être assez long et frustrant.

A+

[madefemere]

Bonjour,

Il faut toujours un début à tout. On peut t'aider, mais il nous faudrait que tu nous montres déjà ce que tu as effectué et quelles sont les améliorations que nous pourrons apporter.
Quelles tables tu as, quelles sont les relations entre elles et ainsi de suite...
Déjà, vu que l'on demande un planning, je te conseille de commencer par lire ces tutos sur les plannings pour que tu comprennes comment on peut en implanter et lequel est le plus proche de tes besoins. Je pense que c'est la partie sur laquelle tu as le plus d'appréhension pour le moment, après les autres vont se greffer dessus selon ta structure actuelle.

@+

EDIT : D'accord avec tout ce que dit René

[h4cktaas]

Merci de vos réponses

J'ai d'abord la table membre avec :

ID "NuméroAuto"
Nom "Texte court"
Prénom "Texte court"
Sexe "Texte court"
DateNaissance "Date/heure"
Téléphone 1 "Texte court"
Téléphone 2 "Texte court"
Adresse "Texte court"
Ville "Numérique" (En relation avec la table Ville champ ville)
Code Postal "Numérique" (En relation avec la table ville champ Code Postal)
Mail "Texte court"
Ecole "Texte court"
Statut "Numérique" (liste de choix pour Actif ou Passif)
Cours suivi "Numérique" (En relation avec la table Cours)
Abonnement "Numérique" (En relation avec la table Abonnement)
Assurance "Texte court" (Avec Abonnement j'ai besoin de le mettre dans j'ignores quoi pour avoir un oeil sur la compta)
Date Abo "Texte court" (Je me suis dit que ce serait utile pour les dates mais sans certitude)


La table "Abonnement" qui reprend tous les abonnements
Numéro Auto
Type "Texte court"
Durée "Texte court"
Prix "Texte court"

La table "Cours"

ID "Texte court"
Nom "Texte court"
Prof "Numérique" (En relation avec la table Prof)
Salle "Numérique" (En relation avec la table Salle)
Heure "Numérique" (En relation avec la table Heure)
Jour "Numérique" (En relation avec la table "Jour")
Commentaire "Texte court"
Membre "Numérique" (Je voulais créer une relation avec les membres pour qu'ils soient référencé dans le cour dés leur inscription)


Voila j'en suis la... C'est ce qui me semblait le plus logique. Ensuite viennent les problèmes et je suis venu vers vous pour avoir des conseils

[marot_r]

Bonjour,

Il est recommandé de typer proprement les champs de données.

Je te suggère de changer le type prix pour réel double (note : les types monaitaires ne sont pas fiables). Il est plus difficile de faire des calculs sur des textes (aussi appelé chaînes de caractères).

Ensuite pour les cours c'est un cas de table d'association, voici ce que je te suggère :

Table AssCoursMembre
IdMembre (Entier long)
IdCours (Entier long)

En relation avec Membre
En relation avec Cours

Table Cours
Id (Numero auto)
Code "Texte court"
Nom "Texte court"
Prof "Numérique" (En relation avec la table Prof)
Salle "Numérique" (En relation avec la table Salle)
Heure "Numérique" (En relation avec la table Heure)
Jour "Numérique" (En relation avec la table "Jour")
Commentaire "Texte court"

[h4cktaas]

Bonjour,

voila j'ai bien écouté vos conseils, j'ai trouvé d'autre topic avec des fragments de réponses et tout accumulé, tout fonctionne comme je le souhaites. Maintenant mon problème c'est réellement prendre les présences... Je pensais utiliser un système de leçon avec une requête qui me permettrait simplement de cocher une case pour les présents (j’espère que je suis assez claire...)
Le problème qui se pose, c'est comment créer automatiquement les cours chaque jours sous forme de "leçon"... Je sais qu'il existe une macro qui permet de le faire mais pour chaque jour sur un grand nombre de cours? Je ne sais pas si vous auriez une idée a me soumettre?