Discussion :

[scamphp]

Bonjour, j’utilise comme beaucoup Mysql ou Autre... parce que c'est comme ça.

Wordpress utilise un système de base de donnée... tous les Tutos sur la création de site de A à Z utilisent des bases de donnée...

On l'utilise sans se poser de question (je parle pour le personnes qui bricole comme moi, pas pour les pro de la programmation)...

Une base de donnée c'est bien, c'est pratique, c'est rapide, cela gère les accès concurrentiel et l'intégrité des transactions...

OK OK, je ne doute pas des avantages...

MAIS en réalité c'est quoi la face caché d'un système de base de donnée.

Quand j'enregistre une info dans un fichier c'est simple a comprendre (visualiser). L'info est dans un fichier sur mon disque dur rangé dans des dossiers.

C'est d’ailleurs le point de départ des systèmes de base donnée, si je ne ma trompe pas -> base de donnée hiérarchique (IBM). J'ai un peu lu avant de poser ma question lol

Mais dans une base de donnée (Moderne), les infos sont stockés comment ?

Pourquoi une recherche dans une base de donnée est-elle plus rapide que dans des fichiers... elle doit bien stocker aussi dans des fichiers ?

Pourquoi certains préconisent de mettre les pages en CACHE... si au final les bases de données sont plus rapide... car le Cache au final c'est bien lire un fichier (on utilise une BD pour ne pas utiliser les fichiers et au final on utilise un fichier).

Voila je voulais essayer de de comprendre la face caché des SGBD, pour ne pas juste utiliser bêtement... mais comprendre le mécanisme.

Explication pour un niveau débutant

[Michel.Priori]

Vaste question que celle posée en titre.
Ce sont ces questions qui paraissent naïves mais qui au final mettent mal à l'aise.
C'est un peu comme poser la question "mais au juste c'est quoi un arbre ?"

Attends toi à avoir des réponses aussi diverses que variées en fonction de la compétence du rédacteur.
Ceci dit, je n'aurais pas posté dans la rubrique "Décision SGDB" qui est elle même une spécialité des SGBD.

Voici ma réponse :
Pour ce qui est des sgbd-R, le modèle de stockage le plus répendu repose sur les caractéristiques des disques durs magnétiques versus la mémoire.
Vu la relative lenteur des disques magnétiques, le stockage est organisé en page ou bloc dans lesquels on trouve des lignes d'une même table.
Ces pages sont stockées dans des fichiers.
L'adéquation entre les fichiers, la collection de page et les tables dépendent des fabricants. Pour Oracle et SQL server il existe la notion de table-space ou de groupe de fichiers, 2 vocable pour la même notion. Chez InnoDb l'ensemble des pages sont soit groupées dans un même fichier soit dissociées à raison de 1 fichier par table.
L'idée de cette complication est de répondre au besoin de besoin d'espace de stockage "infini".

Je m’arrête là.
Il y a encore beaucoup de choses à dire

[escartefigue]

Bonjour Scamphp

Tout d'abord, c'est plutôt un SGBD qu'une, puisque le sigle signifie Système de Gestion de Base de Données, un système donc

C'est d’ailleurs le point de départ des systèmes de base donnée, si je ne ma trompe pas -> base de donnée hiérarchique (IBM). J'ai un peu lu avant de poser ma question lol

D'autres éditeurs qu'IBM ont proposé des bases hiérarchiques et IBM propose depuis longtemps, avec DB2, des SGBD relationnels
Des SGBD-R car les différentes variantes de DB2 - Z/OS, Sytem-I, Windows et Linux - sont significativement différentes l'une de l'autre

Mais dans une base de donnée (Moderne), les infos sont stockés comment ?

