Bonjour,
 
Pour le boulot, on m'a demandé de voir la meilleure solution pour stocker et utiliser nos résultats d'expériences.
En gros, on fabrique des capteurs. Pour chaque capteurs, on note le process de fabrication, les propriétés au temps 0 et la variations de ces propriétés en fonctions du temps.
Donc il faut rentrer les données, pouvoir faire quelques calculs sur certaines données (+,-,*,/ et c'est tout), pouvoir les trier (par exemples pour comparer les propriétés au temps 0 en fonctions du process de fabrication) et faire des graphiques (pour voir les tendances, c'est plus pratique).
 
Je connais un peu Excel et avec quelques macros, je dois pouvoir m'en sortir.
Mais est-ce qu'un logiciel de base de données ne serait pas plus adapté puisqu'au final il s'agit d'une base de données de nos résultats (qu'on veut interroger pour les mettre en forme) ?
Pourriez-vous me donner votre avis car je ne sais pas vraiment quel est le champ d'action d'une base de données ?
Et la question subsidiaire si vous penchez pour la solution base de données : quel logiciel sous Linux ? (mais c'est surtout la réponse au-dessus qui m'intéresse - pour cette question, je chercherai un peu tout seul)
 
Merci par avance,
Ptit Bleu (complet en base de données)

Salut,  
 
Alors oui pour stocker des données, une base de données c'est toujours mieux qu'un tableau Excel, c'est clair...
 
Mais avant de te lancer dans les bases de données sur serveur, pourquoi ne pas commencer tout doucement avec Access ? C'est assez facile à utiliser, tu peux apprendre le SQL à ton aise en même temps puisque tu as des interfaces graphiques pour tout ... si tu fais un modèle de données sufisamment bon (i.e. ne pas faire sur Access ce que tu ferais sur Excel: une grosse table unique) tu dois pouvoir même par la suite exporter ça vers un système "plus sérieux" comme MySQL ou MSSQL ...
 
Je ne sais pas si Access offre la possibilité de faire des shiny camemberts donc à explorer pour l'exigence de graphiques ..

Salut Zebix.
En fait on travaille avec le Pingouin. Une alternative à Access sous Linux pour commencer ?
 
Sinon, on se lancera dans le grand bain tout de suite avec une base "sérieuse". Mais on peut faire des calculs et sortir des quelques courbes avec les SGBD comme Mysql ou il faut un logiciel externe pour qui interroge la base et réalise les graphes (et je ne suis pas informaticien ...) ?
 
Merci encore pour vos lumières.
Ptit Bleu.

tu as avec openoffice 2 un equivalent : "Open Office Base".
Je n'ai jamais farfouillé en profondeur, donc je ne peux pas te garantir l'existence de "graphes/courbes" ( d'ailleurs je doute fortement).
Néanmoins je suis d'accord avec Zebix, c'est une bonne façon d'aborder les bdds simplement.

Enfin, se lancer "avec une base sérieuse" ne veut pas dire que tout sera plus facile.
Par exemple, mysql "tout seul" ne sait rien faire (à part stocker des données). Il faudra donc passer par de la "programmation" pour afficher les données ( sous la forme désirée, que cela soit un graphique ou une simple page html).

Sur vos conseils, je vais commencer par faire des essais avec Calc et Base et voir ce qui peut le mieux nous convenir car je ne me sens pas de me lancer dans de la programmation en plus de l'apprentissage d'un logiciel de base de données.
Mais si vous avez d'autres conseils, je suis toujours preneur.
 
A plus,
Ptit Bleu.
 

C'est encore moi.
Est-ce que oracle express pourrait-être une solution pour ce que je cherche à faire ?
Est-ce quelqu'un connait ?
 
Merci,
Ptit Bleu.

Oracle express c'est la version "gratuite" d'oracle.  
tu as l'equivalent chez IBM "DB2 express", et également chez crosoft avec "ms sql server express".
 
Grosso-modo se sont des versions allégées des produits vendus par chacun de ces editeurs.
Dis autrement ce sont de vraies ( par opposition à Access/Base) bases de données, et pour t'en servir il te faudra apprendre à programmer dans un langage qui permet l'intérrogation d'une de ces bases.
 
La réponse courte est donc: Non c'est pas plus une solution que MySQL si tu veux pas programmer.

Oui, mais surtout pas! C'est trop puissant, trop difficile à utiliser -- on en a justement parlé dans un topic ouvert récemment par veryfree.
 
De quelle quantité de données parle-t-on? Parce que tu risques d'être vite limité par un tableur. Tu peux apprendre en douceur à utiliser MySQL ou Postgres et te faire la main en SQL. Il existe des DBMS encore plus simples, genre HSQLDB, qui tourne en mémoire ou avec un simple fichier.
 
 
N.B. "Pas taper" dans le titre, ça ferait moins cloche.

Au niveau quantité de données, je dirai environ 50 capteurs par semaines avec chacun 10 propriétés à mesurer au temps 0 et à suivre (en espérant qu'on les suive longtemps car ça signifiera qu'ils marchent bien - donc pas mal de données). Et le projet est prévu sur 3 ans, ce qui fait, à la louche, 7000 capteurs.
Ca ne fait sans doute pas une grande base par rapport à ce que certains d'entre vous gèrent. En fait, je ne me rends pas compte.
 
Donc, à votre avis, base de données ou tableur ?
 
Moi, j'ai l'impression que le problème n'est pas trop la base de donnée mais plutôt comment je vais faire pour visualiser et exploiter mes données, car je le répète, je ne suis pas informaticien.
Qu'associer à Mysql pour faire ça, relativement facilement ?
 
Merci pour vos avis éclairés,
Ptit Bleu (boulet illétré et tout piteux pour la faute d'orthographe - désolé sircam)
 

Et bien je redirais encore une fois que "oO Base" ( ou access) est une bonne solution pour débuter.
Ces deux applications intègrent des outils qui facilitent la création de formulaire d'alimentation de la base ainsi que l'édition de rapports.
AMHA c'est amplement suffisant pour débuter ( et même pour maintenir une liste de 7000 capteurs)

C'est encore le boulet illettré (et pas illétré - vraiment nul aujourd'hui !)
Je n'ai pas compris ce qu'était AMHA mais je vais faire des tests avec oO Base et je verrai si ça me convient.
 
Sinon, est-ce que quelqu'un sait si on peut créer une requête sous oO Base et enregistrer le résultat sous un format utilisable sous Calc, ce qui me permettrait de réaliser mes graphes sous Calc sans avoir à programmer ?
 
Merci pour vos conseils,
Ptit Bleu (nul en base de données, en programmation et en orthographe ... entre autres).

Oui avec "Base", tu peux enregistrer les résultats d'une requête sous format "tableur" de ton choix, je t'ai fait une capture d'écran pour te montrer:

Sinon pour AMHA: http://www.google.fr/search?q=define%3AAMHA

Il va vraiment falloir que je me mette à la page (pour le français moderne , style "amha", et pour le français traditionnel pour l'orthographe en général)
 
Je pense que je vais commencer avec le couple Base/Calc et on verra.
 
Mais avant de me lancer sur mon clavier, il faut que je réfléchisse à la structure de la base (j'ai bon, non :-)
 
Encore merci à tous pour votre aide rapide et sûrement à bientôt, une fois que j'aurais commencé à toucher à Base,
Ptit Bleu.

Vu la quantité de données, modeste mais peut-être un peu chiante à manipuler, une DB ne serait pas un luxe. Au fait, tu comptes les encoder à la main, tes données?!
 
Si tu n'as besoin des rapports que de manière occasionnelle, un retour vers le tableur est acceptable, mais s'il s'agit de tirer un rapport quotidien, ça va rapidement devenir plus ch...
 
IMHO, tu n'es pas un "boulet illettrés"
 
Commence par modéliser, en effet, et repasse nous voir...

 
 
Pour les données, normalement je devrais pouvoir les récupérer à partir de fichiers de mesures. Ouf !
Il n'y a plus qu'à trouver quelques tutos sur la conception "sur papier" d'une base de données, ensuite je modélise, je fais quelques essais avec Base et Calc et on se rappelle.
Donc à dans 6 mois dans le meilleur des cas  
Et d'ici-là, j'essaierai aussi de relire mon Bescherelle ...
Ptit Bleu.

Aaah, un connaisseur. Franchement, t'en a pas besoin.

 
*troll incoming*
 
Mais toi t'en as peut-être besoin        

Base et access sont des db hein  
 

Bin t'as un editeur de report intégré à Base et Access... ça suffit amplement pour faire des rapports.
Rappel petit_bleu a besoin de rendu "graphique" genre camembert, courbes, histogrammes. Et l'utilisation d'un "vrai" sgbdr ne simplifiera en rien ce rendu dans des rapports quotidiens.

Sorry, j'avais pas percuté que "Base" permettait des rapports graphiques. Alors, oui, ça doit amplement le faire.

Alors c'est parti.
Je disais 6 mois, c'est parce que je n'y connais vraiment rien mais j'espère qu'il me faudra quand même moins de temps que ça (sinon le chef va sûrement gueuler ...).
 
A plus (6 mois ou moins),
Ptit Bleu.

Bonjour,
 
J'ai commencé à regarder comment organiser la base de données. Voici mon premier jet :
 
1ère table : description des lots d'échantillons avec les champs suivants :
N° du lot / Date de réalisation / Nombre d'échantillons réalisés / Caractéristique 1 du process / Caract. 2 du process / Process. 3 / Process. 4
 
2ème table : description des échantillons :
N° du lot / Nom de l'échantillon / Position lors de la réalisation / Caractéristique 1 de l'échantillon / Echant. 2 / Echant. 3  
 
3ème table : Variation des propriétés des échantillons en fonction du temps (régulièrement on reprend les échantillons et on remesure leurs propriétés) :
Nom de l'échantillon / Temps / Propriété 1 de l'échantillon / Propriétés 2 / Propriété 3
 
Le N° de lot relie la Table 1 à la Table 2 et le Nom de l'échantillon relie la Table 2 à la Table 3.
 
Que pensez-vous de cette organisation ?
 
Et la petite question subsidiaire :
Comment traduire cette requête en langage compréhensible pour le PC :
Balayer l'ensemble des lots et pour chaque N° de lot, pour un Temps t donné, trouver celui qui a le meilleur résultat pour la Propriété 2 et créer une Table lisible par le tableur ayant les champs suivants :
N° du lot / Nom de l'échantillon / Position lors de la réalisation / Caractéristique 1 du Process / Process 2 / Process 3 / Process 4
 
Suis-je assez clair ?
 
Je compte travailler avec Base et Calc mais je me contenterai d'un exemple qui marche avec la base de données que vous utilisez et j'essaierai de l'adapter. C'est juste pour me montrer comment démarrer.
 
Merci par avance pour vos commentaires sur la manière d'agencer la base de données et pour votre aide pour l'écriture de la requête.
Bon week-end,
Ptit Bleu.

Lot 1--n Sample 1--n SampleProp
 
- Soit sûr que tu n'as pas trop de champs "caract" dans la même table (comme tu le présente, ça va);
- Sample : il te faut une clef primaire, disons sample_id;
- SampleProp : idem, clef primaire sampleprop_id et clef étrangère sample_id.
 
On n'utilise en général pas "nom échantillon" comme identifiant (sauf si celui-ci est un code identifiant unique); c'est pq je te propose sample_id.
 
Je devine que les mesures seront toutes dans SampleProp et que Sample ne contient que les caractérisitques "immuables" de l'échantillon (celles qui ne varient pas à chaque mesure).
 
Pour les queries : finalise formellement ta modélisation, et on verra.

Salut Sircam,
 
Merci pour ton message. Bon finalement je n'étais pas trop loin de ta solution.
Pour ce qui est du nom de l'échantillon, ce sera en fait un code, ce qui rejoint ton sample_id.
Sinon, effectivement, toutes les mesures à t0 et en fonction du temps seront dans SampleProp. Cette table sera donc la plus grande et amenée à grossir (du moins je l'espère car cela signifiera que nos échantillons durent longtemps).
 
Par contre, je n'ai pas compris pourquoi le nombre de champs "caract" devait être assez réduit. Si notre process inclut plusieurs paramètres, il faut bien que j'en tienne compte. Donc là, pour l'exemple, j'en ai mis 4 mais il se peut qu'il y en ait plus. Ca pose un problème ???
 
Dernière question : que signifie pour toi "finaliser formellement la modélisation" ? Quel est la différence avec ce premier jet (ça fait 2 questions en fait) ?
 
Encore merci pour ton aide,
A plus,
Ptit Bleu.

Oui, parce que si tu as un nombre indéterminé ET important de caractéristiques, tu vas avoir des difficultés à interroger ta DB. Je suppose que les "caract" sont interchangeables (et pas : couleur, poids, taille, ... qui sont effectivement des attributs de ton échantillon).
 
Peux-tu préciser/donner un exemple de caractéristiques? Sont-elles génériques ou pas?
 

Formalise, càd fait un joli diagramme ou une jolie description table par table et champ par champ, avec intitulés exacts et explication. Autrement dit, qq chose prêt à être utilisé pour créer la DB.
 
Inutile de tenter des queries si ton modèle n'est pas terminé, ne serait-ce que pour nous te filer un coup de main. On sera plus à l'aise en connaissant exactement le résultat final, la DB telle qu'elle sera, plutôt que d'en avoir une idée vague. En plus, on peut encore affiner/corriger!
 
Ensuite seulement, on risquera du SQL.

Les "caract" auront un nombre bien déterminé et ne seront pas interchangeables. Ce sont des paramètres électriques (par exemple : résistance de l'échantillon) et optiques (transmission de la lumière) mais cela pourrait tout aussi bien être couleur, poids, taille pour reprendre ton exemple. On a défini des paramètres à suivre et on regarde leurs variations dans le temps mais on ne s'amusera pas à ajouter ou enlever des paramètres en cours de route.
Ca simplifiera le travail du gars qui fera la base de données (moi en l'occurence).
J'essaie de faire une jolie description dès que possible et je reviens.
 
Bon week-end,
Ptit Bleu.

Encore une question : je ne comprends pas l'utilité de la clef primaire sampleprop_id dont Sircam parlait dans son avant-dernier message.
Avec sample_id et le cham "temps", je peux identifier les propriétés de l'échantillon sample_id à un temps donné, non ?
 
Merci pour vos lumières (je dis "vos" car sircam a peut-être besoin de souffler un peu),
A plus,
Ptit Bleu.

Voilà, j'ai finalisé le formalisme de ma Base de Données (je reprends les termes de Sircam  ) en 3 Tables.
J'ai bon ???  
 
Table_Lot (Identifie le lot - la date de réalisation du lot - le nombre d'échantillons dans le lot - les 4 caractéristiques de réalisation du lot)
 
Lot_Id (clé primaire - type entier positif)
Lot_Date (type date)
Lot_Nombre (type entier positif (<= 24 / on ne peut pas faire plus d'échantillons par lot))
Lot_Caract1 (type réel)
Lot_Caract2 (type réel)
Lot_Caract3 (type réel)
Lot_Caract4 (type réel)
 
 
Table_Sample (Identifie le lot - l'échantillon dans le lot - la position de l'échantillon pendant sa réalisation - les 3 caractéristiques de l'échantillon)
 
Sample_Id (clé primaire - type entier positif)
Lot_Id (clé étrangère - type entier positif)
Sample_Position (type entier positif (<= 24 car il n'y a que 24 places au maximum))
Sample_Caract1 (type réel)
Sample_Caract2 (type réel)
Sample_Caract3 (type réel)
 
 
Table_Time (Identifie l'échantillon - le moment auquel on mesure les propriétés (le temps 0 correspondant à la première mesure) - les 4 propriétés sue l'on souhaite suivre avecle temps sachant que, par exemple, Time_Caract3 correspond à la même propriété pour tous les échantillons)
 
Sample_Id (clé étrangère - type entier positif)
Time (si ça dure longtemps peut-être que le type entier n'est pas suffisant ? Je ne me souviens plus quelle est la limite pour le type entier)
Time_Caract1 (type réel)
Time_Caract2 (type réel)
Time_Caract3 (type réel)
Time_Caract4 (type réel)
 
 
La liaison entre Table_Lot et Table_Sample se fait par l'intermédiaire de Lot_Id.
Chaque Sample_Id fait partie d'un Lot_Id
 
La liaison entre Table_Sample et Table_Time se fait par Sample_Id et Time (mais il faut les 2 car un temps Time donné on fait des mesures sur plusieurs échantillons ayant donc des Sample_Id différents).
Connaissant Sample_Id et le temps Time de la mesure, on peut connaître les Time_Caract de l'échantillon Sample_Id.  
 
Je ne sais pas si cette description est suffisante et (surtout) correcte mais je me risque à reposer ma question :
Comment traduire cette requête en langage compréhensible pour le PC :
Balayer l'ensemble des lots Lot_Id et dans chaque lot Lot_Id, pour un Temps Time donné, trouver l'échantillon Sample_Id qui a le meilleur résultat (en fait, la valeur la plus élevée) pour la Propriété Time_Caract1 (une fois que j'aurais compris pour une, je pourrai le faire pour les autres) et créer une Table lisible par le tableur regroupant tous les Sample_ID "gagnants" de chaque lot Lot_Id et ayant les champs suivants sur une même ligne :
Lot_Id / Time / Sample_Id / Sample_Position / Lot_Caract1 / Lot_Caract2 / Lot_Caract3 / Lot_Caract4  
 
Je vais quand même chercher de mon côté mais je compte un peu beaucoup sur vous pour me donner un embryon de réponse parce que là je pars dans l'inconnu   .
 
Merci par avance pour vos réponses (mais rien ne presse, le week-end approche),
Donc Bon week-end à tous   ,
Ptit Bleu
 

Selon la théorie, oui, et ce serait tt à fait correct, mais dans la pratique, les "timestamps" sont malaisés à manipuler. Une clef primaire composite n'a rien de mal en soi (la théorie), mais ça complique parfois la couche applicative au-dessus (la pratique). Une clef primaire composite avec timestamp, c'est chercher la bagarre.
 
* Inutile de pré-fixer tous les champs avec le nom de la table.
 
* Caract : nomme la caractéristique. 'poids', 'taille', 'couleur'.
 
* Pour ce qui est des requêtes, il te faut potasser SQL et commencer petit... "Balayer l'ensemble des lots", puis "Balayer l'ensemble des lots Lot_Id et dans chaque lot Lot_Id, pour un Temps Time donné", et ainsi de suite...
 

 
Voir comment faire la jointure (classique avec LOT.ID = SAMPLE.LOT_ID ou en utilisant des JOIN tous faits, variable de dialecte SQL à dialecte SQL, même parfois entre versions d'un même DBMS). Mais ça, c'est à toi de potasser...

Ok Sircam, je vais revoir ma base en tenant compte de ta remarque sur les clés composites.
Par contre, pour m'aider à potasser, quelqu'un aurait un lien du style "le sql par l'exemple pour les nuls" ? Pas un truc théorique ou un catalogue de commandes, mais un truc appliqué.
 
En tous les cas merci à tous (surtout à Sircam). Je vais maintenant essayer de remplir la base et de tester mes premières requêtes.
 
A plus,
Ptit Bleu.

il y a pleins de tutoriaux de qualité variable sur le net, mais sur ce forum Magicbuzz a rédigé un très bon topic:
http://forum.hardware.fr/hfr/Progr [...] 6416_1.htm

Merci pour le lien. Je m'en vais me former.
Bonne semaine à tous,
Ptit Bleu.