En première, nous avons manipulé des données en tables, le plus souvent contenues dans des fichiers csv.

Cette structure de données, bien que pratique et facilitant l’échange de données entre utilisateurs, ne permet bien souvent pas de décrire facilement la complexité des relations existant entre différentes informations.

Dans le cas de données plus compliquées, on peut donc utiliser une base de données. Différents modèles existent mais le plus utilisé reste la base de données relationnelle. C’est ce modèle que nous allons étudier ci-dessous.

Seule, une base de données est assez inutile. On la couple souvent avec un Système de Gestion de la Base de Données (SGBD) qui permet d’interagir avec celle-ci en ajoutant des valeurs, cherchant des données… On pourra retenir les exemples suivants :

• MySQL : le plus connu et courant
• SQlite : bibliothèque écrite en C dont il existe aussi une version Python (sqlite3)

I. Des relations et des tables

1. Tables et attributs

Une base de données relationnelle est construite à l’aide de relations que l’on appelle communément des tables. Voici par exemple une table eleves :

On peut le voir : une relation est en réalité un tableau à double-entrée.

• La première ligne comporte les entêtes, les attributs de la table.
• Les lignes suivantes comprennent les données

Lorsqu’on définit un attribut, on précise son type : cela permet de préciser quelles sont les valeurs possibles. Par exemple lorsque l’utilisateur ajoute des données, le SGBD vérifie que celles-ci correspondent bien aux types indiqués.

Dans le cas de l’exemple précédent, les types sont :

• id : type entier INT
• nom, prenom, classe : type texte VARCHAR
• naissance : type date DATE

2. Clé primaire

Par principe, une table ne peut pas contenir deux lignes parfaitement identiques. L’exemple ci-dessous sera refusé par le SGBD :

On pourrait toutefois imaginer que deux élèves de même nom, prénom, nés le même jour soient dans la même classe (si, si, c’est possible !). Dans ce cas comment gérer notre table ?

Il sera possible de les distinguer en utilisant leur id : cette valeur numérique est unique pour chaque ligne : deux lignes ne peuvent avoir le même id.

Le plus souvent on va même jusqu’à préciser que l’id est la clé primaire (PRIMARY KEY dans les SGBD) de notre table :

• cet attribut permet d’identifier sans aucune ambiguïté une ligne.
• une table ne contient qu’une seule clé primaire…
• …mais une clé primaire peut-être composée. Par exemple le couple (niveau, numéro) permet de définir sans ambiguïté une classe du lycée. Ainsi (T, 3) décrit la “Terminale 3” alors que (1, 3) la “Première 3”

II. Plusieurs tables

Complétons la table précédente en ajoutant les professeurs principaux :

Nous obtenons une nouvelle table valide mais contenant des répétitions : est-il vraiment utile de préciser pour chaque élève que M. Ayrault est le professeur principal de la Terminale 1 ?

Il serait plus judicieux de créer une seconde table classes :

On le voit, dans cette seconde table, une ligne correspond à une classe et le nom du professeur principal n’est alors indiqué qu’une seule fois.

Ici aussi l’attribut id sert de clé primaire.

Remarque : On peut s’interroger sur le nom des attributs : est-ce que le SGBD ne va pas confondre les deux colonnes id ? Non, à condition d’être explicite en précisant eleves.id ou classes.id selon que l’on souhaite parler de l’un ou l’autre.

On peut donc utiliser l’id de la classe dans la première table :

Comment le SGBD va-t’il savoir que la classe 1 de la table eleves est la 1 de la table classes ? On utilise une clé externe (FOREIGN KEY) : la clé externe de l’attribut eleves.classe est classes.id. On indique ainsi que la valeur de la colonne classe de la table eleves correspond à l’id de la tables classes.

Remarque : un élève appartient à une classe mais une classe compte plusieurs élèves. On parle de relation un pour plusieurs. On peut aussi imaginer des relations un pour un : un élève a une place précise dans le plan de classe et une place correspond à un élève unique.

III. Modèle de données relationnel

Travailler avec une base de données, créer une base de données nécessitent donc de bien comprendre sa structure, les relations entre les différentes tables et attributs.

Cette structure peut être décrite facilement à l’aide du modèle de données ou schéma. Voici par exemple un schéma représentant la base de donnée d’un lycée :

Sur ce schéma on peut voir qu’il existe cinq tables liées les unes avec les autres.

Ainsi un élève :

• fait partie d’une classe (grâce à la clé externe entre eleves.classe et classes.id)
• suit un cours en première spécialité (correspondance entre eleves.spe_1 et cours.id)

Les cours (qui correspondent ici à des groupes d’une matière) sont associés :

• à des élèves
• à une matière (cours.matiere = matieres.id)
• à un professeur (cours.professeur = professeurs.id)

Les 1 et les * sur les relations entre les tables indiquent le type de relation :

• le 1 indique que cet attribut correspond à une unique entrée dans l’autre table (un élève est dans une classe)
• le * permet de dire que cet attribut peut se retrouver plusieurs fois (une classe comporte plusieurs élèves)

Remarque : On trouve souvent le symbole \(\infty\) à la place de * dans les schémas.