Base de données

Définition

En tant que machine à traiter les informations de manière automatisée, l'informatique a dès sa naissance été confrontée à la notion de donnée. La capacité de stockage des ordinateurs permet donc l'agrégation d'une grande quantité de données informatiques.

Or, très tôt (Voir CODASYL) - relativement à l'histoire de l'informatique - la notion de structuration des données s'est faite ressentir. En effet, bien qu'il soit utile de pouvoir sauver des informations diverses, il est aussi nécessaire de les manipuler en les ordonnant, rangeant ou indexant de manière à optimiser leur sauvegarde et/ou leur recherche ultérieure.

Dès lors, des Systèmes de Gestion de Base de Données (souvent abrégé en database par la suite) informatisés ont été créés de manière à atteindre ce but. Ces derniers sont un ensemble de procédure permettant les opérations de gestion de grandes quantités de données structurée. On pense notamment aux bases de données relationnelles, qui sont très répandues dans différents domaines, mais également à d'autres types de systèmes qui sont en train d'être (ré)découvert de manière alternative ou intégrée aux bases "traditionnelles".

In extenso, une base de données n'est autre qu'un ensemble de données structurées permettant une gestion optimale de ces dernières. À noter encore, que l'on entend ici le mot 'donnée au sens d'information pouvant être stockée et traitée de manière informatisée.

Fonctionnement des bases de données

La plupart des systèmes de gestion de databases permettent des opérations sur les données telles que :

• CRUD, acronyme de Create, Retrieve, Update, et Delete, c'est-à-dire les opérations les plus communes effectuées sur des données ;
• Filtrer : appliquer des critères de sélection pour obtenir un sous-ensemble de données par rapport à la totalité de l'information stockée ;
• Trier (ou Sorting en anglais) : utiliser des critères pour placer les données dans un ordre précis. Le tri est une opération informatique qui nécessite d'une grande puissance computationnelle, et les bases de données sont souvent optimisés pour ce type d'opération ;
• Répliquer : créer des "clones" d'une base de données pour des raisons de sécurité (backup) ou pour balancer les ressources (e.g. utiliser deux databases "jumeaux" pour départager un nombre élevé d'interrogations).

Ces opérations se font à travers des interrogations (en anglais queries) qui déterminent :

1. Quel type d'opération effectuer (créer, modifier, effacer, ... des données) ;
2. Quelles données seront affectées par l'opération.

Toute opération sur les données comporte un temps d'exécution qui est souvent proportionnel à la complexité de l'interrogation et/ou au nombre des données affectées par l'opération.

La modalité d'interrogation d'une base de données dépendent de différents facteurs. Il existe des bases de données qui disposent (ou qui sont incorporées) avec un logiciel qui permet de créer directement des modules pour manipuler ou des reports pour visualiser les données. C'est le cas des databases comme Microsoft Access, Open Office Base, ou FileMaker. Ce type de base des données est utilisé souvent pour des logiciels de type gestionnaire à petite échelle.

D'autres base des données doivent être interrogées à travers un langage, comme par exemple SQL (Structured Query Language). Il est utile, à ce propos, de faire une distinction entre deux formats de databases :

1. Les databases sous forme de "normal" fichier (e.g. SQLite) ;
2. Les databases qui doivent être installés en tant que logiciel ou service sur l'ordinateur/serveur (e.g. MySQL, MongoDB, ...).

Dans les deux cas, il existe principalement deux manières pour accéder et manipuler les données :

1. À travers des interfaces d'administration qui permettent surtout des opérations de gestion (e.g., installation, maintien, résolution de problème, importation/exportation, ...) ;
2. À travers des "connecteurs" qui permettent à des langages de programmation (e.g. PHP, Node.js, ...) d'interroger les bases de données et obtenir les résultats des opérations dans des formes exploitables directement à l'intérieur du langage de programmation. C'est de cette manière que beaucoup de logiciels et applications web (y compris ce Wiki) sont développés.

Modélisation des données (Data Model)

Un autre aspect important relatif aux bases de données concerne la modélisation des données (en anglais Data Model ou simplement Model). Cette étape, qui est souvent faite au moment de la création de la base des données, consiste à façonner la structure des données, plus précisément :

