SQL(1) : Base de donnée

[Reivax]

Bonjour !

Ce petit tutoriel a pour but de vous expliquer le fonctionnement d'une base de donnée et plus particulièrement MySQL. Cependant le but est aussi de vous d'appliquer ces explications à d'autres types de bases de données comme postGreSQL, Access ou encore Oracle. Ces différentes bases de données (ou SGBD) sont plus ou moins accessible au grand public, par exemple Oracle est une base de donnée extrêmement coûteuse en terme de licence et ne se rencontre donc que dans le milieu professionnel alors que MySQL est gratuit et sert énormément dans tous ce qui touche au net. Il est fort probable que le forum jeu.video soit sous MySQL (mais je peux me tromper !) :).

Qu'est ce qu'une base de donnée ?

Une base de donnée est un rassemblement d'informations qui sont ordonnées sous forme de différents "tableaux" appelé tables. Ces tableaux contiennent des colonnes appelées "Champ" et les lignes de ces tableaux sont appelées "Tuple". Dans la base de donnée les tables sont reliées entre elle par des relations. Ainsi si vous avez deux tables, une table facture et une table client. La table client contient les informations sur votre client avec un numéro d'identifiant du client et la table facture contient les informations sur les factures dont le client facturé et donc le numéro client. La liaison entre les deux tables se fera grâce à l'identifiant client.

Le schéma suivant montre notre base de donnée sommaire :

Cette base de donnée nous permet donc de retrouver les factures et leur clients associés.

Les types de champs et la valeur null

Le type d'un champ est son format. Dans l'exemple précédent j'ai mis que le Id_Client était un Integer, ceci signifie que IdClient est un entier naturel. Name est quand à lui un VarChar, c'est à dire une chaîne de caractère. Il existe de nombreux types différents pour les champs, ceux ci définissent le format de votre champ et sont très important car ils indiquent à la base de donnée comment stocker les informations. Vous ne pourrez donc mettre dans un champ Integer que des entiers et dans un champ decimal que des nombres décimaux. etc !

Il existe une valeur particulière dans une base de donnée qui est la valeur "inconnu" c'est à dire null. Cette valeur permet de remplir grosso modo un champ à vide. Dans notre base de donnée d'exemple précédente nous n'avons pas de valeur null possible. Effectivement il est possible d'interdire la valeur null dans un champ d'une table. Par exemple une facture sans client étant totalement illogique, nous pouvons obliger ce champ à être renseigné.

Les clés primaires et secondaires :

Les clés primaires d'une table sont généralement le moyen d'obtenir de manière unique une information. Dans notre exemple précédent les champ qui sont soulignés sont des clés primaires. Ainsi si vous utilisez un idFacture, par exemple le "1", alors vous aurez accès qu'à une seule facture. De même pour l'idClient, si vous cherchez le "2", vous n'aurez alors accès qu'à une seule ligne de la table Client.

Les clés secondaires sont des clés primaires d'une table mais présente dans une autre table. Prenons notre champ IdClient, celui ci est clé primaire dans la table Client mais il est aussi présent en tant que champ normal dans la table Facture. La liaison entre les deux tables étant donnée par ce champ IdClient alors le champ IdClient est une clé secondaire dans la table Facture. Attention il arrive que l'on ne déclaré pas la clé secondaire dans la base de donnée malgré le fait qu'elle soit dans le modèle, et ceci pour simplifier et éviter quelques problèmes dans l'utilisation de la base de donnée. En effet, si vous aviez créer une facture sur le client 1, vous ne pourrez pas supprimer le client 1 sans supprimer cette facture ! (L'exemple n'est pas très bon car dans ce cas là nous perdrions toutes cohérence pour la facture mais il existe des cas où ce genre de chose peut exister et est nécessaire).

Les clés composées

Une clé de table n'est pas forcément composée que d'un seul champ. Elle peut être composé de plusieurs champs. Rajoutons des lignes à notre factures !

La table Ligne Facture contient deux clés primaires ! Dont une est même clé secondaire ! Ainsi à partir d'une facture vous pouvez retrouver toutes les lignes associés à celle ci grâce au champ IdFacture. Quel est l'intérêt d'avoir une clé composé ? Car nous aurions pu créer une clé primaire simple IdLigneFact et mettre en clé secondaire la facture ?

Déjà si vous allez consulter la table LigneFact ce sera plus clair d'avoir deux clés primaires, la vision de la facture associée est directe.

Ensuite si vous aviez utilisé qu'une seule clé primaire, vous auriez alors un numéro incrémental commun à toutes les factures. Dans notre cas ici la facture 1 aura un idligne 1 et 2 et la facture 2 un idligne 1 et 2 aussi alors que sinon vous auriez eu les numéro allant de 1 à 4. Pour retrouver les numéros de lignes vous auriez du ajouter un autre champ numeroLigne. Or dans ce cas là vous perdez l'unicité entre le numéro de facture et le numéro de ligne. En effet la facture 1 aurais pu avoir deux lignes 1 ! Avec la clé primaire unique composé c'est impossible car l'ensemble facture 1 ligne 1 existe déjà !

