5.6 Neo4j et Algorithmes de graphe
5.6.4 Procédures APOC
5.1 – Système de gestion de bases de données 95
5.1 Système de gestion de bases de données
5.1.1 Présentation d’un système de gestion de bases de données
Un système de gestion de base de données (SGBD) est un ensemble de logiciels informatiques permettant aux utilisateurs de manipuler une base de données. Ce système à usage général facilite les processus de définition, de construction, de manipulation et de partage de bases de données entre plusieurs utilisateurs et applications [Elmasri and Navathe,2010].
Le SGBD sert également à manipuler les données stockées en effectuant des opérations ordi- naires telles que :
— interroger la base de données pour extraire des données spécifiques ; — mettre à jour la base de données pour intégrer les modifications ; — générer des rapports.
Le SGBD joue un rôle intermédiaire entre les utilisateurs et la base de données. Il fonctionne comme une interface qui veille à garder les données stockées de manière permanente et sûre sur de longues périodes, indépendamment des programmes qui y ont accès [Silberschatz et al.,1997].
5.1.2 Architecture d’un SGBD
Le SGBD utilise un catalogue pour stocker la description de la base de données. On appelle ce catalogue un schéma, qui prend en charge plusieurs vues d’utilisateurs. Ainsi, nous distinguons trois niveaux dans un SGBD [Gardarin,2003] :
— Niveau physique (SGBD interne : le système de gestion de fichiers) : il gère l’organisation et le stockage physique des données. Ce niveau utilise le modèle physique des données et décrit les détails pour accéder aux données ainsi que les chemins d’accès à la base de données dans le système.
— Niveau conceptuel : il décrit la structure de toute la base de données. Ainsi, on trouve les détails sur le schéma des tables, les propriétés des colonnes des tables, les procédures stockées et les contraintes.
— Niveau vue (SGBD externe) : il explique la mise en forme et la présentation des données aux utilisateurs ayant accès à la base de données. Ce niveau décrit simplement la partie de données présentant un intérêt pour un utilisateur. Cependant dans les autres niveaux, les schémas décrivent toute une base de données.
5.1.3 Propriétés communes
Dans cette section, nous allons présenter les propriétés communes à tous les SGBD : propriétés ACID, opérations CRUD et indexation.
Pour cela, nous avons besoin de définir quelques termes [Silberschatz et al.,1997].
Définition 5.1.1 (Transaction). Une transaction est une opération atomique sur les données. Elle peut entraîner la lecture de certaines données depuis la base de données ainsi que leur écriture dans la base de données.
Définition 5.1.1 (Requête). Une requête est un ensemble d’instructions qui se fait d’une manière déclarative pour manipuler des données de la base.
96 CHAPITRE 5 — Notions sur les bases de données
Définition 5.1.2 (Langage de requête). Un langage de requête est un langage déclaratif utilisé pour récupérer les informations à travers une requête. Ce type de langage nécessite qu’un utilisateur spécifie quelles données demander sans avoir besoin de spécifier comment obtenir ces données. Définition 5.1.3 (Jointure). Une opération de jointure est une opération binaire permettant de fusionner les données à partir de deux ensembles de données.
Définition 5.1.4 (Contrainte d’intégrité). Une contrainte d’intégrité est une règle définie dans la base de données pour garantir la cohérence d’une donnée ou d’un ensemble de données. Dans une base de données, on peut définir plusieurs contraintes.
Propriétés ACID
Les propriétés ACID sont les quatre principaux composants permettant de garantir qu’une tran- saction a été exécutée de façon fiable. Ces propriétés sont très utiles pour réaliser des transactions ou des applications financières : par exemple, un transfert de fonds d’un compte bancaire à un autre. En effet, les systèmes bancaires se basent sur des transactions et les propriétés ACID. ACID signifie Atomicité, Cohérence, Isolation et Durabilité. Ces quatre propriétés sont la base des applications transactionnelles [Silberschatz et al.,1997].
— Atomicité (en anglais Atomicity) signifie que si une transaction exécute certaines tâches, celles-ci doivent être exécutées complètement ou pas du tout. Si jamais, une tâche ne peut pas être faite, alors il faut effacer toute trace de la transaction et remettre les données dans l’état initial.
— Cohérence (en anglais Consistency) assure que les données restent cohérentes avant et après la transaction. Cela veut dire que n’importe quelle transaction transformera le système d’un état valide à un autre état valide. Un système à état valide est un système respectant les contraintes d’intégrité.
— Isolation (en anglais Isolation) veut dire que l’exécution d’une transaction se fait indépen- damment des autres transactions, c’est comme si elle était seule sur le système. Cette pro- priété garantit que l’exécution simultanée de plusieurs transactions produit le même état que leur exécution en série. Ainsi, les opérations d’écritures et lectures des transactions réussies ne seront pas affectées par celles d’autres transactions quels que soient leurs résultats. — Durabilité (en anglais Durability) assure la sauvegarde des données. Il est possible d’annuler
une transaction ou de rétablir l’état du système après une défaillance. Ceci est réalisé grâce au journal des transactions. En effet, chaque SGBD possède un journal des transactions qui enregistre toutes les transactions et les modifications apportées par chacune d’entre elles.
Opérations CRUD
Dans un SGBD, la manipulation des données consiste à effectuer les opérations CRUD, qui signifie Create, Read, Update et Delete. Les opérations CRUD sont implémentées par quatre procédures stockées [Gardarin,2003] :
— Create crée des nouvelles données (par exemple, créer de nouveaux aéroports) ; — Read lit les données pour les afficher d’une façon simple ;
— Update met à jour l’ensemble des champs modifiés ;
5.1 – Système de gestion de bases de données 97
Indexation
La technique d’indexation est une technique utilisée dans les systèmes des fichiers et des bases de données. Cette technique a pour but d’améliorer les performances de recherche des informations qui se fait par un index. Un index est une structure de données qui reprend la liste des valeurs auxquelles il se rapporte : c’est une copie "intelligente" des données de la table [Kroenke and Auer,2013].
Il existe différents types d’index, les plus fréquents étant les arbres B (en anglais B-Tree) [Gar- darin, 2003, Silberschatz et al., 1997]. Un arbre B est un arbre équilibré, dont les données sont triées. C’est une généralisation d’un arbre binaire de recherche où les nœuds parents peuvent pos- séder plus de deux nœuds enfants. Ce type de structure permet de stocker les données sous une forme triée ce qui permet d’exécuter des opérations de recherche et d’insertion en temps logarith- mique [Comer,1979].
La technique d’indexation est très utile pour certaines requêtes de filtre ou tri sur le champ ayant l’index. Néanmoins, elle a des inconvénients notamment quand il s’agit de mettre à jour les données. En fait, il faut mettre à jour les données ainsi que les index. Un autre inconvénient est la volumétrie des index car cela ajoute du volume à la base de données.
5.1.4 Exemple fil conducteur : 2-hops
Dans cette section, nous présentons un problème de recherche de correspondance dans un réseau aérien inspiré par le problème de la recherche d’amis de mes amis (en anglais friends of friends). La recherche d’amis de mes amis est très connu dans le domaine des systèmes de recommandations. Un tel système a pour but de fournir à un utilisateur des ressources pertinentes en fonction de ses préférences. Ainsi, ce concept permet à l’utilisateur de réduire son temps de recherche. Par exemple dans le domaine du e-commerce, Amazon a un système qui recommande à l’utilisateur des produits qui répondent le plus à ses préférences [Béchet,2012].
Le problème de friends of friends consiste à déterminer quels sont les amis possibles d’un utilisateur à un utilisateur dans un réseau social. Pour répondre à cette question, les bases de données relationnelles demandent un nombre coûteux d’opérations de groupage [Miller,2013]. Il en est de même, pour la plupart des bases de données NoSQL [Robinson et al.,2015] car elles stockent les données sous une forme déconnectée, ce qui complique la recherche des amis.
Pour illustrer ce problème, nous allons prendre un exemple dans le domaine aérien que nous appelons : problème de deux sauts (en anglais 2-hops problem). Supposons que nous ayons un réseau aérien et que nous souhaitions trouver les itinéraires à une escale seulement partant d’un aéroport. Dans un graphe, cela consiste à chercher les chemins ayant deux arcs.
Prenons l’exemple d’un réseau aérien qui contient 16 aéroports et 21 vols présenté dans la figure5.1. Les nœuds du graphe représente les aéroports tandis que la présence d’un arc entre une paire de nœuds correspond au vol entre cette paire d’aéroports. Le poids sur les arcs correspond au temps de vol moyen. Le réseau est modélisé par une approche indépendante du temps qui est le modèle condensé (voir la section7.1).
Nous voyons par la suite comment mettre en œuvre cet exemple dans différents types de sys- tèmes de bases de données que nous allons présenter. Pour cela, nous commençons par présenter l’ensemble des requêtes nécessaires pour répondre aux questions suivantes, ces exemples permet- tant de mieux illustrer les opérations CRUD (voir la section5.1.3) :
98 CHAPITRE 5 — Notions sur les bases de données a´eroport temps NCE BKK CDG IST ESB LIS FNC LHR GLA DOH NBO KWI CMN ABJ ICN DXB 380 310 270 170 100 245 210 80 375 100 465 150 170 85 485 75 360 425 75 105 660 70
FIGURE5.1 – Réseau aérien de vols. Le graphe contient 16 nœuds (aéroports) et 21 arcs (vols) .
2. Comment exprimer les contraintes d’intégrité dans un SGBD ? 3. Comment afficher les informations sur les aéroports ?
4. Comment peut-on trouver la liste des destinations joignables à partir de l’aéroport NCE ? 5. Quelles sont les destinations joignables en moins de 2h en partant de l’aéroport LIS ? 6. Comment peut-on trouver la destination la moins chère en partant de l’aéroport NCE ? 7. Comment récupérer les noms des aéroports ayant des vols ?
8. Comment peut-on trouver les itinéraires à une escale seulement partant de l’aéroport NCE ? La dernière question correspond à la question que nous avons posé dans le problème 2-hops.
5.2 Base de données relationnelle
5.2.1 Présentation d’un système de bases de données relationnelle
Un SGBDR est un SGBD basé sur le modèle relationnel présenté par [Codd,1981]. C’est un modèle dans lequel les données sont organisées sous la forme de tables. Chaque table contient plusieurs lignes, chaque ligne représente un enregistrement. Définir une base de données nécessite la spécification des types de données, structures et contraintes des données à stocker. Le SGBDR supporte les propriétés ACID.
Le SGBDR permet de résoudre les problèmes de dépendance de données. Cette dépendance n’est pas gérée dans les systèmes de gestion de données par fichiers. Comme tout SGBD, le SGBDRse décompose en trois niveaux. Dans l’exemple5.2.1, nous illustrons le niveau conceptuel et le niveau physique.
Exemple 5.2.1 (Structure de SGBDR). L’exemple suivant illustre deux tables, dont la table (a) est celle qui stocke les informations des aéroports du graphe5.1: code et nom. Supposons que nous
5.2 – Base de données relationnelle 99
souhaitions afficher uniquement le code aux utilisateurs. Alors, le niveau physique du SGBDR décrit le stockage du schéma. Le niveau conceptuel contient le nom des champs et le niveau vue décrit le champ code comme une vue.
Code Name
ESB Ankara Esenboga Airport CDG Charles De Gaulle Airport
(a) niveau conceptuel.
Code ESB CDG
(b) niveau vue.
TABLE5.1 – Exemple d’architecture d’un SGBDR.
Le SGBDR doit limiter les redondances. En effet, stocker des informations redondantes pro- voque une perte en espace mémoire mais également un risque d’erreurs lors de la mise à jour des données. Ces données doivent être cohérentes entre elles. Quand une donnée fait référence à une autre donnée dans la base de données, alors celle-ci doit être présente dans le système : les don- nées sont dépendantes dans un tel système. Effectivement, le SGBDR contrôle que les contraintes d’intégrité sont respectées après chaque mise à jour. Cette intégrité logique est traduite par des contraintes d’intégrité. Ainsi, il existe deux types de contraintes :
— l’intégrité d’entité porte sur une colonne unique ;
— l’intégrité référentielle définit une table lorsque la contrainte porte sur une ou plusieurs colonnes.
Exemple 5.2.2 (Contraintes d’intégrité). Considérons l’exemple5.2.1. Si on spécifie que la va- leur du champ code doit être unique et non nulle, alors c’est une contrainte d’intégrité d’entité. Supposons qu’on ait une deuxième table sur les vols qui contient les champs suivants : num_vol, origine, destination et durée. Si on spécifie que chaque origine dans la table des vols doit être liée à un code dans la table des aéroports (voir la table5.1a) alors ce type de contrainte s’inscrit dans la catégorie des contraintes référentielles. Ce type de contrainte est plus complexe, puisqu’il implique plusieurs tables (voir la figure5.2).
id origin destination duration cost
1 NCE BKK 660 2100
2 NCE DXB 375 1000
TABLE5.2 – Table des vols en SGBDR.
5.2.2 Contraintes d’intégrité
Les contraintes d’intégrité sont définies au moment de la création des tables de la façon sui- vante [Elmasri and Navathe,2010] :
— Unique assure que la valeur d’une colonne est unique.
— Primary key (Clé primaire) spécifie la (ou les) colonnes dont la connaissance permet de désigner précisément une et une seule ligne.
100 CHAPITRE 5 — Notions sur les bases de données
— Foreign key (Clé étrangère) permet de définir les colonnes d’une table garantissant la validité d’une autre table.
— Not Null assure que l’absence de valeur n’est pas permise.
— Check contrôle la validité de la valeur des propriétés d’une ou plusieurs colonnes spécifiées à un domaine (par exemple, l’âge d’un client doit être toujours > 18).
5.2.3 Langage de requête SQL
Le langage de requête structuré SQL (en anglais Structured Query Language) permet de ma- nipuler les données dans un système SGBDR.
La syntaxe globale de la requête en SQL est donnée dans le listing5.1: 1 SELECT < l i s t e d e s c o l o n n e s >
2 FROM <nom de l a t a b l e > 3 WHERE < c o n d i t i o n s >
Listing 5.1 – syntaxe globale d’une requête en SQL
Dans la requête du listing5.1, les colonnes du résultat sont spécifiées dans la clause SELECT. La clause FROM est une clause obligatoire qui désigne les tables d’extraction. Enfin, WHERE est une clause optionnelle pour filtrer le résultat renvoyé.
Pour insérer des nouvelles données dans un SGBDR, on utilise la clause INSERT. La jointure se traduit par la clause joins. La jointure permet de rechercher les correspondances en combinant deux tables et renvoyer le résultat en une seule table.
Par la suite, nous allons illustrer ces opérations sur l’exemple de 2-hops présenté dans la sec- tion5.1.4.
5.2.4 2-hops dans le modèle relationnel
5.2.4.1 Représentation et manipulation des données en SQL
Tout d’abord, nous commençons par créer les données dans le SGBDR. Les données du graphe5.1sont stockées dans deux fichiers CSV, elles sont décrites en annexeA:
— airports.csv contient les informations sur les nœuds du graphe : code et name des aéroports (voir l’extrait de la table5.1a).
— flights.csv stocke les données sur les arcs : origin, destination, duration et costdes vols (voir l’extrait de la table5.2).
Exemple 5.2.3 (Création en SQL). La procédure de création correspond au schéma de la table à savoir, noms des colonnes, types de données et contraintes d’intégrité.
1 CREATE TABLE " a i r p o r t s " (
2 " code " varchar ( 5 0 ) PRIMARY KEY NOT NULL, 3 " name " varchar ( 2 0 0 ) NOT NULL UNIQUE 4 ) ;
5.2 – Base de données relationnelle 101
La clé primaire de la table airports porte sur la colonne code de type varchar(50) (ligne 2 du listing5.2). La création de la table des vols (flights) se fait de la même manière (voir la figure5.2). Airports AS A code(PK) name Flights AS F id(PK) origin(FK) destination(FK) duration cost 1 ⋆
FIGURE5.2 – Diagramme entité-relation du 2-hops. PK (respectivement FK) correspond à la clé
primaire (respectivement secondaire).
Exemple 5.2.4 (Insertion en SQL). Pour insérer les données, nous utilisons la commande INSERT. Le SGBDR vérifie lors de toute opération d’insertion que l’utilisateur a bien fourni les valeurs des deux champs : code et name. Sinon, l’opération est rejetée par le système.
1 INSERT INTO a i r p o r t s
2 VALUES ( ’NCE ’ , ’ Nice Côte d ’ ’ Azur A i r p o r t ’ ) ;
Listing 5.3 – requête pour insérer des données en SQL dans la table airports
En SQL, il est possible d’importer des données stockées dans un fichier CSV. Pour cela, nous utilisons la commande BULK INSERT. Cela permet d’insérer en masse des données dans la table. La commande possède des paramètres pour spécifier le séparateur de lignes et de colonnes (lignes 6 et 7 du listing5.4). Le paramètre FIRSTROW permet d’ignorer l’en-tête du fichier. 1 BULK INSERT a i r p o r t s
2 FROM ’ a i r p o r t s . c s v ’ 3 WITH
4 (
102 CHAPITRE 5 — Notions sur les bases de données
6 FIELDTERMINATOR= ’ , ’ , 7 ROWTERMINATOR = ’ \ n ’ 8 ) ;
Listing 5.4 – requête pour importer des données à partir d’un fichier CSV en SQL
Après l’exécution de la requête du listing5.4, le système renvoie une erreur liée à la violation de la contrainte qui porte sur le champ code. En effet, nous avons déjà inséré ce champ avec la requête du listing5.3. Comme cet enregistrement correspond à la deuxième ligne du fichier, nous changeons le paramètre FIRSTROW à 3 pour l’ignorer. Pour les vols, on procède de la même façon pour insérer les données.
Exemple 5.2.5 (Affichage en SQL). Supposons que nous souhaitions afficher la table des aéro- ports. Cette opération correspond à la procédure READ des opérations CRUD. Le tableau 5.1a
présente un extrait de cette table. 1 SELECT *
2 FROM a i r p o r t s ;
Listing 5.5 – requête pour afficher la table airports en SQL
Exemple 5.2.6 (Liste des destinations en SQL). Supposons que nous souhaitions renvoyer les destinations des vols partant de l’aéroport NCE, alors la requête exprimée est dans le listing5.6. 1 SELECT d e s t i n a t i o n
2 FROM f l i g h t s
3 WHERE o r i g i n = ’NCE ’ ;
Listing 5.6 – requête pour récupérer la liste des destinations en SQL
destination BKK DXB DOH CMN
TABLE5.3 – Résultat de la requête du listing5.6.
Exemple 5.2.7 (Destinations en moins de 2 heures en SQL). Pour trouver les destinations qu’on peut rejoindre depuis l’aéroport de Lisbonne (LIS) en moins de deux heures, nous employons un filtre avec la clause WHERE (voir la requête du listing5.7).
1 SELECT d e s t i n a t i o n 2 FROM f l i g h t s
3 WHERE o r i g i n = ’ LIS ’ 4 AND d u r a t i o n <=120;
5.2 – Base de données relationnelle 103
destination FNC CMN
TABLE5.4 – Résultat de la requête du listing5.7.
Exemple 5.2.8 (Destination la moins chère en SQL). Pour chercher la destination la moins chère, nous utilisons la clause ORDER BY pour trier la table des vols partant de l’aéroport dont le code est NCE. C’est un tri ascendant sur les coûts (ligne 4 du listing5.8). La destination la moins chère correspond au premier résultat renvoyé par l’ajout du TOP 1 (voir la requête du listing5.8). Le résultat de cette requête est présenté dans la table5.5.
1 SELECT TOP 1 d e s t i n a t i o n 2 FROM f l i g h t s
3 WHERE o r i g i n = ’NCE ’ 4 ORDER BY c o s t ASC ;
Listing 5.8 – requête pour trouver la destination la moins chère en SQL
destination CMN
TABLE5.5 – Résultat de la requête du listing5.8.
Exemple 5.2.9 (Récupérer les noms en SQL). Un exemple de jointure est illustré par la récupéra- tion des noms des aéroports stockés dans la table airports. Cette opération intervient quand on a besoin de chercher les données dans d’autres tables. Ainsi, nous utilisons la commande INNER JOINpour chercher les noms des aéroports dont le code figure dans la table flights (voir la requête du listing5.9et son résultat dans la table5.6).
1 SELECT DISTINCT TOP ( 2 ) a . name 2 FROM f l i g h t s AS F
3 INNER JOIN a i r p o r t s AS A 4 ON F . o r i g i n =A . code
5 OR F . d e s t i n a t i o n =A . code ;
Listing 5.9 – requête pour récupérer les noms en SQL
name
Ankara Esenboga Airport Chales De Gaulle Airport
TABLE5.6 – Résultat de la requête du listing5.9.
5.2.4.2 Complexité algorithmique des requêtes
En SQL, la complexité des requêtes nécessitant de faire une opération de sélection est linéaire. En effet, pour récupérer la liste des destinations depuis l’aéroport, il faut parcourir toute la table
104 CHAPITRE 5 — Notions sur les bases de données
flights[Ben-Gan et al., 2015]. En revanche, l’opération la plus coûteuse est la jointure. Sa complexité dépend fortement de la taille de la table et de la présence d’un index sur la colonne concernée.
Généralement, il existe trois types de jointures [Taniar et al.,2008] :
1. Jointure par boucle imbriquée (en anglais Nested loop join) : énumérer toutes les correspon- dances possibles.
2. Jointure par hachage (en anglais hash-based join) : construire une table de hachage sur une des tables.
3. Jointure par tri-fusion (en anglais Sort-Merge join).
Supposons que nous avions deux tables M et N de taille m (respectivement n). Alors, on a une complexité quadratique pour le premier cas, O(mn). Pour le deuxième cas, une complexité linéaire, O(m + n). Cependant, la complexité de la jointure par tri-fusion dépend également de la présence d’un index sur la colonne concernée :
— Le pire des cas, c’est dans l’absence des index sur les colonnes de jointure : O(m × log m +