Les Bases de Données

Les Bases de Données 1. Introduction 1.1 Définition On peut parler de bases de données partout où des informations sont plus ou moins structurées et rassemblées dans des systèmes organisés. La gestion et l évaluation des données deviennent possibles dès l instant où les données sont organisées selon une structure déterminante, c est à dire que les informations sont construites d après un schéma bien précis. Exemples : - Fichier d adresses - Fichier du personnel - Gestion de factures - Gestion des commandes clients 1.2 Modèle de bases de données hiérarchiques Il s agit du plus ancien modèle de bases de données. Les relations entre les différentes informations sont organisées suivant une structure hiérarchique. Un pointeur permet de référencer un ou plusieurs éléments qui à leur tour divergent vers d autres et ainsi de suite. Le système de gestion des fichiers sur un disque magnétique est construit suivant ce modèle. 1.3 Modèle de bases de données relationnelles Les informations sont ici rassemblées dans des tables. Une base peut renfermer plusieurs tables communicantes entre elles par des relations. C est le modèle de bases de données que nous étudierons dans ce cours. 2. Modèle de bases de données relationelles 2.1 Les tables A l intérieur de la table toutes les fiches (les enregistrements) ont la même structure, elles contiennent toutes le même type d information. Une table est organisée en lignes et en colonnes, chaque ligne représentant un enregistrement et chaque colonne un champ. N personnel Nom Prénom Service Supérieur 10 Térieur Alain Comptabilité Maurice 22 Térieur Alex Commercial Martin 25 Kanne Jerry Comptabilité Maurice 41 Nemar Jean Technique René Les Bases de Données Page 1 / 12

2.2 Les enregistrements Chaque enregistrement est constitué de champs. 2.3 Les champs Il s agit de la plus petite information qui compose un enregistrement comme le prénom dans un fichier d adresses. Un champ est caractérisé par : Son intitulé Son type (nature de l information qu il contient) Texte Nombre Date Etc. Par analogie avec un fichier «manuscrit», une table correspond à un bac a fiches, un enregistrement à une fiche, un champ à une rubrique à l intérieur de la fiche. 2.4 La clé Un champ peut être défini comme clé, une clé sert à identifier sans ambiguïté un enregistrement. C est le rôle du champ N Personnel dans l exemple. En effet, le champ nom ne permet pas de gérer des «homonymes» dans la table. (Cas des doublons) 2.5 L index Créer un index se traduit par la création d une table d index. Cette dernière permet d optimiser le tri de la table suivant le champ qui aura été «indexé». 2.6 Normalisation d une base de données relationnelles Le but d une base de données relationnelle est de mémoriser le moins de redondance possible. La sauvegarde des données répétitives gaspille de la place en mémoire et nuit à la vitesse d exécution. Les tables doivent être tronqués jusqu'à atteindre la norme de niveau trois. Reprenons l exemple précédent : N personnel Nom Prénom Service Supérieur 10 Térieur Alain Comptabilité Maurice 22 Térieur Alex Commercial Martin 25 Kanne Jerry Comptabilité Maurice 41 Nemar Jean Technique René Il faut remarquer que certaines entrées apparaissent deux fois. On peut gérer un fichier indépendant contenant les services ou les supérieurs. L accès se fera par l intermédiaire d un champ N Service ou N Supérieur qu il convient de créer. Ce dernier doit intervenir dans les deux tables pour pouvoir établir une relation. Une table ainsi divisée est structurée selon la deuxième normalisation. On arrive en général ainsi à un niveau de non-redondance assez élevée. Si les champs de clé ne contiennent plus de doublons, on parle alors de troisième normalisation. Les Bases de Données Page 2 / 12

2.7 Structurer une base de données relationnelle Pour être certain de construire une base répondant aux besoins, il convient de suivre la méthode suivante : Déterminer l ensemble des traitements à réaliser. Déterminer l ensemble des données nécessaires pour réaliser ces traitements Déterminer la structure des tables et les liens entre les tables contenant toutes ces données. (Normaliser la base) 3. Exemple 3.1 Objectif Concevoir une base de données qui gère les commandes d une petite société. 3.2 Traitements à réaliser 3.2.1 : Suivi des commandes Pour chaque commande, noter les coordonnées du client, noter les différents articles vendus, noter la date de la commande. Chaque trimestre éditer la liste des articles vendus pour inventaire. 3.2.2 : Suivi des clients Tous les ans, éditer la liste des clients afin de leur envoyer un catalogue. 3.3 Données à traiter Les données à traiter peuvent être regroupées dans une seule table nommée Commande. Les Bases de Données Page 3 / 12