La dernière raison est une raison de performance. Lorsque vous allez faire la jointure entre la table Facture et LigneFact ce sera plus rapide avec la clé composé. Je vous expliquerai pourquoi avec les index tout de suite !

Les index :

Les index sont des objets SQL ressemblant aux tables mais n'ont d'existence qu'associé à une table. Nous avons déjà vu quelques index depuis le début de ce tutoriel. En effet les clé primaire sont des index !

Qu'est ce qu'un index ? C'est en fait une table trié dans un ordre précis. Ainsi dans notre exemple la table facture possède un index dit primaire qui stocke et trie tous les IdFacture dans l'ordre. Il est aussi possible d'avoir des index sur d'autre champ que les clé primaires, ce sont alors des index secondaires. Nous pourrions ainsi créer un index sur l'idClient de la table Facture.

Un index n'a pas non plus forcément qu'une seule colonne, il peut en avoir deux comme dans le cas de la table LigneFacture. Dans ce cas l'index contient les deux colonne IdFacture et IdLigne. L'index est d'abord trié dans l'ordre croissant sur le numéro de facture et ensuite dans l'ordre croissant du numéro de client.

Mais à quoi ça sert ?

Imaginez l'annuaire téléphonique, vous l'avez entre les mains et vous êtes en train de chercher le numéro de Toto. Manque de bol, l'annuaire a été fait au fur et à mesure et donc les numéros des gens apparaît dans l'ordre dans lequel ils se sont abonnés aux téléphone. En gros pour aller chercher Toto il va vous falloir parcourir tous l'annuaire ! Bon courage ! Surtout si Toto a plusieurs numéros et qu'il vous les faut tous, vous allez devoir vraiment tous parcourir ! En gros ça va être long !

En fait l'index va vous aider à parcourir votre annuaire, il l'a trié par ordre alphabétique ! Au lieu de faire page par page il va ouvrir l'annuaire trié au milieu voir si Toto est après ou avant cette page, puis de nouveau il va ouvrir une page au milieu de ce qui reste et ainsi de suite. Il va donc opérer par dichotomie (j'en ai perdu quelques uns là ?) et ne fera qu'un nombre très limité d'opération pour trouver tous les numéros de Toto ! L'index est donc un outil de performance incroyable !

Mais attention ! Cet index est aussi un gros gourmand ! Parfois un index ou trop d'index tue l'index ! Comme je vous l'ai expliqué l'index est une table trié ! Quand vous allez ajouter un tuple dans votre table facture, il va aussi devoir le faire dans l'index. Vous dédoublez donc l'information sur IdFacture mais aussi le temps d'insertion d'une ligne ! Alors si vous n'avez qu'un index dans une petite table ça va ! Mais imaginez si vous avez des centaines de millions de lignes ? Et 40 Index ? Votre recherche sera rapide mais l'insertion sera devenu super lente !

Les index sont donc à utiliser, il faut les utiliser mais il faut bien choisir les champs à indexer. Dans notre exemple précédent il est par exemple totalement inutile d'indexer les champs Descr. Personne ne fera de recherche sur la description d'une ligne de facture ! Par contre, nous pourrions faire un index sur le champ name de la table client, il est possible que dans notre logiciel qui utilisera cette base de donnée veuille retrouver les clients par nom d'utilisateur et non par idClient.

 

C'est fini !

Voilà je vous ai expliqué ce qu'est une base de donnée SQL dans les grandes lignes. Il existe plein d'autres choses à connaître tel que les tablespaces (lieu où sont stockés les tables). Mais ceci n'est pas très utile à ce niveau. Si vous voyez une boulette n'hésitez pas à me le dire que je corrige. Je n'ai rien expliqué sur le SQL car avant d'expliquer le SQL ben il faut savoir ce qu'est une base de donnée !

 

[Minstery]

Le 15/5/2016 à 11:35, Reivax a dit :

vous êtes en train de chercher le numéro de Toto

Ah ce sacré Toto... 
Super intéressant comme topic ^^ ça me fait un petit rappel du tout début du premier semestre d'info haha

[Wolf18]

Reivax, connais-tu l'AJAX ? J'aimerais apprendre mais n'ayant pas de grandes connaissances en javascript je tourne en rond, j'ai essayé des livres mais sans succès... Connais-tu un site ou même un livre ?

[Reivax]

Il y a 1 heure, Wolf18 a dit :

Reivax, connais-tu l'AJAX ? J'aimerais apprendre mais n'ayant pas de grandes connaissances en javascript je tourne en rond, j'ai essayé des livres mais sans succès... Connais-tu un site ou même un livre ?

Je ne connais pas l'AJAX.

En recherchant vite fait j'ai trouvé un tuto sur openclassroom : https://openclassrooms.com/courses/dynamisez-vos-sites-web-avec-javascript/l-ajax-qu-est-ce-que-c-est

Si cela peut t'aider ! Par contre ce n'est pas vraiment comme les base de donnée apparemment.