BDD , datamarts et PHP Mysql ?

dans le cadre de mon projet d'autoformation sur le développement web secteur santé , j'ai une application qui marche sur le plan fonctionnel.
descriptifs:
Application web de surveillance épidémiologique d'une pathologie X.
saisie de donnée quotidienne type agrégats ( age , sexe , localité...) ,
modalité de surveillance:
tableau de bord utilisateur ( Total générales , par age et sexe ,Minimum , maximum , moyenne et graphe d’évolution hebdomadaire)
unité temps : une année avec cumule quotidien.
la table principale contiens les données d'une seul année
problématique:
Faut-il limité la table principale a une seul année de saisie?
est ce que dans la même application en peut crée un datamarts?
si oui comment et quel sont les outils?
est ce que PHP et mysql suffit pour la mise en place?

Citation:

---

Faut-il limité la table principale a une seul année de saisie?

---

Je ne vois pas pourquoi, au pire tu peux la partitionner.

Citation:

---

est ce que dans la même application en peut crée un datamarts?

---

Oui, pourquoi pas. Tu peux faire un star schema par exemple pour te simplifier la vie.

Coté outils, PHP et MySQL peuvent se prêter sans problème à ce petit jeu, à toi de voir en fonction du cahier des charges, des volumes de données à stocker et traiter mais à vue de nez ça se fait tout à fait sur une stack LAMP.

Merci , je viens d'apprendre une nouvelle chose "partitionnement d'une table".

Citation:

---

Oui, pourquoi pas. Tu peux faire un star schema par exemple pour te simplifier la vie.

---

là en vire vers les entrepôts de données.

Citation:

---

Coté outils, PHP et MySQL peuvent se prêter sans problème à ce petit jeu

---

dans le cadre de projet d'autoformation.
dans le cas ou en s'oriente vers l'informatique décisionnelle sa donne quoi comme résultat ? surtout avec php et mysql !!!!

Citation:

---

stack LAMP.

---

demande Lunix non !!!

après une relecture du lien sur le partitionnement sa semble très intéressant pour des petits travaux avec des requêtes d'agrégats sur année, mois , semaines.. ect.
mais si on veut faire des recoupement par rapport aux établissements , clients , patient ou autre là je crois que sa demande plus que cet dimensions de partitionnement.

Le but avoué du partitionnement est de permettre l'utilisation de très grosses tables par exemple de log d'activité (par très grosses, j'entends plusieurs millions de tuples).

Ce n'est pas toujours utile de partitionner une table. Mais des tables Client, Etablissements, Patients etc ne sont jamais aussi grosses que ça, un moteur InnoDB classique fera tout à fait l'affaire.

Ah et au fait, il n'y a pas de concept de "Table principale" dans une database relationnel. Le plus important ce sont les attributs et les relations. Si tu te retrouves à tout mettre dans la même table, c'est que tu as foiré la conception de ton schéma.

@ Benjamin:

Citation:

---

Ah et au fait, il n'y a pas de concept de "Table principale" dans une database relationnel. Le plus important ce sont les attributs et les relations. Si tu te retrouves à tout mettre dans la même table, c'est que tu as foiré la conception de ton schéma.

---

ma table principale : c'est la table qui contient des enregistrements en plus des id d'autres tables , tous cela est basé sur la méthode MERISE.
la genèse de la problématique du post:
dans mon application web : j'ai deux onglets 1- Tableau de Bord 2- Analyse
Tableau de Bord:
permet de suivre l’évolution des événement dans l'année en cours par rapport a la maladie X.
tous les requêtes d'agrégats se font sur la table que j'ai nommée principale.
la table doit contenir les données d'une seule année.
le verrouillage se fait après 10 jours de la fin d'année ( exemple : 10 janvier 2012 pour l'année 2011).
ensuite les données sont transférés vers table archives.

Analyse:
contiens plusieurs indicateurs de suivis par rapport a un ensemble d'année de suivit de la maladie X , ces données normalement sont transféré de la table principale vers table archive.

Objet:
afin de permettre a l'utilisateur de faire la saisie et le suivit ( tableau de bord sur une seul table).
l'analyse sur une autre table.
s’orienter vers l'informatique décisionnelle dans le cadre de mon autoformation.
questions:
Est ce que c'est la bonne démarche?

je crois que je me suis mal exprimé.
après avoir lu la doc sur le BI , j'ai constaté que l’entrepôt des données c'est une autre modélisation par rapport au projet principale.
je reste sur le projet principale:
table principale ou table conteneur , c'est une table qui contient tous les déclarations de la Maladies X durant une période.
définition de la période : j'ai fixé cette période en terme de semaine en 53 semaines soit une année.
sur la page web , j'ai trois onglets :
N° 1 pour la mise a jour des données.
N° 2 pour afficher le tableau de bord.
N° 2 pour faire des analyses sur plusieurs années.

Démarche:
1-l'utilisateur saisie les données ( sa marche bien).
2-Tableau de bord y'a pas de problème.
3-la mise a jours est verrouiller le dixième jours de la nouvelle année par rapport a l'année précédente et les données sont transférés vers la table objet de l'analyse.

la question 1 :
pour la démarche 1 et 2 je laisse l'utilisateur travaillé sur la même table.
est ce que c'est la bonne méthode?

la question 2 :
pour l'analyse , je pense crée une autre table contenant tous les données transféré de la table principale.
est ce que c'est la bonne méthode ou il y a autre démarche?

aussi je vous informe que l'analyse comporte des éléments du décisionnelles tel que la moyenne , min , max , taux et autres indicateurs.

Q1: oui, je ne vois pas pourquoi on ferait autrement.

