Discussion :

[Lemouba]

Bonjour Denis
Je voudrais créer une basse de donnée d'une petite association.
Elle a pour objet l'épargne volontaire. Chaque membre dépose chaque fin du mois une partie de ses économies dans notre association. Au du début de chaque rentrée scolaire, le montant épargné par chaque membre lui est restitué avec un intérêt mensuel de 2%. Il faut noter que tout membre peut également prêté de argent dans l'association. Le remboursement se fait sur trois mois, non renouvelables, avec un intérêt mensuel de 3%. Et aucun membre ne peut prêté s'il doit encore au groupe.

Voici un peu ce que j'ai fait :
J'ai créé 4 tables
1- Table Membre. Elle comprend 11 champs:
- Numéro d'ordre ( clé primaire )
- Nom
- Prénom
- No carte nationale d'identité
- Contact (1; 2 et 3)
- E-mail
- Domicile ou résidence
- Photos ou pièces jointes
- observation

2- Table épargne. Elle comprend les champs suivants :
- Nom
- Prénom
- Date ou mois de dépôt
- Montant déposé ou versé

3- Table Prêts. Ses champs sont:
- Nom
- Prénom
- Avaliste
- Montant demandé
- Montant reçu
- Intérêt mensuel
- A rembourser avant le
- Observation

4 Table Remboursements. Ses champs sont:
- Nom
- Prénom
- Montant prêté
- Net à rembourser
- Versement du jour
- Reste à verser
- Observation

Ayant déjà réalisé ces différentes tables, Je n'ai pas pu créer la base de donnée, ( mes essais sont rejetés ). Ce qui me rend la suite extrêmement compliqué.

Comment créer?
Aidez moi

[fsmrel]

Bonjour Lemouba,

Où est le MCD (modèle conceptuel des données) ?

Quel est votre SGBD ?

Veuillez fournir le script de création des tables.

[Paprick]

Bonjour,
Il est effectivement essentiel de commencer par la conception, et donc d'établir un Modèle Conceptuel de Données avant de parler de tables (qui en seront la conséquence directe).
Par ailleurs, les tables que vous proposez semblent présenter des redondances (Nom, Prénom, ...) ce qui ne conviendra pas du tout au moment de définir le schéma relationnel de la base de données.
Mais bon, première étape : le MCD !

[escartefigue]

Bonsoir Lemouba,

Outre les judicieux conseils qui précèdent, j'ajoute quelques remarques

Dans une table d'une base de données, il n'y a pas de "champ", il y a des colonnes.
Les champs sont les attributs d'un formulaire de saisie ou d'un état.


Par ailleurs ici :

J'ai créé 4 tables
1- Table Membre. Elle comprend 11 champs colonnes:
[...]
- Contact (1; 2 et 3)
- Domicile ou résidence
- Photos ou pièces jointes
- observation

S'il peut y avoir plusieurs contacts, alors il faut créer une nouvelle table en lien avec la table des membres
Domicile ou résidence ne saurait être un attribut unique, les adresses sont normées, pour la France, il faut appliquer la norme postale accessible gratuitement en quelques clics sur la toile
"Photos ou pièces jointes" : le pluriel sur chaque substantif me fait craindre à une collection de valeurs dans une même colonne à ne jamais faire ! Là encore, à remplacer par un lien entre le contact et sa ou ses photos d'une part et sa ou ses pièces jointes d'autre part

3- Table Prêts. Ses champs colonnes sont:
- Nom
- Prénom
- Avaliste
- Montant demandé
- Montant reçu
- Intérêt mensuel
- A rembourser avant le
- Observation

L'usage est de nommer les tables au singulier, on aura donc la table PRETS dans laquelle on trouvera tous les prêts
Comme mentionné par mes prédécesseurs, nom et prénom n'ont rien à faire ici, par contre, l'identifiant du membre est requis en tant que clef étrangère (FK)
Qu'est-ce qu'un "avaliste" ? S'il s'agit de la personne qui se porte garant et que cette personne est un membre, alors il faut la aussi utiliser un lien FK avec la table des membres, à préciser dans vos règles de gestion
Les montants sont ils toujours en € ? Dans la négative, ajoutez un attribut pour préciser la devise.

4 Table Remboursements. Ses champs sont:
- Nom
- Prénom
- Montant prêté
- Net à rembourser
- Versement du jour
- Reste à verser
- Observation

Nom et prénom à virer
Il manque un identifiant de remboursement qui devrait constituer tout ou partie de la clef primaire (PK). Idéalement, la clef primaire devrait être constituée en majeur de la référence du prêt (FK composante de la PK) et d'un identifiant de remboursement .
Il manque le lien avec le prêt (sauf si un membre ne peut avoir qu'un et un seul prêt) et la date de remboursement
Le reste à verser est a priori un montant à calculer en fonction du montant emprunté, du taux et des remboursements déjà effectués.
Si c'est le cas il ne doit pas être stocké. Précisez exactement ce qu'est ce reste à verser dans vos règles de gestion

Ayant déjà réalisé ces différentes tables, Je n'ai pas pu créer la base de donnée, ( mes essais sont rejetés ). Ce qui me rend la suite extrêmement compliqué.

Pas clair : les tables sont des composants de la base de données, la création de la base de données est un pré-requis à la création des tables.
Par contre il est fort possible que le script de création de vos tables soit en erreur, ce qui n'est pas surprenant puisque vous avez commencé par la fin : la création des tables.
Commencez par le modèle conceptuel comme l'ont justement suggéré Fsmrel et Paprick, ça vous évitera bien des erreurs.