Apprendre les BDD relationnelles : Structure

De l’algèbre relationnelle au modèle relationnel

Au sein d’une base de données relationnelle, la manipulation des données se fait selon le concept mathématique de la théorie des ensembles, c’est-à-dire l’algèbre relationnelle. L’algèbre relationnelle a été inventée en 1970 par Edgar Frank Codd, le directeur de recherche du centre IBM de San José (Californie).

L’algèbre relationnelle étudie les ensembles, c’est-à-dire des collections d’éléments. Les ensembles peuvent être utilisés pour modéliser des éléments de différentes natures : les étudiants d’une classe, les livres d’une bibliothèque, les produits d’une boutique, etc.

Ces ensembles sont manipulables via des opérations ensemblistes (union, intersection, différence, produit cartésien) et relationnelles (projection, sélection, jointure).

Le modèle relationnel, est un modèle de données qui utilise des tableaux pour représenter des données et les relations entre elles.

• Chaque tableau représente un ensemble d’éléments (par exemple des étudiants).
• Chaque colonne du tableau représente une caractéristique de cet élément (prénom, nom, âge).
• Chaque ligne de la table représente un élément (John Doe 21 ans).

Le modèle relationnel peut être considéré comme une extension de la théorie des ensembles à la gestion de données. En utilisant des tables et des relations pour représenter les données, le modèle relationnel permet de gérer de manière efficace de grandes quantités de données et de les interroger de manière flexible.

Ces manipulations de données se font essentiellement via le produit cartésien, une opération mathématique qui permet de créer un ensemble en combinant tous les éléments de deux ensembles A et B de manière à ce que chaque élément de l’ensemble A soit associé à chaque élément de l’ensemble B.

Détaillons davantage le modèle relationnel en apprenant à structurer une base de données.

Anatomie d’une base de données

Tables (= tableaux)

En informatique, une base de données relationnelle est une structure de stockage dans laquelle l’information est organisée dans des tableaux à deux dimensions appelés « tables ».

Chaque table stocke une typologie d’élément à exploiter par notre système (application, logiciel, site web…). Il peut s’agir :

• Des utilisateurs d’un site web
• Des articles d’un blog
• Des produits d’un site e-commerce
• Des messages sur un forum
• Etc.

On nomme généralement cette table en anglais. Exemple : users

Attributs (= colonnes)

Une table est divisée en plusieurs colonnes. Une colonne stocke une caractéristique spécifique, appelée attribut.

Pour chaque attribut, les valeurs stockées appartiennent à un certain type.

Au sein d’une base de données, on distingue 3 grands types possibles pour nos valeurs :

• Nombre (entier ou décimal)
• Texte
• Date

A partir du type, on spécifie le domaine de l’attribut. Le domaine est un ensemble de valeurs autorisées pour l’attribut en question. Il peut s’agir d’un texte comprenant entre 10 et 255 caractères, d’un nombre entier positif, d’une valeur comprise dans la liste “rouge”, “vert” ou “bleu”…

Le domaine d’un attribut permet de s’assurer que les données stockées dans la table sont cohérentes et conformes aux contraintes définies.

Par exemple, si le domaine de la colonne « likes » est défini comme étant l’ensemble des entiers positifs, il ne sera pas possible d’insérer une valeur comme “azerty” dans cette colonne, car “azerty” n’est pas un entier positif.

Pour une table articles, on pourrait par exemple définir les attributs suivants :

• Son titre (texte)
• Sa description (texte)
• Son contenu (texte)
• Son statut (booléen) - si statut = 0, l’article est public, s’il vaut 1 alors il est premium
• Sa date de publication (date)

Uplets (= lignes)

Les lignes de ces tables sont appelées des uplets, tuples, entrées ou enregistrements ; elles représentent tout simplement les données stockées.

• Une ligne correspond donc à un échantillon de données.
• Un ensemble de ligne constitue un jeu de données ou en anglais « dataset ».

Exemple : articles

Relations entre tables

Concept

Si une table permet de stocker des données thématisées, il est fréquent que ses données ne soient pas isolées, mais bien en relation avec des données stockées dans d’autres tables.

Pour bien comprendre ce concept, reprenons l’exemple de notre table articles.

