KURZWEG Ivan ik-r@wanadoo.fr Version 1.1 GRETA Neotech III Last Updated: $Date: 2006/03/06 09:43:02 $ Permission to use, copy, modify, and distribute this documentation for any purpose with or without fee is here by granted, provided that the above copyright notice and this permission notice appear in all copies. THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS DOCUMENTATION. Dans ce chapitre, nous allons faire une première approche de la méthode de conception de systèmes informatiques, Merise. Aspect historique et général d’abord, puis ensuite les différents niveaux de modélisation, ainsi que les étapes et les documents qui jalonnent la conception d’un SI. MERISE est une méthode de conception, de développement et de réalisation de projets informatiques, mise au point par une équipe de chercheurs français, sur commande du Ministère de l’Industrie en 1977. La collaboration entre des universitaires, des professionnels et des spécialistes en organisation d’entreprise a abouti à la publication d’un ouvrage en 1978. La méthode a ensuite donné lieu à plusieurs mises à jour, et on a parlé de « MERISE 2 ». Aujourd’hui, la méthode Merise reste une référence en matière de conception de systèmes d’information. Mais la montée en puissance de l’approche objet pose certains problèmes, en particulier au niveau de la séparation des données et des traitements. Une nouvelle méthode s’affirme, UML (United Modeling Language), et fait de plus en plus d’ombre à Merise. Mais dans le cadre de cette formation, Merise convient parfaitement, les outils de gestion de base de données orientée web étant basés plus sur une approche relationnelle que sur une approche orientée objet. Parce que la maintenance d’une application informatique met clairement en évidence plusieurs types de problèmes, depuis les modifications qu’entraîne un changement de matériel, jusqu’à la refonte complète de l’application qu’exige la mise en place d’une réglementation totalement nouvelle, il a paru essentiel de dégager des niveaux correspondant à ces préoccupations différentes. Pour Merise et la plupart des méthodes de conception, il est classique de mettre en évidence 3 niveaux de réflexion : Il correspond à la définition des finalités de l’entreprise en explicitant sa raison d’être. Ce niveau, décrit à travers un ensemble de règle de gestion, traduit les objectifs et les contraintes qui pèsent sur l’entreprise. On y retrouve par exemple les règles de gestion du personnel, de tenue de la comptabilité, de livraison des produits finis, etc.. Son rôle est de définir l’organisation qu’il est souhaitable de mettre en place dans l’entreprise. On parle de choix d’organisation. L’analyste précise les postes de travail, la chronologie des opérations, les choix d’automatisation, etc.. Enfin, sont intégrés les moyens techniques nécessaires au projet. Ils s’expriment en terme de matériels ou de logiciels, et sont les plus sujets à changements (évolution technologique). La conception du système d'information se fait par étapes, afin d'aboutir à un système d'information fonctionnel reflétant une réalité physique. Il s'agit donc de valider une à une chacune des étapes en prenant en compte les résultats de la phase précédente. D'autre part, les données étant séparées des traitements, il faut vérifier la concordance entre données et traitements afin de vérifier que toutes les données nécessaires aux traitements sont présentes et qu'il n'y a pas de données superflues. Cette succession d'étapes est appelée cycle d'abstraction pour la conception des systèmes d'information : Système d'information manuel Expression des besoins Modèle conceptuel Modèle logique Modèle physique Système d'information automatisé Niveaux Données Traitements Questions Conceptuel Modèle Conceptuel des Données (MCD) Modèle conceptuel des Traitements (MCT) Quoi ? Organisationnel Modèle Logique des Données (MLD) Modèle Organisationnel des Traitements (MCT) Qui ? Où ? Comment ? Technique Modèle Physique des Données (MPD) Modèles Opérationnel des Traitements (MOpD) Comment ? La courbe du soleil permet de représenter le cycle de vie du projet selon Merise. On remarque une montée vers le niveau conceptuel, qui correspond à une étude de l’existant, puis une redescente vers le niveau physique, c’est la phase de conception.

Comme nous venons de le voir, Merise est à la fois une méthode d'analyse informatique et une méthode de conduite de projet. Parfaitement adaptée à la réalisation de systèmes d'information importants, elle reste cependant très vaste comparativement aux besoins exprimés dans le cadre d'un développement d'une application Internet. Ainsi, nous allons recentrer notre étude de Merise sur la modélisation des données. En effet, la plupart des applications orientées Internet utilisent aujourd'hui une base de données comme support d'informations. Mais la conception d'une base de données peut rapidement tourner au cauchemar si l'emploi d'une méthode fiable est ignoré. Dans les chapitres suivants, nous allons donc examiner les procédures permettant de modéliser le "réel" en une base de données solide et bien conçue. La modélisation conceptuelle des données est la représentation de l’ensemble des données du système d’information étudié, sans tenir compte des aspects organisationnels et techniques liés à leur mise en œuvre dans tel ou tel traitement. Cette représentation, appelée « schéma conceptuel des données »est obtenue par la mise en œuvre des concepts et des outils du modèle entité - association de la méthode Merise. Il y a nécessité de formaliser le SCD (schéma conceptuel des données) En analyse, pour traiter un problème, une situation, il faut :

Caractéristiques d’un formalisme : Approche naturelle et de compréhension aisée (pour les analystes et les utilisateurs) Rigoureux Informatisable Une des images les plus classique de l’informaticien est celle d’un technicien concevant des solutions géniales à des problèmes qui ne lui sont pas posés, et rétif à tout dialogue avec l’utilisateur. Même si les cas d’écoles qui sont présentés en formation ont des objectifs clairement posés sur un existant vide, dans la vie professionnelle, il en va généralement bien autrement. Lors des différentes interviews qui jalonnent l’étude préalable, l’analyste recense les données apparaissant dans les différents documents de l’entreprise. Au cours de la conception détaillée, il va tenter de les décomposer en données élémentaires, et les épurer, c’est-à-dire n’en retenir que les pertinentes. Etablir un dictionnaire des données, c'est recenser l'ensemble des informations de l'application, et leur attribuer un type de données, c'est-à-dire indiquer sous quelle forme informatique elles seront enregistrées. Une donnée élémentaire est une donnée qui ne peut être décomposée. Souvent les données brutes sont constituées de plusieurs parties, mais on ne doit décider de les décomposer qu’en fonction de l’usage qui en sera fait. Une adresse postale d’un client est une donnée brute, qu’on peut décomposer en AdresseRue, CodePostal et Ville. Cela permet par exemple de sélectionner tous les clients d’une ville. Mais si on a aussi besoin de connaître tous les clients d’une rue, on sera alors obligé de décomposer AdresseRue en NuméroRue et NomRue. Lorsque deux noms recouvrent la même réalité, il s’agit d’une synonymie. Lorsqu’un même nom de données recouvre plusieurs réalités, il s’agit d’une polysémie. Il faut bien sûr supprimer ces deux défauts. CodeClient et referenceClient sont deux noms de données qui peuvent recouvrir la même réalité, c’est-à-dire le moyen d’identifier le client. Il ne faut donc retenir qu’un seul nom pour cette propriété. Une donnée calculée est une donnée dont la valeur peut être obtenue en appliquant une règle de calcul aux valeurs d’autres données élémentaires. Ces données ne doivent pas entrer dans le modèle conceptuel des données. Les données élémentaires, calculées ou non calculées, épurées et retenues pour leur pertinence, constituent le dictionnaire des données. Pour chacune d’elles, on précise le type et le domaine de définition. On indiquera également si elles sont calculées ou non. Tout au long de ce dossier, nous allons tenter de modéliser un système d’information concernant des accidents de la circulation. En voici les grands traits : Dans un double objectif de suivi et de prévention des accidents de la route, il a été décidé de nommer un haut responsable, M. Sécurité. Celui-ci dispose uniquement d’une remontée quotidienne d’informations, constituée par les photocopies des constats d’accident à l’amiable, transmise par les compagnies d’assurance. Outre des études ponctuelles, il fournira périodiquement un tableau de bord de la sécurité routière. M. Sécurité gère cette information pour les objectifs qui lui ont été assignés. C’est pourquoi, il place hors de son champ d’étude tout ce qui est lié au strict problème d’assurance. Etablir le dictionnaire des données pour ce SI. Un exemple de constat à l’amiable vous est fourni ... Définition : Appelée aussi information élémentaire, données élémentaire ou rubrique, la propriété désigné le plus petit élément d’information manipulable. Pour être correctement définie, une propriété doit toujours être décrite par un « nom de propriété », prendre ses valeurs dans un domaine de valeurs et avoir un sens dans le système d’information étudié. Remarque : Une propriété est véritablement élémentaire si elle n’est pas décomposable en un ensemble de propriétés signifiantes plus petites. On dit alors qu’elle est atomique. Par exemple, une adresse postale peut être décomposé en : - numéro de rue - nom de rue - code postal - ville Mais cette décomposition fine n’est pas systématique, elle est uniquement guidée par la pertinence à traduire une réalité de l’entreprise. Ainsi, il n’est pas nécessaire de découper une date en trois propriétés distinctes, jour, mois et année. Une entité est un type d’élément (abstrait ou concret) du monde réel défini par : - une existence propre et une utilité pour l’organisation étudiée - des occurrences multiples (c’est-à-dire au moins deux) - des propriétés (au moins une), dont un identifiant. L’entité est représentée par un rectangle.