1. Définir un symbole qui va identifier la donnée, par exemple "first_name", "last_name", "age", etc.
2. Définir le type de donnée qui sera associé au symbole, par exemple "suite de caractères", "texte", "chiffre entière", "chiffre décimal", etc.

La modélisation des données dépendent étroitement du type de database utilisé, car les bases de données peuvent différer par rapport :

• À la structure des données : certains acceptent des structure exclusivement bidimensionnelles (i.e. lignes et colonnes) comme dans les feuilles de calculs (e.g. Excel) tandis que d'autres permettent des structures plus flexibles/complexes ;
• Au types de données acceptés : dans certains databases on peut stocker exclusivement des données dites "primitives" (en gros chiffres et texte), tandis que d'autres acceptent des données plus complexes comme des fichiers, des listes, des objects, etc.

Selon le type de database utilisé, au stade de la modélisation on peut également déterminer si le contenu associé à un symbole est obligatoire ou facultatif, s'il existe une valeur automatique à associer (e.g. la date et l'heure actuelles), etc.

Types de bases de données

Il existe plusieurs types de base de données, nous allons nous limite à illustrer brièvement, dans une analyse comparée, ces grandes "familles" de databases :

• Bases de données relationnelles
• Bases de données de type document
• Bases de données clé-valeur (ou key-value)
• Bases de données de type Graph

SQL vs NoSQL

La différence plus marquée entre bases de données réside entre les databases de type relationnel (ou SQL) est les autres type de base de données qui sont souvent regroupés sous l'acronyme NoSQL signifiant à la fois :

• No SQL dans le sens "pas de SQL"
• Not Only SQL, "pas seulement du SQL"

SQL, acronyme de Structured Query Language (voir également plus bas dans la page), représente aujourd'hui (2017) la modalité principale pour structurer et interroger des bases de données. La caractéristique principale des databases SQL concerne la structure fixe en lignes et colonnes, similaire à celle utilisé par les feuilles de calcul (e.g. Excel). L'aspect relationnel des databases SQL est déterminé par la possibilité de combiner des données sur plusieurs tableaux (voir plus bas). Les databases NoSQL, par contre, se caractérisent par des structures plus flexibles, pas forcément bi-dimensionnelles. Même si souvent ces bases des données peuvent être interrogées avec un langage de type SQL (ou similaire), la différence fondamentale réside dans la flexibilité de la structure des données. Ces structures peuvent être très utiles dans le cadre du recueil de données dont on ne peut pas prévoir à l'avance la structure, et sont par conséquent utilisés souvent (mais pas uniquement) en relation avec les analyses de type "Big Data" ou "Machine Learning".

Bases de données relationnelles

Les bases de données relationnelles sont le type de database le plus fréquemment utilisé à présent (2017). Leur structure est déterminée par une ou plusieurs tableaux, divisées en lignes et colonnes, comme c'est les cas des feuilles de calculs (e.g. Excel). Le terme "relationnelles" se réfère à la possibilité de faire des références croisées entre tableaux, à travers notamment des foreign keys, c'est-à-dire des colonnes dans un tableau X qui font références à un tableaux Y ou Z.

Voici un exemple de relation entre un tableau "Students" qui contient une liste d'étudiants et le tableau "Grades" qui contient une liste de notes.

Table "Students"
*****
ID | Name         | University           | ...
--------------------------------------------------------
1  | A. B.        | UNIGE                | ...
--------------------------------------------------------
2  | C. D.        | UNIGE                | ...
--------------------------------------------------------

Table "Grades"
*****
ID | Student_ID | Course     | Grade  | ...
--------------------------------------------------------
90 | 1          | STIC I     | 5.5    | ...
--------------------------------------------------------
91 | 1          | STIC II    | 5.75   | ...
--------------------------------------------------------
92 | 2          | STIC I     | 4.5    | ...
--------------------------------------------------------
93 | 2          | STIC I     | 5.25   | ...
--------------------------------------------------------

