MySQL dispose d'un ensemble de commandes qui permettent son adminsitration; Nous ne parlons pas des commandes (ou requêtes SQL - LMD et LDD) mais bien plus que cela.
Nous allons voir dans cet article quelques commandes que nous avons déjà exécutées pendant les démos du cours (ABD - 3L Informatique à l'Université de Jijel).
Il est possible d'utiliser un outil graphique pour manipuler MySQL; il permet de faire (pratiquement) tour ce que la ligne de commande permet de le faire. Une question reste à répondre : est ce que cet outil sera toujours disponible sur le serveur ? Et la réponse est : pas forcément ! C'est pour cela que l'apprentissage des commandes en mode console reste toujours important pour les administrateurs des bases des données.
Un outil graphique très connu est : MySQL Workbench. Avec ses fonctionnalités variées (il offre, même, la possibilité de concevoir un schéma en Entité/Association, c'est-à-dire de travailler sur un niveau conceptuel), il peut être très utile et très productif.
Nous allons "ignorer" cet outil pour le moment et se concentrer sur la ligne de commande. La commande que nous avons utilisée pour se connecter à MySQL est la suivante :
Nous avons passé trois paramètres (et ils ne sont pas les seuls que nous pouvons passer) :
-h localhost : pour dire que je vais me connecter sur la machine locale,
-u username : le nom d'utilisateur qui veut se connecter,
-p : pour dire que je vais me connecter par un mot de passe (il ne faut pas le saisir, MySQL va le demander après la validation de la commande).
Dans le cadre d'adminsitration, nous allons toujours nous connecter autant que super-utilisateur, autrement, les fonctionnalités avancées ne seront pas disponibles (ou visibles pour être plus précis).
Une deuxième commande très fréquente est la commande "source"
Cette commande permet d'exécuter un script SQL (plusieurs commandes SQL séparées par des point-virgules ";" dans un seul fichier). Généralement, il est préféré de créer votre script de création de la base des données (ou autre) dans un fichier séparé; il est très probable que la structure eds tables changent au cours du développement et cela vous évietra de réécrire à chaque fois les requêtes inchangées dans la console de MySQL.
Passons à des choses un peu plus difficiles :
Pour pouvoir analyser du près la couche "Analyseur" (présente sur le schéma d'exécution d'une requête de type LMD - voir ici) ainsi que la couche "Méta-base", il est possible de voir du plus près les bases dédiées à MySQL lui même sur un serveur donnée.
Comme nous avons vu (cours 4), un SGBD doit pouvoir gérer efficacement la structure de la base des données; il doit à chaque fois vérifier ce schéma pour analyser la sémantique d'une requête. Cette analyse vient après l'analyse syntaxe qui garantit que la requête respecte bien la syntaxe du langage SQL. L'analyse sémantique permet de garantir que la requête respecte le schéma de la base des données (nombre de colonne, ordre des colonnes) et de ses contraintes.
Comment implémente MySQL ce niveau ?
Comme expliqué sur le même document, nous avons dit qu'il est possible d'utiliser une base des données relationnelle pour stocker les schémas des autres bases des données; cette base aura comme schéma le méta-modèle des modèles Entité/Association. MySQL utilise cette approche pour garantir cette fonctionnalité.
Pour voir du plus près, nous allons utiliser les commandes suivantes :
show :
Databases : permet d'affciher la liste des bases des données sur le serveur,
Tables : permet d'afficher la liste des tables de la base des données en cours.
use : permet de spécifier la base des données en cours. Si aucune base des données n'est spécifiée, aucune requête SQL ne sera exécutée (sauf Create Database) et MySQL retourne un message d'erreur
describe : permet d'afficher la strcuture d'une table donnée.
La base des données utilisée par MySQL pour stocker les scéhma des autres bases des données est la base "information_schema", ainsi, nous commençons par la définir comme la base en cours :
Affichons la liste des tables :
Nous remarquons qu'il s'agit bien du méta-modèle du modèle Entité/Association avec des données nécessaires pour le moteur utilisé pour gérer les bases des données; dans cet exemple, il s'agit du moteur InnoDB.
Jettons un coup d'oeil sur la table Table; c'est la table qui contient les données sur les tables (évidemment).
Il est diffcile de visualiser toutes ces données, prennons une partie des colonnes et afficher la description des tables de la base des donnée ABD1 (c'est la base utilisée pour la plus part des démos, elle représente la solution du premier exercice de la première série, sa structure et ses données seront publiés dans un autre article) :
Sur cette base, nous avons quatres (04) tables; trois tables physiques et une table virtuelle (view). il est important de noter que la table virtuelle n'est associée à aucun moteur (d'où la valeur NULL).
Ainsi, la abse des données "information_schema" est une base des données relationnelle sur laquelle nous pouvons exécuter les différentes reuqêtes pour voir du plus près l'implémentation de MySQL de la couche "analyseur" (l'analyseur sémantique) et de sa méta-base.
Nous allons voir dans cet article quelques commandes que nous avons déjà exécutées pendant les démos du cours (ABD - 3L Informatique à l'Université de Jijel).
Il est possible d'utiliser un outil graphique pour manipuler MySQL; il permet de faire (pratiquement) tour ce que la ligne de commande permet de le faire. Une question reste à répondre : est ce que cet outil sera toujours disponible sur le serveur ? Et la réponse est : pas forcément ! C'est pour cela que l'apprentissage des commandes en mode console reste toujours important pour les administrateurs des bases des données.
Un outil graphique très connu est : MySQL Workbench. Avec ses fonctionnalités variées (il offre, même, la possibilité de concevoir un schéma en Entité/Association, c'est-à-dire de travailler sur un niveau conceptuel), il peut être très utile et très productif.
Nous allons "ignorer" cet outil pour le moment et se concentrer sur la ligne de commande. La commande que nous avons utilisée pour se connecter à MySQL est la suivante :
mysql -h localhost -u username -p
Nous avons passé trois paramètres (et ils ne sont pas les seuls que nous pouvons passer) :
-h localhost : pour dire que je vais me connecter sur la machine locale,
-u username : le nom d'utilisateur qui veut se connecter,
-p : pour dire que je vais me connecter par un mot de passe (il ne faut pas le saisir, MySQL va le demander après la validation de la commande).
Dans le cadre d'adminsitration, nous allons toujours nous connecter autant que super-utilisateur, autrement, les fonctionnalités avancées ne seront pas disponibles (ou visibles pour être plus précis).
Une deuxième commande très fréquente est la commande "source"
mysql> source CreerTable.sql;
Cette commande permet d'exécuter un script SQL (plusieurs commandes SQL séparées par des point-virgules ";" dans un seul fichier). Généralement, il est préféré de créer votre script de création de la base des données (ou autre) dans un fichier séparé; il est très probable que la structure eds tables changent au cours du développement et cela vous évietra de réécrire à chaque fois les requêtes inchangées dans la console de MySQL.
Passons à des choses un peu plus difficiles :
Pour pouvoir analyser du près la couche "Analyseur" (présente sur le schéma d'exécution d'une requête de type LMD - voir ici) ainsi que la couche "Méta-base", il est possible de voir du plus près les bases dédiées à MySQL lui même sur un serveur donnée.
Comme nous avons vu (cours 4), un SGBD doit pouvoir gérer efficacement la structure de la base des données; il doit à chaque fois vérifier ce schéma pour analyser la sémantique d'une requête. Cette analyse vient après l'analyse syntaxe qui garantit que la requête respecte bien la syntaxe du langage SQL. L'analyse sémantique permet de garantir que la requête respecte le schéma de la base des données (nombre de colonne, ordre des colonnes) et de ses contraintes.
Comment implémente MySQL ce niveau ?
Comme expliqué sur le même document, nous avons dit qu'il est possible d'utiliser une base des données relationnelle pour stocker les schémas des autres bases des données; cette base aura comme schéma le méta-modèle des modèles Entité/Association. MySQL utilise cette approche pour garantir cette fonctionnalité.
Pour voir du plus près, nous allons utiliser les commandes suivantes :
show :
Databases : permet d'affciher la liste des bases des données sur le serveur,
Tables : permet d'afficher la liste des tables de la base des données en cours.
use : permet de spécifier la base des données en cours. Si aucune base des données n'est spécifiée, aucune requête SQL ne sera exécutée (sauf Create Database) et MySQL retourne un message d'erreur
mysql> use ABD1;
describe : permet d'afficher la strcuture d'une table donnée.
La base des données utilisée par MySQL pour stocker les scéhma des autres bases des données est la base "information_schema", ainsi, nous commençons par la définir comme la base en cours :
mysql> show databases; +--------------------+ | Database | +--------------------+ | information_schema | | ABD1 | | ABD2 | | basedeteste | | moodle | | mysql | | performance_schema | | test | +--------------------+ 8 rows in set (0.00 sec) mysql> use information_schema Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql>
Affichons la liste des tables :
mysql> show Tables; +---------------------------------------+ | Tables_in_information_schema | +---------------------------------------+ | CHARACTER_SETS | | COLLATIONS | | COLLATION_CHARACTER_SET_APPLICABILITY | | COLUMNS | | COLUMN_PRIVILEGES | | ENGINES | | EVENTS | | FILES | | GLOBAL_STATUS | | GLOBAL_VARIABLES | | KEY_COLUMN_USAGE | | PARAMETERS | | PARTITIONS | | PLUGINS | | PROCESSLIST | | PROFILING | | REFERENTIAL_CONSTRAINTS | | ROUTINES | | SCHEMATA | | SCHEMA_PRIVILEGES | | SESSION_STATUS | | SESSION_VARIABLES | | STATISTICS | | TABLES | | TABLESPACES | | TABLE_CONSTRAINTS | | TABLE_PRIVILEGES | | TRIGGERS | | USER_PRIVILEGES | | VIEWS | | INNODB_BUFFER_PAGE | | INNODB_TRX | | INNODB_BUFFER_POOL_STATS | | INNODB_LOCK_WAITS | | INNODB_CMPMEM | | INNODB_CMP | | INNODB_LOCKS | | INNODB_CMPMEM_RESET | | INNODB_CMP_RESET | | INNODB_BUFFER_PAGE_LRU | +---------------------------------------+ 40 rows in set (0.00 sec) mysql>
Nous remarquons qu'il s'agit bien du méta-modèle du modèle Entité/Association avec des données nécessaires pour le moteur utilisé pour gérer les bases des données; dans cet exemple, il s'agit du moteur InnoDB.
Jettons un coup d'oeil sur la table Table; c'est la table qui contient les données sur les tables (évidemment).
mysql> describe Tables; +-----------------+---------------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +-----------------+---------------------+------+-----+---------+-------+ | TABLE_CATALOG | varchar(512) | NO | | | | | TABLE_SCHEMA | varchar(64) | NO | | | | | TABLE_NAME | varchar(64) | NO | | | | | TABLE_TYPE | varchar(64) | NO | | | | | ENGINE | varchar(64) | YES | | NULL | | | VERSION | bigint(21) unsigned | YES | | NULL | | | ROW_FORMAT | varchar(10) | YES | | NULL | | | TABLE_ROWS | bigint(21) unsigned | YES | | NULL | | | AVG_ROW_LENGTH | bigint(21) unsigned | YES | | NULL | | | DATA_LENGTH | bigint(21) unsigned | YES | | NULL | | | MAX_DATA_LENGTH | bigint(21) unsigned | YES | | NULL | | | INDEX_LENGTH | bigint(21) unsigned | YES | | NULL | | | DATA_FREE | bigint(21) unsigned | YES | | NULL | | | AUTO_INCREMENT | bigint(21) unsigned | YES | | NULL | | | CREATE_TIME | datetime | YES | | NULL | | | UPDATE_TIME | datetime | YES | | NULL | | | CHECK_TIME | datetime | YES | | NULL | | | TABLE_COLLATION | varchar(32) | YES | | NULL | | | CHECKSUM | bigint(21) unsigned | YES | | NULL | | | CREATE_OPTIONS | varchar(255) | YES | | NULL | | | TABLE_COMMENT | varchar(2048) | NO | | | | +-----------------+---------------------+------+-----+---------+-------+ 21 rows in set (0.01 sec) mysql>
Il est diffcile de visualiser toutes ces données, prennons une partie des colonnes et afficher la description des tables de la base des donnée ABD1 (c'est la base utilisée pour la plus part des démos, elle représente la solution du premier exercice de la première série, sa structure et ses données seront publiés dans un autre article) :
mysql> Select TABLE_CATALOG, TABLE_NAME, TABLE_TYPE, ENGINE
-> from Tables
-> Where TABLE_SCHEMA = 'ABD1';
+---------------+-------------+------------+--------+
| TABLE_CATALOG | TABLE_NAME | TABLE_TYPE | ENGINE |
+---------------+-------------+------------+--------+
| def | Course | BASE TABLE | InnoDB |
| def | CourseJijel | VIEW | NULL |
| def | Cycliste | BASE TABLE | InnoDB |
| def | Performance | BASE TABLE | InnoDB |
+---------------+-------------+------------+--------+
4 rows in set (0.00 sec)
mysql>
Sur cette base, nous avons quatres (04) tables; trois tables physiques et une table virtuelle (view). il est important de noter que la table virtuelle n'est associée à aucun moteur (d'où la valeur NULL).
Ainsi, la abse des données "information_schema" est une base des données relationnelle sur laquelle nous pouvons exécuter les différentes reuqêtes pour voir du plus près l'implémentation de MySQL de la couche "analyseur" (l'analyseur sémantique) et de sa méta-base.
