# 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. 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.

## Exigences idéales pour l'intégration des schémas

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.
* 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.
* 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.
* 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.

## Exemple de l'intégration de deux schémas

Par exemple si nous souhaitions créer un schéma média (ou médiated schema) pour intégrer deux base de données de voyages, Go-travail et Ok-flight.
Go-travel a deux relations :
Ok-flight a une seule relation :

### Intégration des schémas

L’information qui se chevauche entre les schémas de Go-travel et Ok-flight peut être représentée dans un schéma médié. Un schéma médié (ou mediated schema) est un schéma unifié qui sert de couche intermédiaire pour intégrer des informations provenant de différentes sources ou schémas. Il permet de créer une vue cohérente et harmonisée des données en les représentant dans un format commun, facilitant ainsi l'accès et l'utilisation des données issues de plusieurs systèmes. Le schéma médié résout les chevauchements ou conflits de données entre les différentes bases de données tout en offrant une vue intégrée.
Dans cet exemple, un schéma médié pourrait combiner les éléments communs des deux bases de données, comme suit :
Dans ce schéma médié, les éléments flight-number, date, time, et price sont intégrés, car ils sont présents dans les deux bases de données. Les détails supplémentaires, comme les informations sur le repas (meal) dans Go-travel ou la fonctionnalité nonstop dans Ok-flight, peuvent être omis ou traités séparément, selon les besoins spécifiques du schéma médié.
Ainsi, le schéma médié représente une version simplifiée et unifiée des deux schémas d'origine, permettant l'intégration des informations essentielles sans perdre de données cruciales.

## Spécificités des bases de données Oracle

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.

## Spécificités des bases de données Microsoft SQL Server

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.

### Points clés concernant le schéma dbo dans SQL Server

* Schéma par défaut : Lorsqu'un nouvel objet (par exemple, une table, une vue ou une procédure stockée) est créé sans spécifier de schéma, il est placé dans le schéma dbo par défaut.
* Permissions : Le schéma dbo est généralement utilisé par l'administrateur de la base de données (DBA) ou d'autres utilisateurs privilégiés, leur donnant un contrôle total sur les objets stockés dans ce schéma.
* Propriété des objets : Les objets dans le schéma dbo sont généralement considérés comme appartenant à la base de données, ce qui permet de gérer facilement les permissions et l'accès aux utilisateurs de la base de données.
Par exemple, si un utilisateur crée une table sans spécifier de schéma :
Elle sera créée par défaut dans le schéma dbo, ce qui donnera une table nommée dbo.Employee.
En revanche, un utilisateur peut spécifier un autre schéma, comme suit :
Dans ce cas, la table sera placée dans le schéma Sales au lieu de dbo.
Ce comportement par défaut du schéma simplifie la gestion de la base de données et permet une meilleure organisation et un meilleur contrôle d'accès.