La relation entre les deux tableaux se fait grâce à la colonne Student_ID qui fait référence à la colonne ID du tableaux "Students" (on dit donc que Grades.Student_ID est une foreign key de Students.ID). Les lignes avec ID 90 et 91 de "Grades" font références à l'étudiant avec ID 1 (i.e. celui avec nom "A. B.") du tableau "Students", tandis que les lignes 92 et 93 é l'étudiant avec ID 2 (i.e. celui avec nom "C. D.").

Utilisation d'une foreign key dans deux tableaux relationnels

Ce type de structure est très utile pour :

• créer des agrégation des données, par exemple : trouver toutes les notes (tableau Grades) qui appartiennent à l'étudiant (tableau Students) "A. B." ;
• récupérer des informations "internes" à un tableau, par exemple : compter les nombres d'étudiants dans le tableau "Students" ;
• faire des calculs dans un tableau, par exemple : calculer la moyenne du cours "STIC I" dans le tableau "Grades"

Types de relations

Il existe trois grands types de relation entre deux tableaux :

1. One-to-One : à une ligne dans le tableau X est liée seulement une ligne dans le tableau Y
2. One-to-Many : à une ligne dans le tableau X sont liées une ou plusieurs lignes dans le tableau Y (c'est le cas de l'exemple Students -> Grades)
3. Many-to-Many : deux tableaux X et Y sont liés par un tableau Z qui contient plusieurs références croisées entre X et Y

On peut modifier notre exemple One-to-Many Students -> Grades pour faire un exemple de Many-to-Many. Au lieu d'ajouter dans le tableau "Notes" le nom du cours à chaque ligne, on peut ajouter un troisième tableau "Courses" :

Table "Courses"
*****
ID  | Name      | ....
--------------------------------------------------------
101 | STIC I    | ....
--------------------------------------------------------
102 | STIC II   | ....
--------------------------------------------------------

À ce point on peut modifier notre tableau "Notes" en substituant la colonne "Grade.Course" par une foreign key Grade.Course_ID qui fait référence au tableau "Courses.ID" :

Table "Grades" revised in Many-to-Many
*****
ID | Student_ID | Course_ID  | Grade  | ...
--------------------------------------------------------
90 | 1          | 101        | 5.5    | ...
--------------------------------------------------------
91 | 1          | 102        | 5.75   | ...
--------------------------------------------------------
92 | 2          | 101        | 4.5    | ...
--------------------------------------------------------
93 | 2          | 102        | 5.25   | ...
--------------------------------------------------------

Relation de type Many-to-Many

L'avantage de cette structure et de séparer les données et de créer donc des tables qui peuvent être plus facilement interrogées, par exemple maintenant on peut facilement récupérer le nombre de cours grâce au tableau "Courses", tandis qu'avant il aurait fallu contrôler toutes les lignes du tableau "Grades" et récupérer seulement les valeurs distinctes. De plus, on peut réutiliser le tableau "Courses" pour associer des professeurs (dans un tableau "Teachers") à un ou plusieurs cours sans devoir dupliquer les informations.

Le désavantage, par contre, concerne le fait que si on veut récupérer la liste des notes d'un étudiant, avec ses informations personnelles, il faut faire une interrogation qui implique l’agrégation de trois tableaux différents, ce qui comporte deux conséquences :

• Il faut une manière plus complexes pour "demander" les données, car il faut expliciter dans la requête les relations entre tableaux
• La recherche des données correspondantes doit se faire à trois "endroits" différents, ce qui implique un temps et une puissance computationnelle plus élevés

Le SQL

Le Structured Query Language (SQL) est un langage permettant la gestion et l'interrogation d'un système de base de données relationnelles. Ces dernières étant presque exclusivement utilisées aujourd'hui, on comprend mieux pourquoi nombre de produits (MySQL, SQL Server, PostgreSQL) intègrent l'acronyme dans leur dénomination. Attention cependant à ne pas confondre le langage des noms de produits commerciaux.

Le langage peut être vu sous quatre aspects distincts. En parenthèse, le nom de la catégorie en anglais.