La réponse dépend du SGBD et de l'OS sous-jacent.
Par exemple, avec DB2 for Z/OS, les données sont organisées en pages stockées dans des tablesspace qui peuvent être mono-table ou multi-table, certaines tables ayant plusieurs tablespaces. Selon les options de paramétrage, les colonnes de la table ne sont pas stockées dans l'ordre selon lequel elles sont décrites, par exemple, on peut décider, pour des raisons de performances, de déplacer les colonnes de type varchar (ou nvarchar) à la fin. Les tablesspaces sont attachés à des bufferpool ce qui permet d'associer une tablespace à un pool de disques particulier.
Pour les index également, l'organisation et le fonctionnement dépendent du SGBD.
Il existe des index BTree, Rtree, Hash... tous les types ne sont pas suportés pour tous les SGBDR
De plus certains SGBD requièrent obligatoirement de lire l'index cluster, tous les autres index utilisant cet index cluster (c'est le cas par exemple de SQL Server ou MySQL).

Pourquoi une recherche dans une base de donnée est-elle plus rapide que dans des fichiers... elle doit bien stocker aussi dans des fichiers ?

Parceque le moteur du SGBDR dispose d'un optimiseur dont le rôle est justement d'optimiser les recherches.
Plus la recherche est complexe, plus le gain lié à l'utilisation d'un SGBD-R est important, sous réserve toutefois que la modélisation du SGBD ait été faite dans les règles de l'art et que la requete soit écrite correctement

Pourquoi certains préconisent de mettre les pages en CACHE... si au final les bases de données sont plus rapide... car le Cache au final c'est bien lire un fichier (on utilise une BD pour ne pas utiliser les fichiers et au final on utilise un fichier).

L'intérêt du cache est de limiter les relectures des mêmes espaces disques, mais n'évite évidemment pas de les lire au moins une fois
Une fois les données stockées dans le cache (c'est à dire en RAM) il n'est plus nécessaire d'accéder aux disques

[scamphp]

A*

L'intérêt du cache est de limiter les relectures des mêmes espaces disques, mais n'évite évidemment pas de les lire au moins une fois
Une fois les données stockées dans le cache (c'est à dire en RAM) il n'est plus nécessaire d'accéder aux disques

Quand vous dites dans le CACHE c'est dans le Cache -> la RAM ?

Souvent sur les tutos, on propose de créer une page type HTML servant de Cache, (mais cette page n'est pas dans la RAM, mais bien sur le disque Dur...).
*
B

Vu la relative lenteur des disques magnétiques, le stockage est organisé en page ou bloc dans lesquels on trouve des lignes d'une même table.

Cela veut-il dire qu'avec les disque SSD (montage en RAID) l'organisation en page ou bloc n'a plus trop de sens ?

C* Une tablespace c'est une segmentation du disque de stockage pour éviter la fragmentation des fichiers un peut partout dans le disque ?

D*

Selon les options de paramétrage, les colonnes de la table ne sont pas stockées dans l'ordre selon lequel elles sont décrites, par exemple, on peut décider, pour des raisons de performances, de déplacer les colonnes de type varchar (ou nvarchar) à la fin.

cela ressemble a quoi un fichier de stockage:
enregistrement1; enregistrement2; enregistrement3;
Comme un fichier log ou CSV

[escartefigue]

A* Quand vous dites dans le CACHE c'est dans le Cache -> la RAM ?

Oui

B* Cela veut-il dire qu'avec les disque SSD (montage en RAID) l'organisation en page ou bloc n'a plus trop de sens ?

L'organisation en pages est indépendante du type de disque. Certains SGBD ne connaissent pas la maille "page" mais seulement la maille "table" et "ligne" (ex : MySQL)
L'intérêt de la maille "page" est de permettre un verrouillage plus optimisé (moins de verrou qu'avec le niveau ligne et verrouillage moins catégorique que le niveau table)

C* Une tablespace c'est une segmentation du disque de stockage pour éviter la fragmentation des fichiers un peut partout dans le disque ?

Le tablespace c'est le ou les fichier(s) qui contien(en)t les données de la table. La table n'est qu'une structure, un masque décrivant les colonnes, le tablespace c'est le contenu, les lignes de cette table.

D* cela ressemble a quoi un fichier de stockage:
enregistrement1; enregistrement2; enregistrement3;
Comme un fichier log ou CSV

Tout dépend du SGBD, mais d'une part, la notion "d'enregistrement n" n'a pas vraiment de sens, puisque en environnement multi-utilisateur et multi-threads, l'ordre selon lequel les lignes (plutôt que enregistrements) sont insérées n'est pas connu de l'utilisateur. C'est le SGBD qui gère. D'autre part, la position relative des lignes dans le table space n'est pas immuable dans le temps. Un simple update peut provoquer un déplacement de certaines lignes, de même avec une réorg.
D'où l'importance de la clause ORDER BY dans les requêtes quand une séquence particulière est requise !

[scamphp]

Bon la maille "table" et "ligne"...

Dans GG j'ai de superbes tables en ferronnerie avec grande ou petite maille... Il n'y a que maille qui maille

Une petite explication (niveau enfant de 14 ans... enfant normal... pas un génie)... du concept de maille page, maille table et maille ligne

Juste pour comprendre les notions...

[SQLpro]

Je n'ai pas lu les réponses de mes confrères pour vous répondre afin de ne pas être influencé par les réponses précédentes...

...
Mais dans une base de donnée (Moderne), les infos sont stockés comment ?

Au gré de l'éditeur, dans des pages (unité logique de stockage d'un même dimension, par exemple 8Ko) puis dans des "blocs" (série de n pages contiguës, constituant une unité physique de stockage, par exemple 8 pages de 8 Ko = 64 Ko), le tout rangé dans un "storage", pour les SGBDR bas de gamme comme PostGreSQL ou MySQL dans un répertoire du file système et pour les "grands" SGBDR dans un seul et même fichier ou plusieurs (pour faire du parallélisme d'accès - Oracle, SQL Server - et aussi afin d'accélérer les accès systèmes aux fichiers). Ceci concernant aussi bien les données des tables que les index...
Et dans les bon SGBDR (Oracle, SQL Server), les lignes des tables étant elles aussi organisées de manière a accélérer certaines recherches. par exemple en groupant toutes les données fixes en tête de ligne....

Pourquoi une recherche dans une base de donnée est-elle plus rapide que dans des fichiers... elle doit bien stocker aussi dans des fichiers ?

Pour 3 raisons au moins :
1) le SGBDR met en mémoire toutes les données des tables et index et travaille exclusivement en mémoire
2) la création d'index accélère certaines recherches
3) l'optimiseur choisit soit la table soit un index en fonction de la requête en estimant la meilleure des solutions compte tenue de la nature de la demande... C'est le plan de requête (comment le SGBDR va exécuter la demande)