La liste épurée des données conçue au précédent exercice fait apparaître deux acteurs essentiels d’un accident, VEHICULE et CONDUCTEUR. Représentez ces deux objets sous forme d’entité. Parmi toutes les propriétés d’une entité, une ou plusieurs d’entre elles doivent jouer un rôle particulier, celui de permettre de distinguer chaque occurrence de l’entité par rapport à toutes les autres. Cette propriété ou groupe de propriétés est appelé identifiant. Il existe plusieurs types d'indentifiant :  Identifiant simple : il est composé d’une seule propriété (exemple précédent)  Identifiant composé : il est composé de deux propriétés ou plus.  Identifiant relatif : il est constitué pour partie d’une propriété appartenant à une autre entité.  Identifiant hérité : il résulte d’un lien de dépendance avec une entité générique. L’identifiant d’une entité est l’ensemble des propriétés soulignées.

Indiquez les identifiants des entités définies dans l’exercice précédent. Justifiez vos choix Définition : Une association est un type d’élément du monde réel défini par : - une absence d’existence intrinsèque - au moins une occurrence - une dimension (mesurée par le nombre d’entités rattachées) - une utilité pour l’organisation étudiée. . Formalisme : L'association est représentée par un ovale.

Association entre deux entités (dimension 2) :

Association entre trois entités (dimension 3) :

Association réflexive (dimension 1) :

Exercice : 1. Dans l’exercice précédent, nous avons considéré un conducteur comme une personne, mais aussi comme le titulaire d’un permis de conduire. M. Sécurité souhaite établir un rapport entre les types de permis, leur « ancienneté », et la dangerosité du conducteur. Décomposez l’entité CONDUCTEUR en 2 entités, et indiquez leur association. 2. Modélisez maintenant les accidents. Un accident implique deux véhicules et deux conducteurs… Définition : Une occurrence de propriété est une valeur que peut prendre une propriété. Une occurrence d’entité est un ensemble ayant une existence propre d’occurrences de ses propriétés. Soit l'entité suivante :

L’ensemble {PAYET, JEAN, 23/10/1970} est une occurrence de l’objet STAGIAIRE car « PAYET » est une occurrence de la propriété NOM, « JEAN » une occurrence de PRENOM et « 23/10/1970 » une occurrence de DATE_DE_NAISSANCE. Une occurrence de relation est constituée d’une et d’une seule occurrence de chacune des entités associées. L’occurrence de chacune des propriétés de l’association est en relation avec les occurrences des entités associées.

Soient les occurrences suivantes : • {PAYET, JEAN, 23/10/1970} : une occurrence de l’entité « STAGIAIRE ». • {BDD} et {JAVASCRIPT} : deux occurrences de l’entité « MODULE ». 12 peut être une occurrence de « NOTE » associée aux occurrences {PAYET, JEAN, 23/10/1970} et {BDD} ; 13 une autre occurrence de « NOTE » associée aux occurrences {PAYET, JEAN, 23/10/1970} et {JAVASCRIPT}. Définition : La cardinalité d’une entité par rapport à une association s’exprime par deux nombres appelés cardinalité minimum et cardinalité maximum. La cardinalité minimale peut être égale à 0 ou à 1. Si la cardinalité est égale à 0, c’est qu’il existe au moins une occurrence de l’entité qui ne participe pas aux occurrences de l’association. Si la cardinalité est égale à 1, chaque occurrence de l’entité participe aux occurrences de l’association. La cardinalité maximale exprime le nombre maximum de fois où une occurrence de l’entité participe aux occurrences de l’association. On la note égale à n, elle peut être égale à 1 ou à tout autre nombre strictement positif (quand le nombre d’occurrences est quantifiable).