3.4 Normalisation de la base 3.4.1 : Structuration des tables Dès qu un client enregistre plus d un article, les informations concernant les clients se trouvent dupliquées, il convient de diviser la table pour effectuer une première normalisation. Il convient de créer des champs supplémentaires afin de pouvoir établir une relation entre ces tables. Il reste un risque de dupliquer les informations concernant les articles, une autre table permet d y remédier. Si un client commande plus d un article, le NoClient se trouve dupliqué, réalisons pour cela un troisième niveau de normalisation. Les Bases de Données Page 4 / 12

3.4.2 : Définition des relations La définition des clés primaires est obtenue en choisissant des champs qui identifient clairement chaque enregistrement d une table. Dans notre exemple les champs qui conviennent parfaitement sont les champs qui ont été ajoutés : Table Client Commande Article Clé primaire NoClient NoCommande NoArticle Les tables doivent contenir des champs identiques pour pouvoir créer une relation. L équivalent du champ de clé primaire défini dans la première table doit exister dans la deuxième sous forme d une clé externe. Relation 1 : n Relation de un à plusieurs, (cas le plus fréquent). Un enregistrement de la première table est en relation avec plusieurs enregistrements de l autre table. Mais un enregistrement de la deuxième ne peut être joint qu à un seul de la première. Un enregistrement de la table article comporte un ou plusieurs équivalents dans la table commande. Un enregistrement de la table commande ne peut en revanche être associé qu à un seul article. Ce type de relation est aussi appelé relation maître-détail. Relation 1 : 1 Relation de un à un. Un enregistrement de la première table est en relation avec exactement un enregistrement de la deuxième. Ce cas se produit par exemple lorsque des tables sont réparties en deux ou un enregistrement contient une partie des informations dans une table, et le reste dans une autre. Relation n : m Relation de plusieurs à plusieurs. Un enregistrement de la première table peut être associé à plusieurs enregistrements de la deuxième. Inversement, il en va de même. Par exemple un fournisseur peut envoyer plusieurs articles, un article peut provenir de plusieurs fournisseurs. Les Bases de Données Page 5 / 12

4. Le langage SQL (Structured Query Langage) 4.1 Introduction Les systèmes de gestion de Base de Données (SGBD) offrent un langage de manipulation des données standards, SQL (Strutured Query Langage), qui est fondé sur l algèbre relationnelle. SQL c est : - Un langage de définition de schémas pour décrire les relations, - Un langage de manipulation de données pour accéder et mettre à jour une base de données, - Une syntaxe pour inclure des expressions dans un programme écrit dans un langage classique. 4.2 Convention sur les noms 4.2.1 : Introduction Cette rubrique décrit les conventions sur les noms de tables et de colonnes, les améliorations et les limites de la syntaxe pour SQL local. Les instructions SQL sont divisées en deux catégories différentes, DDL (Data Definition Language) et DML (Data Manipulation Language) : La norme ANSI de SQL autorise pour chaque nom de table ou de colonne un mot unique formé de caractères alphanumériques et du caractère de soulignement (_). Cependant, SQL local est amélioré pour supporter des noms plus détaillés. Les Bases de Données Page 6 / 12

4.2.2 : Tables SQL local supporte le nom complet et le chemin d'accès dans un nom de table. Les noms de tables comportant des chemins d'accès ou des extensions de fichiers doivent être délimités par des apostrophes ou des guillemets, comme dans : SELECT * FROM 'PARTS.DBF' SELECT * FROM "C:\SAMPLE\PARTS.DBF" Si vous omettez l'extension de fichier pour un nom de table local, le type de table sera par défaut soit celui spécifié dans le paramètre DEFAULT DRIVER de la page Système, dans l'utilitaire de configuration BDE, soit celui spécifié par l'alias standard associé à la requête ou à la table. Enfin SQL client permet d'utiliser comme noms de tables des mots réservés SQL, pourvu qu'ils soient délimités par des apostrophes ou des guillemets, comme dans: SELECT PASSID FROM "PASSWORD" 4.2.3 : Colonnes SQL local supporte les noms de colonnes Paradox formés de plusieurs mots et les noms de colonnes constitués de mots réservés SQL pourvu que ces noms de colonnes soient : Délimités par des apostrophes ou des guillemets préfixés par un nom de table SQL. Par exemple, le nom de colonne suivant est formé de deux mots : SELECT E."Emp Id" FROM EMPLOYEE Dans l'exemple ci-dessous, le nom de colonne coïncide avec le mot SQL réservé DATE : 4.2.4 : Dates SELECT DATELOG."DATE" FROM DATELOG SQL local suppose que les dates sont au format américain MM/DD/YY. Les formats de dates internationaux ne sont pas supportés. 4.3 Manipulation des données 4.3.1 : Introduction Les instructions SQL du langage de manipulation des données (DML) sont utilisées pour sélectionner, insérer, mettre à jour et supprimer des données dans des tables. 4.3.2 : SELECT pour accéder à des données existantes L'instruction SELECT est utilisée pour retrouver des données à partir d'une ou de plusieurs tables. Une instruction SELECT qui retrouve des données depuis plusieurs tables est appelée une "jointure". SQL local supporte la forme suivante de l'instruction SELECT. SELECT [DISTINCT] liste_colonnes FROM référence_table [WHERE condition_recherche] [ORDER BY liste_tri] [GROUP BY liste_groupe] [HAVING condition_having] [UNION expr_select] Les Bases de Données Page 7 / 12

