Prise en main de HeidiSQL

Comme nous l'avons dit au chapitre précédent, HeidiSQL est un logiciel permettant de gérer l'accès à différentes bases de données dont MySQL et donc aussi MariaDB. du fait de l'interopérabilité quasi-totale entre ces deux bases de données.

Au lancement de HeidiSQL, on a une fenêtre intitulée Gestionnaire de sessions :

La partie gauche présente les différentes sessions déjà définies, la partie droite présente le détail de la session courante, celle sélectionnée dans la partie gauche.

La première fois, il faut créer une session en renseignant en partie droite :

• le type de réseau : sélectionnez la première option MySQL (TCP/IP)
• le nom ou l'adresse IP de l'hôte, c'est à dire la machine sur laquelle s'exécute le serveur de données MariaDB
• renseignez le code utilisateur et le mot de passe associé. La première fois, vous utilisez le code root avec le mot de passe choisi lors de l'installation du serveur MariaDB. Vous pouvez opter également pour une approche plus sécurisée en cochant la case Demander les identifiants. Dans ce cas, il vous faudra saisir le code utilisateur et le mot de passe à chaque ouverture de cette session dans HeidiSQL.
  Notez que l'option Utiliser l'identification Windows ne fonctionne qu'avec une base de données Microsoft SQL Server. Elle ne peut pas être utilisée pour une base MySQL.
• Pour plus de clarté, vous pouvez renommer la session dans la partie gauche de la fenêtre, par un clic droit puis option Rename dans le menu contextuel.
• Une fois la session définie, cliquez sur le bouton Ouvrir pour ouvrir une session sur le serveur MariaDB.

Création de la base de données

La fenêtre principale de HeidiSQL se présente ainsi :

La liste des base de données accessibles sur le serveur MariaDB auquel on est connecté apparaît en partie gauche.

Pour en créer une nouvelle, faites un clic droit sur la racine de l'arborescence (le nom du serveur de données), puis sélectionnez l'option Créer un(e) nouveau(el/elle)/Base de données dans le menu contextuel.

Vous obtenez la fenêtre ci-dessous où il vous faut simplement renseigner le nom souhaité pour la base de données. Nous conseillons d'utiliser le nom EntrepotLD :

Validez par OK.

C'est tout ce qu'il y a à faire à ce stade.

En effet, la création des tables au sein de la base de données se fera au travers du logiciel LDETLFB, comme cela est décrit au chapitre suivant

Notez toutefois que HeidiSQL peut être utilisé à tout moment pour consulter les données présentes dans la base. Mais il y a un pré-requis important : il faut maîtriser le langage SQL, seule interface reconnue ici.

Pour en savoir plus, reportez-vous si nécessaire à l'aide proposée dans HeidiSQL (disponible uniquement en anglais malheureusement).

Gestion des droits d'accès

On a vu plus haut que l'accès par défaut au serveur de données se faisait avec le profil root.

Par mesure de sécurité, il est préférable de ne pas diffuser le mot de passe associé à ce profil root, qui pourrait alors être remplacé par mégarde, avec le risque de perte associé.

Nous conseillons donc de créer un autre utilisateur, nommé par exemple ld. Et c'est avec ce code utilisateur ld que l'on accédera à l'entrepôt de données, que ce soit depuis LDETLFB ou le composant Get and Transform d'Excel.

Pour cela, depuis HeidiSQL, lancez l'option Outils/Gestionnaire utilisateur. Cliquez sur le bouton Ajouter en haut à gauche, puis renseignez en partie droite :

• le code utilisateur ld
• les conditions d'utilisation de ce code utilisateur. Par défaut, avec la valeur localhost, le code utilisateur ne sera utilisable que sur la machine locale. Comme on veut la plupart du temps accéder aux données présentes sur le serveur depuis différents postes de travail au travers d'un réseau, il faut élargir cet accès. Vous pouvez le faire soit en stipulant une partie d'adresse IP (par exemple, si votre serveur est à l'adresse 192.168.1.100, vous pouvez indiquer 192.168.1% ; tous les postes de travail ayant une adresse IP commençant par 192.168.1 y auront accès), soit en indiquant la valeur % pour stipuler que l'accès peut se faire de partout.
• enfin, le mot de passe associé à ce code utilisateur.
  Choisissez un mot de passe suffisamment robuste, il donnera accès à toutes les données enregistrées dans l'entrepôt, dont certaines peuvent être très sensibles (données nominatives de paye par exemple).

Il reste alors à définir les droits d'accès de nouvel utilisateur. Cela se fait dans la partie basse de la fenêtre, à droite :

• soit on accorde à cet utilisateur les privilèges globaux.
  Il n'y a alors rien de plus à faire, l'utilisateur dispose implicitement des droits d'accès à toutes les tables de toutes les bases de données.
• soit on accorde des droits d'accès à une base de données, la base EntrepotLD créée plus tôt notamment.
  Il faut alors indiquer à quelles commandes l'utilisateur a accès sur cette base de données. Si ce code utilisateur va servir à mettre à jour la base de données au travers de LDETLFB, il est préférable de lui conférer tous les droits sur cette base. Si au contraîre le code utilisateur ne servira qu'à la lecture ders données via Get and Transform dans Excel, on peut se contenter de données l'accès à la seule commande SELECT.
• soit on accorde des droits d'accès au niveau des différentes tables de la base EntrepotLD.
  Cette façon de faire va permettre de gérer les droits d'accès plus finement :

• on crée un premier utilisateur ayant accès à l'ensemble de l'entrepôt, avec donc accès à toutes les commandes SQL sur cet entrepôt
• puis on crée autant d'utilisateurs que nécessaire, chacun n'ayant accès qu'à la commande SELECT sur un certain nombre de tables. Par exemple, un premier utilisateur ayant accès aux tables contenant des données comptables, un second ayant accès aux tables de la paye.
  
  

Remarques complémentaires

Quand on donne des droits d'accès sur une base de données, on ne peut pas ensuite retirer des droits sur une table en particulier : la commande REVOKE retire un droit attribué par GRANT sur le même objet, mais ne vient pas en « soustraction » de droits accordés sur un objet de niveau supérieur. Il faut donc donner des droits explicitement sur chacune des tables de la base et non pas sur la base elle-même.

Mais il y a des solutions alternatives si le nombre de tables et/ou d'utilisateurs est conséquent :

• mettre de côté, dans une base de donnée différente, les tables que l'on veut protéger. Par exemple, les tables de données relatives à la paye, souvent les plus sensibles, peuvent être isolées dans une base distincte. Ainsi, il n'est pas nécessaire de gérer des droits sur les tables, mais uniquement sur des bases entières.
• accorder des droits avec des noms de table génériques, par exemple CPT% ou PAY%. HeidiSQL ne le permet pas directement depuis son interface graphique, mais on peut le faire en passant par des commandes GRANT ou même plus simplement, en commençant par accorder des droits sur une table en particulier, puis en allant remplacer le nom de la table par un nom générique dans la table nommée Table_priv de la base de données mysql où sont enregistrés tous ces droits d'accès, cette base mysql étant accessible par le profil root depuis HeidiSQL.

Autre chose à savoir : les droits d'accès sur une table particulière sont conservés même lors d'une suppression-recréation de la table. Ainsi, même si LDETLFB procède par suppression-recréation d'une table à chaque mise à jour (ce qui est le cas pour les tables ayant un faible volume de données, par souci d'efficacité), les droits d'accès à la table définis à l'origine demeurent.