Pourquoi certains préconisent de mettre les pages en CACHE... si au final les bases de données sont plus rapide... car le Cache au final c'est bien lire un fichier (on utilise une BD pour ne pas utiliser les fichiers et au final on utilise un fichier).

Ceci n'a aucun intérêt car le SGBDR met lui même tout ce qu'il a besoin en cache et le gère dynamiquement. Dans les grands SGBDR (Oracle, SQL Server) il ne met pas seulement les données en cache mais aussi :
1) les plans de requête
2) les données systèmes (métadonnées)
3) des statistiques sur sa propre exécution, afin de s'auto-corriger et fournir un diagnostic pour les DBA.

Voila je voulais essayer de de comprendre la face caché des SGBD, pour ne pas juste utiliser bêtement... mais comprendre le mécanisme.

Explication pour un niveau débutant

Une autre des forces des SGBDR sont les contraintes qui permettent de contrôler et l'intégrité, et la qualité des données. Ces contraintes servant dans les grands SGBDR (oracle, SQL Server) à optimiser encore plus l'exécution des requêtes.
Un seul petit exemple, "trouvez les produits en vente dont le prix est négatif". Une telle requête effectuée sur un fichier nécessite de parcourir tous les enregistrements des fichiers et finira par ne rien renvoyer (enfin espérons le, sauf erreur de saisie...); Dans un SGBDR, avec une contrainte CHECK(PRIX >=0), il n'y aura jamais de prix négatif et l'optimiseur, va immédiatement renvoyer un dataset vide sans lire la table...

