Discussion :

[marietar]

Bonjour
Je débute en sql, je sais faire des choses intermédaire en exercices, sur une page web.
Là, je suis dans une boite avec un vrai moteur SQL.




j'utilise dbeaver pour accéder au serveur.
Je me dis : c'est cool, je vair voir visuellement les bases et les tables associées à chaque base.

je vois bien les bases comme dans le screenshot 1


quand je cliqur sur une base, je m'attends à voir les tables mais en fait, je vois des schémas.: voir screenshot 2


puis quand je clique sur un schéma, je vois les tables, avec pour chaque table les colonnes asscoiées: voir screenshot 3



ma question:
c'est quoi le schéma que je vois en dessous des bases?
je pensais qu'un schéma était associé à une table, que c'était le nom des colonnes et le type des colonnes (INT, STR etc...)

or ici, je vois que un schéma peut avoir plusieurs tables.
Pourquoi plusieurs schémas dans une base?

merci

[escartefigue]

Un schéma permet de gérer les droits des objets qui lui sont associés sans devoir le faire sur chaque objet.
Une même table peut se trouver dans plusieurs schémas, on peut très bien avoir des droits sur la table T1 du schéma S1 et des d'autres droits sur la même table T1 du schéma S2.

Attention toutefois : MySQL/MariaDB confondent schéma et database

Le schéma n'a aucun rapport avec le nom et le type des colonnes.

[SQLpro]

Voici ce que je dis dans mon prochain livre sur SQL à paraître en libre avant la fin de l'année :

1.9 – Organisation interne d’un SGBD Relationnel
Un SGBD Relationnel est en fait un programme informatique de type « service » et tourne en permanence. Il et est à l’écoute des demandes des nombreux utilisateurs. Il reçoit des requêtes qu’il analyse et exécute suivant les permissions accordées aux utilisateurs sur les objets.

Il peut se faire que sur une même machine physique ou virtuelle soit installées plusieurs instances d’un même type de SGBDR. Ceci est fortement déconseillé en production, mais est courant pour les entreprises assurant le développement ou la maintenance d’applications.

Le terme de « base de données » (en anglais « database ») n’existait pas à l’époque de Ted Codd. On parlait alors de « databank » (banques de données) dans lesquelles on trouvait des « catalogues » de données. Le terme « catalogue » est cependant resté dans certaines vues de métadonnées et nous le rencontrerons au cours de cet ouvrage.

1.9.1 – La notion de base de données ou CATALOG

Un SGBD Relationnel moderne peut comporter de nombreuses bases de données chacune devant être utilisée par une application précise. Par exemple dans une entreprise, on pourra trouver une base de données pour les ressources humaines, une autre pour la comptabilité et une troisième pour la gestion des clients (actions commerciales, commandes, facturation, livraisons…). Le cloisonnement par base doit être relativement étanche, mais certaines données de chacune de ces bases peuvent alimenter d’autres bases. À titre d’exemple, les factures de la base client seront poussées vers la base comptable.
Une commande spécifique, généralement CREATE DATABASE, permet de créer une nouvelle base de données dans le s

Certains SGBD Relationnels permettent de faire des jointures entre les tables des différentes bases de manière naturelle et optimisées. C’est le cas de Microsoft SQL Server. D’autres nécessitent l’établissement d’une liaison entre deux bases par un mécanisme à créer (DBLink), et la jointure s’effectue en migrant les données des tables distantes dans la base locale (remote join). Cette dernière technique adoptée par Oracle Database et PostGreSQL ne permet aucune optimisation.

1.9.2 – La notion de schéma SQL
À l’intérieur d’une base de données relationnelle on trouve des schéma SQL qui sont en fait des conteneurs logiques. Tout objet relationnel doit figurer dans un schéma et le nom complet d’un objet doit être préfixé par le nom du schéma SQL. Toutefois il existe systématiquement un schéma par défaut dans toutes les bases. De même il existe un schéma par défaut attribué pour chacun des utilisateurs SQL qui sont les entités de sécurité sous lesquelles naviguent les applications accédant à la base.

Il n’est pas possible de créer un objet relationnel hors d’un schéma SQL. En revanche certains objets non relationnels comme ceux permettant de gérer le stockage des données de la base ne peuvent être placés dans un schéma SQL.

Le concept de schéma est proche de celui de « bibliothèque » de code des langages procéduraux ou d’espace de noms des langages plus moderne comme C++, Java ou C#, à la différence près que l’on ne peut pas imbriquer les schémas SQL les uns dans les autres pour former une hiérarchie. En d’autres termes, il n’existe qu’un seul niveau de schéma SQL.

L’idée sous-jacente aux schémas SQL est de modulariser la base de données. Par exemple un ERP, souvent doté de plusieurs milliers de tables et vues, gagnera à voir ces objets répartis en différents schéma comme RH, COMPTA, MARKETING, VENTE, PRODUCTION… qui permet de présenter la base de données sous un aspect silo souvent utile à la mode actuelle des micro-services. Un autre découpage, souvent complémentaire, consiste à utiliser des schémas SQL transverses, notamment pour des données techniques ou référentielles. À titre d’exemple on pourra créer les schémas suivants : SYSTEME, META, REFERENTIEL, IMPEX, EXT… Ceci pour, respectivement, des tables d’utilisateurs, des dictionnaires de données, un référentiel interne, des tables tampon, les données d’un référentiel externe.
Enfin, il faut savoir que l’on peut affecter des permissions spécifiques aux schéma SQL ce qui permet une grande souplesse en plus de la modularité apportée naturellement par le découpage d’une base en de multiples schémas SQL.

Notez que certains schémas SQL sont fournis par les éditeurs. En principe on trouve dans toutes les bases le schéma SQL normatif INFORMATION_SCHEMA dans lequel sont implantées des vues présentant les métadonnées logiques de la base (tables, colonnes, contraintes…) et le schéma SQL « sys » dans lequel on trouve tous les objets systèmes propres à chaque éditeur de SGBD Relationnels.

ATTENTION

MySQL / MariaDB font confusion entre les notions de schéma SQL et de base de données, mélangeant allègrement ces différents concepts sans les apports normatifs nécessaire à la sécurité ou la modularité (les sauvegardes pouvant s’avérer inconsistantes)…

A +

[marietar]

Un schéma permet de gérer les droits des objets qui lui sont associés sans devoir le faire sur chaque objet.
Une même table peut se trouver dans plusieurs schémas, on peut très bien avoir des droits sur la table T1 du schéma S1 et des d'autres droits sur la même table T1 du schéma S2.

Attention toutefois : MySQL/MariaDB confondent schéma et database

Le schéma n'a aucun rapport avec le nom et le type des colonnes.

un objet c'ets une table?

[SQLpro]

Pas uniquement...

Un objet peut être une table, une vue, une fonction utilisateur (ou UDF pour User Defined Function), une procédure...

Il serait peut être temps d'apprendre le SQL !
Mon site web comme mes bouquins peuvent vous y aider https://sqlpro.developpez.com/

A +