Bonjour.
Je suis en train de réfléchir, dans le but de me mettre à la programmation libreoffice base, à une appli permettant de suivre mes dépenses de manière assez fine.
En effet, sur le site de ma banque, je dispose d'un ensemble d'outils permettant de catégoriser les achats sur le mois et de voir vers quoi vont mes dépenses. Cependant ces outils ont un défaut : la granularité à la transaction bancaire. Pour certains paiements, ce n'est pas un problème (facture EDF, achat dans une boutique spécialisée …), mais pour d'autres paiements (exemple en supermarché), c'est plus difficile de répartir les dépenses par catégories. Aussi je me suis dit que je pouvais tenter de développer une appli avec libreoffice base pour suivre tout ça.
En réfléchissant à la façon d'organiser les données, j'ai choisi de modéliser une table produit, qui contiendrait soit des articles (paquets de pâtes, fromage râpé, champignons, liquide vaisselle, éponge, chaussettes, gel douche, etc …). Je réfléchis également à y intégrer des "services" (assurance habitation, abonnement téléphonie fixe ou mobile, accès a des services de vidéo en ligne, coupe chez le coiffeurcoiffeur, etc…). Dans les grandes ligne en ce qui concerne les articles, j'y mettrais la description, la quantité unitaire, le nombre d'éléments si c'est vendu en lot, etc … J'envisage également une table "magasin" ou "établissement" qui correspondrait au magasin dans lequel j'ai effectué l'achat. Et ensuite les choses se compliquent un peu pour moi.
En effet, je suis en train de me demander comment modéliser un achat. Pour moi un achat correspond à un paiement effectué pour un (ou plusieurs) produits dans un magasin à une date donnée. Autrement dit, si je modélise un achat dans une table (pour un article), j'aurais les éléments suivants :
- date
- magasin
- article
- prix payé
Le problème c'est que si je veux lier d'une façon ou d'une autre mes achats à une transaction de compte bancaire (parce que en effet c'est ce que je veux faire), je dois avoir quelque part un moyen d'identifier une liste d'achats (correspondant à un ticket de caisse et à une transaction bancaire). Donc je pense qu'il me faut quelque part une table qui identifierait ce groupe d'achat … mais je ne sais pas comment le modéliser. Une table "facture" ? Que contiendrait-elle, sachant que j'aimerais me servir de cette appplication pour pouvoir comparer les prix entre des articles dans plusieurs magasins différents ?
Auriez-vous des suggestions à me faire ?
# Créer une table ou pas ?
Posté par Suzanne . Évalué à 3.
Je pense que la question à se poser n'est pas tant s'il faut créer une table ou pas mais plutôt quel est l'identifiant unique d'une facture
Dans une table Achat(date, magasin, article, prix_payé) la facture est identifiée par le couple : (date, magasin) seulement si tu ne vas pas plus d'une fois par jour dans le même magasin.
Si ce n'est pas le cas, il faut ajouter un identifiant de facture. et ta table Achat devient :
Achat(id_facture, date, magasin, article, prix_payé)
Maintenant qu'il y a un id de facture, on peut ne pas vouloir répéter systématiquement date et magasin dans la table Achat. Dans ce cas on fait une table facture :
Facture(id, date, magasin) et la table Achat devient : Achat(id_facture, article, prix_payé)
avec Facture.id unique et Achat.id_facture faisant référence à Facture.id
Un autre axe de réflexion est de penser aux requêtes SQL que tu devras écrire en fonction de la structure de données choisie. Ici le choix "une seule table Achat" peut amener à écrire des requêtes plus simples.
# Utiliser les relations
Posté par Luc-Skywalker . Évalué à 2. Dernière modification le 16 février 2024 à 21:41.
C'est le cas typique d'une base de données relationnelle dans laquelle il y a plusieurs tables:
Facture {id, magasin_id, date, montant} <= sur ton relevé bancaire
Magasin/Fournisseur {id, nom}
Produit {id, nom, montant} <= le stylo, le CD etc
Categorie {id, nom} <= loisirs, énergie,
Et entre ces tables principales il y a des tables intermédiaires qui indiquent les relations:
Produit_Facture {produit_id, facture_id}
Produit_Categorie {produit_id, categorie_id} (si on admet que le produit "we en amoureux" rentre dans les catégories "chérie" et "vacances" par exemple)
C'est loin d'être complet et ce ne sont que quelques pistes. Quant à utiliser LibreOffice Base pour cela, cela me semble approprié, mais le plus important est de structurer tes données (tables) et d'établir les relations entre elles (et d'éviter les redondances):
1 <-> 1 une facture = un magasin (la relation est dans la table Facture)
1 <-> n un même produit peut être acheté dans différents magasins
n <-> n un produit peut être classé dans différentes catégories
Après, je ne sais pas jusqu’où tu comptes aller (comme détailler chaque item d'une facture de supermarché longue comme le bras avec dedans, du bricolage, de la nourriture, un disque dur externe en super promo, des fournitures scolaires pour les gosses …)
"Si tous les cons volaient, il ferait nuit" F. Dard
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.