A +

[SQLpro]

L'organisation en pages est indépendante du type de disque. Certains SGBD ne connaissent pas la maille "page" mais seulement la maille "table" et "ligne" (ex : MySQL)

Pour une fois je vais défendre MySQmerde, mais depuis quelques versions il connait le niveau page avec des pages de 8 ou 16 ko....

A +

[SQLpro]

A*

Quand vous dites dans le CACHE c'est dans le Cache -> la RAM ?

Cache = RAM oui.... Mais parfois il existe des SGBDR qui ont des caches de second niveau, pas exemple sur des SSD en montage PCI...

Souvent sur les tutos, on propose de créer une page type HTML servant de Cache, (mais cette page n'est pas dans la RAM, mais bien sur le disque Dur...).
*
B
Cela veut-il dire qu'avec les disque SSD (montage en RAID) l'organisation en page ou bloc n'a plus trop de sens ?

Ho que si, le stockage en SSD ne change pas la méthode d'accès ni la granularité de verrouillage !

C* Une tablespace c'est une segmentation du disque de stockage pour éviter la fragmentation des fichiers un peut partout dans le disque ?

Non, c'est un storage sous la responsabilité du SGBDR (dans les grand SGBDR (Oracle, SQL Server) sinon pour les "free" c'est juste un répertoire...

D* cela ressemble a quoi un fichier de stockage:
enregistrement1; enregistrement2; enregistrement3;
Comme un fichier log ou CSV

Pas tout à fait....

A +

[escartefigue]

Bon la maille "table" et "ligne"...

Dans GG j'ai de superbes tables en ferronnerie avec grande ou petite maille... Il n'y a que maille qui maille

Une petite explication (niveau enfant de 14 ans... enfant normal... pas un génie)... du concept de maille page, maille table et maille ligne

Juste pour comprendre les notions...

Si le traitement T1 pose un verrou de niveau table : toute la table est verrouillée.

- Si ce verrou est de type mise à jour alors aucun autre traitement ne peut accéder à la table, ni en lecture*, ni en mise à jour, même si ces autres traitements accèdent à des lignes qui ne sont pas en cours de traitement dans T1.
- Si ce verrou est de type lecture, alors seuls les traitements qui veulent lire la table peuvent y accéder, les autres ne le peuvent pas, là encore, même si les lignes accédées par ces autres traitements sont sans rapport avec celles traitées dans T1

Si le traitement T1 pose un verrou de niveau ligne : seule la ligne en cours de traitement est verrouillée, les traitements concurrents peuvent accéder aux autres lignes*, en lecture comme en mise à jour.

Une page selon sa taille et la taille de chaque ligne contient un certain nombre de lignes, par exemple, une page de 4k contient en théorie 40 lignes de 100 octets, en réalité ce seront 39 ou 38 lignes car quelques octets techniques sont nécessaires à la gestion de chaque page et chaque ligne dans la page. Donc, dans cet exemple, un verrou en lecture de niveau page dans T1 bloquera l'accès en mise à jour aux autres traitements pour une petite quarantaine de lignes.

Un verrou de niveau ligne est en général la bonne solution pour un traitement unitaire, type TP.
Un verrou de niveau page est la bonne taille pour les traitements par lots
Les verrou de niveau table et tablespace sont utilisés dans des cas particuliers où l'on souhaite interdire tout accès pendant le traitement et/ou éviter le phénomène de "lock escalation"

* c'est en réalité plus compliqué que ça : le niveau d'isolation de chaque transaction et la mise en oeuvre des commits entrent également en jeu

[scamphp]

WAOUW c'est toujours un régal de vous lire. Je suis comme un enfant dans un magasin de jeux... Car je ne viens pas du monde de l'informatique...

Je me pose beaucoup de questions... mais je n'ai pas la compétence pour avoir les réponses.

Simple utilisateur Wordpress -> j'ai appris HTML -> puis PHP -> Programmation Orienté Objet

Puis sur le forum j'avais posé des questions sur les Bases de Donnée -> J'ai découvert (grâce à vous) La modélisation des bases de données (j'ai même acheté le livre de Ch SOUTOU avec les coups de gueule de SQLPRo).

Actuellement je découvre le monde de linux -> qui m'ouvre les portes des Arduino (du coup je me mets un peu à l'électronique) et je regarde un peu vers python.

Après quelques installations et test d'apache (et nginx) sur petit serveur perso pour voir comment cela marche...

Forcement vient le moment de se pencher sur les système de gestion des bases de sonnées.

Et comme a mon habitue toute une série de questions (mais avec un niveau faible de connaissances).


Juste pour resituer le contexte, je suis urbaniste et j'ai 43 ans -> donc un pas tout jeune qui aime chercher à comprend pas pour faire un truc de fou, mais juste pour le plaisir personnel...

Pour bien comprendre j'ai toujours besoins d'image... de procédures.... (Oué mon Cerveau est plus procédural que Objet lol, normal c'est un ancien modèle).


Dans la PROCEDURE ETAPE 1 : J'installe un SGDB sur mon ordi (sachant que je n'ai pas encore créé ma 1er base de donnée)

[SQLpro]

Il y a de nombreux autres services que doivent assurer un bon SGBDR :

1) la sauvegarde et la restauration.
Le système doit pouvoir générer une sauvegarde, alors même que de nombreux utilisateurs travaillent, c'est à dire sans bloquer les utilisateurs ou se faire bloquer par eux. Ceci n'est pas possible dans certains SGBDR mal conçus comme MySQL. Dans certains SGBDR haut de gamme il est possible de faire de la restauration "online", c'est a dire pendant que les utilisateurs travaillent....

