Les bases de données, à quoi servent-elles ?

Généralités sur les bases de données et leur utilisation. (Extrait du forum Graphweather).

Modérateurs : jturlier, Météo Villarzel

Verrouillé
Avatar du membre
jturlier
Administrateur du site
Messages : 393
Enregistré le : 10 déc. 2014, 10:20
Localisation : Sérignan 34410
Contact :

Les bases de données, à quoi servent-elles ?

Message par jturlier » 23 févr. 2015, 10:23

*********************************
Ce sujet est verrouillé et ne peut donc pas recevoir de nouveaux posts. Si vous souhaitez faire des commentaires ou poser des questions, vous avez naturellement la possibilité d'ouvrir de nouveaux sujets.


Que sont les bases de données

Le seul moyen que la plupart des utilisateurs connaissent pour enregistrer des données ce sont les fichiers séquentiels : on écrit puis on lit chaque enregistrement ligne par ligne, et que quand on veut en lire un qui est au milieu du fichier, on doit lire toutes le lignes précédentes.

Il existe d'autres solutions, dont celle couverte par le sujet très général des bases de données relationnelles.

Une base de données est le lieu de stockage d'un certain nombre d'informations.
Ces informations sont organisées non pas en fichiers mais en tables. Dans chaque table on trouve plusieurs champs dont les noms généralement décrivent ce qu'on va trouver dedans : par exemple dans notre table météo on va avoir un champ qui concerne la date et l'heure, un autre pour la température extérieure, le point de rosée, ...
Du fait de leur organisation spatiale, chaque morceau d'un même enregistrement est accessible soit par son nom, soit par son contenu. Comment sait-on où se trouve tel ou tel nom ? grace à des pointeurs qui gardent trace de l'endroit ou chacune des valeurs est stockée.
J'essaie de m'expliquer : si on recherche toutes les données qui concernent une date et une heure le moteur va utiliser un index qui trouvera directement sur la date qui nous intéresse, et des pointeurs qui indiqueront où sont la température, le point de rosée... qui concernent cette date et heure (Très schématiquement !!!)
mais on peut aussi rechercher toutes les dates et heures pour lesquelles on a eu une température supérieure à 24°. Vous me direz qu'on peut aussi faire ça sur des fichiers séquentiels, c'est vrai, mais pas à la même vitesse, par exemple pour un fichier de 5 millions d'enregistrements, il faudra plusieurs heures, alors que sur une table quelques centièmes de secondes seront généralement suffisants.
Maintenant pourquoi "relationnel", tout simplement parce qu'une même table contient généralement des données de types homogènes, et il nous faudra plusieurs tables, une pour chaque type de données homogènes de notre application. Toutes ces tables auront des liens bivalents entre elles, certaines pouvant être reliées au travers d'une cascade de plusieurs autres.

Exemple les "fichiers" d'un services du personnel,
Dans une table on va avoir : le matricule, le nom, le numéro de service, l'age, le coefficient ... Ces données sont homogènes et concernent un seul individu.
Mais qu'en est-il des caractéristiques de son service ? On pourrait le mettre, bien sûr, mais au prix d'un manque d'homogénéité
Eh bien dans une autre table on va trouver les données concernant chacun des services : le Numéro de service, le matricule du manager, le lieu ou se trouve le service, son nom, le département auquel il appartient ...

Vous commencez à voir ?
si on demande : Quels sont les personnes nées en 1978 et qui sont à Montréal ? Facile direz vous on n'a pas besoin de tout ça. On sait qui c'est.
En langage SQL on va dire au moteur qui gère la base de données : SELECT Nom,lieu,coefficient from tabledesnoms, tabledesservices WHERE lieu="montreal" AND anneedenaissance=1978 AND tabledesnoms.numerodeservice=tabledesservices.numerodeservice
Ce mot "relationnel" prend ici sa signification : on utilise le champ numerodeservice de chacune des 2 tables pour créer une relation entre elles et faire notre recherche.

Si vous devez créer une base de données, la première et plus importante des tâches est de bien réfléchir à sa structure, car ce sera vital pour ses performances qui seront affectées de manière significative.
Il faut tout simplement garder en mémoire que c'est en fait un peu comme quand vous étiez en primaire et que vous appreniez le PPCD : on cherche le plus petit élément commun à plusieurs types de données pour les relier entre elles.

Précédemment, j'ai bien écrit "le moteur", parce que quel qu'il soit (MySQL, SQLServer, MSSQL, Oracle ...) c'est toujours la même syntaxe qui est utilisée.

Il faut voir que malgré tout, même s'ils utilisent le même langage, ils n'utilisent ni les mêmes structures de données, ni les mêmes algorithmes pour calculer où une donnée sera stockée, mais c'est pratiquement transparent pour l'utilisateur.

****************************************
Graphweather
Graphweather n'utilise qu'une seule table pour une question d'architecture (similarité avec les autres plugins), mais cela ne pose aucun problème parce que les données sont homogènes et donc rien ne justifie dans leur utilisation d'établir des relations avec d'autres types de données.

Alors pourquoi utiliser un SGDB ?
Pour la vitesse et surtout la flexibilité dans l'utilisation des données par d'autres programmes : votre site en PHP sait très bien utiliser ce type de données alors que vous aurez des difficultés énormes à programmer en utilisant des fichiers séquentiels.
Un exemple encore, le dernier : Cherchez la date et l'heure du maxi de la température pour un mois donné
- en séquentiel vous allez devoir lire tout votre fichier jusqu'au mois recherché, ensuite comparer chaque ligne avec le maxi trouvé précédement, garder en mémoire le contenu de la ligne si c'est le nouveau maxi, et ainsi de suite jusqu'à la fin du mois.
- en SQL vous allez dire je cherche la température maxi pour le mois de ... le moteur va utiliser les index pour pointer sur le mois et sur la température : opération quasi immédiate
Vous pourriez écrire : SELECT annee,mois,jour,heure,MAX(Temperature) FROM TableMeteo WHERE Annee=2007 and mois=12. N'est-ce pas trop simple ? !!!

Ce problème de vitesse et de charge du processeur est d'ailleurs la raison qui pousse les éditeurs de la plupart de nos logiciels, a créer des fichiers séquentiels mensuels ou autres, qu'il faut ensuite réassembler. Cela fonctionne, mais manque cruellement d'élégance quand on compare avec une base de données !

Les ODBC
Je vais aussi donner quelques précisions sur ce qu'est un ODBC. (Je n'ai pas eu encore la question, mais qui sait ...)
C'est tout simplement l'interface qui permet aux programmes extérieurs en PHP, VisualBasic, C++, Perl, Python et autres C# de communiquer avec le moteur, et ce, quel que soit le moteur, la syntaxe est toujours la même. Cela permet de rendre totalement indépendant un programme vis à vis des SGDB utilisés.

Je pense avoir répondu à vos questions. Bien que j'ai utilisé quelques mots du langage SQL le but n'était pas de vous faire un cours mais de montrer la simplicité et la flexibilité du langage.

Il existe de très nombreux sites, sur le sujet, certains répondront beaucoup mieux que moi sur des questions aussi bien générales que précises.
En voici quelques uns (en français) que je viens à l'instant de chercher pour vous (Merci G..gle et internet) :

http://sql.toutestfacile.com/

http://docs.postgresqlfr.org/

http://dev.mysql.com/doc/refman/5.0/fr/index.html
Jean

Station :
VP2pro + anémomètre ultrasons et console Vue
Cumulus 1.9.4 + Cumulus2SQL + MySQL

Audio :
FR
PC :
W10 64bits migré
http://meteoserignan.ddns.net
Image

Verrouillé