8791 sujets

Développement web côté serveur, CMS

[Résolu]Recherche aide pour la structuration d'une BDD mysql !

Bonjour à toutes et à tous. Je souhaiterais réaliser une BDD me permettant de stocker les consommations énergétiques de ma maison (et cette BDD pourra peut être me servir par la suite pour d'autres maisons, de ma famille qui sait!). J'ai dans l'idée par la suite d'afficher les valeurs sous forme de graphique.

Donc pour l'instant je suis parti dans l'idée d'avoir une table maison, une table zone (ex cuisine, chambre, etc.), une table capteur (capturant les données), une table consommation(type, val et date) et une table utilisateur(parent, enfant). Sachant que les enfants n'auront accès qu'au données de leur chambre.

Je fais donc appel à vous pour savoir comment je pourrais structurer au mieux cette BDD, si une table consommation unique est judicieuse ou vaut-il mieux avoir une table consommation pour chaque type d'énergie. Comment créer des relations entre les tables (avec les clés primaires et secondaires)...


Voilà, je vous remercie par avance et j'espère que vous allez pouvoir m'éclairer sur ce point Smiley murf

[NB] : Je suis sous phpmyadmin
Modifié par lorenzo_one (02 Aug 2011 - 16:06)
Bonjour,
J'ai pas vraiment compris l’intérêt de faire ça par Internet?
Possibilité de suivre en ligne c'est ça?

En tout cas, ce que tu veux faire et ce que t'as donné adrien881 et facilement faisable sur Access.

Et même si tu choisis toujours de faire ça par BDD je te conseille de lire un peu de doc sur Merise Smiley cligne (là encore méthode employée par adrien881)
Tout d'abord, merci pour vos réponses.
Alors en effet, j'ai dans l'idée de vouloir visualiser mes graphiques à distance via le net, d'où ma demande.

Pour les graphiques, je pense me diriger vers du Javascript.

Sinon adrien881, est-il nécessaire de créer la table PermissionDacceder? Ou alors est-ce que j'obtiendrais le même résultat avec des jointures dans mes requêtes sans utiliser cette table?.

En fait ce qui me pose problème depuis le début, c'est bien les relations entre tables, comment les faire sur Phpmyadmin? Faut-il utiliser des jointures? J'ai beau regarder des forums et tutoriaux, j'ai du mal à voir comment réaliser ces relations (clé primaire et clé étrangère?).
Dans ce diagramme seules les tables maison, zone, utilisateur et capteur ont une clef.
Elle sont primaires se nomment id_nom_de_la_table. Les rendre auto-incrémentales simplifie la vie. La colonne id_capteur de la table consommation elle n’est pas une clef, mais sert à lier les tables capteur et consommation. Faire une relation entre tables sous phpMyAdmin c’est juste créer une colonne dans une table reprenant l’identifiant d’une autre table, et c’est tout.

Cela marche très bien quand une ligne d’une table A peut être liée à plusieurs lignes d’une table B alors qu’une ligne de la table B est liée à une seule ligne de la table A. On rajoute la colonne id_A dans la table B.

Mais quand tu as 2 tables A et B où une ligne de A peut être associée à plusieurs lignes de B et qu’une ligne de B peut être aussi associée à plusieurs lignes de A, on passe par une table d’association. C’est le cas de PermissionDAccéder (un utilisateur peut accéder à plusieurs zones et une zone peut être accédée par plusieurs utilisateurs). Ces tables n’ont que 2 colonnes reprenant les id des 2 tables associées. Elles n’ont pas de clef.

Les jointures ne servent pas dans l’analyse du problème elles interviendront quand ton programme souhaitera interroger ta base sur des tables séparées par plus d’une relation.
Merci beaucoup Adrien car le noeud de mon problème commence à se dénouer. Cependant une question me reste en suspend : comment fait-on pour utiliser les tables d'association?
Le mieux sera de prendre un exemple.

Table Utilisateur
id_utilisateur   prénom
1                papa
2                maman
3                enfant

Table Zone
id_nom         nom
1          chambre_parents
2          chambre_enfant

Table PermissionDAcceder
id_zone   id_utilisateur
1            1       // La chambre des parents est accessible à papa
1            2       // La chambre des parents est accessible à maman
2            1       // La chambre des enfants est accessible à papa
2            2       // La chambre des enfants est accessible à maman
2            3       // La chambre des enfants est accessible à l’enfant


Dans ton code si tu voudras connaître les id des zones accessibles de l’utilisateur d’id 2 (maman)
select id_zone
from PermissionDAcceder
where id_utilisateur=2


Si tu souhaites récupérer le nom de la zone il faudra faire une jointure
select Zone.id_zone, Zone.nom
from Zone
inner join PermissionDAcceder
on PermissionDAcceder.id_utilisateur=2 and PermissionDAcceder.id_zone=Zone.id_zone

Modifié par adrien881 (20 Jul 2011 - 15:17)
Bien écoute je te remercie d'avoir donné de ton temps pour m'expliquer les choses et m'en vais dès à présent réaliser cette BDD. Peut être à une prochaine sur un autre poste.
Bonjour,
j'arrive un peu après la guerre mais bon ça pourra peut être toujours servir...

La structure décrite (Maison -> Zone -> Capteur) est en fait un arbre.
Hors la manière correcte de modéliser un arbre est d'utiliser une clé reflexive ! C'est beaucoup plus propre et évolutif !

Dans ton cas cela permettrait de n'avoir que 4 tables tout en gardant la même base si tu veux rajouter des niveaux de granularité, exemple :
- une zone quartier regroupant plusieurs maisons,
- une zone étage regroupant plusieurs pièces,
- des groupes abstraits de plusieurs pièces comme par exemple cuisine+sdb, ou cave+grenier, ou chambre1+chambre2+chambre3 (cela peut être très utile pour tes graphiques)

En gros cela donnerait

Utilisateurs (id, prenom, ...)
PermissionsUtilisateurs (idUtilisateur, idZone)
Zone (id, parentId, type, adresse)
Consommation (idZone, valeur, date)

Pour que ta BDD respecte la forme normale, il faudrait idéalement sortir les champs comme adresse et type qui ne sont utilisés qu'à certains niveaux de l'arbre de Zone et les places dans une table d'attributs. Mais en toute honnêteté : pour un projet de cette taille et pour seulement deux champs, ça ne vaut pas le coup de se faire chier.
BonjourYwg, ne penses tu pas qu'il serait plus simple de creer une nouvelle table nommée domaine par exemple pour regrouper l'ensemble des batiments?
lorenzo_one a écrit :
BonjourYwg, ne penses tu pas qu'il serait plus simple de creer une nouvelle table nommée domaine par exemple pour regrouper l'ensemble des batiments?


Tant que l'application reste simple il est toujours plus simple de mettre un "bout de scotch" que de concevoir de manière pérenne.

Le problème se pose quand :
- l'application évolue souvent et que tu dois mettre des bouts de scotch tout les mois.
- l'application est complexe et que la pose du bout de scotch représente 3 mois de travail et génère des centaines de bugs.

Après oui, une clé réflexive si c'est la première fois que tu en fais une, ce sera plus compliqué à mettre en place.
Mais au niveau de l'évolutivité, de la qualité de conception et de la simplicité quand ton programme deviendra conséquent, c'est sans commune mesure.

Par exemple la si tu rajoute une table "Domaine" regroupant des maisons, il faut que :
- tu modifie ta BDD
- modifie toutes tes requêtes
- modifie tes classes et tes fichiers php pour qu'elles redescendent un niveau de lien en plus pour accéder aux mesures
- modifie l'interface utilisateur

Si dès le début tu crée une clé réflexive et que tu tourne tes classes et ton interface autour de cet notion d'arborescence il faut que :
- ......
- ...
- ha bah non en fait il ne faut rien faire du tout, c'est déjà tout fait


C'est un choix à faire, sois tu vois les choses de manière pragmatiques, tu veux un truc qui marche et de toute façon tu aura jamais besoin de le modifier, sois tu veux faire les choses bien car ca évoluera ou parce que tu veux apprendre. C'est à toi de voir. Smiley cligne
Sujet clos
Aller à