2 - la gestion des accès
Bien plus complexes que de simples "droits" sur les fichier il s'agit de permettre d'exécuter certaines commandes (CREATE, ALTER, DROP, SELECT, INSERT, UPDATE, DELETE....) sur certains objets, voire même partiellement (filtrage de colonnes).

3 - gestion de la concurrence
Le SGBDR doit pouvoir accepter la lecture concurrente (sur les mêmes objets) par de multiples utilisateurs simultanés, comme l'écriture et fournir un mécanisme de protection pour gérer les transactions.

4 - la haute disponibilité
Il s'agit de permettre de basculer sur un serveur de secours (soit manuellement, soit sur les grands SGBDR de manière automatique) qui possède une copie synchrone des données originales.

5 - la maintenance
Parce que les structures de stockage se fragmentent ou peuvent être corrompues, permettre leurs vérification (intégrité physique) comme leurs réorganisation par reconstruction ou leur défragmentation.

6 - le diagnostic
Pour pouvoir garantir les performances tout au long de la vie de la base, il faut pouvoir diagnostiquer les requêtes couteuses afin de permettre leur réécriture, mais aussi savoir quels index doivent être rajoutés ou supprimés. par exemple, dans SQL Server, le SGBD est capable de donner la liste des index à créer pour rendre la base globalement plus performante.

Ce ne sont que quelques unes des fonctionnalités nécessaires à un bon SGBDR !

A +

[scamphp]

ETAPE 1 : J'installe un SGDB sur mon ordi (sachant que je n'ai pas encore créé ma 1er base de donnée)

et là, il se passe quoi concrètement -> je suppose qu'il installe des bibliothèques de fonction (les fameuses fonctions -> langage SQL).
Il doit peut être créer des trucs sur le disque dur (organisation de dossiers...).

Cette étape est intéressent a comprendre car c'est elle qui plante le décors...

[SQLpro]

Juste pour resituer le contexte, je suis urbaniste et j'ai 43 ans -> donc un pas tout jeune qui aime chercher à comprend pas pour faire un truc de fou, mais juste pour le plaisir personnel...

J'ai toujours constaté que les informaticiens autodidactes, comme ceux ayant fait plusieurs métiers avant de sombrer dans l'informatique, faisaient des informaticiens bien plus brillant que ceux qui n'avaient jamais nagé que dans le code.... Question d'ouverture d'esprit sans doute, mais aussi de curiosité ! Donc, bienvenue... malgré mes coups de gueule !!!