Sur un blog, les articles peuvent être associés à d’autres données, comme par exemple :

• Un utilisateur inscrit sur la plateforme
• Des catégories
• Des commentaires

Dans ce cas-là, on comprend qu’il faudra 3 tables supplémentaires afin d’enregistrer ces informations en base de données :

users : pour stocker les utilisateurs

id	email	password	role
1	[email protected]	$2y$10$B8CfOi3H5n4ezfxM5WQepOK9BqH1gFER2BXaZG2JZgYYtPxq/dYHe	admin
2	[email protected]	$2y$10$ht/077X426dH3ht3FwZYa.k1riyRLEtyFqSzQon207Bi918Vg2vfi	author
3	[email protected]	$2y$10$1By62kzM.LV.sD6BP8fiKu5Z.BBS35CKc7zVpH5fXTP9Nuzr4LgYe	author

categories : pour stocker les catégories d'articles

id	name
1	Développement
2	Design
3	Marketing

comments : pour stocker les commentaires d'articles

id	content
1	Top cet article merci beaucoup !
2	Merci, ça m’a bien aidé :)
3	Attention il manque un “s” dans le premier titre de l’article. Sinon, très bon article.

Nous avons maintenant 4 tables dans notre base de données. Toutefois, cela ne présente pas encore de grand intérêt car aucune relation n’est actuellement définie entre elles.

Avant de concrètement créer nos relations dans les tables, il est important d’aborder le concept de multiplicité des relations.

Multiplicité

La multiplicité (aussi désignée par le terme « cardinalité ») d’une relation consiste à définir pour un enregistrement d’une table A, avec combien d’enregistrements d’une table B il peut être en relation au maximum, et inversement.

On distingue 3 multiplicités principales :

Relation One to One (1:1)

Un enregistrement dans une table A est associé à un enregistrement dans une table B.

Exemple : Les informations d’un auteur pourraient par exemple être stockées dans deux tables distinctes : users (nom, prénom, biographie…) et avatars (chemin vers l’image, son approbation - pas de contenu explicite…).

Il s’agit bien d’une relation One to One car :

• Un utilisateur possède 1 avatar.
• Un avatar appartient forcément à 1 utilisateur.

Relation One to Many (1:n) et Many to One (n:1)

Un enregistrement dans une table A peut être associé à plusieurs enregistrements d’une table B, et inversement.

Exemple : Les articles publiés par un auteur sont stockés dans la table articles et les auteurs dans la table users.

Il s’agit bien d’une relation One to Many et Many to One car :

• Un auteur peut avoir publié plusieurs articles.
• Un article ne peut être publié que par 1 auteur.

Relation Many to Many (n:n)

Plusieurs enregistrements dans une table A peuvent être associés à plusieurs enregistrements d’une table B.

Exemple : Les articles publiés par un auteur sont stockés dans la table articles et les catégories associées dans la table categories.

Il s’agit bien d’une relation Many to Many car :

• Un article peut être associé à plusieurs catégories.
• Une catégorie peut être associée à plusieurs articles.

Relation facultative

Une relation facultative est une relation qui n’est pas nécessaire pour le bon fonctionnement de la base de données. Autrement dit, la cardinalité minimale est de 0 et non 1.

Exemple :

• Un utilisateur peut ne pas avoir d’avatar mais un avatar est forcément associé à un utilisateur.
• Un article peut ne pas avoir de commentaire, mais un commentaire est forcément associé à un article.
• Etc.

Clés

Mais alors comment implémenter ces relations en base de données ? 🤔 En définissant des clés primaires et des clés étrangères. Il s’agit de colonnes un peu spéciales à ajouter dans nos tables.

Clé primaire

Une clé primaire est un attribut dont le rôle va être d’identifier un enregistrement de manière unique.

Cet identifiant est généralement nommé id et contient généralement un nombre unique (1, 2, 3…), défini automatiquement par notre base de données. Cet identifiant peut également avoir une forme plus complexe, comme par exemple celle d’un uuid.

À partir de maintenant, nous ajouterons à chaque table un attribut id en tant que clé primaire.

Clé étrangère

Le rôle d’une clé étrangère est de mettre en relation des enregistrements stockés dans des tables distinctes.

