[MUSIQUE] [MUSIQUE] [MUSIQUE] [MUSIQUE] Bienvenue dans ce cours qui va porter sur les bases de données relationnelles qui sont la forme la plus largement répandue de bases de données et que l'on retrouve dans absolument tous les domaines de la vie courante. Les objectifs de cette leçon consistent donc à découvrir les bases de données. En particulier, les bases de données relationnelles. Et la manière dont la dimension spatiale est intégrée dans ces bases de données. Et au terme de cette leçon, vous devriez être capables de décrire le concept qui fonde les bases de données relationnelles, ainsi que les divers types d'objets qu'elle contient. Dans la leçon précédente, nous avons vu plusieurs formes de stockage de données sous forme de fichiers simples, de fichiers semi-structurés. Aujourd'hui, nous allons passer en revue la suite des possibilités de stockage de données. A savoir les bases de données qui permettent un stockage plus structuré et la plupart du temps un stockage centralisé dans une architecture client serveur. Dans cette leçon, nous allons aborder la question de la définition d'une base de données, les notions de fiabilité de ces bases de données. Nous ferons un bref survol historique de l'évolution des différents types de bases de données. Puis, nous nous concentrerons sur le modèle relationnel que nous verrons assez en détails. Et puis, nous parlerons ensuite de la manière dont la composante spatiale est gérée dans cette base de données. Et pour finir, un premier bref aperçu des logiciels SGBD. Donc, des logiciels systèmes de gestion de bases de données que nous verrons aussi à plusieurs reprises dans les cours suivants. [MUSIQUE] Une base de données peut être définie comme une collection de données persistantes. Éventuellement centratralisée, utilisée par plusieurs applications et par plusieurs groupes d'utilisateurs qui peuvent éventuellement travailler en parallèle. On voit qu'avec cette définition très générale, les fichiers d'hébergements de données que nous avons vus lors de la précédente leçon peuvent aussi être considérés comme des bases de données, dans la mesure où elles offrent une certaine persistance au stockage d'informations. Les systèmes de gestion de bases de données sont par contre des logiciels qui permettent de créer, de structurer, de documenter, de consulter les bases de données. Il s'agit en fait de l'interface qui existe entre base de données et les utilisateurs ou les applications qui utilisent les bases de données. Comme le montre cette image, il en existe un très grand nombre. Autant dans le domaine commercial que dans le domaine du logiciel libre. Les modifications d'une base de données sont le fruit de transactions. Les transactions étant une suite d'opérations qui font passer la base de données d'un état initial à un état final. Et pour qu'une base de données passe d'un état initial intègre et cohérent à un état final intègre et cohérent, les transactions doivent respecter un certain nombre de critères, qui sont l'atomicité, la cohérence, l'isolation et la durabilité. Critères que l'on résume souvent sous le nom de propriétés ACID et que nous allons voir un peu plus en détail à présent. Le principe d'atomicité stipule que la transaction se fait complètement ou pas du tout. Dans le cas ici d'une transaction qui comprend deux opérations, la première consistant à retrancher 10 à un ensemble A. Et la seconde, à ajouter 10 à un ensemble B. Avec pour condition de validité, que A + B = 100. On voit que l'opération se fait en deux étapes pour arriver à un résultat qui est ensuite enregistré dans la base de données, par une opération qui s'appelle un Commit. Une opération de validation. Il peut arriver que l'une de ces deux opérations échoue. Et dans ce cas-là, le principe d'atomicité veut que la première opération de la transaction puisse être réversible et annulée. Donc, on puisse retourner en fait à l'état initial de la base de données. Les bases de données doivent vérifier des principes de cohérence. Si nous avons ici l'exemple d'une transaction qui consiste à retrancher 5 d'un ensemble A et à ajouter 10 à un ensemble B, avec une condition de validité A + B = 100 comme tout à l'heure, on voit bien qu'au terme de la transaction, le résultat ne respecte plus la condition de validité. Si bien que la validation doit être empêchée et l'opération dans son ensemble annulée. Le principe d'isolation. On a ici le cas de deux transactions. La première consistant à retrancher 10 d'un ensemble A, à ajouter 10 à un ensemble B. Avec toujours la même condition de validité. Et une deuxième transaction qui fait à peu près la même opération. On retranche 5 de l'ensemble B, on ajoute 5 à l'ensemble A. Et en fait, le principe d'isolation veut que l'exécution de ces transactions l'une après l'autre donne le même résultat que si les transactions sont exécutées en même temps, c'est-à-dire en série. Et on voit que si l'une de ces opérations échoue, la dernière par exemple, il faut s'assurer que le principe d'annulation nous ramène la base de données dans un état valide, ce qui est le cas dans le cas séquentiel. Mais par contre, lorsque les opérations se font en série, on voit qu'il faut qu'une procédure spéciale soit mise en place, au niveau du système gestion de base de données, pour s'assurer que l'exécution en série en cas de pépin remette la base dans un état valide et cohérent. Finalement, le principe de durabilité stipule que l'enregistrement en mémoire de la transaction au moment de la validation ne puisse pas être empêché ou interrompu par un événement extérieur. Par exemple, une coupure de courant, un tremblement de terre ou que sais-je. Cela signifie techniquement en fait qu'il faut éviter de passer par une mémoire tampon qui pourrait s'effacer en cas de coupure de courant, avant la validation proprement dite. En résumé, les principes ACID stipulent donc pour l'atomicité qu'une transaction doit être effectuée complètement ou pas du tout. Pour la cohérence, que l'on va vérifier au niveau de la base de données, les conditions de validité. Le principe d'isolation qu'une exécution en série donne le même résultat qu'une exécution séquentielle, les différentes opérations d'une transaction. Et finalement, le principe de durabilité stipule que des incidents externes, type coupure de courant ou autre n'affectent pas la manière dont l'information est stockée et validée dans la base de données. [MUSIQUE] Nous passons donc maintenant à la typologie historique des bases de données. Dès les années 50 et 60 s'est développé le stockage sous forme de fichiers, dont nous avons vu quelques exemples lors de la leçon précédente. Puis, à partir des années 60-70, se sont développées dans un premier temps les bases de données hiérarchiques, où les enregistrements sont associés par des relations selon une arborescence descendante et chaque élément a un et un seul parent. Dans les domaines d'applications, eh bien, les structures d'organisations, les systèmes de fichiers, les systèmes taxonomiques, etc, etc. Par la suite, les bases de données réseau qui sont une variante de bases de données hiérarchiques, avec simplement une multiplicité des parents possibles. Donc, l'arborescence n'est plus strictement descendante. Il peut y avoir des structures cycliques. A partir des années 70-80, les bases de données relationnelles, qui reposent sur le principe d'enregistrements hébergés dans des tables à deux dimensions. Une relation étant une table, un attribut se trouvant dans une colonne ou un champ et l'objet dans les lignes. Et à partir des années 90, les bases de données objet et les bases de données semi-structurées dans lesquelles les données sont stockées sous formes d'objets qui peuvent avoir des structures spécifiques et variables de différents types. Nous parlerons dans cette leçon plus précisément des bases de données relationnelles donc. Et le thème des bases de données objet sera quant à lui abordé plus spécifiquement dans un cours ultérieur. [MUSIQUE] Le modèle relationnel a donc été développé essentiellement pour répondre aux principes ACID, dans les transactions qui permettent de modifier une base de données. De s'assurer d'avoir une bonne cohérence de l'information, d'éviter la redondance des informations. C'est un modèle qui est fondé sur des bases théoriques solides, puisque cela s'appuie sur la théorie des ensembles dont est tirée l'algèbre relationnel. C'est un modèle qui a été très largement utilisé par tous les grands acteurs du domaine des bases de données. Aujourd'hui, on peut dire qu'environ 80 % à 90 % des bases de données sont construites sur le modèle relationnel. C'est quelque chose qui change un petit peu avec le Big Data, qui fait appel à d'autres types de modèles. Mais le modèle relationnel reste largement le plus important. C'est un modèle finalement qui a été développé à partir des années 70 chez IBM par un ingénieur du nom de Ted Codd. Dans le modèle relationnel, les données sont donc organisées sous forme de tables également appelé relation. Une relation est constituée de colonnes ou d'attributs, caractérisés par un nom et un domaine, un domaine étant un ensemble de valeurs, par exemple le domaine des valeurs entières, le domaine des booléens, le domaine des disciplines sportives, etc. Dans une table chaque ligne correspond à un enregistrement également appelé tuple, et pour un tuple il peut arriver qu'un attribut ne soit pas valué, donc qu'il n'ait pas de valeur. Et dans ce cas-là, on indique ce fait par la valeur nulle, NULL. Un ensemble ne peut contenir deux fois le même objet, c'est pour cette raison que dans le modèle relationnel on doit absolument s'assurer que chaque objet est unique. La meilleure façon de s'assurer que cet objet est unique c'est de définir un identifiant spécifiquement pour les besoins, comme dans le cas de la première table que l'on voit ici, où on a créé un numéro d'étudiant qui permet d'identifier sans ambiguïté chaque étudiant. Cet identifiant est également parfois appelé clé primaire, peut être fabriqué pour les besoins de la cause, mais peut aussi être construit à partir des attributs existants, par exemple en associant le nom et le prénom des étudiants. On voit bien que si on se contente que du nom et du prénom, eh bien on peut être confronté au problème des homonymes et avoir plusieurs personnes qui ne pourraient pas être distinguées par cet identifiant. D'où la nécessité d'étendre le concept et puis d'intégrer l'adresse, le nom de la rue, le numéro postal, etc. En fait l'identifiant pourrait être constitué de l'ensemble des champs de la table, avec évidemment, on l'imagine bien, un certain nombre d'inconvénients lorsqu'il s'agit d'indexer les objets pour pouvoir les retrouver plus vite lors d'une recherche, ou bien pouvoir faire des tris et des choses comme ça. C'est pour cette raison en fait que l'utilisation d'un identifiant spécifique est le cas de figure largement le plus souvent rencontré. Les identifiants externes, également appelés clés étrangères, décrivent des liens entre différentes relations. Par exemple dans le cas de cours suivis par des étudiants, on a une table d'étudiants, une table de cours, une table de professeurs, et on voit qu'un cours est donné par un professeur et que ce professeur en fait doit existé dans la table des professeurs pour que la base de données soit intègre. Dans la relation Suivi de cours, qui associe un numéro d'étudiant avec un titre de cours, donc qui est la liste des cours suivis par les étudiants, ou la liste des étudiants qui suivent un cours, on voit que le numéro d'étudiant référence un étudiant de la relation étudiant, et titre cours référence un cours dans la table des cours. La référence doit pointer sur un objet unique, évidemment, et il peut arriver que cet objet soit nul si l'attribut est facultatif, par exemple dans le cas de la salle de cours qui pourrait ne pas encore avoir été attribuée au moment où on documente la table. L'intégrité référentielle de la base de données est un principe vérifié automatiquement par le système de gestion de bases de données. Si par exemple un utilisateur veut insérer un nouveau cours de géologie dans la table des cours suivis par les étudiants et que ce cours n'existe pas dans la table cours, la transaction sera refusée. De même si un utilisateur veut changer le nom d'un cours et que ce nom n'existe pas dans la table de référence, la transaction sera également refusée. De même si un utilisateur veut supprimer un cours qui est référencé par d'autres relations, l'opération peut être refusée, on peut supprimer les références dans l'autre relation, ou alternativement annuler ces références. Pareillement si un utilisateur veut modifier le nom d'un cours dans une table et que ce nom est référencé ailleurs, on peut refuser l'opération ou mettre à jour l'autre table également. Le modèle relationnel ne se prête pas à l'enregistrement d'attributs multivalués, donc qui ont plusieurs valeurs ou d'attributs complexes, composé de plusieurs éléments. Il est de fait nécessaire de les modéliser autrement. Dans le cas d'un attribut monovalué complexe, comme par exemple une adresse qui est composée d'une rue, d'un numéro dans la rue, d'un numéro postal d'une localité, une possibilité consiste à définir un attribut, un champ par composant comme c'est illustré par la table qui se trouve ici en haut à droite, et par la suite de construire dans la base de données une vue, donc qui est une table virtuelle contenant en fait l'agrégation de ces différents champs pour restituer l'idée d'adresse. L'autre possibilité consiste à créer un attribut adresse globale qui serait de type chaîne de caractères dans lequel on va enregistrer l'ensemble de l'adresse, chemin, numéro, numéro postal, localité. On voit que dans ces relations le numéro d'étudiant est un identifiant de la relation étudiant. Pour un attribut multivalué comme par exemple le cas de prénoms multiples, une possibilité serait de définir plusieurs attributs pour chaque prénom, prénom 1, prénom 2, etc. C'est un mauvais choix parce qu'en fait on ne sait pas combien de prénoms il faut prévoir, et si c'est pas des prénoms ça peut être un autre type d'attribut qui pourrait avoir une succession innombrable d'éléments donc on voit bien que ça ne fonctionne pas très bien. D'autant plus que ça conduit à définir beaucoup de champs qui seront remplis de valeurs nulles. C'est pas quelque chose qui est très optimal du point de vue base de données. Une solution alternative consiste à créer une table supplémentaire dans laquelle vont être hébergés les prénoms en relation avec l'identifiant des étudiants auxquels ces prénoms se rattache, et donc on voit que le champ numéro étudiant qui est une clé primaire de la table Etudiants devient une clé étrangère de la table EtudPrénoms. Une autre possibilité, un peu plus subtile, consiste à intégrer dans la table EtudPrénoms le numéro du prénom de sorte à pouvoir restituer l'ordre dans lequel les prénoms apparaissent. Premier prénom, second prénom, etc. Et dans ce cas également numéro d'étudiant est une clé primaire pour la table Etudiants et une clé étrangère pour la table EtudPrénoms, qui elle n'a pas de clé primaire. Nous avons donc passé en revue les principales notions de base du modèle relationnel, à savoir le domaine de valeurs, l'attribut, la relation, le tuple, l'identifiant, l'identifiant externe. Il nous reste encore à évoquer les différents opérateurs de l'algèbre relationnelle qui fonde les opérations que l'on va pouvoir ensuite faire sur ces tables, opérations que nous verrons de manière assez détaillée dans la deuxième semaine de ce module, avec tout ce qui est requête, langage SQL etc. Ces opérateurs sont en premier lieu l'opérateur d'union, donc on est dans une logique ensemble-liste, et pour l'exemple on prend ici une série de photographies qui ont été réalisés par un auteur, une certaine année dans une certaine ville, et on voit que l'union de deux tables consiste en fait à agréger ces deux tables en une seule. La différence entre deux tables est la soustraction de la seconde à la première, donc l'élimination des objets redondants de la première. Cette opération n'est pas commutative, donc si on la fait dans l'autre sens le résultat va être différent. Nous avons ensuite le produit croisé qui consiste à associer chaque élément, chaque tuple de la première table à chaque tuple de la seconde. Donc ici les versions couleur et noir blanc des photos qui donnent donc deux fois trois six photos, et puis les opérations de sélection sur une table. Sélection qui consiste à identifier, à extraire un certain nombre d'éléments. Des opérations de projection qui consistent à extraire un certain nombre d'attributs pour l'ensemble de la table, ce qui dans le cas précis débouche sur quelque chose qui n'a pas grand, ou en tout cas qui est contraire au principe de la théorie des ensembles puisque l'on a des objets identiques. Donc c'est une opération qui ne serait pas valide. Et finalement les opérations de jointure qui consistent à associer deux tables par l'intermédiaire d'un champ qui leur serait commun, ici la table des photographies couleurs avec une table qui associerait ville et pays. Le champ commun étant évidemment la ville. Ces opérations de jointure peuvent être assorties d'une condition. Donc, on pourrait ne garder que les éléments jointifs qui ont pour pays le Sénégal. Et donc, une seule, une seule photographie sur les trois qui étaient comprises dans la jointure de départ. [MUSIQUE] [MUSIQUE] Nous en venons maintenant aux spécificités des bases de données qui possèdent une composante spatiale. Spécificités qui sont au nombre de trois principalement. Tout d'abord, le type de données. Donc, les domaines concernant ces types de données. On voit que dans la table ici en haut à droite, en haut à gauche, pardon. Dans une base de données traditionnelle, on a un certain nombre de types de données bien définis, varchar pour le texte, les entiers pour le numérique, le réel, également pour les nombres, les dates. Dans la base de données spatiale, on ajoute de nouveaux types de données, de type point, ligne, polygone, etc. Enfin, les géométries de base qui sont gérées par les systèmes d'informations géographiques. Le second domaine important, c'est celui de l'indexation. L'indexation des objets spatiaux pour pouvoir, par la suite, effectuer des requêtes et retrouver rapidement les objets. Et finalement, un certain nombre de fonctions qui permettent d'effectuer des opérations spécifiques sur les objets géométriques. Il existe plusieurs formes d'indexation des données. Dans le domaine des bases de données non spatiales, on utilise souvent une structure appelée B-tree. Donc, une arborescence hiérarchique qui permet en fait de retrouver facilement les données. On a dans cette illustration un exemple d'un arbre d'ordre 5 dans lequel un nœud peut avoir au plus quatre clés et cinq enfants. Chaque nœud ayant au moins deux clés et trois enfants. Cette idée d'arborescence hiérarchique se retrouve dans le domaine des bases de données spatiales sous la forme d'un R-tree, dans lequel les objets les plus proches sont regroupés et représentés à l'échelle supérieure par une enveloppe minimale, qui est le minimum bounding rectangle. Et lorsque l'on fait ensuite une requête pour retrouver des objets, en fait si la requête n'intersecte pas l'enveloppe minimale, on peut écarter tous les objets de cette enveloppe et puis se concentrer sur ceux qui restent en jeu. Dans l'illustration qui est ici, on voit à gauche le lien entre une approche hiérarchique non spatiale et une approche hiérarchique spatiale. Et puis, à droite, un exemple de structuration d'index spatial qui concerne les bureaux de postes en Allemagne. Le Quadtree est une autre méthode d'indexation spatiale qui est pas mal utilisée dans les systèmes de tuilage de cartes géographiques type Google, etc. Il s'agit d'une structure arborescente dans laquelle chaque nœud possède exactement quatre enfants. Donc chaque zone géographique est divisée en quatre. Et à nouveau en quatre, chaque fois que l'on descend d'un niveau de zone. Le mode d'indexation en grille est similaire dans le sens qu'il s'agit aussi d'une tessellation régulière. Simplement que la subdivision de chaque entité ne se fait pas nécessairement en quatre, mais peut se faire en neuf, en seize, etc, etc. Parmi les fonctions spécifiques aux bases de données spatiales, on peut distinguer trois familles principales. Tout d'abord, la famille des mesures spatiales qui donnent des indications de longueur, de surface, de distance à propos des objets géométriques. Des fonctions spatiales qui sont, qui créent de nouvelles entités. Par exemple, on peut imaginer la création d'une zone tampon autour d'un objet géométrique, l'intersection de deux objets qui crée un nouvel objet. L'union de deux objets, etc, etc. Et des opérateurs topologiques qui testent la véracité de relations de voisinage. Est-ce que deux géométries se chevauchent? Est-ce qu'elles se touchent? Est-ce qu'elles sont contenues l'une dans l'autre ou vice versa, etc. Tous ces différents types de fonctions sont de plus en plus souvent implémentés dans les systèmes de gestion de base de données spatiales. [MUSIQUE] [MUSIQUE] Comme je l'ai dit au début de ce cours, il existe un très grand nombre de systèmes de gestion de base de données consacrées au modèle relationnel. Et non seulement il existe un très grand nombre de bases de données, mais ces bases de données sont accessibles par l'intermédiaire de toute une série de clients qui sont soient des logiciels commerciaux, soit des logiciels libres. Tous ces clients offrant en fait une interface utilisateur et permettent d'entrer en contact avec ces bases de données et de les manipuler. Parmi les fonctionnalités que l'on souhaite trouver dans les systèmes de gestion de base de données, il en est en fait de trois types. Tout d'abord, celles qui permettent de gérer la structure des données. Donc, de créer de nouveaux champs, de nouveaux attributs avec leurs domaines de valeurs et de créer de nouveaux index clé primaire, clé externe, etc, etc. De consulter les données enregistrées dans la base de données. Donc, de consulter les tables de valeurs. Éventuellement de pouvoir importer des données depuis l'extérieur pour peupler ces différentes tables. Et finalement, toutes les fonctionnalités qui sont liées à la construction et à l'exécution de requêtes pour aller rechercher des objets dans une base de données, sur la base d'un certain nombre de critères, etc. Toutes choses que nous allons voir plus en détail, en particulier dans les leçons du deuxième, de la deuxième semaine de ce module. Dans l'immédiat, nous allons prendre un petit exemple qui est celui des districts des Seychelles que l'on peut exporter dans un format base de données. En l'occurrence, une base de données SpatiaLite. Donc, on va appeler ce fichier mahe.sqlite. Et l'enregistrer. On peut préciser quelques paramètres. La couche enregistrée va être ajoutée en fait. Il demande de préciser le système de projection utilisé. UTM Sud 40. On peut masquer cette nouvelle couche. Et dans un deuxième temps, on va enregistrer simplement les attributs de la couche, donc sans la géométrie, sous la forme d'un fichier ASCII, fichier texte, .csv, donc un fichier texte avec des valeurs séparées par les virgules. Donc là, pareillement, la table va être ajoutée dans la liste des objets disponibles. Et si on passe maintenant à un logiciel de gestion de base de données, donc il s'agit de SQLiteStudio, on peut importer. On va commencer par créer une base données, dans laquelle on va importer le fichier texte. Donc, on va appeler cette base de données mahe_data. Cette base de données, une fois créée, on voit qu'elle, on va commencer par se connecter à cette base de données. Et on voit qu'elle peut contenir des tables et des vues qui sont en fait des résultats de requêtes, les vues. Rendues un peu permanentes. Dans les tables, on va importer des données dans une nouvelle table. On va créer cette nouvelle table qu'on va appeler districts. Et importer le fichier texte qui contient les attributs de ces districts qu'on a sauvegardé précédemment. On dit que la première ligne représente les entêtes des colonnes. Et on voit que cette table apparaît maintenant dans l'arborescence. Cette table districts qui contient un certain nombre de colonnes qui sont les différents champs que nous avions dans la couche districts de QGIS. On peut consulter également les données elles-mêmes. Et modifier la structure de données si nécessaire. Dans un deuxième temps, on va ajouter une autre base de données, qui est en fait la base de données sauvegardée de QGIS avec les éléments de géométrie. Et on voit que si on se connecte à cette base de données, on a un nombre d'objets beaucoup plus considérable. Puisqu'en fait pour gérer la dimension géométrique, la base de données SQLite génère tout un tas d'objets qui sont nécessaires et qui rendent la chose, quand on l'aborde comme cela de loin, un peu plus complexe. Mais on retrouve aussi la table de données des districts de Mahé, avec les mêmes colonnes, les mêmes valeurs que l'on peut consulter sous forme de tables. On voit qu'il n'y a en plus pas encore d'index, mais des déclencheurs, triggers en anglais, qui sont en fait les règles que le système de gestion de base de données doit vérifier lors de chaque transaction. Donc, on peut définir les règles de validation au cas par cas. Voilà pour les logiciels, pour cette introduction aux logiciels systèmes de gestion de bases de données, que nous reverrons plus en détail dans d'autres leçons du cours. [MUSIQUE] Nous voilà donc au bout de cette leçon qui nous aura permis d'aborder de manière assez détaillée le thème des bases de données relationnelles. Et de faire une petite introduction aux systèmes de gestion de bases de données. Tous ces éléments seront repris plus en détail par la suite. En particulier par la prochaine leçon qui va porter sur la modélisation des données. Et puis par la suite sur, dans les leçons qui vont porter sur les requêtes, les langages de requêtes où on va beaucoup utiliser pour illustrer le propos, des systèmes de gestion de bases de données. [MUSIQUE] [MUSIQUE]