Pour bien comprendre j'ai toujours besoins d'image... de procédures.... (Oué mon Cerveau est plus procédural que Objet lol, normal c'est un ancien modèle).

Dans la PROCEDURE ETAPE 1 : J'installe un SGDB sur mon ordi (sachant que je n'ai pas encore créé ma 1er base de donnée)

et là, il se passe quoi concrètement -> je suppose qu'il installe des bibliothèques de fonction (les fameuses fonctions -> langage SQL).
Il doit peut être créer des trucs sur le disque dur (organisation de dossiers...).

Cette étape est intéressent a comprendre car c'est elle qui plante le décors...

En fait, lors de l'installation, il place un gros fichier exécutable qui tourne comme un service, c'est à dire que le SGBDR est à l'écoute des demandes (requêtes SQL) des utilisateurs, de la même manière qu'un serveur Web est à l'écoute des demandes (requêtes URL)...

Autour de cela de nombreuses bibliothèques (dll) et de nombreux outils périphériques sont installées.....

A +

[scamphp]

HA ben ça au moins cela me parle... c'est clair... merci. Curieux oui, mais c'est normal l'approche n'est pas la même, souvent à l'école, il y a des choses qui nous intéresse et d'autres que l'on apprend (ou pas) parce que cela fait parti du programme... alors que moi, je suis en demande, pas par obligation, mais tout simplement par envi... Mais la formation à l'école (m^me si on n'écoute pas tout) donne des bases solide, une connaissance solide généraliste et un environnement (collègues avec les mêmes centres d’intérêt avec qui on peut échanger) que je n'ai pas.

Etape 2... avec mes petits doigts... et PHP (via commandes SQL) (ou PhpMyAdmin), je vais créer ma base de donnée

CREATE DATABASE nom_base;

Et la magie, il se passe quoi... le SGBDR à l'écoute des requêtes SQL exécute quoi... il va créer quoi avec aussi peut d'info... (juste un dossier et peut-être un fichier du nom de la base de donnée).

[SQLpro]

il va créer quoi avec aussi peut d'info... (juste un dossier et peut-être un fichier du nom de la base de donnée).

Avec MySQL c'est exactement ce qui se passe....

Avec d'autres SGBD c'est plus sophistiqué pour des raisons de performances......

A +

[scamphp]

Cool j'aurais pu inventer Mysql avec mon niveau lol

Avec d'autres SGBD c'est plus sophistiqué pour des raisons de performances...

Sans rentrer dans des détails techniques de fou... ils font quoi de plus... et dans quel état d'esprit ; philosophie ; concept (pour être plus performant)

[SQLpro]

Cool j'aurais pu inventer Mysql avec mon niveau lol
Sans rentrer dans des détails techniques de fou... ils font quoi de plus... et dans quel état d'esprit (pour être plus performant)

Dans MySQL (comme dans PostGreSQL et Oracle) il n'y a qu'un seul journal de transaction, partagé par toutes les bases...
Dans SQL Server le CREATE DATABASE entraine la création d'un journal de transaction propre à la base. Ceci permet d'augmenter le débit transactionnel de manière très significative lorsqu'il y a plusieurs bases dans la même instance.

Dans MySQL comme il n'y a pas de catalogue système interne au serveur, le répertoire créé pour la base, appartient au compte système du service MySQL, ce qui constitue un trou de sécurité, surtout si le compte est "root" comme 99% des installations MySQL sous Linux...
Dans SQL Server, le compte de connexion au serveur SQL sert de propriétaire à la base lors de la création. Comme c'est un compte interne au serveur SQL et non un compte de service système, on peut à tout moment désactiver ce compte ou changer le propriétaire...

Dans SQL Server, la création d'une base se traduit par l'ajout de données dans diverses tables systèmes (le fameux catalogue) afin de lister les bases existantes, et ce afin de savoir quelles sont les bases. Par exemple en cas de disparition des disques sur laquelle les bases sont stockées le moteur le sait. Dans MySQL il n'y a pas de catalogue système, tant est si bien qu'en cas de perte du répertoire créé pour la base, MySQL ne sait pas que la base avait existé !!!!!

Dans SQL Server, ce sont des fichiers qui sont créés (ce ne sont pas des répertoires), mais ils correspondent grosso modo à des disques virtuels. Ils sont formatés afin de recevoir les données et les transactions, et ce afin d'accélérer les écritures. On peut aussi les dimensionner préventivement à une taille réaliste qui sera celle de la base après 3 à 5 ans d'activité par exemple. Grace à cela on :

• évite les opérations de croissances des fichiers intervenant en pleine production, qui sont chronophage
• permet de ne pas fragmenter les fichiers (et donc effectuer des lectures en continuité - lectures anticipées)
• permet de stocker les fichiers en choisissant les endroits les plus "confortables" sur les disques (bords externe sur les disques magnétiques)
• peut créer plusieurs fichiers de données pour une même base sur différents disques afin de paralléliser les accès (équipartition des données entre différents fichiers)
• passer certains fichiers spécifique en mode READ ONLY, après les avoir alimentés, afin de ne plus se poser la question du verrouillage

Il y aurait bien d'autres choses à dire.....

A +

[fsmrel]

Voila je voulais essayer de comprendre la face cachée des SGBD, pour ne pas juste utiliser bêtement... mais comprendre le mécanisme.

Pour comprendre le mécanisme de ce qui est caché derrière le rideau, c’est comme pour tout, il faut y consacrer un minimum de temps...

Extrait du cours (étalé sur une semaine) que je donnais à l’époque, voici le MCD de DB2 version 2, datant de 1988... Au début du cours, les élèves avaient une vague notion de ce qu’est une table, ils n’avaient aucune idée de ce qu’est une base de données ; quant aux autres concepts n’en parlons évidemment pas. Néanmoins, à la fin de la semaine ils étaient capables de s’exprimer sur chaque terme, et plein d’autres concepts ne figurant pas ici.

Si vous vous plongiez dans SQL Server 2014 de F. Brouard, C. Soutou, N. Souquet et D Barbarin, à votre tour vous pourriez ensuite expliquer aux autres ce qu’est un SGBD/R.

En attendant, pour être très bref, un SGBD (système de gestion de bases de données) est un logiciel qui gère tous les accès à une base de données ou à un ensemble de bases de données. En particulier, un SGBD relationnel peut être perçu, voire défini, comme une implémentation du Modèle Relationnel de Données (défini par Codd à partir de 1969).

Les programmes ne voient que des tables (sans avoir à faire la différence entre table de base et table dérivée (vue). En conséquence, le SGBD nous propose un ensemble d’opérateurs pour manipuler ces tables, et nous permet de déclarer des contraintes pour en garantir l’intégrité.

Les administrateurs des bases de données (les DBA) en savent évidemment beaucoup plus. Ils définissent les objets physiques permettant d’héberger les tables et de booster les performance du système (rôle décisif des fameux index). Ils passent du temps à observer les tables de la métabase (le catalogue relationnel), lesquelles les renseignent en statistiques sur, par exemple, la volumétrie de nos tables, leur état de désorganisation, ce qui permet au DBA de décider de la réorganisation des données quand ils intuitent que les performances vont commencer à se dégrader. Le SGBD (qu’il soit relationnel, hiérarchique, réseau, liste inverse, j’en passe et des meilleurs) permet de définir les classes d’accès aux données selon le profil des (groupes d’) utilisateurs ; le SGBD fournit au DBA la panoplie des utilitaires permettant de sauvegarder, réorganiser les données ; le SGBD contrôle la concurrence des accès aux données et plus généralement garantit l’«acidité» des transactions : je vous renvoie à ce sujet à la page 810 de l’ouvrage déjà cité, SQL Server 2014 et pour qu’il n’y ait pas de jaloux, je vous renvoie aussi à la page 485 de An Introduction to Database Systems, Eighth Edition de Chris Date.

Potassez bien !