Si deux tables A et B sont liées, alors la clé étrangère de la table A va référencer la clé primaire (= avoir une valeur identique) de la table B. Le nom donné à cette clé étrangère correspond généralement au nom de la table (au singulier) que référence la colonne, suivi de _id. Par exemple article_id, user_id, category_id…

Le choix de la table dans laquelle placer cette clé étrangère varie en fonction de la multiplicité de la relation.

Clé étrangère dans une relation One to One (1:1)

Une relation One to One est obligatoirement facultative.

Dans une relation One to One, on place la clé étrangère dans la table :

• De notre choix si la relation est de même cardinalité des deux côtés.
• Pouvant avoir une multiplicité nulle si la relation est facultative.

Table users

Table avatars

Dans cet exemple, un utilisateur peut avoir un avatar (l’utilisateur n°102 n’en a pas), mais un avatar est forcément associé à un id. La clé étrangère sera donc dans la table pouvant avoir une multiplicité nulle, soit avatars.

Clé étrangère dans une relation One to Many (1:n) et Many to One (n:1)

Dans une relation One to Many ou Many to One, on place la clé étrangère dans la table côté many.

Table users

Table articles

Clé étrangère dans une relation Many to Many (n:n)

Dans une relation Many to Many, il n’est pas possible d’ajouter une clé étrangère directement au sein d’une table car cela contraindrait la relation à n’avoir qu’un lien possible.

• Si j’ajoute category_id dans la table articles, alors un article ne pourrait avoir qu’une seule catégorie liée.
• Si j’ajoute article_id dans la table categories, alors une catégorie ne pourrait être associée qu’à un article

On créera alors une table d’association (aussi appelée « table de jointure ») entre les deux tables. Cette table d’association comportera un couple unique de clés étrangères, formant ainsi à elles deux, une clé primaire.

On nomme généralement cette table du nom des deux tables séparées par un _. Il arrive aussi parfois d’y ajouter le mot get entre. Exemple : articles_categories ou articles_get_categories.

Table articles

Table categories

Table articles_categories

Modéliser ses bases de données

Avant de commencer à construire une base de données dans un système informatique, il est important de représenter visuellement les éléments à manipuler et les connexions entre ces éléments.

Cette étape de réflexion et de modélisation est parfois trop négligée, ce qui peut entraîner des désagréments voire la dégénérescence de l’application lors de ses évolutions. Pour éviter cela, il existe de nombreuses méthodes et outils utiles à la conception d’une base de données.

La méthode Merise et le langage UML sont aujourd’hui très utilisés pour modéliser des Systèmes d’Information (SI). Un système d’Information désigne l’ensemble des composantes (hardware + software) permettant de concevoir, gérer et diffuser l’information.

Les SI caractérisent à la fois les données, les traitements, la sécurité, le réseau et toute la couche métier qui va avec. Il s’agit d’un concept général désignant l’informatique.

Une base de données est une composante d’un SI.

Intéressons nous à la méthode Merise, qui propose entre autres 3 modèles décrivant la structure de la base de données relationnelle à des niveaux de préoccupation différents. Chacun remplit une fonction différente à mesure que vous avancez dans le processus de modélisation des données.

1. Le Modèle Conceptuel de Données (MCD)

Le MCD est le modèle le plus abstrait et le moins détaillé visant à concevoir la structure de la base de données.

Il permet de conceptualiser la base de données en détaillant ses entités et ses associations ; on parle de diagramme Entité-Associations (E-A).

Il est indépendant de toute implémentation physique ou logicielle.

2. Le Modèle Logique de Données (MLD)

Le MLD est une version un peu plus détaillée du MCD visant à l’adapter à un type de base de données spécifique.

Il permet de vérifier que la structure de la base de données décrite par le MCD est conforme aux normes de conception de base de données.

Il est également indépendant de l’implémentation physique ou logicielle.

3. Le Modèle Physique de Données (MPD)

Le MPD est une version encore un peu plus détaillée du MLD visant à créer la base de données en utilisant un Système de Gestion de Base de Données (SGBD) spécifique.

Il dépend de l’implémentation physique ou logicielle de la base de données puisqu’il définit dans un Langage de Description de Données (LDD), comme SQL, les scripts de création de la base de données.

Voici un tableau de comparaison des trois modèles de données de la méthode MERISE :