Schéma de base de données

Le schéma de base de données est la structure d'une base de données décrite dans un langage formel généralement pris en charge par un système de gestion de base de données relationnelle (SGBDR). Le terme « schéma » fait référence à l'organisation des données comme plan directeur indiquant comment la base de données est construite (divisée en tables dans le cas des bases de données relationnelles ). La définition formelle d'un schéma de base de données est un ensemble de formules (phrases) appelées contraintes d'intégrité imposées à une base de données^[1]. Ces contraintes d'intégrité assurent la compatibilité entre les parties du schéma. Toutes les contraintes sont exprimables dans le même langage. Une base de données peut être considérée comme une structure dans la réalisation du langage de base de données. Les états d'un schéma conceptuel créé sont transformés en un correspondance explicite, le schéma de base de données. Cela décrit comment les entités du monde réel sont modélisées dans la base de données.

« Un schéma de base de données définit, selon les connaissances de l'administrateur de la base de données sur les applications possibles, les faits pouvant être intégrés dans la base de données ou ceux présentant un intérêt pour les utilisateurs finaux possibles. » La notion de schéma de base de données joue le même rôle que la notion de théorie dans le calcul des prédicats. Un modèle de cette « théorie » correspond de près à une base de données, qui peut être considérée à tout instant comme un objet mathématique. Ainsi, un schéma peut contenir des formules représentant des contraintes d'intégrité spécifiques à une application ainsi que des contraintes spécifiques à un type de base de données, toutes exprimées dans le même langage de base de données. Dans une base de données relationnelle, le schéma définit les tables, les champs, les relations, les vues, les index, les packages, les procédures, les fonctions, les files d'attente, les déclencheurs, les types, les séquences, les vues matérialisées, les synonymes, les liens de base de données, les répertoires, les schémas XML (XML schema) et d'autres éléments.

Une base de données stocke généralement son schéma dans un dictionnaire de données. Bien qu'un schéma soit défini dans un langage textuel de base de données, le terme est souvent utilisé pour désigner une représentation graphique de la structure de la base de données. En d'autres termes, le schéma est la structure de la base de données qui définit les objets qu'elle contient.

Dans un système Oracle Database, le terme « schéma » a une connotation légèrement différente car il désigne un ensemble d'objets de base de données (tables, vues, index, etc.) appartenant à un utilisateur spécifique, plutôt que la structure globale de la base de données.

Les exigences ci-dessous influencent la structure détaillée des schémas qui sont produits lors de l'intégration des données. Bien que certaines applications ne nécessitent pas que toutes ces conditions soient remplies, les quatre exigences suivantes sont considérées comme les plus idéales dans un processus d'intégration de schémas.

• Préservation du chevauchement : Chaque élément en chevauchement spécifié dans le mappage (data mapping) d'entrée doit être inclus dans une relation du schéma de base de données. Cette exigence assure que les informations communes, souvent générées à partir de plusieurs sources de données, sont correctement conservées dans le schéma final. Cela permet de maintenir l'intégrité des relations entre les différentes entités au sein du schéma^[2].

• Préservation étendue du chevauchement : Les éléments spécifiques à une source, qui sont associés aux éléments en chevauchement d’une source donnée, doivent être intégrés dans le schéma de base de données. Cela garantit que les informations relatives à chaque source, particulièrement celles qui se chevauchent avec d'autres sources, sont correctement transférées sans perte de contexte ou de données^[2].

• Normalisation : Les entités et relations indépendantes dans les données sources ne doivent pas être regroupées dans une même relation du schéma de base de données. En particulier, les éléments spécifiques à une source ne doivent pas être mélangés avec les éléments en chevauchement, si cela entraîne la co-localisation d’entités ou de relations indépendantes. La normalisation vise à réduire la redondance des données et à éviter les anomalies lors des opérations de mise à jour, d’insertion ou de suppression dans la base de données^[2].

• Minimalité : Un schéma de base de données n'est pas considéré comme idéal si la suppression de l'un de ses éléments entraîne une perte d'information ou d'intégrité. L'objectif de la minimalité est de s'assurer que seuls les éléments essentiels sont inclus dans le schéma sans sacrifier les relations ou la structure nécessaire pour garantir que la base de données fonctionne de manière optimale et complète^[2].

Par exemple si nous souhaitions créer un schéma média (ou médiated schema)^[3] pour intégrer deux base de données de voyages, Go-travail et Ok-flight.

Go-travel a deux relations :

Go-flight(flight-number, time, meal(yes/no))
Go-price(flight-number, date, price)

Ok-flight a une seule relation :

Ok-flight(flight-number, date, time, price, nonstop(yes/no))

Flight(flight-number, date, time, price)

Dans le contexte des bases de données Oracle, un objet de schéma est une structure logique de stockage de données. Un schéma Oracle est associé à chaque utilisateur de la base de données et comprend un ensemble d'objets de schéma.

Parmi les exemples d'objets de schéma, on trouve :

• tables
• vues (ou view)
• séquences
• synonymes
• index

• clusters
• liens de base de données
• instantanés
• procédures
• fonctions
• packages

En revanche, les objets non liés au schéma peuvent inclure :

• utilisateurs
• rôles
• contextes
• objets de répertoire

Les objets de schéma n'ont pas de correspondance directe avec les fichiers physiques sur disque qui stockent leurs informations. Cependant, les bases de données Oracle stockent les objets de schéma de manière logique au sein d'un tablespace de la base de données. Les données de chaque objet sont physiquement contenues dans un ou plusieurs fichiers de données du tablespace. Pour certains objets (tels que les tables, index et clusters), un administrateur de base de données peut spécifier l'espace disque que le SGBD Oracle (système de gestion de base de données) alloue pour l'objet dans les fichiers de données du tablespace.

Il n'existe pas de relation nécessaire entre les schémas et les tablespaces : un tablespace peut contenir des objets provenant de différents schémas, et les objets d'un seul schéma peuvent résider dans différents tablespaces. Toutefois, la spécificité d'Oracle impose une reconnaissance au niveau de la plateforme des différences de séquences non homogénéisées, ce qui est considéré comme un facteur limitant crucial dans les applications virtualisées^[4].

Dans Microsoft SQL Server, le schéma par défaut de chaque base de données est le schéma dbo (Database Owner). Ce schéma est automatiquement attribué à tous les objets de la base de données (tels que les tables, vues et procédures stockées) à moins qu'un autre schéma ne soit spécifié explicitement par l'utilisateur. Le schéma dbo sert à gérer les permissions des objets de la base de données. Les utilisateurs propriétaires des objets dans le schéma dbo ont généralement un contrôle total sur ces objets, et ce schéma est souvent utilisé pour les objets système et les tâches administratives^[5].

CREATE TABLE Employee (ID INT, Name VARCHAR(100));

CREATE TABLE Sales.Employee (ID INT, Name VARCHAR(100));

• Sciences de l’information et bibliothèques
• Portail de la programmation informatique