Etre capable de concevoir un schéma relationnel.
Etre capable de créer une base de données relationnelle et d’en manipuler les données avec le langage SQL.
Niveau requis Aucune connaissance préalable n’est requise.
Durée 3 jours
Infotique - 2 -
conception des bases de données relationnelles ............................................ 5
1. Introduction aux bases de données ................................................................................ 5
1.1. Architecture d’un système informatique utilisant des bases de données ........................................ 5
1.2. Les trois niveaux de description des données ................................................................................... 5
2. La conception des bases de données .............................................................................. 6
2.1. les deux étapes principales de la conception .................................................................................... 6
2.2. Objectif de la modélisation ............................................................................................................... 6
2.3. Raisonnements et démarche pour la conception des bases de données ......................................... 7
2.4. Démarche pour la conception des modèles de données .................................................................. 9
2.5. Quelques représentations intéressantes ........................................................................................ 13
2.6. Les contraintes ................................................................................................................................ 17
Systèmes de gestion de bases de données .................................................... 21
1. Indépendance des niveaux physique / interne / externe ............................................. 21
2. Manipulation des données par des langages non procéduraux ................................... 22
3. Partage des données ..................................................................................................... 22
4. Sécurité des données .................................................................................................... 23
5. Principales fonctions assurées par les SGBD ................................................................. 23
Le modèle relationnel ................................................................................... 24
2.1. Domaine .......................................................................................................................................... 24
2.2. Relation ........................................................................................................................................... 24
2.3. Attribut ............................................................................................................................................ 25
2.4. Clefs ................................................................................................................................................. 25
2.5. Vues ................................................................................................................................................. 26
3. Les opérateurs relationnels ........................................................................................... 28
3.1. Les opérateurs uniares .................................................................................................................... 29
3.2. Les opérateurs n-aires ..................................................................................................................... 29
3.3. Les agrégats ..................................................................................................................................... 32
4. Les contraintes .............................................................................................................. 32
Infotique - 3 -
4.2. Contraintes sur une colonne ........................................................................................................... 33
4.3. Contraintes d’intégrité référentielle ............................................................................................... 35
5. Les règles de normalisation ........................................................................................... 36
5.1. Première forme normale ................................................................................................................. 36
5.2. Deuxième forme normale ............................................................................................................... 36
5.3. Troisième forme normale................................................................................................................ 36
6. Les règles de traduction modèles conceptuels de données -> schémas relationnels .. 37
6.1. Traduction des entités..................................................................................................................... 37
7. Exemple récapitulatif .................................................................................................... 38
7.3. Enoncé ............................................................................................................................................. 39
7.4. Solution ........................................................................................................................................... 39
2. Normes .......................................................................................................................... 44
4. La création et la modification de schémas .................................................................... 45
4.1. Création de schéma ......................................................................................................................... 45
4.2. Création de table ............................................................................................................................. 45
4.3. Modification de table ...................................................................................................................... 46
4.4. Ajouter des contraintes ................................................................................................................... 47
4.5. Suppression de table ....................................................................................................................... 47
4.6. Création de vues.............................................................................................................................. 47
5.1. Insertion de lignes ........................................................................................................................... 48
5.2. Modification .................................................................................................................................... 48
6. La consultation des données ......................................................................................... 50
6.1. Forme canonique des requêtes SELECT .......................................................................................... 50
6.2. Les opérateurs : booléens, BETWEEN, LIKE… .................................................................................. 50
6.3. Utilisation de fonctions SQL ............................................................................................................ 52
6.4. Fonctions numériques ..................................................................................................................... 53
Infotique - 4 -
6.9. Les sous-requêtes ............................................................................................................................ 57
7.1. Accorder une autorisation .............................................................................................................. 58
7.2. Révoquer une autorisation.............................................................................................................. 58
2.1. L’utilisation en mode commande .................................................................................................... 59
2.2. Utilisation via l’utilitaire PHPMYADMIN .......................................................................................... 63
2.3. Utilisation via un programme PHP .................................................................................................. 63
3. Eléments d’administration de MySQL ........................................................................... 68
3.1. Administrer comptes utilisateurs et autorisation ........................................................................... 68
3.2. Créer une base de données ............................................................................................................. 70
3.3. Afficher, insérer, modifier, supprimer des données ....................................................................... 74
3.4. Exécuter des requêtes SQL .............................................................................................................. 74
3.5. Sauvegarder, importer et exporter ................................................................................................. 75
4. Exemple récapitulatif .................................................................................................... 76
4.1. Premier exemple – recherche dans une base de données et affichage du résultat dans un
formulaire ..................................................................................................................................................... 76
Bases de données relationnelles & SQL
Infotique - 5 -
CONCEPTION DES
données
1.1. ARCHITECTURE D’UN SYSTEME INFORMATIQUE UTILISANT DES BASES DE
DONNEES
Premier composant- la base de données que l’on peut considérer en première approche comme un stock de données sur support permanent
Deuxième composant - un Système de Gestion de Base de Données (SGBD) dont la fonction est la manipulation des données de la base de façon efficace et sure : mise à jour et consultation
Troisième composant : une ou des application(s) informatiques qui constituent des interfaces entre les utilisateurs et leur logique « métier » et le SGBD
1.2. LES TROIS NIVEAUX DE DESCRIPTION DES DONNEES
Le niveau conceptuel qui s’attache à décrire (à représenter) la sémantique d’un ensemble d’objets de gestion constituant un « domaine » sans préoccupation de représentation en machine. Ce niveau sera représenté par un « modèle conceptuel des données ».
Le niveau interne (ou logique) qui représente l’implémentation du niveau conceptuel pour une classe de solutions informatiques : par exemple les Systèmes de Gestion de Bases de Données Relationnelles SGBDR. Dans le contexte d’un SGBD relationnel, ce niveau sera représenté, par exemple, par un « schéma relationnel ».
Bases de données relationnelles & SQL
Infotique - 6 -
Le schéma, unique, de la base de données est parfois nommé « schéma canonique » par opposition aux schémas liés aux applications.
Le niveau externe qui décrit la vision des applications (perception via les besoins utilisateurs) sur les données. Ce niveau sera lui aussi représenté par des schémas relationnels qui constitueront des « vues ».
2. La conception des bases de
données
2.1. LES DEUX ETAPES PRINCIPALES DE LA CONCEPTION
Dans le cadre des bases de données relationnelles, le résultat de l’opération de conception d’une base de données est un « modèle logique de données » ou « schéma relationnel » immédiatement implémentable avec le SGBD choisi.
L’opération de conception se déroule généralement en deux étapes de poids différents :
Une étape de modélisation sémantique des données dont le résultat est un ou plusieurs « modèles conceptuels des données « (vocabulaire Merise) ou diagrammes de classes (vocabulaire UML). Cette étape représente la plus grande part de l’effort de conception.
Une étape de traduction des modèles conceptuels des données ou diagrammes de classes en schémas relationnels.
2.2. OBJECTIF DE LA MODELISATION
D’une façon générale un modèle est la représentation d’un objet réel tel que la manipulation du modèle vaille celle de l’objet lui-même. Le modèle « simule » l’objet représenté.
Le modèle est présenté dans un formalisme adéquat.
Le modèle ne préjuge d’aucune solution d’implémentation (base de données ou autre).
La modélisation de données vise en premier lieu à « capturer » la sémantique d’objets de gestion dans un document.
Le document résultant est exprimé dans un formalisme adapté dont les principales qualités doivent être notamment :
L’expressivité : utilisation d’un nombre de signes réduit pour exprimer n’importe quelle situation
La simplicité d’interprétation pour permettre un dialogue sans ambigüité entre utilisateurs et concepteurs
Un modèle conceptuel des données ne doit pas essayer de représenter le point de vue des
applications (besoin en données) mais le point de vue sémantique d’un domaine : gestion des
Bases de données relationnelles & SQL
Infotique - 7 -
effectifs, manuscrits médiévaux, observatoire virtuel… Un modèle de données vise la plus grande neutralité de point de vue sur le domaine considéré.
2.3. RAISONNEMENTS ET DEMARCHE POUR LA CONCEPTION DES BASES DE
DONNEES
Le modèle « Entité / Association »
Le diagramme de classe UML 2
2.3.1. Le modèle « Entité / Association » Il s’agit d’un modèle graphique à base de deux objets : les entités et les associations.
2.3.1.1. Les représentations graphiques
Graphiquement, une entité est représentée par un rectangle doté de deux compartiments :
Un premier compartiment pour le titre : « Personne », « Unité »
Un second compartiment pour les propriétés de l’entité, c'est-à-dire toutes les informations pouvant lui être associées.
Une association est représentée par un rectangle aux bords arrondis. Une association peut posséder un titre (« affecté ») ainsi que des propriétés.
2.3.1.2. Sémantique
Entités
Du point de vue de la sémantique, une entité représente un objet majeur dans le domaine de l’utilisateur, c'est-à-dire d’un objet homogène et consistant et d’un objet aisément distinguable des autres objets du domaine.
Les propriétés à l’intérieur d’une entité sont fortement couplées : le numéro d’agent, le nom d’agent et la date de naissance agent sont par exemple fortement liés.
Bases de données relationnelles & SQL
Infotique - 8 -
Une association représente un couplage sémantique entre plusieurs objets du domaine de l’utilisateur.
Une association est le signe d’un couplage entre données mais moins fort qu’entre données appartenant à une même entité. Les données numéro agent et code unité sont couplées mais d’une façon moins forte que sont couplées les données numéro agent et nom agent.
Le titre d’une association est souvent une forme verbale.
Une association peut elle-même porter des propriétés.
La dimension d’une association est le nombre d’entités y participant.
La plupart des associations sont binaires (dimension de deux), mais on peut représenter des associations d’une dimension supérieure.
Une dimension supérieure à trois ou quatre est souvent le signe d’une erreur de représentation.
L’exemple ci-dessous présente une association de dimension trois.
L’association porte une propriété.
Une association peut être définie d’une entité sur elle-même :
Une personne est supérieure hiérarchique d’une autre
Un mot clef peut être synonyme (ou antonyme ou dérivé…) d’un autre
Plusieurs associations peuvent être définies entre deux mêmes entités
Bases de données relationnelles & SQL
Infotique - 9 -
2.3.1.3. Les cardinalités
Chaque « patte » d’association est qualifiée par un couple de cardinalité mesurant une sorte d’intensité de participation d’une entité à une association.
Le couple de cardinalité est un couple d’entier : (cardinalité minimum, cardinalité maximum).
Par exemple : une personne est affectée au minimum à aucune unité et au maximum à une unité. Le couple de cardinalité est : (0, 1).
Les cardinalités minimum sont 0 ou 1
Les cardinalités maximum sont 1 ou n
Les cardinalités sont l’indication de contraintes sur la participation d’une entité à une assocation.
Ces contraintes sont indiquées pour la participation minimum : 0 (pas de contrainte) et 1 (contrainte) et pour la cardinalité maximum : 1 (contrainte) et n (pas de contrainte).
2.3.1.4. Les identifiants
Une des règles essentielles liées à la construction des modèles est la garantie d’absence de doublons d’occurrences d’entités.
L’identifiant d’une entité est une propriété ou la combinaison minimum de propriétés nécessaire pour distinguer deux occurrences d’une entité.
Plusieurs propriétés ou combinaisons de propriétés peuvent parfois jouer le rôle d’identifiant, il importe de choisir parmi les identifiants potentiels celui qui jouera ce rôle.
Un identifiant peut être « relatif », c'est-à-dire qu’il n’identifie une entité que dans le contexte de la participation de celle-ci à une association.
Dans l’exemple ci-dessous une classe est identifiée par un numéro de classe (par exemple A2) et par un niveau (par exemple 6ème). L’identifiant complet de Classe est donc la combinaison de numéro de classe et de niveau, numéro de classe étant un identifiant relatif.
2.3.1.5. Identifiant d’une association
L’identifiant d’une association est constitué de la collection des identifiants des entités participant à l’association.
Dans l’exemple cité plus haut et concernant les Personnages, les Textes et les Rôles, l’identifiant de l’association « intervient » est constitué de la collection des identifiants de Personne, de Rôle et de Texte.
2.4. DEMARCHE POUR LA CONCEPTION DES MODELES DE DONNEES
Bases de données relationnelles & SQL
Infotique - 10 -
2.4.1. Première étape : préparation du projet Les deux tâches préalables à mener au minimum sont les suivantes :
Mener l’étude d’opportunité
Délimiter le domaine
2.4.2. Deuxième étape : établissement du dictionnaire des données et du dictionnaire des règles
Un dictionnaire des données est un document à deux colonnes :
Nom de la donnée
Signification de la donnée
Le dictionnaire des données se construit après avoir délimité précisément le domaine.
2.4.2.1. Dresser la liste des données
La première étape de constitution du domaine consiste en un relevé systématique de toutes les informations du domaine jugées « pertinentes ».
Ce travail s’appuie principalement sur le dépouillement de documents existants (documents écrits, écrans d’applications…)
La principale préoccupation est de dresser un relevé complet.
A l’issue de cette première étape, on dispose d’une liste « brute » d’informations.
2.4.2.2. Epurer la liste des données
La deuxième étape vise à épurer la liste obtenue en la débarrassant :
Des informations calculées
Des synonymes
Des polysèmes
Les informations calculées ne seront pas stockées dans la future base de données pour deux raisons :
Si des résultats de calcul étaient stockés, ils deviendraient faux dès qu’un des opérandes changerait de valeur
Les résultats peuvent être recalculés à tout instant
La suppression des synonymes et des polysèmes permet de lever toutes les ambigüités de représentation des informations et d’interprétation de leur restitution.
2.4.2.3. Dictionnaire des règles
Le dictionnaire des règles consigne l’énoncé des principales règles de gestion dans le but de déterminer comment associer les données entre elles (soit en les regroupant au sein d’une même entité, soit en associant des entités).
Bases de données relationnelles & SQL
Infotique - 11 -
2.4.3. Troisième étape : ébaucher le modèle de données Il n’est en général pas très difficile de produire une première ébauche de modèle de données.
Une démarche possible est la suivante :
1) Identifier les principaux objets du domaine de gestion concerné
2) Dessiner les entités (au moins les entités majeures)
3) Dessiner les associations en s’appuyant sur le dictionnaire des règles
4) Préciser les cardinalités
5) Choisir les identifiants
2.4.4. Quatrième étape : supprimer les redondances et les multivaluations Le premier objectif d’un modèle est de « capturer » la sémantique d’un domaine.
Un autre objectif essentiel d’un modèle est d’éviter les anomalies de représentation et de cohérence liées à :
La redondance de certaines informations
Au caractère multivalué de certaines propriétés
La redondance des informations est une des principales sources d’incohérence des bases de données.
Si une même valeur doit être répétée plusieurs fois (une orthographe de pays par exemple), elle risque de ne pas l’être d’une façon identique ce qui rendrait impossible toute recherche sur la propriété concernée (le pays par exemple)
En cas de mise à jour, il n’est pas garanti que toutes les occurrences de la valeur soit bien mises à jour (le Zaïre devient le congo…)
Le problème de la redondance d’une propriété est entièrement résolu par la création d’une nouvelle entité de type référentiel.
Exemple
La solution est :
Infotique - 12 -
La multivaluation des informations, classique dans les bases de données réalisées sans méthode, entraine une mauvaise représentation des données et un futur accès malaisé à celles-ci. Par exemple, si une entreprise implantée sur plusieurs sites était représentée sous la forme : entreprise, site 1, site 2, site 3…
Il faudrait pour bien faire pouvoir prévoir le nombre maximum de sites,
La majorité des entreprises auraient des propriétés vides
Pour rechercher toutes les entreprises implantées sur un site donné, il faudrait écrire une requête du type : Site = site 1 ou Site = site 2….
Le problème de la multivaluation est entièrement résolu par la création d’une nouvelle entité.
Exemple
Cette entité possède en fait une propriété ville multivaluée.
Le fait qu’une unité soit implantée dans 4 ou 5 villes ne pourrait être représenté.
La solution est la suivante :
La modélisation et surtout la génération de la base de données sont grandement facilitées par
l’utilisation d’un AGL, si possible libre, comme DBDesigner (v4).
Bases de données relationnelles & SQL
Infotique - 13 -
2.5. QUELQUES REPRESENTATIONS INTERESSANTES
2.5.1. Les associations réflexives
Cette modélisation permet d’exprimer qu’une entité est associée à elle-même.
Peuvent être traitées de cette façon les associations exprimant une hiérarchie entre occurrences d’une entité.
Dans l’exemple ci-dessous, on modélise un organigramme hiérarchique. L’association n’est pas symétrique, le « rôle » de chacune des pattes de l’association doit être précisé : « est le » et « a pour ».
Peuvent également être traitées les associations exprimant une équivalence entre occurrences d’une entité.
Dans l’exemple ci-dessous, les deux associations sont symétriques, il n’est pas nécessaire de préciser le « rôle » de chacune des pattes de l’association.
Bases de données relationnelles & SQL
Infotique - 14 -
2.5.2. Généralisation / spécialisation
Une difficulté récurrente de la modélisation est de choisir entre représenter des objets comme étant des objets différents ou comme étant un seul objet.
Le mécanisme dit de « généralisation / spécialisation » appuyé sur le concept d’héritage permet de faire coexister les deux points de vue.
Cette modélisation permet d’exprimer que :
Des entités sont traitées de la même façon (un agent titulaire, un CDD, un thésard sont tous trois collaborateurs d’une unité de recherche).
Les mêmes entités sont traitées différemment (un agent titulaire, un CDD, un thésard n’ont pas toutes leurs propriétés en commun).
Bases de données relationnelles & SQL
Infotique - 15 -
2.5.3. Les historiques
En cas de modification d’une occurrence d’association, on peut souhaiter conserver l’ancienne valeur. On ajoute alors la nouvelle valeur aux anciennes plutôt que de remplacer la dernière valeur par la nouvelle.
Si la cardinalité maximum était de 1, elle est alors de n.
La modélisation ci-dessous permet de conserver l’historique des nominations des personnes à des grades successifs.
L’identifiant de l’association possèdeGrade est constitué par le couple des identifiants des entités associées, soit(numeroPersonne, CodeGrade).
Il sera impossible d’enregistrer deux fois la même occurrence d’association (Personne, Grade) ce qui convient bien car il est impossible d’être nommé deux fois au même grade dans la carrière d’une personne.
Dans l’exemple ci-dessous, l’association est de dimension 3 et son identifiant est (numeroPersonne, codeSite, Date).
En effet, il doit être possible d’enregistrer deux affectations successives d’une même personne à une même unité, l’identifiant ne peut par conséquent être limité au couple (numeroPersonne, codeSite) et doit contenir un troisième élément quel qu’il soit (date est le plus courant).
Bases de données relationnelles & SQL
Infotique - 16 -
La date est placée dans une entité (pseudo entité) Date et n’est pas considérée comme une
propriété de l’association affecté pour que l’on puisse distinguer deux affectations successives d’un agent à une même unité.
2.5.4. La méta modélisation
Cette modélisation permet, en introduisant un degré d’abstraction supplémentaire, de représenter de façon commune un grand nombre d’entités qu’il serait peu pratique de considérer comme étant tout à fait différentes.
On souhaite modéliser les équipements installés sur les carrefours à feu d’un département.
Dans le but de pouvoir assurer la maintenance de ces équipements et de pouvoir éditer des statistiques périodiques, les caractéristiques techniques des équipements doivent être décrites.
Les équipements sont très divers : poteaux, lampes, radars, boucles enterrées, modems, pilotes d’armoires à feu… et leurs caractéristiques très différentes.
Une première modélisation « naïve » donnerait ceci (on ne tient pas compte des propriétés redondantes) :
Bases de données relationnelles & SQL
Infotique - 17 -
2.6. LES CONTRAINTES
D’une façon générale, la qualité des données dans un système d’information, automatisé ou non, dépend de la bonne structuration de celles-ci et aussi pour une part importante du respect d’un certain nombre de contraintes de gestion de celles-ci.
La qualité des données contenues dans une base de données dépendra donc en grande partie du soin apporté identifier ces contraintes, les exprimer et les implémenter dans la base.
Les contraintes peuvent être exprimées :
Soit dans le modèle (conceptuel) des données
Soit dans le schéma relationnel
Soit lors de l’implémentation du schéma relationnel.
Il est notamment possible d’exprimer un certain nombre de contraintes sémantiques dans un modèle de données, même s’il n’existe pas de langage approprié et complet pour le faire :
Soit sous forme purement textuel (essentiellement)
Soit sous forme normalisée
2.6.1.1. Contrainte d’existence
Cette contrainte exprime le fait qu’une propriété possède nécessairement une valeur.
2.6.1.2. Contrainte d’unicité
Cette contrainte exprime le fait qu’une propriété ne peut posséder deux fois une même valeur.
Bases de données relationnelles & SQL
Infotique - 18 -
2.6.1.3. Contrainte d’identifiant
Une contrainte d’identifiant est la combinaison d’une contrainte d’existence et d’une contrainte d’unicité.
2.6.1.4. Contrainte de type
Cette contrainte exprime le fait qu’une propriété appartient à un des types suivants : texte (ou caractère ou alphanumérique), numérique, date…
Si la propriété est de type texte, on peut spécifier s’il s’agit d’une propriété dont la longueur (nombre de caractères) est fixe ou variable et indiquer une longueur qui sera soit une longueur exacte, soit une longueur maximum).
2.6.1.5. Contrainte de valeur
Les contraintes de valeurs peuvent s’exprimer de plusieurs façons :
Par encadrement : valeur minimale et valeur maximale
En définissant un domaine de valeur.
Dans l’exemple ci-dessous, on définit un domaine de valeurs pour la propriété quotitePersonne, stipulant que cette propriété ne peut prendre qu’une parmi les valeurs suivantes : 50, 60, 70, 80, 90, 100.
Si le domaine contient plus de quelques valeurs (une dizaine), on préfèrera construire une
entité.
2.6.1.6. Contrainte de stabilité
Cette contrainte exprime le fait que la valeur d’une propriété ne change pas dans le temps.
Les propriétés identifiables possèdent en général des valeurs stables.
Bases de données relationnelles & SQL
Infotique - 19 -
2.6.2. Contraintes d’intégrité référentielle La contrainte d’intégrité référentielle entre deux entités stipule que si une occurrence de la première entité est associée à une occurrence de la deuxième entité, la modification ou la suppression de cette dernière ne doit pas entrainer la survenue d’une association « vide ».
Par exemple, si plusieurs personnes sont affectées à un site, il doit être impossible de supprimer le site sans soit « recaser » les personnes dans un site existant, soit supprimer les personnes concernées (ceci n’est qu’un point de vue informatique).
Il y a contrainte d’intégrité référentielle pour chacune des associations.
Cette question est traitée plus en détail au chapitre consacré au modèle relationnel.
2.6.3. Contraintes sur les pattes d’associations Une patte d’association peut être « verrouillée », c'est-à-dire que les associations entre les occurrences de deux entités ne peuvent être mises à jour, c'est-à-dire ni modifiées ni supprimées.
Dans l’exemple ci-dessous, on exprime que si un règlement est noté comme effectué par une société, cette information ne peut pas être modifiée ni supprimée.
2.6.4. Les contraintes entre associations De même qu’il est possible d’exprimer des contraintes afférentes à des propriétés d’entités, il est possible d’exprimer des contraintes entre associations.
Les contraintes entre association peuvent décrire une des situations suivantes :
Aucune contrainte (c’est le cas général)
Partition (Totalité et Exclusion) : XT
Totalité sans Exclusion : T
Inclusion : I
)
Dans l’exemple ci-dessous, on exprime le fait que l’on ne peut être à la fois propriétaire et locataire d’une même habitation.
On peut en revanche occuper une autre position vis-à-vis de son habitation (« hébergé à titre gratuite »…). Il y a donc une contrainte d’exclusion mais pas de totalité.
Bases de données relationnelles & SQL
Infotique - 20 -
Dans l’exemple ci-dessous, on exprime le fait qu’un règlement peut s’opérer soit (exclusif) en espèces, en chèque ou en carte bancaire. Il y a donc une double contrainte : de totalité (pas d’autre modalité de règlement) et d’exclusion (un règlement ne peut s’opérer en espèces et en chèque). La contrainte est de type « X » et « T », il s’agit d’une contrainte de partition.
Ce modèle n’est donné qu’au titre d’exemple pédagogique. En réalité, une représentation de
type « généralisation / spécialisation » (voir plus haut) aurait été préférable.
Dans l’exemple ci-dessous, on exprime le fait que le responsable d’une unité est nécessairement affecté à l’unité. Le « I » désigne une inclusion.
Bases de données relationnelles & SQL
Infotique - 21 -
SYSTEMES DE
DE DONNEES
Le terme « base de données » est lié à la notion de « persistance des données ».
Une donnée est dite « persistante » si sa durée de vie excède la durée d’exécution du programme qui l’a créée. Une donnée persistante peut être rechargée en mémoire principale à tout instant.
En pratique la persistance de données est assurée par leur stockage sur un support permanent (disque…).
De ce point de vue, le terme de base de données mérite précision.
Deux acceptions peuvent être proposées :
Une acception générale : une base de données est un ensemble de données électroniques stockées sur support permanent
Une acception plus restrictive : une base de données est un ensemble de données électroniques stockées sur support permanent et manipulées par un logiciel spécialisé : un Système de Gestion de Base de Données Les Systèmes de Gestion de Base de Données imposent un certain nombre de règles de structuration des données, notamment des règles de représentation sous forme tabulaire, règles de non redondance, de non répétitivité....
1. Indépendance des niveaux
physique / interne / externe
Le niveau physique désigne le mode de stockage matériel des données sur mémoire permanente : types de fichiers, méthodes d’accès, modes de placement, procédés de chainage…, les données d’une base de données étant , comme toutes les données informatiques stockées dans des fichiers organisés suivant des modalités de placement, d’accès…
Le niveau logique désigne une perception des données sous forme tabulaire exprimant la sémantique des informations du domaine couvert par la base de données.
La fourniture d’une vision « logique » ou « niveau logique » des données permet de masquer totalement les détails de stockage physique des données : noms et emplacements des fichiers,
Bases de données relationnelles & SQL
Infotique - 22 -
organisation des fichiers : méthodes de placement, méthodes d’accès… et présente les données comme étant organisées en tables.
Il est ainsi possible qu’une modification de l’organisation physique des données, dans le but d’optimiser l’occupation mémoire ou les temps d’accès aux données, n’ait aucune incidence sur le niveau physique.
Réciproquement, il est également possible qu’une modification du schéma logique consécutif au changement d’une règle de gestion n’ait aucune d’incidence sur l’organisation physique des fichiers de stockage.
Le niveau externe désigne le niveau des applications, c'est-à-dire la vision particulière des applications sur le schéma canonique de la base. Un schéma externe est obtenu par un réarrangement des données du schéma interne, quitte à introduire des synonymes, un certain niveau de redondance…
Grâce aux mécanismes de production de schémas externes, il est possible qu’une modification applicative laisse inchangés les autres schémas externes et le schéma interne (ou presque).
Il faut bien comprendre qu’une base de données ne doit pas être liée à une utilisation
particulière des données, c'est-à-dire à une application. Une base de données organise les données suivant leur sémantique sous forme d’un schéma « canonique » auquel les applications viendront s’alimenter.
2. Manipulation des données par
des langages non procéduraux
L’accès aux données à une base de données doit pouvoir s’effectuer d’une façon totalement indépendante des structures de stockage physique (organisation en fichiers).
L’accès aux données doit pouvoir être réalisé en formant des prédicats sur la valeur des données contenues dans la base.
Les langages de manipulation doivent être relativement proches du langage naturel.
Ces langages doivent pouvoir être utilisés aussi bien en mode intercatif qu’intégré à des programmes procéduraux.
3. Partage des données
Un des objectifs majeurs des SGBD est de permettre le partage des données contenues entre plusieurs utilisateurs, plusieurs applications successivement et simultanément. Tout doit se passer comme si chaque utilisateur, chaque application était seul à utiliser (consultation et mise à jour de la base).
Bases de données relationnelles & SQL
Infotique - 23 -
La sécurité des données doit être envisagée sous deux aspects :
La protection contre les accès non autorisés est assurée par des mécanismes d’attribution explicite d’autorisations (lecture, écriture…) à des d’utilisateurs identifiés sur certains objets de la base.
La tolérance aux pannes
La tolérance aux pannes est assurée par un certain nombre de mécanismes tels que la restauration de données sauvegardées, journalisation des transactions, reprise à chaud, à froid
5. Principales fonctions assurées
par les SGBD
Les principales fonctions d’un SGBD peuvent être présentées de façon synthétique :
La définition des schémas
La recherche de données
Le contrôle de l’intégrité des données
La gestion de la sécurité
Bases de données relationnelles & SQL
Infotique - 24 -
LE MODELE
1. Objectifs du modèle relationnel
Le « modèle relationnel » est un ensemble de concepts et de règles de structuration de données, essentiellement alphanumériques, sous forme tabulaire.
Ces règles, énoncées par CODD au début des années 70, associées à un langage de requête basé sur des prédicats en logique du premier ordre (des énoncés sur les données) visent à représenter de façon assez simple la sémantique d’objets de gestion tout en évitant les anomalies de mise à jour.
2. Les concepts principaux
2.1. DOMAINE
Un domaine est un ensemble de valeurs (essentiellement alphanumériques). Comme en théorie des ensembles, un domaine peut être défini « en compréhension » et / ou « en extension ».
Le plus souvent un domaine est défini par un type de données : numérique (entier, réel, caractère, date…) et par des valeurs.
Exemple :
Domaine (années de naissances de personnes) : {1923, 1920, 1937, 2005}
Les domaines sont caractérisés par un nom : nom de personne, prénom de personne…
2.2. RELATION
Une relation est un sous-ensemble du produit cartésien de plusieurs domaines.
Exemple :
Infotique - 25 -
Une relation est donc composée de vecteurs.
Le terme consacré est celui de tuples .
D’une façon moins savante et plus courante, on parle :
De table plutôt que de relation
De ligne plutôt que de tuple
2.3. ATTRIBUT
Un attribut est une colonne d’une relation.
Le nom d’une colonne doit être évocateur de sa sémantique.
Le nom d’une colonne peut obéir à des restrictions de caractères et à une convention de nommage.
2.4. CLEFS
2.4.1. Clefs primaires Le concept de clef primaire est équivalent à celui d’identifiant conceptuel.
Les qualités d’une clef primaire sont les suivantes :
Valeur obligatoire et unicité par définition
Stabilité de valeur dans le temps
Compacité : les clefs primaires étant utilisées pour rapprocher des tables en consultation (jointures), plus les clefs sont compactes et de petite taille, plus les temps de traitement seront courts.
Une clef primaire est soit une des propriétés (ou une collection des propriétés) de la table, soit un élément artificiel (numéro d’ordre).
En pratique, l’exigence de stabilité de valeur dans le temps interdit l’utilisation d’une propriété significative et entraine l’utilisation systématique d’un numéro d’ordre (un entier autoincrémenté).
2.4.2. Clefs étrangères Une clef étrangère est la duplication de la clef primaire d’une table dans une autre table dans le but de traduire une association conceptuelle entre les deux entités représentées par les deux tables.
Le concept de clef étrangère est un des concepts majeurs du modèle relationnel.
Bases de données relationnelles & SQL
Infotique - 26 -
2.5. VUES
Une vue est un assemblage des données du schéma d’une base de données (appelé souvent « schéma canonique) visant à satisfaire les besoins d’une application en informations.
Dit autrement, un ensemble de vues liées à une application constitue un « sous schéma » relationnel, déduit du schéma de la base de données et représentant le « point de vue » de cette application sur l’ensemble des données.
Le schéma constitué des vues liées à une application peut différer sensiblement du schéma canonique :
Les vues peuvent être construites par projection (seulement certaines colonnes) et par restriction (seulement certaines lignes) des tables de base.
Les colonnes peuvent ne pas être nommées de la même façon
Des données réparties entre plusieurs tables dans le schéma canonique peuvent être assemblées en une seule vue
Les règles de structuration du modèle canonique peuvent ne pas être respectées dans les vues qui ne sont en définitive qu’une présentation des tables de base (qui doivent respecter les règles d’intégrité).
Les principaux intérêts de ce mécanisme sont :
La possibilité de masquer la complexité du schéma canonique aux applications
L’apport d’un haut niveau d’indépendance schéma canonique / vues : une modification du schéma interne n’entraine pas de changements profonds des applications et réciproquement, un changement applicatif n’entraine pas nécessairement une modification profonde du schéma canonique.
2.6. LES TYPES DE COLONNES
Pour des motifs de représentation des données en mémoire, il est indispensable de décrire chacune des colonnes d’une base de données par un type prédéfini.
Ces types sont alphanumériques ou binaires.
Aucun SGBD ne respectant scrupuleusement les normes SQL, il convient de s’intéresser aux idiomes de chacun de ceux-ci.
Les types principaux sont les suivants :
Chaines de caractères
Infotique - 27 -
2.6.1. Types chaines de caractères Une colonne de type chaine de caractères permet de stocker des caractères sous forme d’un octet (ASCII ou codes ISO 88-59-n) ou de plusieurs octets (UNICODE dans ses implémentations UTF-8 ou UTF-16 notamment).
Les principaux types chaines de caractères sont les suivants :
CHAR(n) : chaîne de longueur fixe n et d’une longueur maximum de 255 caractères. Une option permet de préciser le jeu de caractères : binaire, ASCII, UNICODE. Si le nombre de caractères effectif est inférieur à la taille fixée, ceux-ci seront complétés par des caractères « blancs » (par exemple des espaces) non restitués par les extractions.
VARCHAR(n) : chaîne de longueur variable de maximum n caractères (jusqu’à 65 535 caractères dans MySQL). Les caractères sont codés en UNICODE.
D’autres types permettent de stocker des caractères sur une taille plus importante : TEXT (n) jusqu’à 65 535 caractères pour MySQL), MEDIUMTEXT(n) : 16 MO, LONGTEXT(n) : 4,29 GO.
2.6.2. Types numériques Les deux types principaux sont :
Le type entier qui se subdivise généralement lui-même en sous types :
SMALLINT – entier non signé sur 2 octets
MEDIUMINT (pas dans la norme SQL, utilisable avec MySQL) – entier signé sur 3 octets
INTEGER – entier signé sur 4 octets
BIGINT (pas dans la norme SQL, utilisable avec MySQL) – entier signé sur 8 octets
Le type réel qui se subdivise généralement lui-même en sous types :
FLOAT – réel entre 4 et 8 octets – précision simple (7 décimales)
DOUBLE – réel sur 8 octets - précision double (15 décimales)
2.6.3. Types temporels Les principaux types temporels sont :
DATE - sur 3 octets stocke les dates comprises entre 1er janvier de l’an 1 000 jusqu’au 31 décembre 999. Le format est ‘YYYY-MM-DD’ (MySQL)
DATETIME – sur 8 octets – date et heure (MySQL)
TIME – sur 3 octets – stocke les heures de – 839 heures 59 minutes et 59 secondes à + 839 heures 59 minutes et 59 secondes (MySQL)
TIMESTAMP : sur 4 octets – instants écoulés du 1er janvier 1970 à 0h 0m jusqu’à l’année 2037. Mise à jour à chaque modification de la table (MySQL)
2.6.4. Types binaires Les colonnes binaires contiennent des chaînes de bits, sans référence à un jeu de caractères.
Peuvent être stockés dans une colonne de ce type des éléments multimédia, des applications…
Le type BLOB permet de stocker jusqu’à 65 535 octets (MySQL)
Bases de données relationnelles & SQL
Infotique - 28 -
Le type MEDIUMBLOB (n) permet de stocker jusqu’à 16 MO (MySQL)
Le type LONGBLOB (n) permet de stocker jusqu’à 4,29 GO (MySQL)
3. Les opérateurs relationnels
Les SGBDR fournissent un ensemble d’opérateurs dits relationnels dont les opérandes sont des relations (des tables) et les résultats des relations (des tables).
Les opérateurs relationnels peuvent être classés en deux catégories :
Les opérateurs « unaires » qui n’utilisent qu’un opérande
Les opérateurs « n-aires » qui utilisent plusieurs opérandes
Le modèle de référence permettant de présenter les opérateurs relationnels est le suivant :
Table Personne (nom, prénom, date de naissance, quotité, code établissement)
Table Etablissement (code établissement, nom établissement, adresse établissement)Les opérateurs unaires
Personne
quotité code établissement
EPICURE DANTE 1985-12-25 50
1 BEAU CAMPUS 12 rue de la recherche
2 CHEZ GERMAINE 33 rue des fayots
3 LE BON COIN 6 rue Cartier Bresson
Bases de données relationnelles & SQL
Infotique - 29 -
3.1. LES OPERATEURS UNAIRES
3.1.1. La projection Créé à partir d’une première table une deuxième table contenant les colonnes spécifiées de la première table.
Exemple
nom quotité
MARTIN 80
DUPOND 100
DURAND 100
DUPUY 80
DUPONT 100
EPICURE 50
3.1.2. La restriction Créé à partir d’une première table une deuxième table contenant les lignes spécifiées par un prédicat (vérifiant une condition).
Exemple
quotité code établissement
EPICURE DANTE 25/12/1955 50
3.2. LES OPERATEURS N-AIRES
3.2.1. La jointure Création d’une table en associant deux tables sur une condition d’égalité de valeurs entre une colonne de la première table et une colonne de la deuxième table.
Bases de données relationnelles & SQL
Infotique - 30 -
La jointure peut être :
Interne (ou naturelle) : la table résultat est composée des lignes de Personnes et des lignes de Etablissement pour lesquelles l’égalité est vérifiée.
Externe (gauche ou droite) : le résultat est celui de la jointure interne auquel sont ajoutées soit les lignes de la table Personne sans correspondance dans Etablissement, soit les lignes de la table Etablissement sans correspondance dans la table Personne.
Jointure interne
quotité Code établiss ement
33 rue des fayots
DUPOND MARCEL 12/10/197 8
100 1 1 BEAU CAMPUS 12 rue de la recherche
DURAND ADOLPHE 13/08/196 8
100 1 1 BEAU CAMPUS 12 rue de la recherche
DUPUY ELIANE 12/12/196 5
33 rue des fayots
DUPONT ARMELLE 05/04/198 5
recherche
3.2.2. L’union Création d’une table contenant les lignes présentes dans au moins une table parmi deux, les deux tables ayant même schéma.
Exemple
Last name First name
Infotique - 31 -
nom prénom
MARTIN ALBERT
DUPOND MARCEL
DURAND ADOLPHE
DUPUY ELIANE
DUPONT ARMELLE
EPICURE DANTE
SMITH JOHN
KRUGER HANS
Le résultat est compose des colonnes nom et prénom et des lignes présentes dans au moins une des deux table.
En général, l’opération d’union s’effectue sur deux projections.
3.2.3. L’intersection Création d’une table contenant les lignes présentes dans deux tables ayant mêmesschéma.
Exemple
nom prénom
DUPUY ELIANE
EPICURE DANTE
Le résultat est compose des colonnes nom et prénom et des lignes présentes dans les deux tables (nom = last name et prénom = first name).
En général, l’opération d’intersection s’effectue sur deux projections.
3.2.4. La différence Création d’une table contenant les lignes présentes dans une table parmi deux mais pas dans la seconde, les deux tables ayant même schéma.
Bases de données relationnelles & SQL
Infotique - 32 -
nom prénom
MARTIN ALBERT
DUPOND MARCEL
DURAND ADOLPHE
DUPONT ARMELLE
Le résultat est composé des colonnes nom et prénom et des lignes présentes dans la table Personne et pas dans la table Worker.
En général, l’opération différence s’effectue sur deux projections.
3.3. LES AGREGATS
Création d’une table par « agrégation » des lignes de la table sur les valeurs d’une colonne.
La fonction d’agrégat s’utilise généralement avec une fonction de synthèse : somme, compte, moyenne…
Exemple
quotité Nombre personnes
4. Les contraintes
Cette question a été traitée en partie dans les chapitres consacrés aux modèles conceptuels des données.
La qualité des données stockées dans une base de données est étroitement liée au respect des règles de gestion par celles-ci représentées par des contraintes déclarées par le concepteur et prises en charge par le SGBD lui-même ou par des procédures ad hoc (triggers et procédures stockées).
Les contraintes présentées ci-dessous doivent être associées aux descriptions de table afin d’être prise en charge par le SGBD plutôt que par des programmes ad hoc.
Bases de données relationnelles & SQL
Infotique - 33 -
4.1. L’INTEGRITE DES BASES DE DONNEES
Une base de données est dite intègre si les données contenues respectent l’ensemble des règles de gestion régissant les valeurs de celles-ci ainsi que leurs associations.
Une opération de mise à jour doit prendre la base dans un état d’intégrité 1 et la rendre dans un état d’intégrité 2.
4.2. CONTRAINTES SUR UNE COLONNE
4.2.1. Contrainte d’existence La colonne doit posséder une valeur.
Cette contrainte s’implémente de la façon suivante :
Colonne NOT NULL
Cette contrainte est notamment utilisée sur les clefs étrangères implémentant une patte d’association dont la cardinalité minimum est de 1.
4.2.2. Contrainte d’unicité La colonne ne doit pas contenir deux fois la même valeur.
Cette contrainte s’implémente de la façon suivante :
UNIQUE (colonne1, colonne2…)
4.2.3. Contrainte de clef primaire Cette contrainte s’implémente de la façon suivante :
Colonne … PRIMARY KEY
Infotique - 34 -
4.2.4. Contraintes de domaine La colonne obéit à certaines restrictions de valeurs : plage de valeurs….
Cette contrainte s’implémente avec la clause CHECK
Cette contrainte s’implémente de la façon suivante :
CHECK (condition de validité)
La clause CHECK peut indiquer par exemple une valeur numérique minimale et maximale
Colonne CHECK (Colonne > 0 AND Colonne <1000
Ou :
Colonne CHECK (VALUE > 0 AND VALUE <1000)
VALUE peut être utilisée à la place du nom de la colonne lorsqu’il n’y a pas d’ambiguïté (lorsque la contrainte ne porte que sur la colonne en cours de déclaration.
La clause CHECK peut indiquer par exemple un domaine
Colonne CHECK (VALUE IN(50,60,70,80,90,100))
Il est possible de déclarer une contrainte plus générale, portant sur plusieurs colonnes, avec la clause CHECK à condition de créer une contrainte nommée à l’aide de la déclaration CONSTRAINT.
CONSTRAINT nom contrainte CHECK (…)
les opérateurs arithmétiques +, -, *, /
des expressions SQL : BETWEEN, IN…
Tous les SGBD n’implémentent pas la clause CHECK. En particulier, la version 5.1 de MySQL
permet de déclarer ce type de contraintes mais celles-ci ne sont pas opérationnelles.
4.2.5. Contrainte de stabilité La valeur affectée à une colonne ne peut être mise à jour.
Bases de données relationnelles & SQL
Infotique - 35 -
4.3. CONTRAINTES D’INTEGRITE REFERENTIELLE
Cette contrainte concerne la valeur des clefs étrangères qui doivent être présentes dans les colonnes clefs primaires qu’elles réfèrent.
Soit les deux relations :
Personne (idPersonne, nomPersonne, idUnité)
Unité (idUnité, codeUnité, titreUnité)
Par exemple : une personne ne peut être affectée à un service que dans la mesure où celui-ci existe.
Il existe une contrainte d’intégrité référentielle entre la clef étrangère idUnité dans la relation Personne et la clef primaire idUnité de la table Unité : toutes les valeurs de idUnité dans la relation Personne doivent exister dans idUnité de la table Unité.
Toutes les clefs étrangères sont concernées par cette contrainte.
La contrainte d’intégrité référentielle doit être examinée vis-à-vis des trois opération de mise à jour des données :
L’insertion
La modification
La suppression
La question est triviale vis-à-vis de l’insertion : l’intégrité référentielle est assimilée à une contrainte de domaine : la valeur d’une clef étrangère doit être prise dans la liste des valeurs d’une clef primaire référencée.
La syntaxe normalisée pour implémenter une contrainte d’intégrité référentielle entre une clef étrangère et une clef primaire est :
FOREIGN KEY(colonne clef étrangère)
REFERENCES Table(colonne clef primaire)
Vis-à-vis des opérations de modification et de suppression, deux options sont possibles :
Empêcher l’opération de modification ou de suppression d’une valeur de clef primaire si celle-ci est utilisée par une clef étrangère : interdiction de modifier le code d’un site ou de supprimer un site auquel sont affectés des personnes. La syntaxe normalisée est : ON UPDATE NO ACTION et ON DELETE NO ACTION.
Propager la modification ou la suppression d’une clef primaire dans la table contenant une clef étrangère référençant cette même clef primaire : si l’on modifie la clef primaire d’une table site (ce qui ne devrait jamais se produire), on modifie automatiquement les valeurs correspondantes de clefs étrangères utilisées pour décrire les affectations ; si l’on supprime un site, on supprime également toutes les affectations à ce site. La syntaxe normalisée est : ON UPDATE CASCADE et ON DELETE CASCADE.
Bases de données relationnelles & SQL
Infotique - 36 -
5. Les règles de normalisation
Les règles de normalisation sont des règles applicables à la structuration d’une base de données dans le but de se prémunir de certaines anomalies de lecture, d’écriture, de redondance de données et de garantir la cohérence des données et un bon niveau de performance.
La normalisation des bases de données correspond en partie aux règles de non redondance et de non multivaluation appliquées aux modèles conceptuels de données.
Ne sont examinées ci-dessous que les trois premières formes normales.
5.1. PREMIERE FORME NORMALE
Une base de données est en première forme normale si les colonnes contiennent toutes des valeurs :
Atomiques du point de vue des choix de gestion
Non répétitives
Par exemple, une colonne nomPersonne peut être considérée comme une propriété atomique si on ne s’intéresse pas au nom d’usage des femmes mariées ou non atomique sinon.
5.2. DEUXIEME FORME NORMALE
Une base de données est en deuxième forme normale si elle est en première forme normale et si toutes les colonnes non clefs dépendent de la totalité de la clef.
Cette règle ne s’applique qu’aux tables dont la clef primaire est une collection de plusieurs propriétés.
Exemple
Une table Classe (niveau, numéro, âge d’entrée) dont un exemple serait (6ème, A2, 11 ans) et dont la clef primaire serait (niveau, numéro) n’est pas en deuxième forme normale car l’âge d’entrée ne dépend que du niveau et pas du numéro de la classe.
Cette structure impliquerait que l’on répète le même âge d’entrée (11 ans) pour toutes les 6ème et impliquerait d’éventuelles anomalies de mise à jour si l’âge d’entrée des 6ème était modifié.
5.3. TROISIEME FORME NORMALE
Une base de données est en troisième forme normale si elle est en deuxième forme normale et si toutes les colonnes n’appartenant pas à la clef ne dépendent pas d’une colonne non clef.
Cette règle interdit les dépendances transitives sources de redondances de données.
Une table Site (code site, nom du site, ville, pays) et dont la clef primaire est code site n’est pas en troisième forme normale car pays est en dépendance de ville (ou en dépendance transitive de la clef code site).
Bases de données relationnelles & SQL
Infotique - 37 -
Cette structure impliquerait que l’on répète le même pays pour la même ville et impliquerait d’éventuelles anomalies de mise à jour si une ville changeait de pays.
6. Les règles de traduction
modèles conceptuels de
données -> schémas relationnels
Les règles de traduction d’une entité sont plutôt triviales :
Une entité se traduit par une table
Une propriété se traduit par une colonne
Un identifiant se traduit par une clef primaire
6.2. TRADUCTION DES ASSOCIATIONS
Les règles de traduction des associations sont à peine moins triviales
Une association peut se traduire de deux façons différentes selon la situation.
6.2.1. Association binaire, cardinalité maximum de 1 Dans le cas d’une association binaire où une patte porte une cardinalité maximum de A, l’association se traduit par la création d’une clef étrangère dans la table « source », c'est-à-dire la table dont la patte d’association porte la cardinalité maximum de 1.
Exemple
Grade (code grade, intitulé grade)
Bases de données relationnelles & SQL
Infotique - 38 -
Les clefs primaires sont soulignées.
6.2.2. Autres associations Dans tous les autres cas, l’association se traduit par une table contenant autant de clefs étrangères que d’entités participant à l’association.
Exemple
Unité (code unité, titre unité)
Ville (code ville, nom ville)
Implantation (code unité, code ville)
7. Exemple récapitulatif
Il s’agit de modéliser les données correspondant au dictionnaire des données et au dictionnaire des règles présentées ci-dessous :
Domaine : affectation de personnes à des sites.
7.1. DICTIONNAIRE DES DONNEES
Date d’entrée dans l’organisme (pas dans le site)
Statut : permanent ou non permanent
Quotité de travail
Prénom du supérieur hiérarchique
Adresse du site
Infotique - 39 -
Une personne a aucun ou un supérieur hiérarchique
Une personne est le supérieur hiérarchique d’aucune, d’une ou de plusieurs personnes
Une personne est affectée à aucun site, un site ou plusieurs sites
Un site est entièrement situé dans un pays
7.3. ENONCE
2) D’installer DBDesigner v 4
3) De construire le modèle avec DBDesigner
4) D’examiner la traduction modèle conceptuel -> schéma relationnel
5) De générer le script SQL de génération des tables avec les options : ranger les tables par FK, définir clé primaire, définir les préférences FK autorisées par l’éditeur de relations, option sortie de table, sortie d’insertion standard, sans les options créer indices et sortir commentaires.
7.4. SOLUTION
Un diagramme de classe UML limité aux données
Un modèle logique (ou schéma relationnel)
Le script de création de la base de données
7.4.1. Modèle Conceptuel des Données (Entités / Associations) complet
Ce modèle prévoit d’introduire une date d’affectation et de conserver l’historique de celles-ci.
Une personne pouvant être affectée successivement plusieurs fois à la même unité, date constitue une entité participant à l’association affecté.
Bases de données relationnelles & SQL
Infotique - 40 -
Infotique - 41 -
La présentation proposée par DBDesigner est intermédiaire entre les modèles conceptuels des
.
Infotique - 42 -
CREATE TABLE Personne (
Personne_idPersonne INTEGER UNSIGNED NOT NULL,
nomPersonne VARCHAR(255) NULL,
prenomPersonne VARCHAR(255) NULL,
dateEntree DATE NULL,
statutPersonne BOOL NULL,
nomPays VARCHAR(255) NULL,
Pays_idPays INTEGER UNSIGNED NOT NULL,
nomSite VARCHAR(255) NULL,
adresseSite VARCHAR(255) NULL,
PRIMARY KEY(Personne_idPersonne, Site_idSite),
Infotique - 43 -
Infotique - 44 -
1.1. OBJECTIFS DE SQL
L’objectif de SQL est d’implémenter les opérateurs relationnels dans un langage proche du langage naturel.
SQL = Structured Query Language
Il existe trois normes successives de SQL :
1) SQL1 (ou SQL 89) représentant la norme de base sur laquelle s’alignent la quasi-totalité des SGBDR
2) SQL2 (ou SQL 92) divisé en trois ensemble : Entrée (équivalent à SQL1), Intermédiaire qui ajoute la possibilité de modifier des schémas et enrichit le langage de contraintes, Complet. La plupart des SGBDR récents implémentent SQL2 intermédiaire.
3) SQL3 qui étend SQL2 avec l’intégration d’instructions procédurales et une approche objet. Cette norme a fait l’objet de plusieurs révisions, n’est implémentée aujourd’hui par aucun SGBDR et demeure contestée.
1.3. UTILISATION DE SQL
SQL s’utilise soit en mode interactif, soit intégré dans un programme procédural ou objet.
Le langage SQL se divise en trois ensembles :
Le langage de description de schémas (LDD)
Le langage de manipulation des données (mise à jour et accès aux données)
Le langage de contrôle des données
Bases de données relationnelles & SQL
Infotique - 45 -
de schémas
Exemple
2.2. CREATION DE TABLE
CREATE TABLE nom de table (nom de colonne1 type, nom de colonne2 type, …, nom de colonnen type) ;
Des contraintes peuvent être associées à la table
Valeur obligatoire : colonne… NOT NULL
Clef primaire : PRIMARY KEY
Validation générale: CHECK prédicat
Clef étrangère et intégrité référentielle : FOREIGN KEY REFERENCES nom de table (nom de colonne)
Intégrité référentielle vis-à-vis des opération de mise à jour : ON DELETE ou ON UPDATE NO ACTION, CASCADE ou SET NULL
Autres contraintes sur une colonne : CHECK (prédicat)
Contraintes générales : CONSTRAINT nom contrainte CHECK (prédicat)
Exemple
Création de la Table Personne (voir modèle de référence plus haut)
CREATE TABLE Personne (
nomPersonne VARCHAR(255) NULL,
prenomPersonne VARCHAR(255) NULL,
dateNaissance DATE NULL,
Infotique - 46 -
IN(50,60,70,80,90,100)),
);
La clause CHECK …. N’est pas opérationnelle avec les versions actuelles (juillet 2009) de MySQL
Une table peut être créée à partir d’une requête de sélection.
CREATE TABLE Travailleurs AS (SELECT nomPersonne, prenomPersonne,
dateEntree ,statutPersonne WHERE quotitePersonne>70)
WITH DATA
2.3. MODIFICATION DE TABLE
2.3.1. Ajouter une colonne ALTER TABLE nom de table ADD COLUMN nom colonne type ;
2.3.2. Modifier le nom d’une colonne ALTER TABLE nom de table CHANGE ancien nom colonne nouveau nom colonne type
2.3.3. Modifier le type d’une colonne ALTER TABLE nom de table MODIFY nom colonne nouveau type
Exemple
2.3.4. Supprimer une colonne ALTER TABLE nom de table DROP COLUMN nom colonne ;
Exemple
ALTER TABLE Personne
Infotique - 47 -
ALTER TABLE Personne
Modifier le type de la colonne indiciePaie en FLOAT
ALTER TABLE Personne
2.5. SUPPRESSION DE TABLE
2.6. CREATION DE VUES
CREATE VIEW nom vue AS (SELECT col1,… FROM Table WHERE prédicat)
Exemple
Création d’une vue « TP » des personnels (nom, prénom, quotité) pour les personnes travaillant à temps partiel.
Bases de données relationnelles & SQL
Infotique - 48 -
CREATE VIEW TP AS (SELECT nomPersonne AS nom, prenomPersonne AS prenom,
quotitePersonne AS quotite FROM personne WHERE quotitePersonne < 100)
3. La mise à jour des données
3.1. INSERTION DE LIGNES
VALUES
SELECT col1, col2,…, coln
FROM nom de table
INSERT INTO personne
Bases de données relationnelles & SQL
Infotique - 49 -
WHERE prédicat ;
Ajouter à nouveau une colonne indice de type entier.
Mettre l’indice à 1000 pour ceux dont la quotité est supérieure ou égale à 80.
UPDATE Personne
Modification utilisant une sous-requête
On veut augmenter de 50% l’indice des personnes dont la quotité est la plus élevée.
UPDATE Personne
WHERE quotitePersonne = (SELECT MAX(quotitePersonne) FROM personne)
Suivant les SGBD, il n’est pas toujours possible d’exécuter une requête de modification en
utilisant une sous-requête portant sur cette même table.
On veut augmenter de 100% l’indice des personnes travaillant dans un établissement dont le nom contient l’expression ‘CAMPUS’.
UPDATE personne
nomEtablissement LIKE '%CAMPUS%')
On veut modifier remplacer l’indice d’une personne par l’indice de la même personne que l’on trouve dans la table promus
UPDATE personne, promus
SET personne.indicePaie = promus.indicePaie
WHERE personne.nomPersonne = promus.nomPromu
Infotique - 50 -
4.1. FORME CANONIQUE DES REQUETES SELECT
SELECT [DISTINCT ou ALL] * ou liste de colonnes
FROM nom de table ou de la vue
[WHERE prédicats]
[HAVING condition]
Le délimiteur de chaîne est l’apostrophe (simple quote).
Exemple
Afficher toutes les colonnes de la table personne triées par ordre décroissant des quotités.
SELECT * FROM personne ORDER BY quotitePersonne DESC;
4.2. LES OPÉRATEURS : BOOLÉENS, BETWEEN, LIKE…
4.2.1. Opérateurs booléens AND, OR, NOT
Utilisation de parenthèses
Exemple
Afficher les personnes née savant 1970 et dont la quotité est 50 ou 100.
Bases de données relationnelles & SQL
Infotique - 51 -
(quotitePersonne = 50 OR quotitePersonne = 100)
4.2.2. BETWEEN Recherche entre deux valeurs
SELECT * FROM Table1 WHERE colonne BETWEEN valeur1 AND valeur2
Exemple
Afficher le nom et la date de naissance des personnes nées en 1985.
SELECT * FROM `personne` WHERE dateNaissancePersonne BETWEEN '1985-01-01'
AND '1985-12-31'
4.2.3. La “valeur” NULL NULL représente l’absence de valeur.
SELECT * FROM Table WHERE col IS NULL ;
Exemple
Afficher les personnes n’étant pas affectées à un établissement
SELECT * FROM personne WHERE idEtablissement IS NULL
4.2.4. LIKE Recherche par troncature (caractère ‘%’)
SELECT * FROM nom de table WHERE colonne LIKE ‘valeur%’
Exemple
Afficher le nom des personnes dont le nom commence par la lettre « D »
Bases de données relationnelles & SQL
Infotique - 52 -
SELECT * FROM `personne` WHERE nomPersonne LIKE 'D%'
4.2.5. Utilisation d’Alias Une colonne peut être associée à un “alias” :
SELECT col AS nouvelleCol
Exemple
Afficher le nom et le prénom des personnes (en utilisant « NOM » et « PRENOM » comme titre de colonne).
SELECT nomPersonne as NOM, prenomPersonne AS PRENOM FROM personne
4.3. UTILISATION DE FONCTIONS SQL
SQL permet d’utiliser un grand nombre de fonctions de type chaine de caractères, numérique et date.
4.3.1. Fonctions chaînes de caractères
4.3.1.1. Concaténation
CONCAT(c1, c2, …)
4.3.1.2. Extractions de chaînes de caractères
SUBSTR(c, position de début, nombre de caratères)
Exemple
Afficher les 3 premières lettres du nom de chacune des personnes.
Bases de données relationnelles & SQL
Infotique - 53 -
Peuvent être également utilisées les fonctions LEFT, RIGHT, MID,
4.3.1.3. Longueur de caractères
4.3.1.5. Suppression des espaces inutiles
TRIM() : supprime les espaces à gauche et à droire
RTRIM() : supprime les espaces à droite
LTRIM() : supprime les espaces à gauche
4.3.2. Fonctions numériques Les principales fonctions numériques sont les suivantes :
ABS() : valeur absolue
FLOOR() : retourne l’entier inférieur
MOD() : modulo
POW() : puissance
SQRT() : racine carré
CURTIME() : heure courante
ADDDate(d, n) : ajoute n jours à la date d
ADDATE(…) : ajoute un intervalle à la date initiale
DATEDIFF(d1, d2) : nombre de jours entre d1 et d2
Bases de données relationnelles & SQL
Infotique - 54 -
DAYOFMONTH(d)
DAYOFWEEK()
DAYOFYEAR()
MONTH()
MONTHNAME()
TIMESTAMP()
WEEK()
WEEKDAY()
YEAR()
Exemple
SELECT ADDDATE('2008-12-31', INTERVAL 3 MONTH)
4.3.4. Formats de date et d’heure d% : numéro du jour sur 2 chiffres
D% : nom du jour avec suffixe anglais
W% : nom du jour de la semaine (anglais)
m% : numéro du mois sur 2 chiffres
M% : nom du mois (anglais)
y% : année sur 2 chiffres
Y% : année sur 4 chiffres
Exemple
4.4. LES AGREGATS
GROUP BY col
Infotique - 55 -
Les fonctions de synthèse sont : SUM, COUNT, AVG, MIN, MAX…
Exemple
Compter le nombre de personnes travaillent à temps partiel par quotités
SELECT quotitePersonne AS Quotite, COUNT(*) AS Effectifs FROM personne
GROUP BY quotitePersonne HAVING quotitePersonne < 100
4.5. LES JOINTURES
4.5.1. Jointure naturelle SELECT col1, col2… FROM Table1 INNER JOIN Table2 ON FK = PK
FK désigne une clef étrangère, PK une clef primaire.
Exemple
Afficher le nom des personnes et le nom du site auquel elles sont affectées.
SELECT nomPersonne, nomEtablissement FROM personne INNER JOIN etablissement
ON Personne.idEtablissement = etablissement.idEtablissement
SELECT nomPersonne, nomEtablissement FROM personne, etablissement
WHERE personne.idEtablissement = etablissement.idEtablissement
4.5.2. Jointures externes SELECT col1, col2… FROM Table1 LEFT (RIGHT) OUTER JOIN Table2 ON FK = PK
FK désigne une clef étrangère, PK une clef primaire.
Exemple
Infotique - 56 -
Afficher le nom des personnes (y compris les personnes n’étant affectées nulle part) et le nom du site auquel elles sont affectées.
SELECT nomPersonne, nomEtablissement FROM personne LEFT OUTER JOIN
etablissement
4.6. LES OPERATEURS ENSEMBLISTES
4.6.1. L’union SELECT col1, col2 FROM Table1 UNION SELECT col1, col2 FROM Table2;
Exemple
Afficher le nom des personnes présentes dans la table personne ou (inclusif) dans la table workers.
SELECT nomPersonne, prenomPersonne FROM personne
UNION
SELECT lastNameWorker, firstNameWorker FROM worker
4.6.2. L’intersection SELECT col1, col2 FROM Table1 INTERSECT SELECT col1, col2 FROM Table2;
Exemple
Afficher le nom des personnes présentes dans la table personne et aussi dans la table workers.
SELECT nomPersonne, prenomPersonne FROM personne
WHERE nomPersonne IN (SELECT lastNameWorker FROM workers)
AND prenomPersonne IN (SELECT firstNameWorker FROM workers)
4.6.3. La différence SELECT col1, col2 FROM Table1 MINUS SELECT col1, col2 FROM Table2;
Exemple
Infotique - 57 -
Afficher le nom des personnes présentes dans la table personne et pas dans la table workers
SELECT nomPersonne, prenomPersonne FROM personne
WHERE nomPersonne NOT IN (SELECT lastNameWorker FROM workers)
4.7. LES SOUS-REQUETES
Les requêtes contenant des sous-requêtes doivent être distinguées suivant que celle-ci est susceptible de ne renvoyer qu’une seule ligne de résultat ou plusieurs lignes de résultat.
Si la sous-requête ne renvoie à coup sur (structurellement) qu’une seule ligne, la sous-requête peut être introduite par les opérateurs : = , >, >= …
Exemple
Afficher les noms dont la quotité est inférieure à la moyenne des quotités.
SELECT nomPersonne FROM personne WHERE quotitePersonne < (SELECT
AVG(quotitePersonne) FROM personne)
Les opérateurs ANY et ALL permettent d’introduire une sous-requête avec les opérateurs : = , >, >= …
Exemple
Afficher les noms des personnes présentes dans la table personne et dans la table workers (intersection)
SELECT nomPersonne FROM personne WHERE nomPersonne = ANY (SELECT
lastNameWorker FROM workers)
Si la requête est susceptible de renvoyer plusieurs valeurs, la sous-requête doit être introduite par les opérateurs : IN, NOT IN, EXISTS
SELECT * FROM Table1 WHERE col IN (SELECT col FROM Table2 WHERE prédicat)
Afficher le nom et la quotité des personnes ayant la même quotité qu’une personne du site « BEAU CAMPUS »
Bases de donn&ea