Toutes les clauses sont gérées comme dans la norme ANSI de SQL, à l'exception de ce qui est indiqué ci-après. Les clauses entre crochets sont facultatives. La liste_de_colonnes indique les colonnes dans lesquelles les données doivent être recherchées. 4.3.3 : Clause FROM La clause FROM spécifie la ou les tables dans lesquelles les données doivent être recherchées. référence_table peut être une table unique, une liste de tables séparées par des virgules ou encore une jointure interne ou externe comme cela est spécifié dans la norme SQL-92. L'exemple suivant spécifie une table unique : SELECT PART_NO FROM "PARTS.DBF" L'instruction suivante spécifie pour table une jointure externe gauche : SELECT * FROM PARTS LEFT OUTER JOIN INVENTORY ON PARTS.PART_NO = INVENTORY.PART_NO 4.3.4 : Clause WHERE La clause facultative WHERE réduit le nombre de lignes renvoyées par une requête uniquement à celles qui correspondent au critère spécifié dans condition_de_recherche. L'instruction suivante, par exemple, ne retrouve que les lignes pour lesquelles ART_NO est supérieur à 543 : SELECT * FROM PARTS WHERE PART_NO > 543 La clause WHERE peut contenir le prédicat IN, suivi d'une liste de valeurs entre parenthèses. Ainsi, l'instruction suivante ne retrouve que les lignes dans lesquelles le numéro d'article fait partie des éléments de la liste qui suit IN : SELECT * FROM PARTS WHERE PART_NO IN (543, 544, 546, 547) Outre les opérateurs de comparaison scalaires ( =, <, >... ), d'autres prédicats utilisant IN, ANY, ALL, EXISTS sont supportés. 4.3.5 : Clause ORDER BY La clause ORDER BY spécifie l'ordre des lignes. Par exemple, la requête suivante ramène une liste de tous les articles par ordre alphabétique des noms d'article : SELECT * FROM PARTS ORDER BY PART_NAME ASC La requête suivante présente toutes les informations sur les articles, classées en ordre numérique décroissant des numéros d'article : SELECT * FROM PARTS ORDER BY PART_NO DESC Les champs calculés peuvent être classés par nom de corrélation ou par position numérique. Par exemple, la requête suivante ordonne les lignes selon le champ calculé NOM_COMPLET : Les Bases de Données Page 8 / 12

SELECT NOM ', ' PRENOM AS NOM_COMPLET, TELEPHONE, FROM CLIENTS ORDER BY NOM_COMPLET La projection de toutes les colonnes de groupement ou de tri n'est pas obligatoire. 4.3.6 : Clause GROUP BY La clause GROUP BY spécifie la façon dont les lignes récupérées sont regroupées vis à vis des fonctions statistiques. 4.3.7 : Clause HAVING La clause HAVING spécifie des conditions que les enregistrements doivent satisfaire pour être renvoyés par la requête. C'est une expression conditionnelle utilisée avec la clause GROUP BY. Les groupes qui ne correspondent pas à l'expression de la clause HAVING sont omis de l'ensemble des résultats. Les sous-requêtes sont supportées dans la clause HAVING. Une sous-requête fonctionne comme une condition de recherche limitant le nombre de lignes renvoyées par la requête parent. Voir la Clause WHERE Outre les opérateurs de comparaison scalaires ( =, <, >... ), d'autres prédicats utilisant IN, ANY, ALL, EXISTS sont supportés. La clause HAVING est facultative. HAVING est similaire à WHERE, qui détermine quels sont les enregistrements à sélectionner. Une fois que GROUP BY a regroupé les enregistrements, HAVING détermine quels sont les enregistrements qui seront affichés : SELECT [Code catégorie], Sum([Unités en stock]) FROM Produits GROUP BY [Code catégorie] HAVING Sum([Unités en stock]) > 100 And Like "BOS*"; 4.3.8 : Clause UNION La clause UNION combine le résultat de plusieurs instructions SELECT pour obtenir une seule table. 4.3.9 : Jointure hétérogène SQL local supporte les jointures de tables de formats différents de bases de données. C'est ce qu'on appelle une "jointure hétérogène". Lorsque vous exécutez une jointure hétérogène, vous devez sélectionnez un alias local. Si vous n'avez pas sélectionné d'alias, SQL local recherche la table dans le répertoire courant de la base de données en cours d'utilisation. Par exemple, l'alias :TRAVAIL: peut être le descripteur de base de données passé dans la fonction. Lorsque vous spécifiez un nom de table après la sélection d'un alias local, pour les tables locales, spécifiez l'alias ou le chemin et pour les tables distantes, spécifiez l'alias. L'instruction suivante récupère les données d'une table Paradox et d'une table dbase : SELECT DISTINCT C.CUST_NO, C.STATE, O.ORDER_NO FROM "CUSTOMER.DB" C, "ORDER.DBF" O WHERE C.CUST_NO = O.CUST_NO Les Bases de Données Page 9 / 12

Vous pouvez également utiliser des alias de moteur de base de données Borland en conjonction avec des noms de tables. 4.3.10 : INSERT pour insérer des nouvelles données dans une table Dans SQL local, INSERT a deux formats : INSERT INTO CUSTOMER (FIRST_NAME, LAST_NAME, PHONE) VALUES(:fnom, :lnom, :tel_no) L'insertion depuis une table dans une autre à partir d'une sous-requête n'est pas autorisée. L'instruction suivante ajoute une ligne à une table, en assignant des veleurs à deux colonnes : INSERT INTO EMPLOYEE_PROJECT (EMP_NO, PROJ_ID) VALUES (52, "DGPII"); L'instruction suivante spécifie des valeurs à insérer dans une table avec une instruction SELECT : INSERT INTO PROJECTS SELECT * FROM NEW_PROJECTS WHERE NEW_PROJECTS.START_DATE > "6-JUN-1994"; 4.3.11 : Opérateurs SQL local supporte les opérateurs suivants : 4.4 Définition des données Type Opérateur Arithmétique + - * / Comparaison < > = <> >= =< IS NULL IS NOTNULL Logique AND OR NOT Concaténation de chaîne Local SQL supporte le langage de définition des données (Data Definition Language, DDL) pour la création, la modification et la suppression des tables et d'index. Local SQL supporte les instructions DDL suivantes : Instruction DDL CREATE TABLE ALTER TABLE DROP TABLE CREATE INDEX DROP INDEX Description Crée une nouvelle table. Ajoute des colonnes et supprime des colonnes dans une table existante. Supprime une table existante. Crée un nouvel index secondaire pour une table existante. Supprime un index primaire ou secondaire existant. Les Bases de Données Page 10 / 12

Les Bases de Données Exemple : Gestion de Commandes 1. Introduction Pour être certain de construire une base répondant aux besoins, il convient de suivre la méthode suivante : Déterminer l ensemble des traitements à réaliser. Déterminer l ensemble des données nécessaires pour réaliser ces traitements Déterminer la structure des tables et les liens entre les tables contenant toutes ces données : Normaliser la base 2. Exemple 2.1 Objectif On veut concevoir une base de données qui gère les commandes d une petite société. 2.2 Traitements à réaliser Pour chaque commande, noter les coordonnées du client, noter les différents articles vendus, noter la date de la commande. Chaque trimestre éditer la liste des articles vendus pour inventaire. Tous les ans, éditer la liste des clients afin de leur envoyer un catalogue. 2.3 Données à traiter Les données à traiter peuvent être regroupées dans une seule table nommée Commande. 2.4 Normalisation de la base 2.4.1 : Structuration des tables Dès qu un client enregistre plus d un article, les informations concernant les clients se trouvent dupliquées, il convient de diviser la table en 2 (Commande et Client) pour effectuer une première normalisation. Il convient de créer des champs supplémentaires (NoClient) afin de pouvoir établir une relation entre ces tables. Les Bases de Données Page 11 / 12

Il reste un risque de dupliquer les informations concernant les articles, une autre table (Article) permet d y remédier. Si un client commande plus d un article, le NoClient se trouve dupliqué, réalisons pour cela un troisième niveau de normalisation en ajoutant une table Données-Commande. 2.4.2 : Définition des relations La définition des clés primaires est obtenue en choisissant des champs qui identifient clairement chaque enregistrement d une table. Les tables doivent contenir des champs identiques pour pouvoir créer une relation. L équivalent du champ de clé primaire défini dans la première table doit exister dans la deuxième sous forme d une clé externe. Dans notre exemple les champs qui conviennent parfaitement sont les champs qui ont été ajoutés : Table Client Commande Article Clé primaire NoClient NoCommande NoArticle Les Bases de Données Page 12 / 12