• La gestion de la base: création et modification de la structure de données, les tables (à définir) en particulier (DDL=Data Definition Language).
• La gestion des transactions: opérations permettant de contrôler, manipuler de données (insertion, effacement, déplacement, etc) et d'éviter leur inconsistance (TCL=Transaction Control Language).
• La gestion des droits d'accès: opérations de sécurité permettant la gestion des accès aux données par les différents utilisateurs (DCL=Data Control Language).
• L'interrogation de la base: commandes permettant la récupération des données selon les besoins (DML=Data Manipulation Language).

Pour plus d'informations sur ces catégories et les commandes SQL qui les composent voir ce site ; voir également ce Tutoriel sur W3Schools.

Liste de bases de données rélationnelles

Ci-après, présentés quelques noms de logiciels dédiés à la gestion de bases de données.

• Oracle Site officiel
• MySQL Site officiel (Note. MySQL est aujourd'hui propriété de Sun Microsystems, lui même racheté il y a peu par Oracle)
• Microsoft SQL Server Site Wiki
• Microsoft Access Site officel (Note. Access 2007 est basé sur une version allégée de MS SQL Server)
• PostgreSQL Site officel
• IBM DB2 Site officiel
• FileMaker Site officiel
• OpenOffice Base Site officiel
• Sqlite Site officiel

Bases de données de type document

Les bases de données de type document ont une approche très différent par rapport aux databases relationnels. Dans les bases de données de type document, les données sont organisées en collection (l'équivalente d'un tableau dans les databases relationnels). Chaque collection contient plusieurs documents qui se différencient des lignes d'un database rélationnel par le fait qu'il n'y aucune structure en colonne pré-déterminée.

Les documents ont plutôt la structure des objets JavaScript (voir Tutoriel JavaScript de base), ou JSON pour être plus précis, c'est-à-dire des associations clé-valeur ou la valeur peut être également un array (liste) ou d'autres objets emboìtés. Par exemple :

Collection "Students"
*****
{
  "id" : "8hf347ughf7g3f37gbnfvru",
  "name" : "A. B.",
  "university": "UNIGE",
  "grades": [
     {
       "course": "STIC I",
       "grade": 5.5
     }, {
       "course": "STIC II",
       "grade": 5.75
     }
  ]
},
{
  "id" : "nu3178g3146gvbgc13439",
  "name" : "C. D.",
  "university": "UNIGE",
  "grades": [
     {
       "course": "STIC I",
       "grade": 4.75
     }, {
       "course": "STIC II",
       "grade": 5.25
     }
  ]
}

La structure des documents ne doit par contre pas être forcément la même à chaque "ligne" :

 Collection "Students" modified
*****
{
  "id" : "8hf347ughf7g3f37gbnfvru",
  "name" : "A. B.",
  "university": "UNIGE",
  "grades": [
     {
       "course": "STIC I",
       "grade": 5.5,
       "comment" : "The student performed an alternative exercice",
       "exerciceType" : "EduTechWiki page about databases"
     }, {
       "course": "STIC II",
       "grade": 5.75
     }
  ]
},
{
  "id" : "nu3178g3146gvbgc13439",
  "name" : "C. D.",
  "university": "UNIGE",
  "grades": [
     {
       "course": "STIC I",
       "grade": 4.75
     }, {
       "course": "STIC II",
       "grade": 5.25,
       "delayed" : "0.6 penalty for delayed submission"
     }
  ]
}

L'avantage de cette flexibilité consiste dans le fait qu'on peut ajouter des informations sans avoir à modifier la structure de la base des données. Pour comparaison, si on voulait faire la même chose avec une base de données relationnelles, il aurait fallut créer trois colonnes de plus (comment, exerciceType, delayed) qui auraient dans la plupart des cas une valuer nulle.

Par contre, le désavantage consiste dans le fait qu'avec ce type de structure il faut souvent dupliquer des données (par exemple avoir un tableau "Courses"), parce qu'il n'y a pas de référence symbolique (i.e. une foreign key).

Liste de base des données de type document

• MongoDB Site officiel
• DocumentDB Site officiel
• CouchDB Site officiel
• LokiJS Site officiel

Bases de données clé-valeur

Les bases de données de type clé-valuer (ou key-value databases en anglais) ont une structure beaucoup plus simple par rapport aux databases relationnels ou document: elles se composent en effet seulement de deux colonnes.

Database key-value
*****
KEY      | VALUE                           
--------------------------------------------------------
key1     | value1
--------------------------------------------------------
key2     | value2, value2, value3, value4
--------------------------------------------------------
key3     | 123, 456, abcd, efgh
--------------------------------------------------------

Le fonctionnement de ce type de databases est assez trivial: on associe une valeur à une clé unique. La particularité consiste dans le fait que la valeur peut être pratiquement tout type de données, de données simples (chiffres, texte, etc.) à des données composites comme des objets, des listes, ou mêmes des fichiers à travers le format BLOB (Binary Large Object). Comme l'exemple (fictif) le montre, de plus, la valeur associé à chaque ligne ne doit respecter aucune structure pré-déterminée.

L'association clé-unique -> valeur est une manière efficace est très performante de récupérer des données. En suivant toujours le même exemple pratique relatif aux notes des étudiants, on peut imaginer de stocker le relevé final dans un fichier PDF. À ce point, le fichier peut être stocké dans une base de données où la clé est représentée par le numéro d'immatriculation de l'étudiant, et la valeur est le fichier PDF. Plusieurs databases de type clé-valeur mettent automatiquement en ordre les items par rapport à leur clé, ce qui augmente énormément la vitesse de récupération des données, surtout dans des grandes bases de données.

Database "Grade_Report"
*****
ID             | BLOB_PDF                   |
--------------------------------------------------------
XX-XXX-XXX     | UERGIHdpdGggbm90ZXM=...
--------------------------------------------------------
YY-YYY-YYY     | QW5vdGhlciBQREYgd2l0aCBub3Rlcw==...
--------------------------------------------------------

L'avantage de stocker les PDF dans une base plutôt que comme des fichiers dans le file system peut être lié à :

• Des questions de sécurité et de privilège d'accès : c'est plus simple de gérer des accès à une base de données qu'aux fichiers dans un serveur ;
• Des questions de vitesse de traitement : certains databases key-value sont même plus performant dans la recherche que le gestionnaire des fichiers.

Liste de bases de données de type clé-valeur

• Berkeley DB Site officiel
• Redis Site officiel

Bases de données de type Graph

Les bases de données de type Graph ont une approche qui relève de la théorie des Graphes, c'est-à-dire l'utilisation de représentation graphiques pour expliquer un modèle, un concept similaire donc aux cartes conceptuelles. Dans ce type de database, les données sont représentées par :

• Des noeuds qui représentent une "entité" ;
• Des relations, sous forme de segments ou des flèches, qui relient, de manière sémantique, les nodeus ;
• Des propriétés qui peuvent être associées aux noeuds, mais également aux relations.

La différence par rapport à des bases de données relationnelles concerne donc le type de relation entre données :

• Symbolique pour les databases relationnels : la ligne de la table X est liée à la (les) ligne(s) du tableau Y à travers une référence symbolique (e.g., foreign key) ;
• Physique pour les databases de type Graph : un noeud X est lié à un noeud Y à travers un segment qui détermine la nature de la relation

En d'autres termes, les bases de données de type Graph stock non seulement les données, mais également les relations entre données. Les relations peuvent être définit à travers des propriétés qui permettent de mieux saisir le lien entre deux noeuds. En guardant le même exemple d'un système de notation pour étudiant, on peut imaginer d'utiliser un database de type Graph pour la notation de travaux de groupe :

• Un noeud représente un étudiant avec des propriétés (e.g. nom, ...)
• Une relation entre deux noeuds signifie "a collaboré avec..." et on peut associer à cette relation des propriétés (e.g. cours, note, ...)

Les relations sont stockées tout comme les noeuds.

Lorsqu'on interroge une base de données de ce type, donc, ce qu'on fait est de déterminer un pattern et demander les occurrences qui respectent ce pattern.

Interroger la base de données équivaut à chercher des patterns dans un graphique

Par exemple :

• À partir du noeud étudiant avec nom "A. B.", trouver toutes les collaboration (i.e. les rélations "a collaboré avec...") qui ont la propriété cours = STIC I
  • Celle sélectionnée sur l'image
• A partir du noeud étudiant avec nom "A. B.", trouver combien de relations "a collaboré avec..." existe avec le noeud étudiant avec nom "C. D."
  • Juste une (l'autre est dans le sens inverse)

On peut également interroger par rapport à l'absence d'un pattern, e.g. :

• Trouver tous les étudiants qui n'ont pas collaboré entre eux (i.e. n'ont aucune relation "a collaboré avec...")
  • C.D. et G.H.

Enfin, grâce aux relations, il est possible de créer des patterns à plusieurs niveaux, par exemple :

• Trouver les étudiants qui ont déjà collaboré avec les étudiants qui ont déjà collaboré avec "A. B." (pensez aux suggestions d'amis sur les réseaux sociaux)
  • G. H. qui a collaboré avec E. F. qui a collaboré avec A. B.

Liste de bases de données de type Graph

• Neo4j Site officiel
• AllegroGraph Site officiel

Quel type de bases de données choisir

En guise de conclusion, nous proposons quelques réflexions (plus que conseils) sur le choix de database.

Pas de choix

Souvent le choix n'est simplement pas possible. C'est souvent le cas des applications web de type portail ou CMS (e.g. Wordpress, MediaWiki, etc.) qui sont conçues pour interagir avec une base de données spécifique. En d'autres cas, le choix est limité par le type de database qui est disponible sur la machine ou sur le serveur qui va héberger l'application. À présent (2017), la plupart des hébergement mutualisés proposent exclusivement les bases de données de type MySQL.

La taille de la base de données et la fréquence des interrogations

Un autre critère important concerne combien de données le database va contenir et avec quelle fréquence il sera solliciter pour effectuer des opérations sur les données. Pour des petits applications, des databases de type fichier ou directement des databases de type Microsoft Accesss, OpenOffice Base ou FileMaker peuvent être suffisant. En cas de sollicitations plus massive, il faut plutôt virer sur des système de gestion qui sont installés au niveau du système, ce qui nécessite à la fois un accès administratif à la machine ou un type d'hébergement plus avancé par rapport aux offres traditionnelles d'hébergement mutualisé.

Type de modélisation et relations entre données

Le critère le plus important concerne la structure des données et quel type d'interrogations, notamment en fonction des relations entre données, vont être exécutées. Vukotic & Watt (2014), par exemple, ont conduit un test sur une base de données MySQL (relationnelle) et Neo4j (type Graph) avec des interrogations à plusieurs niveaux (e.g. trouver les amis des amis des amis ...) et on pu constater comme les databases de type Graph ont des meilleures performances déjà à partir du troisième niveau (les amis des amis des amis).

La flexibilité de la structure des données est également un aspect important à considérer. La stricte structure bidimensionnelle des databases relationnels peut être particulièrement indiquée pour des gestionnaires (e.g. database d'étudiants, ressources pédagogiques classifiées strictement, etc.). Dans d'autres contextes, comme par exemple dans les learning analytics, des structures plus flexibles permettent de recueillir des données plus variées, notamment en ajoutant des informations après-coup sans avoir à modifier la structure de la base des données.

Stabilité et fiabilité du système de gestion des bases de données

Enfin, il faut également évaluer la fiabilité des outils, surtout dans le cadre d'une utilisation massive. Les databases de type relationnels sont dans le mainstream depuis plusieurs années et ont par conséquent atteint un niveau de maturité et stabilité très élevé. Au contraire, les bases de données de type NoSQL sont plus récent et par conséquent disposent à présent d'une mineur facilité d'accès. Il faut par contre souligner que les gros projets de type NoSQL essaient de combler ce type de gap à travers des ressources pédagogiques mises à disposition online. MongoDB dispose par exemple de sa propre "Université" et Neo4j propose également des courses online. D'autres courses sont en train d'apparaître également sur des plateformes indépendantes, gratuites ou payantes.

Ressources et références

Bibliographie

• DuBois, P. (2009). MySQL. Fourth Edition. Boston, MA: Addison-Wesley
• Vukotic, A. & Watt, N. (2014). Neo4j in Action. Shelter Island, NY: Manning

Liens

• Base de données sur Comment ça marche
• Base de données sur Wikipedia
• Système de gestion de bases de données sur Wikipedia
• Liste de databases NoSQL