Q2: non, créer plusieurs tables pour contenir les mêmes données n'est pas du tout une bonne idée. S'il y a bien une chose qu'il faut éviter dans un schéma relationnel c'est la redondance. On peut en revanche travailler avec des vues ou des procédures stockées pour faciliter le travail.

D'une manière générale, il faut que le modèle de données soit indépendant des contraintes de l'application: il dois se suffire à lui-même.

merci benjamen de votre modestie, votre disponibilité et surtout pour votre sens d'aidé les autres et sans les complexés. :P
donc je doit resté sur la même table , autrement tous les actions se ferons sur la même table quelque soit le type et le contenu.
en deux si je veux faire une analyse approfondie je doit passé par les datamarts non !!!!!

Je t'en prie ;) (sur le forum on se tutoie, c'est plus naturel :ccool:)

En fait, je voulais attirer ton attention sur le fait que mettre les même données à deux endroits ne va pas améliorer quoi que ce soit (car les accès concurrent sur une table InnoDB soit loin d'être un problème quand on a un design carré et optimisé), au contraire, cela va induire des doublons et de l'incohérence car va finir par se poser le problème suivant: quelle table porte les bonnes/vraies valeurs et comment les synchroniser ?

Je ne connais pas assez bien le principe des datamarts pour te dire si c'est adapté ou non à ton usage. Personnellement, je n'en ai jamais eu besoin: j'ai toujours fait mes traitements de la façon que je t'expose, y compris sur de très gros jeux de données. Si l'analyse prends du temps, il faudra peut être penser à optimiser le schéma (surtout les clés) voire mettre en place un cache applicatif (afin de ne pas se casquer tous les volumes à chaque fois).

L'idée principale d'une modélisation claire c'est d'obtenir l'atomicité de l'information et sa disponibilité d'un bout à l'autre du schéma. On doit toujours pouvoir obtenir les informations qu'on cherche à coups de jointures. Ma philosophie c'est que si tu dois faire plusieurs requêtes pour extraire une donnée, c'est que tu as quelque chose qui cloche dans ton modèle.

Citation:

---

...cela va induire des doublons et de l'incohérence car va finir par se poser le problème suivant: quelle table porte les bonnes/vraies valeurs et comment les synchroniser ?

---

le principe est que une fois l'année terminée exemple année 2011 , le 10 janvier 2012 je procède a vider la table principale est entreposé les données dans la deuxième table ainsi de suite pour les années a suivre.
est ce que c'est la bonne démarche?

Citation:

---

Je ne connais pas assez bien le principe des datamarts

---

http://dico.developpez.com/html/3226...e-Datamart.php
http://grim.developpez.com/cours/bus...datawarehouse/

Citation:

---

voire mettre en place un cache applicatif

---

un peut de détaille merci.

Citation:

---

L'idée principale d'une modélisation claire c'est d'obtenir l'atomicité de l'information et sa disponibilité d'un bout à l'autre du schéma. On doit toujours pouvoir obtenir les informations qu'on cherche à coups de jointures

---

je travaille avec la méthode MERISE. (normalement y a pas de souci ).

Citation:

---

le principe est que une fois l'année terminée exemple année 2011 , le 10 janvier 2012 je procède a vider la table principale est entreposé les données dans la deuxième table ainsi de suite pour les années a suivre.
est ce que c'est la bonne démarche?

---

Ah, là d'accord. Il vaut mieux utiliser une seule table d'archive qui utilise le moteur Archive (qui permet de gagner beaucoup d'espace, en fait presque seul l'espace des données est occupé).

Pour le cache, j'ai des classes pour ça dans Axiom (voir axCache, axFileCache et axCacheManager). C'est à toi, en fonction de tes algorithmes d'extraction qui devra déterminer si c'est pertinent ou non. Dans le cas général, un cache n'est utile que si la même donnée longue à calculer est utilisée plusieurs fois dans un laps de temps assez court.

Je vais jeter un oeil sur les datamarts, ça peut toujours servir merci.

Citation:

---

qui utilise le moteur Archive

---

est ce que ta une doc sur le sujet.
j'ai pas encore développez cette partie et j'aimerai bien avoir une aide.

Pour la conception de la DB ? sûr mais il faudrait ouvrir un topic sur le forum MySQL car là on sort du cadre de la question initiale.

BTW la doc pour les moteurs de stockage MySQL est ici

Merci Benjamim est excuse pour le retard de réponse ( Mois de Karem..).
donc on résumé :
crée une table archive ou lieu d'utilisé un datamarts.
y a aussi des question qui se posent et qui relèvent du forum mysql.
merci encore une fois :P

Après réflexion, je trouve qu'un datamart est surdimentionné pour ton besoin (on parle d'ici d'une seule table et de quelque champs). Le datamart exprime sa puissance dans des infrastructures de données complexes dans lesquels on a besoin de faire du datamining, je ne suis pas certain que ce soit ton usage.

Maintenant qu'on en parle, je me rappelle du projet Palo qui permet la réalisation de datamart "cubiques" (ok c'est plutôt dédié à la BI mais bon...), tu pourrais y jeter un oeil ne serait-ce que pour ta culture générale ;)

Oui Benjamin , aussi je suit arrivé a cette conclusion du moment que une table archive suffit a réalisé mes requêtes (type décisionnelle..).
dans le cadre de l’autoformation sa suffit , mais je doit ajouter un niveau d'utilisation supérieur je serai obligé de passé au datamarts.
merci pour le lien :ccool:

NB/ comment vous faite pour rédigé vos posts ( clair , simple et sa donne envie de relire....) :ccool: