Méthylbro Développeur Web PHP - Tag - Base de Données

Adminer : Une alternative à PHPMyAdmin qui tient dans un seul fichier

Méthylbro — Wed, 23 Sep 2009 08:00:00 +0200

Voilà une alternative intéressante au monstrueux PHPMyAdmin ; Adminer. Ce programme écrit en PHP permet des fonctionnalités d'administration graphique d'un ensemble de base de données MySQL.

Comme vous l'aurez deviné dans le titre, le principal atout d'Adminer c'est qu'il tient dans un simple fichier. Facile et rapide a installer donc.

Niveau fonctionnalités, Adminer est un concurrent sérieux de PHPMyAdmin. En effet, Adminer embarque toute une pléiade de choses intéressante, en plus des options minimum que l'on peu attendre d'un tel script :

Sélection, édition et création d'occurrences de table en mode graphique
Assistant graphique pour la création de tables et de vues
Assistant graphique pour la création de procédures, de fonctions et de triggers
Import et export de données aux formats SQL et CVS
Gestion des privilèges pour les utilisateurs
...

Dans ma rapide découverte de ce script, deux fonctionnalités que je trouve très intéressantes m'ont attiré l'attention :

Des liens sur les clés étrangères

La première est quelque chose que je n'ai encore jamais vu sur les versions de PHPMyAdmin que j'utilise (je ne sait pas si dans les toutes dernières versions c'est proposé). Il s'agit d'un simple lien placé sur les clés étrangères lorsque l'on navigue parmi des occurrences.

Cela n'a l'air de rien comme ça, mais c'est tout bonnement génial d'avoir enfin pensé à le faire.

Un éditeur de MPD

Le petit générateur de Modèle Physique des Données (les habitués de MERISE comprendrons) est aussi agréable. Il est plus sympathique de se représenter graphiquement certaines bases de données.

Cependant parfois, si aucun MCD n'a été réalisé à la conception c'est un cauchemar. Ce petit éditeur me sera également utile pour un projet actuel sur lequel je travaille ou la base de donnée actuelle ne ressemble plus du tout au modèle que j'ai sur papier.

Conclusion

Voici donc un projet qui a un fort potentiel. A tester et a garder sous la main. Ce script peut s'avérer utile.

Adminer

Bases de Données Relationnelles - Partie 4

Méthylbro — Tue, 11 Nov 2008 10:10:00 +0100

Après avoir dans un premier temps défini un exemple, puis expliqué les concepts d'agrégation et de composition, je vous propose d'entrer enfin dans le vif du sujet : la création de votre base de données.

Aujourd'hui nous allons voir comment traduire concrètement les liens de relations entre vos tables lors de la création de vos base de données. Tout cela illustré avec des exemples de script de création de table en SQL.

Avant de commencer, je tient à signaler que l'ensemble des scripts suivant ont été testés sur le SGBDR MySQL 5.0.

Création de notre base de données

Maintenant que nous avons conçue notre base de données, que nous savons quelles sont les données que nous allons devoir stocker et comment ces dernières s’articulent entre elles, nous allons pouvoir créer notre base de données.

Pour rappel, voici notre MCD final :

Avant de commencer à créer nos tables, créons une base de données de tests :

CREATE DATABASE `TEST_LEGO`;

Les exemples suivants utiliseront cette même base de données :

USE `TEST_LEGO`;

La table Thème

Nous allons commencer par définir une première entité simple, les thèmes de construction. D'ailleurs, a partir de maintenant, je ne vais plus parler d'entité, mais de table.

En effet, nous ne sommes plus au niveau logique de notre conception mais désormais au niveau physique. Ne vous inquiétez pas, le nom change mais le concept reste sensiblement le même.

CREATE TABLE `LEGO__THEME` (

`id` int(11) NOT NULL auto_increment,

`nom` varchar(255) NOT NULL,

`description` text NULL,

PRIMARY KEY (`id`)

)TYPE=InnoDB;

Comme vous pouvez le voir dans ce premier script SQL il n'y a pour le moment aucun grand changement comparativement aux tables que vous avez déjà pu créer jusqu'à aujourd'hui.

Pourtant, cet exemple utilise le moteur de table InnoDB. Nous allons utiliser ce moteur de table afin que MySQL prenne bien en compte plus loin les clés étrangères et autres contraintes que nous allons définir. Je m'attarderais dans un autre tutoriel sur les différents moteurs de tables de MySQL.

La table Construction

Maintenant nous allons pouvoir entrer dans le vif du sujet. Voici notre première table incluant une clé étrangère. Nous allons donner vie dans cet exemple à notre premier type de relation dont je parlais dans un billet précédant : l'agrégation.

Comment ce traduit l'agrégation entre deux entités au sein d'une base de données ? Et bien c'est très simple, il faudra mettre en place une clé étrangère (Foreign Key en anglais). Cette clé étrangère correspondra en fait à un champ contenant la valeur de la clés primaire de l'entité agrée.

Reprenons notre exemple ; comment décrire au sein de notre base de données qu'une Construction en Lego doit appartenir à un thème ? C'est très simple, il suffit d'enregistrer ceci au sein de notre table Construction.

Pour ce faire, nous allons en plus de nos champs classiques ajouter une colonne qui contiendra pour chaque construction l'identifiant du thème auquel elle appartient. Puis nous signalerons à MySQL que ce champ correspond a un identifiant provenant de la table THEME.

CREATE TABLE `LEGO__CONSTRUCTION` (

`id` int(11) NOT NULL auto_increment,

`reference` varchar(15) NOT NULL UNIQUE,

`nom` varchar(255) NOT NULL,

`description` text NULL,

`date_creation` timestamp(10) NOT NULL,

`theme` int(11) NOT NULL,


CONSTRAINT `affilier` FOREIGN KEY (`theme`)

REFERENCES `LEGO__THEME` (`id`)

ON DELETE CASCADE ON UPDATE CASCADE,


PRIMARY KEY (`id`)

)TYPE=InnoDB;

Voilà, nous venons d'introduire un concept primordial dans la création de base de données relationnelle : les contraintes. Ici par exemple, en créant une telle base de données, nous venons de contraindre les champ Theme de la table CONSTRUCTION à toujours avoir une valeur égale à une clé primaire de la table THEME.

En gros, il sera impossible d'enregistrer une construction dont le thème n'existe pas. Dans le cas contraire, MySQL vous en refusera l'insertion.

Autre point important, nous venons en moins d'une ligne d'affecter un comportement qui peut s'avérer extrêmement utile. La suppression et la modification en cascade (ON DELETE CASCADE, ON UPDATE CASCADE). Cette instruction permet par exemple d'enchainer une série de suppression et de modification en cascade.

Par exemple, si nous souhaitons supprimer le thème "Voitures", la base de données supprimera automatiquement toutes les constructions qui ont se thème pour attribut. De même, l'instruction "ON UPADTE CASCADE" modifieras toutes les entrées de votre thème dans la table CONSTRUCTION si vous en modifié la valeur dans THEME.

Sachez que d'autres instructions du même genre sont possibles, par exemple :

ON DELETE RESTRICT, ON UPDATE CASCADE

ON DELETE NO ACTION, ON UPDATE RESTRICT

La table Brique

Avant de nous préoccuper de notre lien de composition, je voudrais vous donner un autre exemple de contrainte réalisable. Il s'agit de la contrainte d'unicité qui permet sur une table de rendre unique une valeur, ou un ensemble de valeurs sur toutes les occurrences.

Par exemple, on sait qu'une clé primaire sous entend une contrainte d'unicité. En effet, sur une même table vous ne pourrais jamais avoir deux valeurs identiques pour une clé primaire.

Il s'agit un peut du même principe ici. Prenons par exemple une brique. Dans notre base de données nous souhaitons éviter d'avoir plusieurs fois enregistré des briques avec des caractéristiques identiques.

En fait il serait incohérent d'enregistrer plusieurs fois une brique de même hauteur/largeur/profondeur avec un numéro d'identifiant différent. Nous allons donc lors de la création de notre table BRIQUE déclarer la contrainte Caractéristiques qui aura pour rôle d'interdire ce genre de doublons.

CREATE TABLE `LEGO__BRIQUE` (

`id` int(11) NOT NULL auto_increment,

`hauteur` integer NOT NULL,

`largeur` integer NOT NULL,

`profondeur` integer NOT NULL,


UNIQUE `caracteristiques` (`hauteur`, `largeur`, `profondeur`),


PRIMARY KEY (`id`)

)TYPE=InnoDB;

La table Composer

Désormais il ne nous reste plus qu'a créer notre lien de composition entre les tables CONSTRUCTION et BRIQUE. Comme nous l'avons vu juste au dessus, un lien d'agrégation se traduit par une clé étrangère. Pour la composition, ce sera le même principe, en un peut plus complexe. Car au lieu de n'avoir qu'une clé étrangère, nous en auront deux. Et cet ensemble de clés étrangères formera la clé primaire d'une nouvelle table.

Attention, il est primordial que la clé primaire de cette nouvelle table soit la concaténation des clés étrangères des entités en relation. Sinon cela n'a aucun intérêt. J'ai déjà pu voir très récemment des tables se voulant être des liens de composition mais dont la clé primaire est un champ complètement autonome. C'est à éviter à tout prix !

CREATE TABLE `LEGO__COMPOSER` (

`construction` int(11) NOT NULL,

`brique` int(11) NOT NULL,

`nombre` integer NOT NULL DEFAULT 1,


CONSTRAINT `construction_composer` FOREIGN KEY (`construction`)

REFERENCES `LEGO__CONSTRUCTION` (`id`)

ON DELETE RESTRICT ON UPDATE CASCADE,


CONSTRAINT `brique_composer` FOREIGN KEY (`brique`)

REFERENCES `LEGO__BRIQUE` (`id`)

ON DELETE RESTRICT ON UPDATE CASCADE,


PRIMARY KEY (`construction`, `brique`)

)TYPE=InnoDB;

Comme vous pouvez le voir, cela nous permet de porter des données sur notre relation. Souvenez vous lorsque dans un billet précédant je vous parlez de "porteuse de données". Et bien voici ici comment cela se traduit concrètement (avec le champ nombre).

Bases de Données Relationnelles - Partie 3

Méthylbro — Sun, 09 Nov 2008 00:53:00 +0100

J'avais promis un tutoriel complet sur les principes simple de la création d'une Base de Données Relationnelle avec MySQL ...

Et voilà qu'au bout d'un mois, à cause de beaucoup de boulot et d'un gros poil dans la main je m'apercois que je n'ai rédigé que deux articles à ce sujet.

Je vais donc rattraper mon retard et vous proposer la suite. Aujourd'hui donc, après une Introduction au Base de Données Relationnelle ainsi qu'un premier article expliquant le concept simple de l'agrégation, je vais essayer d'expliquer le principe de la composition.

Si vous ne comprenez pas tout de suite ou je veux en venir ne vous inquiétez pas, des exemples concrets arrivent dans les billets à venir.

Composition

De même que l’Agrégation, il existe un autre type de relation entre deux entités qui permet de composer des éléments de façon plus complexe.

En effet, si l’Agrégation permet de modéliser au sein d’une base de données des liens unilatéraux entre des éléments elle deviens inutilisable dans des cas plus complexes. L’idée ici est de décrire qu’un élément A se compose d’un ensemble d’éléments B. Inversement, cet élément B sera composé d’une série d’éléments A.

Je sens que certains seront vite perdu avec ces explication hasardeuses, reprenons donc notre exemple de modélisation de constructions avec des Lego.

Pour définir une construction en Lego, nous admettrons que celle-ci est en fait un ensemble de briques, de diverses tailles, formes et couleurs assemblés les unes aux autres. Ce qui au final nous donne notre construction. Il s’agit donc d’un lien de composition entre nos entités BRIQUE et CONSTRUCTION.

Le modèle suivant décris ce comportement de façon simple : Une Construction est composée de Briques ou dans l’autre sens, un ensemble de Briques composent une Construction :

Ici vous devez lire ce schéma de la façon suivante :

Une Construction est composée de 0 ou plusieurs Briques.
Une Brique entre dans la composition de 0 ou plusieurs Constructions.

Porteuse de données

Cependant, la solution proposée imposera très vite ses limites pour certains cas. Par exemple ici, comment déterminer le nombre d’une même Brique nécessaire au sein d’une construction ?

Car comme nous le verrons plus loin lors de la création de notre base de données, l’intérêt de modéliser correctement est d’atteindre une intégrité parfaite de nos données. De ce fait il serait incongru de voir apparaitre une même occurrence de notre relation COMPOSER plusieurs fois.

Pour ce faire, nous utiliserons un cas particulier de la Composition : la relation porteuse de données. Ce cas ne s’applique qu’exclusivement aux relations « Composées ». Si lors de vos modélisations vous vous retrouvez avec une Agrégation porteuse de données, c’est que vous avez commis une erreur et que la donnée portée par la relation doit en réalité s’appliqué au sein d’une des entités reliées.

Pour illustrer le cas des relations porteuses de données, nous allons modifier notre exemple précédant en y ajoutant ceci :

Une Construction est composée de Briques. A chaque utilisation d’une brique dans notre construction, nous prendrons soin d’incrémenter la propriété « nombre » de la relation COMPOSER.

Bases de Données Relationnelles - Partie 2

Méthylbro — Mon, 13 Oct 2008 00:40:00 +0200

Deuxième billet dédié à la conception de Base de Données Relationnelle avec MySQL.

Dans ce billet nous aborderons le sujet très intéressant des différentes relations que peuvent avoir vos entités (vos tables) entre elles.

Bases de Données Relationnelles (suite)

Relations

Le simple fait de stocker l’identifiant d'une occurrence de table comme propriété d'une occurrence d’une autre table n’est pas suffisant en soit pour décrire une relation entre les tables concernées. C’est une erreur ; une erreur extrêmement commune et répandue.

Vous devez décrire correctement à votre Système de Gestion de Base de Données le comportement naturel de vos entités et de leurs relations.

Comme vous le savez, il est impératif que les données contenues dans vos bases soient les plus cohérentes possibles. Vous devrais alors prendre soin dés le début à ce que votre base de données dans sa structure même n’accepte pas les incohérences les plus évidentes.

Pour ce faire il faut d’abord être à l’aise avec les relations que vous allez pouvoir rencontrer.

Nous distinguerons deux types de relations : des relations « d’appartenance », que nous appellerons Agrégations ainsi que des relations de « constitution », que nous appellerons Compositions.

L’agrégation et la composition sont des concepts récurrents du génie logiciel. Vous les retrouverez à chaque fois que vous manipulerez des entités. Qu’ils s’agissent de tables comme ici, mais aussi d’objets !

Agrégation

Sous ce nom un peut étrange se cache en fait le type de relation le plus courant ; le plus simple à comprendre et donc, à utiliser.

Une agrégation décris un lien d’affiliation entre une entité A et une entité B. Il s’agit d’une relation unilatérale, car elle n’est décrite que dans l’entité affiliée.

Prenons par exemple des Catégories et des Articles. On peut naturellement dire qu’un article est affilié à une catégorie, car ce dernier sera contenu dans une catégorie. La catégorie quand à elle ne sait pas qu’elle contient cet article. Du moins pas directement car dans notre base de données, le lien entre l’article et sa catégorie est enregistré du coté de l’article.

Reprenons notre exemple sur nos constructions en LEGO. Nous avons dit auparavant qu’un thème contenait des constructions. A fortiori une construction est affiliée à un thème.

Ici vous devez lire ce schéma de la façon suivante :

« Une Construction est forcément affiliée à un Thème.
A un Thème est affilié 0 ou plusieurs Constructions. »

Le plus simple, et le plus évident sera alors de stocker au sein de notre table CONSTRUCTION le numéro d’identifiant du thème à laquelle la construction est affiliée. Nous appellerons donc ce nouveau champ à stocker : une clé étrangère (Foreign Key en anglais).
Clé étrangère car faisant référence à la clé primaire d’une occurrence de la table THEME.

Nous verrons plus loin comment décrire cette clé étrangère lors de la création des tables de notre exemple.

Bases de Données Relationnelles

Méthylbro — Sun, 12 Oct 2008 00:40:00 +0200

Mon tutoriel sur la Programmation Orienté Objet avec PHP ayant apparemment reçu de bonnes critiques, je me suis permis de croire que j’avais un sens didactique faisant mouche pour certaines personnes.

Je vais donc remettre ca cette semaine en proposant un nouveau tutoriel à lire jours après jour. Avec pour thème cette fois les Bases de données.

En effet, je vois trop souvent des applications sous estimant l’utilité d’utiliser une base de données bien conçue. Pourtant, vous allez voir en lisant cette série d’articles que passer un peut de temps à concevoir ses tables et à bien définir les relations entre ces dernières n’est pas une perte de temps.

Bien au contraire, une base de donnée bien conçu vous permet de déléguer bon nombre de validations. Ainsi votre code PHP gagnera en lisibilité, en facilité de rédaction mais vous serez vous aussi gagnant en termes de temps. Car vous n’aurez pas à réécrire en PHP des séries de validations de données qui auraient pu être fait en amont, directement au sein de votre base de données.

Bases de Données Relationnelles

Introduction avec MySQL

En génie logiciel il est communément admis qu’une application est un ensemble composé de données et de traitements. C’est d’ailleurs un des fondements des méthodes de conception (MVC, PAC etc…).

Or trop souvent les développeurs web ont tendance à négliger la conception de leur base de données. Pour la plupart d’entre eux le concept d’une base de données se résume en un ensemble abstrait de tableaux qui n’ont comme seul intérêt qu’une lecture/écriture simplifié.

Bien entendu certains d’entre eux comprennent qu’une base de données bien conçue apportera la réponse à leurs questions. Mais je me suis aperçu que dans la grande majorité des cas, ils ne savent pas comment traduire ces relations dans leurs bases de données voire parfois, ils ne savent même pas les mettre en œuvre concrètement. Sans compter que l'on peut les entendre parler de tables « associatives » ou d’autres inepties de ce genre.

Nous allons donc voir comment concevoir des Bases de Données Relationnelles. Nous aborderons les concepts généraux inhérents à ces questions puis nous les nommerons correctement. D’abord avec un peut de théorie puis ensuite illustré par un cas pratique utilisant MySQL.

Introduction

Prés requis

Ce tutoriel n’est pas destiné aux débutants. Il s’adresse plus aux amateurs, ou à tout développeur ayant quelques difficultés avec les concepts évoqués ici.

Il est indispensable pour comprendre ce que je vais évoquer plus loin de maitriser les commandes de base en SQL. C'est-à-dire CREATE TABLE, ALTER TABLE, INSERT, UPDATE, SELECT, UPDATE …

Il est aussi souhaitable de connaitre les différents types de données simple qui peuvent être déclarés, ainsi que les concepts de clés primaires, contraintes d’unicité et même le principe de contraintes dans son ensemble même si je reviendrais un peu sur ces derniers.

Comparaison avec des bases de données non relationnelles

Comme je l’ai dit plus haut, il est extrêmement simple de s’imaginer une table comme un grand tableau à deux entrées. Il est ainsi possible d’y stocker n’importe quel type d’informations.

En développement web il peut s’agir par exemple d’une liste d’articles, de la liste des membres inscrits sur votre site. Ou bien encore de la liste des abonnés à votre liste de diffusion.

Néanmoins, vous avez déjà du rencontrer des problèmes pour relier toutes ces informations entre elles. Par exemple, votre site est divisé en X catégories. Chacune de vos catégories peut contenir divers articles. Comment stocker ce lien hiérarchique entre vos catégories et vos articles ?

Ou mieux encore, les catégories sur plusieurs niveaux. Comment faire pour enregistrer un lien hiérarchique entre vos catégories, vos sous-catégories, vos sous sous-catégories et ainsi de suite ? Sans forcément avoir à créer de nouvelles tables à chaque niveau de votre arborescence ?

Voilà ce que nous allons apprendre à faire correctement, et proprement dans ce tutoriel.

Exemple employé

Dans cet article nous allons créer une base de données qui enchantera les amateurs de LEGO.

En effet, on peut très simplement avoir une base de données concernant un ensemble de constructions et LEGO. Voire même en poussant un peu plus l’exemple, créer un système permettant aux constructeur en herbe de sauvegarder les plans de leur créations.

Nous admettrons donc qu’une construction en LEGO est composée d’un ensemble de pièces. Afin de simplifier nous ne gérerons pas les différentes couleurs que peuvent avoir ses pièces, mais simplement leur forme ou leur taille ainsi que la quantité de chaque pièce utilisée pour notre construction. Nous verrons aussi comment classer toutes nos constructions par thèmes.