Un stagiaire peut ne pas avoir de note, c’est à dire qu’il peut exister un stagiaire qui n’a pas passé l'évaluation (cardinalité minimum = 0). Un stagiaire peut être inscrit à plusieurs module et avoir une note pour chacun des modules auxquels il est inscrit (cardinalité maximum = n) Il est possible que personne ne se présente à l'évaluation pour un module (cardinalité minimum = 0) Plusieurs notes peuvent être attachées à un même module (cardinalité maximum = n) Définition : Deux rubriques (ou propriétés) sont en dépendance fonctionnelle si la connaissance d’une d’entre elles permet la connaissance de l’autre. Notation : A → B signifie que B dépend fonctionnellement de A. En d’autres termes, la connaissance d’une occurrence de la propriété A permet la connaissance d’une occurrence de la propriété B. Numéro INSEE → sexe ; Numéro INSEE → année de naissance ; Code d’un stagiaire → Nom de ce stagiaire Propriétes des dépendances fonctionnelles : Réflexivité : a → a Projection : a → b + c ⇒ a → b et a → c Augmentation : a → b ⇒ ∀c, a + c → b Additivité : a → b et a → c ⇒ a → b + c Transitivité : a → b et b → c ⇒ a → c Pseudo-transitivité : a → b et b + c → d ⇒ a + c → d Le modèle conceptuel des données sera toujours présenté en troisième forme normale. Une entité est en première forme normale si et seulement si : Toutes ses propriétés sont élémentaires Elle possède un identifiant (une clef) Une entité est en deuxième forme normale si et seulement si : Elle est en première forme normale Toutes ses propriétés sont en dépendance fonctionnelle élémentaire de l’identifiant Soient les propriétés P1, P2 et P3. Une dépendance fonctionnelle (P1 → P2) est dite élémentaire si et seulement si il n’existe pas de propriété (P3) incluse dans P1 en dépendance fonctionnelle avec P2 (P3 → P2). Une entité est en troisième forme normale si et seulement si : Elle est en deuxième forme normale Toutes ses propriétés sont en dépendance fonctionnelle élémentaire directe de l’identifiant Soient les propriétés P1, P2 et P3. Une dépendance fonctionnelle (P1 → P2) est dite directe si et seulement si il n’existe pas de propriété (P3) telle que P1 → P3 et P3 → P2. Vous gérez une base de données archéologique dans laquelle vous voulez mettre les informations suivantes. Un objet est trouvé par une équipe donnée, dans un site donné. L’équipe est reconnue par le nom de son directeur, et le site par son numéro, sa longueur, sa largeur. Le site appartient à une zone de fouille qui peut en contenir plusieurs. La zone de fouille porte le nom de la ville la plus proche. L’objet est identifié par un numéro, une désignation (qui le décrit), une catégorie (par exemple, meuble, accessoire, élément d’architecture, manuscrit...), par un état de complétude (s’il est total ou s’il est partiel comme un pied de table, un tesson de bouteille ou un nez de gargouille, etc...) et par un état de conservation ( intact, bon, à restaurer, mauvais état, très mauvais). Plusieurs équipes peuvent fouiller simultanément la même zone de fouille, mais pas le même site. En revanche les équipes tournent, d’un site à l’autre, chaque jour. QUESTION : proposez un modèle entité-association (ou modèle conceptuel des données MCD) représentant cet énoncé, en justifiant les cardinalités des couples entité-association, ainsi que les clés des entités. On souhaite modéliser les données pour écrire un programme qui simule un jeu de cartes entre plusieurs joueurs. Voici, en résumé, ce dont vous disposez comme information : 1) un joueur est connu par un nom qui l’identifie. 2) Le jeu peut être fait en équipe, par conséquent, une équipe peut être formée, ou pas, selon le désir des joueurs. Il est évident que l’équipe n’a de sens que si une partie doit être jouée. L’équipe possèdera un numéro qui permet de la reconnaître. Les équipes peuvent être composées d’un nombre quelconque de joueurs supérieur ou égal à 2. Si des équipes jouent, alors il ne peut pas y avoir simultanément des joueurs isolés et des équipes effectuant la même partie. 3) le jeu se déroule durant une session (une partie), qui est faite à une date donnée, entre des équipes composées pour ce jeu, ou des joueurs (si ceux-ci n’ont pas constitué d’équipe). Ce qui est utile pour caractériser le jeu, c’est de connaître : - la nature de la partie jouée : par exemple, belote, tarot, poker, rami... - pour chaque tour, quel est le score des différents joueurs ou des équipes 4) Une partie comprend un nombre quelconque de tours. Elle est terminée dès que le score d’une des équipes dépasse une valeur qui est dépendante de la nature de la partie jouée, ou si les différents joueurs décident d’y mettre fin. Question : Faire le modèle entité-association des données (statiques) de ce programme. Proposer des clés pour les entités. Mettez les cardinalités des couples entité-association, en fonction des hypothèses que vous devrez formuler pour compléter cet énoncé. Au chapitre précédent, nous avons vu le Modèle Conceptuel des Données. Nous allons maintenant examiner le niveau logique des données, et un de ses formalismes particulièrement adapté aux bases de données relationnelles, le modèle relationnel. Nous examinerons également les règles de passage du MCD vers le modèle relationnel. De ce type de formalisme, nous verrons qu’il est aisé de passer à la représentation physique des données, et à la mise en œuvre du SI sur un système de gestion de base de données relationnelles (SGBDR). Comme pour le modèle entité – association, on définit des domaines dans lesquels des attributs prennent leur valeur. Une relation est un ensemble d’entités et sa description peut prendre la forme d’un tableau dans lequel chaque ligne représente une occurrence d’entité et chaque colonne un attribut. La relation COUREUR(nom, prénom, dateNaissance) peut se représenter par Nom Prénom DateNaissance Payet Jacques 01/02/1970 Hoarau Philippe 10/03/1972 La relation ETAPES (NuméroEtape, VilleDépart, VilleArrivée, NbKm) peut se représenter par NuméroEtape VilleDepart VilleArrivee NbKm 1 St-Denis St-Paul 50 2 St-Paul St-Leu 30 Un n-uplet est une occurrence d’une relation. Plus concrètement, il représente une ligne du tableau. On dit aussi t-uple au lieu de n-uplet. Exemple : (1,St Denis, StPaul, 50) est un n-uplet de la relation ETAPES La cardinalité d’une relation est son nombre d’occurrence. Dans l’exemple précédent, la cardinalité de la relation COUREUR est de 2. Le degré d’une relation est son nombre d’attribut. . Dans l’exemple précédent, le degré de la relation COUREUR est de 3. Une clef primaire est constituée d’un ou plusieurs attributs de la relation. Elle permet d’identifier sans équivoque chaque n-uplet de la relation. Dans la relation Coureur, NOM peut ne pas être suffisant pour distinguer les occurrences, en cas d’homonymie. On peut rajouter un attribut à la relation, un numéro de coureur, qui devient clef primaire Selon les dépendances fonctionnelles observées, il peut être nécessaire de connaître la clef primaire d’une relation pour identifier un n-uplet d’une autre relation. Dans ce cas, la clef primaire de la première devient clef étrangère de la seconde. Exemple : soit la nouvelle relation qui permet de modéliser les temps des coureurs : TEMPS(NumCoureur, NumeroEtape, tempsrealisé). Les clefs NumCoureur et NuméroEtape, clefs primaires des relations COUREUR et ETAPES, permettent d’identifier chaque n-uplet de la relation. En effet, un coureur ne participe qu’une seule fois à une étape ! Ce sont donc les clefs étrangères de COUREUR. On représente chaque relation de la modélisation par : NOMRELATION (clefPrimaire1, clePrimaire2, …., attribut1, Attribut2, ….. ,#clefEtrangère1,#clefEtrangère1 ….) Exemple : TEMPS (#NumCoureur,#NumeroEtape, tempsrealisé) COUREUR (NumCoureur, (nom, prénom, dateNaissance) ETAPES (NuméroEtape, VilleDépart, VilleArrivée, NbKm) Le modèle relationnel est une modélisation des données. Nous pouvons le normaliser, de la même manière que nous avions normalisé le MCD. Ainsi, nous allons reprendre les règles de formes normales : Pour être en 1FN, une relation doit avoir une clef et chaque attribut doit être une donnée élémentaire. Exemple : EMPLOYE (NomEmployé, PrénomEmployé, AdresseEmployé, DateEmbauche). Cette table pose des problèmes d’homonymie, deux employés peuvent avoir le même nom, donc le même identifiant !! Pour passer le modèle en 1FN, il faut rajouter un matricule : EMPLOYE (MatriculeEmploye, NomEmployé, PrénomEmployé, AdresseEmployé, DateEmbauche) Pour être en 2FN, une relation doit être en 1FN et tout attribut non-clef ne doit pas dépendre d’une partie de la clef. Seules les relations dont la clef est composée de plusieurs attributs sont concernés. Exemple : COMMANDE (#N°Client, #N°Produit, Qte, Nomclient) CLIENT (N°Client, Adr, VilleClient) Dans la relation commande, NomClient dépend seulement de la partie de la clef N°Client. Pour normaliser le modèle en 2FN, il faut donc mettre NomClient dans la relation CLIENT : COMMANDE (#N°Client, #N°Produit, Qte) CLIENT (N°Client, Adr, VilleClient, Nomclient) Pour être en 3FN, une relation doit être en 2FN et tout attribut non clef ne doit pas dépendre d’un autre attribut non clef. (pas de transitivité) Exemple : FACTURE(N°Facture, dateFact, N°Fournisseur, RSFournisseur, AdrFournisseur, VillFournisseur) Les attributs AdrFournisseur et VilleFournisseur dépendent de la propriété N°Facture, mais aussi de RSFournisseur, qui elle-même dépend de la clef. On a donc 2 dépendances fonctionnelles transitives, qu’on peut supprimer en créant une nouvelle relation. FACTURE (N°Facture, dateFact, N°Fournisseur, #RSFournisseur) FOURNISSEUR (RSFournisseur, AdrFournisseur, VillFournisseur) La normalisation de Boyce - Codd a pour but de supprimer les dépendances fonctionnelles autre que celles de la clé vers les attributs non-clefs. Exemple : Dans une entreprise de production qui travaille à la commande de on veut pouvoir comptabiliser le temps consacré par chaque employé à chaque commande. Un employé n’est pas affecté d’une manière fixe à un atelier et un atelier est entièrement consacré à une commande. Soit la relation suivante : ATTRIBUTION (#N°employé, #N°Commande, NbHeures, N°Atelier) La DF fonctionnelle à supprimer dans cette relation est N°Atelier -> N°Commande. L’application de la BCFN se traduit par les relations suivantes : ATTRIBUTION (#N°employé, #N°Commande, NbHeures) ATELIER (N°Atelier, N°Commande) Le passage du MCD vers le modèle relationnel se base sur l’application de trois règles simples, énoncées ci-dessous. Il est à noter que cette transformation peut se faire en sens inverse, en appliquant les mêmes règles. Toute entité du MCD est traduite en une table dont la clef primaire et les attributs proviennent de l’entité

Une association qui a une cardinalité égale à 0,1 ou 1,1 pour une entité est traduite par une clef étrangère ajoutée à la table qui traduit cette entité. Cette clef étrangère est la clef primaire de l’entité associée.

Une association qui n’a pas de cardinalité égale à 0,1 ou 1,1 est traduite en une table dont la clef primaire est constituée de l’ensemble des identifiants des entités qui y participent.

Nous disposons maintenant d'un modèle logique des données conforme à Merise. Le modèle relationnel est directement transposable à un Système de Gestion de Base de Données Relationnel, tel que MySQL. En effet, chaque table du modèle relationnel donnera une table dans la base de données. Il nous reste maintenant à préciser les types de chaque données de notre modèle et de créer les tables. Le langage de manipulation des données pour créer, utiliser et maintenir une base de données est le SQL pour Structured Query Langage. Nous allons maintenant examiner les instructions de ce langage pour créer la base de données et les tables qui lui sont associées. Volontairement, nous utiliserons en priorité les instructions utilisables sur MySQL. Le logiciel MySQL est un serveur de base de données SQL très rapide, multi−threadé, multi−utilisateur et robuste. Le serveur MySQL est destiné aux missions stratégiques et aux systèmes de production à forte charge, ainsi qu'à l'intégration dans des logiciels déployés à grande échelle. MySQL est une marque déposée de MySQL AB . MySQL version 3.22 a une limite de 4Go par table. Avec le nouveau format de table MyISAM , disponible avec MySQL version 3.23, la taille maximale des tables a été poussée à 8 millions de teraoctets (2 ^ 63 octets). Extrait du manuel de référence de MySQL : MySQL est un serveur de bases de données relationnel. Un serveur de bases de données stocke les données dans des tables séparées plutôt que de tout rassembler dans une seule table. Cela améliore la rapidité et la souplesse de l'ensemble. Les tables sont reliées par des relations définies, qui rendent possible la combinaison de données entre plusieurs tables durant une requête. Le SQL dans `` MySQL '' signifie `` Structured Query Language '' : le langage standard pour les traitements de bases de données. MySQL est Open Source . Open Source (Standard Ouvert) signifie qu'il est possible à chacun d'utiliser et de modifier le logiciel. Tout le monde peut télécharger MySQL sur Internet, et l'utiliser sans payer aucun droit. Toute personne en ayant la volonté peut étudier et modifier le code source pour l'adapter à ses besoins propres. Le logiciel MySQL utilise la licence GPL ( GNU General Public License ), pour définir ce que vous pouvez et ne pouvez pas faire avec ce logiciel, dans différentes situations. Si vous ne vous sentez pas confortable avec la licence GPL ou bien que vous devez intégrer MySQL dans une application commerciale, vous pouvez acheter une licence commercial auprès de MySQL AB. Licences MySQL . Pourquoi utiliser le serveur de bases de données MySQL ? Le serveur de bases de données MySQL est très rapide, fiable et facile à utiliser. Si c'est ce que vous recherchez, vous devriez faire un essai. Le serveur de bases de données MySQL dispose aussi de fonctionnalités pratiques, développées en coopération avec nos utilisateurs. Vous pouvez trouver une comparaison des performances du serveur MySQL avec d'autres systèmes de bases de données dans nos pages de tests de performances. La suite de tests comparatifs de MySQL .Le serveur MySQL a été développé à l'origine pour gérer de grandes bases de données plus rapidement que les solutions existantes, et a été utilisé avec succès dans des environnements de production très contraints et très exigeants, depuis plusieurs années. Bien que toujours en développement, le Le serveur MySQL offre des fonctions nombreuses et puissantes. Ses possibilités de connexions, sa rapidité et sa sécurité font du serveur MySQL une serveur hautement adapté à Internet. Les caractéristiques techniques du serveur MySQL . Le logiciel de bases de données MySQL est un système client/serveur, constitué d'un serveur SQL multi−threadé qui supporte différents systèmes de stockage, plusieurs logiciels clients et librairies, outils d'administration, ainsi que de nombreuses interfaces de programmation (des API ).Nous fournissons aussi le serveur MySQL sous la forme d'une librairie multi−threadé que vous pouvez inclure dans vos applications, pour obtenir un produit plus compact, plus rapide et plus facile à gérer. Il existe plusieurs méthodes pour accéder au SGBD MySQL. En voici quelques unes : Directement sur un serveur : il suffit pour cela de lancer la commande MySQL. L'accès à la base se fait alors via des lignes de commandes, en particulier avec des instructions SQL directement exécutées sur le serveur. Depuis un ordinateur distant : nous pouvons utiliser le module PhPMyAdmin, qui fournit une interface Web pour accèder au système de gestion de base de données. Cet outil propose entre autre de créer - via des formulaires - des bases de données, des tables, des enregistrements, des requêtes, etc.. CREATE DATABASE [IF NOT EXISTS] db_name Cette instruction crée une base de données avec le nom donné. Une erreur survient si la base de données existe déjà et que vous n'avez pas spécifié IF NOT EXISTS .Les bases de données MySQL sont implémentées comme des répertoires contenant des fichiers qui correspondent aux tables dans les bases de données. Puisqu'il n'y a pas de tables dans une base de données lors de sa création, la requête CREATE DATABASE créera seulement le dossier dans le répertoire de données de MySQL. DROP DATABASE [IF EXISTS] db_name Cette instruction détruit toutes les tables dans la base de données et l'efface elle même. Si vous utilisez la commande DROP DATABASE sur un lien symbolique pointant sur la base de données, le lien et la base seront effacés. DROP DATABASE retourne le nombre de fichiers qui ont été effacés du dossier de la base de données. Normalement, c'est égal à trois fois le nombre de tables. CREATE TABLE nom_table ( nom_champ1 type [NOT NULL | NULL] [DEFAULT valeur_par_defaut] [AUTO_INCREMENT] [PRIMARY KEY] [FOREIGN KEY], nom_champ2 type [NOT NULL | NULL] [DEFAULT valeur_par_defaut] [AUTO_INCREMENT] [PRIMARY KEY] [FOREIGN KEY], nom_champ2 type [NOT NULL | NULL] [DEFAULT valeur_par_defaut] [AUTO_INCREMENT] [PRIMARY KEY] [FOREIGN KEY], ...) Cette instruction SQL permet de créer une table contenant une série de champs de données. Pour chaque champ, nous allons pouvoir préciser son type, indiquer à MySQL si sa valeur peut être nulle, éventuellement si il s'agit d'un champ auto-incrémenté, et spécifier les clefs primaires et étrangères de la table. L'exécution de l'instruction CREATE TABLE par MySQL crée trois fichiers dans le répertoire de la base de données : nom_de_table.FRM : Fichier de définition de la table nom_de_table.MYD : Fichier de données nom_de_table.MYI : Fichier d'index MySQL supporte un grand nombre de types de colonnes, qui peuvent être rassemblés en trois groupes : les nombres, les dates et les chaînes de caractères. Les types de données de MySQL sont listés ci-dessous. Les codes suivants sont utilisés dans les descriptions : M : Indique la taille maximale d'affichage. Le maximum légal est 255. D : S'applique aux nombres à virgule flottante, et indique le nombre de décimales qui suivent la virgule. Le nombre maximum est de 30, mais ne doit pas être plus grand que M -2. UNSIGNED : Indique si la propriété optionnelle indiquant si un type de données est toujours positif est autorisée. Si UNSIGNED est présent, le nombre est toujours positif. ZEROFILL : la présence de cette propriété optionnelle indique que des zéros doivent être placés comme caractère de remplissage. Par exemple, pour un type INT(5) ZEROFILL, la valeur 4 sera lue 0004. Le tableau ci-dessous cite les différents types de données numériques sous MySQL. M indique la taille d'affichage, et D (valable pour les nombres en virgule flottante), représente le nombre de chiffres après la virgule. Type De 1 TINYINT(M) -128 127 SMALLINT(M) -32768 32767 MEDIUMINT(M) -8388608 8388607 INT(M) -2147483648 2147483647 BIGINT(M) -9223372036854775808 9223372036854775807 FLOAT[(M,D)] -3.402823466E+38 3.402823466E+38 DOUBLE[(M,D)] -1.7976931348623157E+308 1.7976931348623157E+308 Type TIME : MySQL lit et affiche les colonnes de type TIME au format 'HH:MM:SS'. Les valeurs TIME non valides sont transformées en date zéro '00:00:00' Type DATE : Le type DATE est prévu lorsque vous souhaitez stocker une date. MySQL affiche les valeurs de type DATE au format ' AAAA-MM-JJ '. L'intervalle de validité va de '1000-01-01' à '9999-12-31'. Les dates non valides sont transformées en "0000-00-00" Type DATETIME : Le type DATETIME est prévu lorsque vous souhaitez stocker une date et une heure. MySQL affiche les valeurs de type DATETIME au format ' AAAA−MM−JJ HH:MM:SS' Type TIMESTAMP : Le type TIMESTAMP est prévu pour stocker automatiquement l'heure courante lors d'une commande INSERT ou UPDATE . Si vous avez plusieurs colonnes de type TIMESTAMP , seule la première colonne sera mise à jour automatiquement. Les types chaînes sont CHAR , VARCHAR , TEXT . Il en existe d'autres, mais nous nous intéresserons en priorité à ceux-ci. Ces types de données vous permettent de définir des chaînes de longueur comprise entre 1 et 255 caractères. CHAR(L) : dans ce cas, quelque soit la longueur effective de la chaîne, elle sera toujours stockés sur un nombre d'octets fixe, L. Par exemple, si vous définissez CHAR (10) et que vous entrez la chaîne "Bonjour", elle sera complétée par trois espace dans la table. VARCHAR(L) : dans ce cas, MySQL stocke la chaîne, plus un octet définissant la longueur effecctive de l'enregistrement. Dans notre exemple "bonjour", cette chaîne occupera 7+1 octets dans la base. TEXT : ce type de données peut en fait être considéré comme un VARCHAR de longueur indéfini. Il n'y a pas de limitation de taille pour ce type, insensible à la casse. Dans l'absolu, ce sont les capacités du serveur qui déterminent la longueur maximale d'un TEXT. Pour aborder les différentes notions d'insertion, de modifications et de suppression d'enregistrements dans les tables des bases de données, nous allons créer une base de données qui servira de support aux différents exemple. Cette base de données est représentée par le MCD suivant :

En applicant les règles de transformation propres au MCD, on obtient ainsi le modèle relationnel suivant : PLANCHE(PLA_NUM, PLA_MARQUE, PLA_MODELE, PLA_ANNEE, PLA_TAILLE, PLA_POIDS) CLIENT(CLI_ID, CLI_NOM, CLI_PRENOM, CLI_ADR, CLI_TEL) LOUE(#PLA_NUM, #CLI_ID, LOU_DEBUT, LOUE_FIN) Ce modèle logique des données nous amène au modèle physique suivant :

Enfin, le script de création des tables est le suivant : /*==============================================================*/ /* Table : CLIENT */ /*==============================================================*/ create table CLIENT ( CLI_ID int not null, CLI_NOM varchar(100), CLI_PRENOM varchar(100), CLI_ADR varchar(200), CLI_TEL varchar(12), primary key (CLI_ID) ); /*==============================================================*/ /* Table : LOUE */ /*==============================================================*/ create table LOUE ( PLA_NUM smallint not null, CLI_ID int not null, LOU_DEBUT time, LOU_FIN time, primary key (PLA_NUM, CLI_ID) ); /*==============================================================*/ /* Table : PLANCHE */ /*==============================================================*/ create table PLANCHE ( PLA_NUM smallint not null, PLA_MARQUE varchar(50), PLA_MODELE varchar(50), PLA_ANNEE int, PLA_TAILLE real, PLA_POIDS real, primary key (PLA_NUM) ); Comme nous l'avons souligné dans le chapitre précédent, MySQL ne gère pas les clef étrangères, ni l'intégrité référentielle. Ainsi, notre modèle physique des données nous indiquait que les clefs primaires de CLIENT et PLANCHE devaient devenir clef étrangères de LOUE, mais nous n'avons pas la possibilité de la faire sous MySQl version 3.x. Nous souhaitons maintenant entrer des données dans les tables de la bases de données. Une fois de plus, nous allons être obligé de gérer nous même l'intégrité référentielle, et prendre partciulièrement soin de rentrer des données valides dans nos tables : par exemple, les occurences de la table LOUE devront faie référence à des clients et des planches qui existent ! MySQL ne nous renverra pas d'erreur si nous n'y prenont pas garde. La documentation de MySQL nous fournit la syntaxe de la commande SQL permettant d'insérer des enregistrements dans une table : INSERT [LOW_PRIORITY | DELAYED] [IGNORE] [INTO] nom_de_table [(nom_colonne,...)] VALUES ((expression | DEFAULT),...),(...),... Nous retiendrons de cette définition que pour insérer des données dans une table, nous devons avoir une instruction SQl du type : INSERT INTO NOM_TABLE (LISTE DES COLONNES) VALUES (LISTE DES VALEURS) Dans notre exemple, nous voulons insérer deux planches à voiles : INSERT INTO `planche` (`PLA_NUM`, `PLA_MARQUE`, `PLA_MODELE`, `PLA_ANNEE`, `PLA_TAILLE`, `PLA_POIDS`) VALUES ('1', 'TIGA', 'SLALOM 260', '1997', '2,60', '9'); INSERT INTO `planche` (`PLA_NUM`, `PLA_MARQUE`, `PLA_MODELE`, `PLA_ANNEE`, `PLA_TAILLE`, `PLA_POIDS`) VALUES ('2', 'EXOCET', 'WAVE 259', '1999', '2,59', '7'); Un client se présente maintenant. Nous souhaitons l'enregistrer : INSERT INTO `client` (`CLI_ID`, `CLI_NOM`, `CLI_PRENOM`, `CLI_ADR`, `CLI_TEL`) VALUES ('1', 'KURZWEG', 'Ivan', 'Rue des mouettes', '0692012345'); Il désire louer la planche de vagues Exocet. Nous devons donc enregistrer une ligne dans la table LOUE, en y mettant l'heure courante : INSERT INTO `loue` (`PLA_NUM`, `CLI_ID`, `LOU_DEBUT`, `LOU_FIN`) VALUES ('2', '1', NOW(), NULL); Dans ce cas, nous avons insérer l'heure courante en utilisant la fonction SQL NOW(), qui nous renvoie l'heure au format TIME. Pour l'heure de retour, nous n'avons rien mis, en indiquant à MySQL de remplir ce champ avec NULL. Ici, nous devons bien prendre le soin de mettre des clefs étrangères existantes. En effet, l'instruction suivante ne nous renvoie pas d'erreur : INSERT INTO `loue` (`PLA_NUM`, `CLI_ID`, `LOU_DEBUT`, `LOU_FIN`) VALUES ('3', '1', NOW(), NULL) Or, nous n'avons pas entrer de planches ayant le numéro 3. Il y a donc incohérence avec notre modèle des données, et MySQL ne le détecte pas ! Notre client a terminé sa session de navigation. Il nous ramène donc la planche à voile, et nous devons maintenant mettre à jour l'heure de retour du matériel. Pour ceci, nous allons utiliser l'instruction de modification de N-Uplet, donc la syntaxe est précisée par la documentation MySQL : UPDATE [LOW_PRIORITY] [IGNORE] nom_de_table SET nom_colonne1=expr1 [, nom_colonne2=expr2, ...] [WHERE where_definition] [ORDER BY ...] [LIMIT #] Nous retiendrons pour le moment que la mise à jour d'enregistrements se fait en utilisant une requête SQL de la forme UPDATE NOM_TABLE SET NOM_COL = VALEUR WHERE NOM_COL = VALEUR; Nous reviendrons plus tard sur la manière de rédiger des requêtes plus complexes, en utilisant des clauses WHERE plus conséquentes. Pour le moment, nous considérons que la mise à jour se fera sur un enregistrement dont nous connaissons l'identifiant. Pour mettre à jour l'occurence de la table LOUE représentant que le client numéro 1 a ramené la planche numéro 2 à l'instant : UPDATE LOUE SET LOU_FIN = NOW() WHERE PLA_NUM = 2 AND CLI_ID = 1; Pour le moment, cette instruction marche correctement, puisque le client 1 n'a jamais loué la planche 2 auparavant. Dans le cas contraire, nous aurions surement eu quelques problèmes ... La suppression de données en SQL se fait en exécutant l'instruction SQL DELETE : DELETE [LOW_PRIORITY] [QUICK] FROM nom_de_table [WHERE clause_where] [ORDER BY ...] [LIMIT lignes] Nous retriendrons de cette définition que pour supprimer un enregistrement d'une table, nous utiliserons une instruction de la forme : DELETE FROM NOM_TABLE WHERE CONDITION Dans notre exemple, supposons que nous souhaitons supprimer la planche numéro 2. Nous devons prendre soin de supprimer les enregistrement de la table LOUE correspondant, pour conserver l'intégrité référentielle. Nous commençons donc par supprimer les enregistrements de la table LOUE contenant une référence de planche égale à 2 : DELETE FROM LOUE WHERE PLA_NUM = 2; Une fois ces enregistrements effacés, nous pouvons donc effacer l'enregistrement de la table PLANCHE : DELETE FROM PLANCHE WHERE PLA_NUM = 2; Nous avons bien effacé tous nos enregistrements, et conservé l'intégrité référentielle. Nous avons vu dans les instructions SQL précédentes que nous pouvons employer une clause WHERE, qui nous permet de sélectionner les enregistrements que nous souhaitons manipuler. Nous verrons plus en détail les caractéristiques de ces clauses de sélection de données, mais nous pouvons déjà remarquer que le WHERE nous permet de "trier" les enregistrements sur des critères appliqués aux valeurs des colonnes. Ces différents critères vont par exemple être une égalité avec une valeur fixée ou calculée, ou au contraire une différence par rapport à une valeur entrée, etc ... Nous avons vu dans les chapitres précédents que les tables étaient des regroupements d'enregistrements, encore appelés lignes ou occurences. Nous avons également étudié les requêtes SQL permettant d'insérer, de modifier ou de supprimer des enregistrements. Dans ce chapitre, nous allons maintenant étudier la manière de sélectionner les lignes d'une table, en utilisant la commande SQL SELECT. Même si cette commande peut paraître simple au premier abord, elle devient vite complexe dans certains cas. Dans le prochain chapitre, nous verrons en effet comment sélectionner des données dans plusieurs tables à la fois. Dans ce chapitre, nous utiliserons pour nos exemples la base de location de planches à voiles vue dans le chapitre précédent. Cette base de données a été légèrement modifiée pour prendre en compte la gestion des locations dans le temps : un identifiant a été rajouté dans la table LOUE. Le système peut maintenant conserver l'historique des locations. La commande SELECT est définie par la syntaxe suivante : SELECT [DISTINCT ou ALL] * ou liste de colonnes FROM nom de table ou de la vue [WHERE prédicats] [GROUP BY ordre des groupes] [HAVING condition] [ORDER BY ] liste de colonnes SELECT : permet de définir les colonnes résultats, le signe * retournant toutes les colonnes des enregistrements sélectionnés FROM : définit la table sur laquelle porte la requête WHERE : le filtre portant sur les données (conditions à remplir pour que les lignes soient présentes dans le résultat GROUP BY : définition d'un sous-ensemble HAVING : filtre portant sur les résultats (conditions de regroupement des lignes) ORDER BY : tri des résultats La commande permettant d'afficher l'ensemble des lignes d'une table est donc : SELECT * FROM CLIENT Donc, afficher l'ensemble des lignes de notre table PLANCHE est donc : SELECT * FROM planche PLA_NUM PLA_MARQUE PLA_MODELE PLA_ANNEE PLA_TAILLE PLA_POIDS 1 TIGA SLALOM 260 1997 2 9 2 EXOCET WAVE 259 2000 2 7 3 MISTRAL BEAST 2003 2 5 4 BIC SAXO 2000 2 Pour afficher des lignes avec certains champs, et renommer ces champs pour l'affichage des résultats, nous pouvons exécuter la requête suivante : SELECT PLA_MARQUE AS MARQUE, PLA_MODELE AS MODELE FROM planche MARQUE MODELE TIGA SLALOM 260 EXOCET WAVE 259 MISTRAL BEAST BIC SAXO Nous pouvons égalemennt classer ces résultats par ordre alphabétique par exemple : un premier tri sur le nom de la marque, et un deuxième sur le modèle de la planche. SELECT PLA_MARQUE AS MARQUE, PLA_MODELE AS MODELE FROM planche ORDER BY PLA_MARQUE ASC, PLA_MODELE ASC MARQUE MODELE BIC SAXO EXOCET WAVE 259 MISTRAL BEAST TIGA SLALOM 260 MySQL nous propose aussi de limiter l'affichage des résultats : nous pouvons par exemple afficher les deux premières lignes des résultats : SELECT PLA_MARQUE AS MARQUE, PLA_MODELE AS MODELE FROM planche ORDER BY PLA_MARQUE ASC, PLA_MODELE ASC LIMITS 0,2 ou les lignes à partir de la troisième jusque la denière : SELECT PLA_MARQUE AS MARQUE, PLA_MODELE AS MODELE FROM planche ORDER BY PLA_MARQUE ASC, PLA_MODELE ASC LIMITS 2,-1 Nous pouvons aussi supprimer les doublons dans les résultats en utilisant l'opérateur DISTINCT SELECT DISTINCT CLI_PRENOM AS PRENOM FROM client PRENOM Ivan Paul Jean Marc Il est également possible d'afficher des calculs dans les résultats. La calcul de la masse volumique des planches donnerait par exemple : SELECT PLA_MARQUE, PLA_MODELE, PLA_POIDS / PLA_VOLUME AS MASSE_VOLUMIQUE FROM planche PLA_MARQUE PLA_MODELE MASSE_VOLUMIQUE TIGA SLALOM 260 0.1 EXOCET WAVE 259 0.088607594936709 MISTRAL BEAST 0.045454545454545 BIC SAXO 0.08 L'interêt d'une base de données ne se limite heureusement pas à un simple listage des données. Il est généralement nécessaire de donner des conditions ou filtres. Seules seront sélectionnées les lignes satisfaisant aux conditions situées après la clause WHERE. La sélection des clients habitant à ST-PAUL peut donc se faire avec la requête : SELECT * FROM client WHERE CLI_VILLE = "ST-PAUL" CLI_ID CLI_NOM CLI_PRENOM CLI_ADR CLI_VILLE CLI_TEL 1 KURZWEG Ivan Rue des mouettes ST-PAUL 0692012345 3 PAYET Jean 6 rue des hortensias ST-PAUL 0262010203 5 GRONDIN paul 23 rue des rosiers ST-PAUL 0263708090 Nous allons voir dans les paragraphes suivants l'ensemble des opérateurs permettant de réaliser les prédicats de sélection, c'est-à-dire les fonctions qui vous nous permettre d'appliquer des filtres sur les champs des enregistrements. Nous avons à notre disposition l'ensemble des opérateurs mathématiques et logiques courants :+ - * / Opérateur Symbole Addition + Soustraction - Multiplication * Division / ET logique AND OU logique OR NON logique NOT INFERIEUR < SUPERIEUR > EGALITE = Comparaison de chaînes LIKE Intervalle BETWEEN Nous pouvons ainsi sélectionner les planches qui datent d'avant 2003 : SELECT * FROM PLANCHE WHERE PLA_ANNEE < 2003 PLA_NUM PLA_MARQUE PLA_MODELE PLA_ANNEE PLA_TAILLE PLA_POIDS PLA_VOLUME 1 TIGA SLALOM 260 1997 2 9 90 2 EXOCET WAVE 259 2000 2 7 79 4 BIC SAXO 2000 2 8 100 En combinant les filtres, on peut récupérer les enregistrements des planches antérieures à 2003 et d'un volume inférieur à 100 litres : SELECT * FROM PLANCHE WHERE PLA_ANNEE < 2003 AND PLA_VOLUME < 100 PLA_NUM PLA_MARQUE PLA_MODELE PLA_ANNEE PLA_TAILLE PLA_POIDS PLA_VOLUME 1 TIGA SLALOM 260 1997 2 9 90 2 EXOCET WAVE 259 2000 2 7 79 La sélection des clients dont on a un numéro de GSM donnerait : SELECT * FROM CLIENT WHERE CLI_TEL LIKE "06%" CLI_ID CLI_NOM CLI_PRENOM CLI_ADR CLI_VILLE CLI_TEL 1 KURZWEG Ivan Rue des mouettes ST-PAUL 0692012345 2 HOARAU Paul 2 rue des Lilias ST-PIERRE 0692101112 Ici, le caractères % permet de pérciser à MySQL de sélectionner les enregistrements dont le numéro de téléphone est composé de laa manière suivante : la chaîne "06" suivie de n'importe quel caractère. En plus des différents opérateurs que nous avons vu au paragraphe précédent, nous pouvons également utiliser des fonctions sur les valeurs des champs. Nous n'en détaillerons que certaines, la liste complète de ces fonctions étant disponible dans la documentation de MySQL : TRIM ([LEADING ou TRAILING ou BOTH] [caractère] FROM nom de colonne) : permet de supprimer les espaces ou tout autre caractère spécifié avant (LEADING) ou après (TRAILING) le champ. UPPER(colonne) LOWER(colonne) : passent respectivement en majuscule et minuscules les valeurs de la colonne SUBSTRING ( nom de colonne,M,N) : extrait la sous-chaîne de caractère commençant à la Mième lettre et de longueur N. SELECT CLI_NOM, CLI_PRENOM, UPPER(CONCAT(SUBSTRING(CLI_NOM,1,1) , SUBSTRING(CLI_PRENOM,1 ,1))) AS INITIALES FROM CLIENT CLI_NOM CLI_PRENOM INITIALES KURZWEG Ivan KI HOARAU Paul HP PAYET Jean PJ PAYET Marc PM GRONDIN paul GP De la même manière, il est possible de travailler sur les dates : EXTRACT ( YEAR ou MONTH ou DAY FROM nom de colonne ) : permet d'extraire l'année, le numéro du mois ou le numéro du jour d'une date NOW() : permet de récupérer la date et l'heure courante TO_DAYS(date) : renvoie le nombre de jours depuis la date 0 jusque la date date FROM_DAYS(date) : renvoie le nombre de jours écoulées depuis la date date La sélection de toutes les locations effectuées pendant le mois d'octobre peut donc s'écrire : SELECT * FROM loue WHERE MONTH(LOU_DATE) = 10 LOU_ID PLA_NUM CLI_ID LOU_DEBUT LOU_FIN LOU_DATE 1 1 2 14:10:00 15:12:00 2003-10-06 2 1 2 16:08:00 17:35:00 2003-10-15 3 2 2 13:36:00 14:35:00 2003-10-25 Il existe de nombreuses autres fonctions de travail sur les dates, mais nous ne les passerons pas toutes en revue. Elles sont décrites précisément dans la documentation de MySQL. Il existe des fonctions de statistiques permettant par exemple de calculer le nombre de lignes qu'une requête renvoie. L'utilisation de ces fonctions nécessite souvent la présence de la clause GROUP BY, permettant de créer des sous-ensembles de lignes : les enregistrements sont groupés selon la valeur des colonnes de la clause GROUP BY. Par exemple, nous souhaitons calculer le nombre de planche du magasin : SELECT COUNT(PLA_MODELE) FROM PLANCHE COUNT(PLA_MODELE) 4 Mais si notre requête vise désormais à compter le nombre de planche par marque, nous devons grouper les lignes par marque, pour les compter : SELECT COUNT(PLA_MODELE), PLA_MARQUE FROM planche GROUP BY PLA_MARQUE COUNT(PLA_MODELE) PLA_MARQUE 1 BIC 1 EXOCET 1 MISTRAL 2 TIGA La longueur moyenne des planches serait obtenue par la requête suivante : SELECT AVG(PLA_TAILLE), PLA_MARQUE FROM PLANCHE GROUP BY PLA_MARQUE AVG(PLA_TAILLE) PLA_MARQUE 2.7799999713898 BIC 2.5899999141693 EXOCET 2.5699999332428 MISTRAL 2.6749999523163 TIGA la durée moyenne de location pourrait être obtenue par : SELECT SEC_TO_TIME( AVG(TIME_TO_SEC(LOU_FIN) - TIME_TO_SEC(LOU_DEBUT)) ) AS MOYENNE FROM loue MOYENNE 01:09:20 Nous verrons dans le chapitre suivant qu'il est également possible de filtrer les résultats d'une requête en utilisant la clause HAVING. Les index ne font pas partie du SQL, même si c'est bien ce langage qui permet de créer les index dans les SGBDR, et dans MySQL en particulier. Un index permet de spécifier à MySQL de créer structure de données afin de stocker les données dans un ordre précis, afin d'en accélérer les recherches et les comparaisons. En terme de rapidité, le gain est considérable ! Ce gain est également appréciable lors des tris et des insertions de données. Il est possible d'indexer plusieurs colonnes d'une table à la fois, mais MySQL crée automatiquement un index par table, celui relatif à la clef primaire, afin d'accélérer les accès directs à la table. Plus généralement, il est conseillé de créer des index pour les cas suivants : Les colonnes composant la clef primaire (automatique sous MySQL) Les colonnes composant les clefs étangères (obligatoire sous Mysql 5) Les colonnes les plus sollicitées par les recherches La création d'index se fait par la requête SQL suivante : CREATE INDEX Nom_Index ON Nom_Table(Nom_col1, Nom_col2, ...) Reprenons l'exemple des locations de planches à voile. MySQL a créé automatiquement les index sur les clefs primaires de chaque table. Ainsi, nous avons par défaut les index suivants : Table CLIENT : Index sur CLI_ID Table PLANCHE : Index sur PLA_NUM Table LOUE : Index sur LOU_ID Si l'on suit les recommandations listées dans le paragraphe précédent, nous allons donc devoir créer par exemple l'index supplémentaire : CREATE INDEX CLI_NOM ON CLIENT(CLI_NOM) Création d'un index sur le nom des clients et ainsi accélérer certaines recherches. Avec SQL, il est possible d'imbriquer des requêtes, et MySQL gère ce type de requêtes, depuis sa version 4.2. Sur l'exemple de la base de données Location de planche, nous voulons savoir quelle est la planche qui a le plus gros volume : la requête SQL donne SELECT * FROM t_planche WHERE pla_taille = ( SELECT MAX(pla_taille) FROM t_planche) Quand la sous requête renvoie une seule valeur, il est sûr possible d'utiliser tous les opérateurs de comparaison : SELECT * FROM t_planche WHERE pla_annee > (SELECT AVG(pla_annee) FROM t_planche)SELECT * FROM t_planche WHERE pla_poids < (SELECT AVG(pla_poids) FROM t_planche)Quand la sous requête renvoie une liste de valeur (une colonne), ll est alors possible de manipuler les sous requêtes avec des opérateurs d'existence : IN et NOT IN SELECT * FROM t_planche WHERE pla_num NOT IN (SELECT pla_num FROM t_loue) SELECT * FROM t_planche WHERE pla_num IN (SELECT pla_num FROM t_loue, t_client WHERE t_loue.cli_id = t_client.cli_id AND cli_nom like 'Ivan' ) Nous avons vu dans le chapitre précédent la sélection de données dans une seule table. Cependant, il est souvent nécessaire de manipuler plusieurs tables simultanément afin de faire des recherches plus complexes. Les jointures exploitent le modèle relationnel, et permettent d'utiliser la notion de clef étrangère. La plupart des jointures sont des equi-jointures, qui imposent de regrouper les enregistrements de plusieurs tables en fonction de l'égalité des valeurs d'une colonne. La syntaxe générale est : SELECT nom_chp1, …, nom_chpN FROM table1, table2, …, tableN WHERE table1. nom_chp1 = table2.nom_chp2 … AND table2.nom_chp2 = tableN.nom_chpN … ; Dans notre exemple, si nous souhaitons avoir la liste des locations effectuées par les clients, il nous faut donc récupérer l'identifiant du client, puis sélectionner dans la table T_LOUE les enregistrements ayant les mêmes numéros de client. une première solution est de filtrer la requête : SELECT * FROM t_client,t_loue WHERE t_client.cli_id = t_loue.cli_id Dans de telles requêtes, aucune référence de colonne ne doit être ambiguë. Si deux tables différentes contiennent deux colonnes de même nom auxquelles la requête fait référence, il faut faire précéder le nom du champ par le nom de la table : nom_table.nom_champ. SQL permet de renommer, dans la requête, les différentes tables utilisées : c’est le même procédé que celui utilisé pour les alias (renommer les champs). Cette requête nous renvoie bien la liste de toutes les locations effectuées, en rajoutant les champs de tous les clients. Il est également possible de passer par des jointures dites naturelles, sous la syntaxe suivante. SELECT * FROM t_loue INNER JOIN t_client ON t_client.cli_id = t_loue.cli_id Cette requête affiche donc la liste des champs des tables LOUE et CLIENT en liant les deux tables sur le critère du numéro client. Il est également possible de faire des requête RIGHT OUTER JOIN, qui permettent de renvoyer les enregistrement des tables ne satisfaisant pas la condition d'équi-jointure : SELECT * FROM t_loue RIGHT OUTER JOIN t_client ON t_client.cli_id = t_loue.cli_id On recherche toutes les valeurs satisfaisant la condition de jointure précisée dans prédicat, puis on rajoute toutes les lignes de la table TDroite qui n'ont pas été prises en compte au titre de la satisfaction du critère. Ainsi, on dispose dans notre exemple des locations effectuées, avec en plus les clients enregistrés mais n'ayant fait aucune location. MySQL préconise de se limiter aux jointures droites (RIGHT), et si besoin de modifier une jointure gauche (LEFT) en droite en inversant le sens des tables. Plus que des requêtes d'équi-jointures (c'est-à-dire joignant des champs de deux tables sur un critère d'égalité), il est bien sûr possible de sélectionner des champs de plusieurs tables distinctes sur des critères différents. Par exemple, nous souhaitons dans notre base de location de planches à voiles sélectionner l'ensemble des données des locations portant sur des planches de plus de 2,65 mètres. La requête SQL pourrait donner : SELECT * FROM LOUE, CLIENT, PLANCHE WHERE CLIENT.CLI_ID = LOUE.CLI_ID AND LOUE.PLA_NUM = PLANCHE.PLA_NUM AND PLA_TAILLE > 2.65 Nous avons dans cette requête : deux jointures : sur le numéro de client et sur le numéro de planche, qui correspondent aux clefs étangères. Les champs ayant le même nom dans les tables, nous sommes obligés de préciser à chaque fois de quelle table nous voulons sortir le champ, en faisant précéder le nom du champ du nom de la table. un filtre : il s'agit ensuite filtrer les enregistrements provenant des jointures, en utilisant la condition fixée : la longeur de la planche doit être inférieure à 2,65 mètres. Sous MySQL comme sous la plupart des SGBDR, il est possible de définir des groupes et des utilisateurs, afin d'adopter une stratégie de sécurité. En effet, nous allons pouvoir restreindre certaines opérations sur la base de données à certains groupes ou certains utilisateurs. Ainsi, il sera possible d'autoriser la mise à jour des tables pour certains utilisateurs, et la refuser pour d'autres ! Dans le cas d'applications WEB, il est bien sûr possible de créer autant d'utilisateurs MySQL que d'utilisateurs du site ou de l'Intranet. Mais nous verrons dans le paragraphe consacré à l'optimisation de MySQL que multiplier les utilisateurs peut avoir pour conséquence de ralentir fortement le serveur de base de données. Il est donc généralement préférable de créer un compte utilisateur permettant d'administrer la base de données, et un ou deux comptes utilisateurs n'ayant pas de droits de modification de la structure de la base (ne pouvant pas supprimer de tables, d'en créer, etc..), mais pouvant réaliser des insertions, des modifications ou des suppressions d'enregistrements. Nous allons voir dans le paragraphe suivant comment créer avec le langage SQL de comptes MySQL et leur affecter des droits. Il est possible de créer des utilisateurs en modifiant directement la table USERS dans la base de données MySQL. Ainsi, en ajoutant un nouvel enregistrement dans cette table, un utilisateur est directement créé. Cependant, cette méthode est source d'erreurs de syntaxe et d'attribution des droits. Ainsi, et comme le recommande la documentation de MySQL, il vaut mieux effectuer les opérations de mise à jour des utilisateurs et des droits avec la commande MySQL GRANT. La syntaxe de cette requête est la suivante : GRANT priv_type [(liste_colonnes)] [, priv_type [(liste_colonnes)] ...] ON nom_de_table | * | *.* | nom_base.* TO nom_utilisateur [IDENTIFIED BY [PASSWORD] 'password'] L'ajout d'un utilisateur sur la base de données LOCATION_PLANCHE serait donc : GRANT USAGE ON * .Location_planches TO "util2"@ "%"IDENTIFIED BY "********"; GRANT SELECT , INSERT , UPDATE , DELETE ON `Location_planches` . * TO "util1"@ "%"; Créer un nouvel utilisateur sur la machine locale, ayant tous les droits sur toutes les bases donnerait : GRANT ALL PRIVILEGES ON *.* TO ikare@localhost IDENTIFIED BY 'motdepasse' WITH GRANT OPTION; La révocation des privilèges se fait par la commande REVOKE, dont la syntaxe est la suivante : REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ... ON {tbl_name | * | *.* | db_name.*} FROM user [, user] ... REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ... Une fois les droits ajoutés (ou enlevés) pour un (des) utilisateur(s), il ne faut pas oublier de les recharger, en utilisant la commande FLUSH : FLUSH PRIVILEGES; Enfin, un moyen simple et efficace de créer des utilisateurs et de leur attribuer des droits, est de passer par l'outil PhpMyAdmin ! En effet, PhpMyAdmin (généralement disponible chez la plupart des fournisseurs d'accès), propose sous son interface graphique une gestion simple et complète des utilisateurs : ajout d'un nouvel utillisateur, mise à jour de ses droits, etc.. Dans la commande GRANT ou REVOKE, les droits peuvent être définis selon la liste suivante, selon les privilèges désirés. Droit Signification ALL [PRIVILEGES] Tous les droits sauf WITH GRANT OPTION ALTER Autorise l'utilisation de ALTER TABLE CREATE Autorise l'utilisation de CREATE TABLE CREATE TEMPORARY TABLES Autorise l'utilisation de CREATE TEMPORARY TABLE DELETE Autorise l'utilisation de DELETE DROP Autorise l'utilisation de DROP TABLE EXECUTE Autorise l'utilisateur à exécuter des procédures stockées (pour MySQL 5.0) RELOAD Autorise l'utilisation de FLUSH INDEX Autorise l'utilisation de CREATE INDEX et DROP INDEX SELECT Autorise l'utilisation de SELECT SHOW DATABASES SHOW DATABASES affiche toutes les bases de données SHUTDOWN Autorise l'utilisation de mysqladmin shutdown UPDATE Autorise l'utilisation de UPDATE USAGE Synonyme de ``pas de droits'' GRANT OPTION Synonyme pour WITH GRANT OPTION Nous avons vu que les requêtes SQL de sélection de données peuvent s'écrire de multiples manières. Ainsi, une requête peut s'effectuer plus ou moins rapidement selon l'ordre des conditions de sélection. De manière générale, il est conseillé de placer les conditions les plus restrictives en début de requêtes. Nous avons également vu que nous avions la possibilité d'ajouter des index aux tables. Ainsi, si des requêtes manipulent souvent des colonnes de certaines tables, il peut être intéressant de créer des index sur ces colonnes. Il existe d'autres moyens plus technique d'optimiser les requêtes sur MySQL, mais il faut généralement accéder directement au serveur. La documentation de MySQL détaille ces différents points. Outre la bonne rédaction des requêtes, c'est au niveau même de la conception que nous pouvons agir. En effet, un découpage cohérent des tables dans la base de données peut accélérer considérablement l'accès aux données : en effet, si un index n'est pas créé sur une colonne, MySQL doit lire l'ensemble des données de la table pour accéder à un enregistrement. Plus la taille des enregistrements sera réduite, plus la lecture sera rapide. Cette taille peut être diminué en concevant un modèle relationnel efficace, et en choisissant avec précaution les types de données des colonnes. Le mode transactionnel permet de gérer les requêtes par lot, et ainsir de garantir une certaine intégrité dans la base de données en cas de problèmes sur le serveur (panne, etc..), et de gérer les conséquences des accès concurrentiels : comment doit se comporter le SGBDR dans le cas d'une sélection et d'une suppression intervenant en même temps par exemple. MySQL ne gère pas par défaut le mode transactionnel : il faut en effet recompiler le moteur du SGBD avec l'option InnoDB pour bénéficier des avantages des transactions. Peu de fournisseurs Web propose cette implémentation, mais elle devrait être présente dans la version 5.0 de MySQL. MySQL ne gère pas l'intégrité référentielle, nous l'avons vu dans les chapitres précédents. C'est un problème majeur pour les puristes. MySQL ne gère pas les sous-requêtes, mais ce sera fait dans MySQL 5.0 MySQL ne peut pas gérer les procédures stockées, qui augmentent la rapidité des requêtes. D'une manière générale, on peut dire que MySQL est relativement rapide pour les lectures de données, et capable de supporter quelques dizines connexions simultanées. Mais ce SGBDR est souvent critiqué pour ses faiblesses (choix défendus par les créateurs de MySQL) et de nombreux développeurs se tournent vers PostGreSQL.