par Site hébergé - revault.u-cergy.fr · 1 2 3 Compléments au cours SGBD Contenu du dossier de fin de semestre Examen partiel janvier 2000 Examen partiel janvier 2001 Fichiers

dernière mise à jour novembre 2003

Me contacter

Site hébergé

par

� Université de Cergy

� Cours 0 1 2 3

� Compléments au cours SGBD

� Contenu du dossier de fin de semestre � Examen partiel janvier 2000 � Examen partiel janvier 2001

� Fichiers TD :

� TD01 � TD02 � TD03 � TD04

� Liens vers des sites traitant del'initiation aux bases de données

� Initiation à Access � Introduction aux bases de données � Le modèle relationnel � Méthode Merise � Programmation ASP

� Applications test

� Planning � Petite visite de Graphic Brochage � Intranet FFC � Petite visite de la FFC

Page 1 sur 1Accueil

15/12/2004http://www.brunocollin.com/

Nicolas Revault

Nicolas Revault

Méthode d'approche des bases de données relationnelles

Sachant que :

� Nous n'avons que 12 séances de cours. � Ce cours s'adresse à des futurs utilisateurs de base de données (étudiants en gestion et marketing) et non pas à des futurs informaticiens. � À la suite du cours, les étudiants devront être à même de maîtriser les différents aspects des bases de données. A savoir :

� Exploiter une base de données existante (interrogation statistique) � Déterminer les moyens à mettre en oeuvre pour répondre à un besoin défini (cahier des charges d'une application) � Assurer le suivi de l'implantation d'une base de données.

... sans pour autant être programmeur.

Alors :

Nous aurons donc une approche qui partira d'exemples pratiques pour arriver à l'étude de la modélisation des bases de données.

Nous travaillerons au début sur des études de cas. Après avoir acquis une bonne maîtrise de la technique, on la mettra en forme dans le cadre de concepts comme :

� Modèle relationnel � Modèle entité-association � Algèbre relationnel

... ceci pour répondre à l'exigence de la"connaissance savante"

Mais aussi :

Nous aborderons les aspects matériels de fonctionnement d'une base de données : (voir aussi le contenu du dossier)

� Etude de besoin � Matériel nécessaire � Logiciels nécessaires � Développement d'applications

... Première leçon

Page 1 sur 1Méthode d'approche des bases de données :

15/12/2004http://www.brunocollin.com/Cours00.htm

DONNEES STRUCTUREES

� Exemple de données structurées :

� Aperçu de ces mêmes données NON structurées :

Pour compléter l'adresse d'un client, il est donc évident qu'il faut mettre chaque information dans une case du tableau. La bonne case est celle qui est repérée par la bonne colonne croisée avec la bonne ligne. En l'occurence, pour savoir où indiquer le code postal de "Blondel père et fils", il faut choisir la ligne 7 et la colonne [Code postal].

Dans cet exemple, tout ceci paraît évident et même un peu ennuyeux. Mais cela a des conséquences importantes sur la technique de mise en oeuvre des bases de données. En effet, il ressort de ce qui précède que le nom des colonnes doit être unique et le numéro de ligne également.

N° Société Adresse Code postal Ville Pays Téléphone

1 Alfreds Futterkiste Obere Str. 57 12209 Berlin Allemagne 030-0074321

2 Ana Trujillo Emparedados y helados Avda. de la Constitución 05021 México D.F. Mexique (5) 555-4729

3 Antonio Moreno Taquería Mataderos 2312 05023 México D.F. Mexique (5) 555-3932

4 Around the Horn 120 Hanover Sq. WA1 1DP London Royaume-Uni (71) 555-7788

5 Berglunds snabbköp Berguvsvägen 8 S-958 22 Luleå Suède 0921-12 34 65

6 Blauer See Delikatessen Forsterstr. 57 68306 Mannheim Allemagne 0621-08460

7 Blondel père et fils 24, place Kléber 67000 Strasbourg France 88.60.15.31

8 Bólido Comidas preparadas C/ Araquil, 67 28023 Madrid Espagne (91) 555 22 82

9 Bon app' 12, rue des Bouchers 13008 Marseille France 91.24.45.40

10 Bottom-Dollar Markets 23 Tsawassen Blvd. T2F 8M4 Tsawassen Canada (604) 555-4729

Alfreds Futterkiste; Obere Str. 57; 12209; Berlin; Allemagne; 030-0074321Ana Trujillo Emparedados y helados; Avda. de la Constitución ; 05021; México D.F.; Mexique; (5) 555-4729Antonio Moreno Taquería; Mataderos 2312; 05023; México D.F.; Mexique; (5) 555-3932Around the Horn; 120 Hanover Sq.; WA1 1DP; London; Royaume-Uni; (71) 555-7788Berglunds snabbköp; Berguvsvägen 8; S-958 22; Luleå; Suède; 0921-12 34 65Blauer See Delikatessen; Forsterstr. 57; 68306; Mannheim; Allemagne; 0621-08460Blondel père et fils; 24, place Kléber; 67000; Strasbourg; France; 88.60.15.31Bólido Comidas preparadas; C/ Araquil, 67; 28023; Madrid; Espagne; (91) 555 22 82Bon app'; 12, rue des Bouchers; 13008; Marseille; France; 91.24.45.40Bottom-Dollar Markets; 23 Tsawassen Blvd.; T2F 8M4; Tsawassen; Canada; (604) 555-4729

Page 1 sur 3Notions de base

15/12/2004http://www.brunocollin.com/Cours01_01.htm

NOTIONS FONDAMENTALES

Les bases de données sont destinées à enregistrer des informations complètement structurées. Pour ce faire, avant de commencer à recevoir la moindre information, une base de données doit décrire complètement la structure qui stockera les informations.

Modélisation mathématique :

� Dans la modélisation mathématique, une ligne du tableau est appelée entité notée e . Dans notre exemple, elle désigne un client et son adresse. Les renseignements (N°, Société, Adresse, ... , Téléphone) sont appelés attribus et notés ai . Notation : e = ( a1 , a2 , ... , an )

� On regroupe les entités de même nature dans un ensemble que l'on appelle une classe d'entités notée E . Dans notre exemple, la classe d'entités désigne le tableau qui reçoit les informations concernant les clients. Notation : E = ( A1 , A2 , ... , An ) est le schéma descriptif de l'ensemble des entités E .

� Vocabulaire : e est une instanciation ou une occurence de E .

Avec la notion de classe d'entités, nous avons l'outil de description du stockage des données. Nous y reviendrons dans la partie consacrée aux types de données.

Modélisation informatique :

� Les tableaux qui reçoivent les données s'appellent des TABLES . � A l'intérieur d'une table, les en-têtes de colonnes s'appellent des CHAMPS . � Les lignes du tableau s'appellent les ENREGISTREMENTS . � Chaque enregistrement doit pouvoir être identifié de façon absolue. C'est la raison pour laquelle, il existe, en principe dans chaque table, un

champ spécial qui représente l'identité de l'enregistrement. Ici c'est le champ [N°]. Ce type de champ particulier s'appelle CLE PRIMAIRE . � Les informations concernant un client sont appelées DONNEES . Les informations concernant description de la structure de la table sont

appelées METADONNEES .



Comparatif :

Selon le milieu dans lequel vous évoluez, vous pouvez utiliser trois langages différents :

Langage courant Mathématique InformatiqueTableau Classe d'entités TableRenseignement ou colonne d'un tableau Attribut ChampFiche ou ligne d'un tableau Entité, instanciation ou occurence de la classe d'entité EnregistrementNuméro de fiche Clé primaireDescription du tableau Métadonnées



MATIERE PREMIERE DE L'INFORMATION

De même que le bois, le métal ou le verre servent de matière première à la fabrication d'objet, les types de données constituent la matière première de l'information. Il convient donc de les choisir avec soin lors de la structuration de la base.

On entend par types de données le classement des informations en type "texte", "numérique", "date", "images", etc.

� Code article est de type texte. On ne fait pas de calcul sur un code article. � Libellé est du type texte. � Conditionnement est de type numérique. Des calculs seront possibles. � Prix unitaire est de type numérique. Des calculs seront possibles.

Par exemple la raison sociale d'une entreprise est de type texte alors que le nombre de ses employés est de type entier numérique. La spécification du type de données se justifie par les opérations ou traitement que l'application doit pouvoir effectuer. Par exemple un prix unitaire sera de type numérique afin de pouvoir calculer le total d'une facture. En revanche, un code postal et un numéro de téléphone seront de type texte car il ne font l'objet d'aucun calcul.

En informatique de gestion, les types de données les plus utilisés sont "texte" (anciennement alphanumérique), "numérique" et "date". D'autres types sont pratiques pour certains cas : booléen (valeur = vrai ou faux), mémo (texte de plusieurs milliers de caractères).

Code article

Libellé Conditionnement (pièces/paquet)

Prix unitaire

10456 Thyristor 5 25 E

15235 Chapouniard 1 12 E

12400 Glablutz 20 2 E



Enfin d'autres types de données sont réservés à des applications particulières : champs binaires capables de stocker de la musique, des images, des documents tableur ou traitement de texte. Nous ne les examinerons pas du fait de leur peu d'utilisation en informatique de gestion.

TYPES DE DONNEES

� Texte

Le type texte convient pour les informations sur lesquelles il ne sera pas fait de calcul du genre noms, adresses, codes postaux, téléphone, codes et libellés d'articles. Les types "texte" se divisent en plusieurs catégories :

� Longueur fixe

La longueur du texte doit être prévue d'avance. C'est facile pour les informations de taille fixe (code article sur 5 caractères, numéro de facture sur 7 caractères par exemple). Pour les informations de taille variant peu (noms de personne, libellé d'article par exemple) il faut prendre la taille maximum possible pour cette information. S'il est estimé que le libellé d'un article peut atteindre jusqu'à 35 caractères alors la dimension du champ sera de 35 caractères. En cours d'utilisation, si un libellé dépasse cette taille, il faudra l'abréger.

La taille maximum définissable pour un champ de ce type est de 255 caractères dans Access (plus dans d'autres systèmes). Il n'est pas conseillé de spécifier systématiquement cette taille maximum ceci pouvant poser des problèmes dans certains traitements.

� Longueur variable

Il s'agit d'une information peu ou pas structurée dont la longueur peut varier considérablement. C'est le cas de mémo, commentaires dans une fiche client, compte-rendu de visite. Dans Access, on peut stocker jusqu'à 65.0000 caractères environ dans un seul champ de ce type. Il n'est pas possible d'indexer ce type de champ. Son usage est donc limité à celui du commentaire

� Spéciaux

Il s'agit de champs de type texte qui sont exploités d'une façon particulière par le SGBD



� GUID : "Identificateur mondialement unique". Particulièrement intéressant dans le cas de communication avec des processus extérieurs à la base de données, sinon il est plus simple d'utiliser un champ à incrémentation automatique (NuméroAuto - voir plus loin).

� Lien hypertexte (Access) : permet de spécifier l'endroit d'un fichier ou d'une page Web. En cliquant dessus, on ouvre automatiquement le document.

� Type numérique

Il s'agit des champs sur lesquels il est prévu de faire des opérations arithmétiques. Là encore il convient de distinguer différentes catégories :

� Monétaire

Ce format permet de stocker des nombres de 15 chiffres avant la virgule et 4 chiffres après. Les particularités de ce format sont :

� Reprise automatique sous Windows du format de la monnaie locale définie dans les paramètres.

� Les montants ne sont pas arrondis afin d'éviter des erreurs de totalisation.

� Entier

Convient aux comptages : quantité d'articles dans une ligne de facture par exemple. Les différents types d'entiers sont :

� Entier long : le plus utilisé, il peut prendre une valeur pouvant aller jusqu'à 2 milliards environ.

� Incrémentation automatique : entier long appelé aussi champ "Compteur" dans Access 2, puis "NuméroAuto" dans les versions suivantes. À chaque ajout d'enregistrement, ce champ prend automatiquement sa dernière valeur et lui ajoute un. L'intérêt est double. D'une part il numérote automatiquement une fiche; d'autre part il identifie de façon absolue la fiche. En effet, le numéro utilisé n'est jamais réutilisé pour une autre fiche de la même table ; par ailleurs l'utilisateur ne peut pas intervenir dans cette numérotation. Dans la pratique, ce champ est considéré comme le "numéro d'identité" de



la fiche. Il est donc très pratique pour construire les relations entre les tables.

� Booléen : nombre entier qui prend comme valeur -1 ou 0 signifiant respectivement "Vrai" ou "Faux". Dans la pratique, il est utile pour marquer une fiche qui doit recevoir un certain traitement. Imaginons l'exemple d'une liste de factures comportant un champ booléen Vrai/Faux. En principe le client ne doit recevoir la facture qu'une fois. Donc au moment de son premier envoi, la facture reçoit "Vrai" dans son champ booléen. Si le client demande à en recevoir une copie, le processus d'envoi imprimera automatiquement "Duplicata" sur le document qu'il sait avoir déjà envoyé.

� Les autres formes (entier court et octet) sont très peu utilisées.

� Réel (décimaux) et dates

Choisir de préférence les réels de type double (meilleure précision). Dans la pratique, ils sont utilisés pour les pourcentages, les ratios commerciaux, les taux de change, etc.

Cas particulier très important : les dates et heures qui sont en fait enregistrées en interne comme les composants d'un nombre réel. La partie à gauche de la virgule représente une date comprise entre le 30 décembre 1899 et le 30 décembre 9999. Les valeurs négatives représentent des dates antérieures au 30 décembre 1899. La partie à droite de la virgule représente une heure comprise entre 0:00:00 et 23:59:59

Ce type de donnée autorise une arithmétique particulière à la mesure du temps. On peut considérer qu'une valeur est un repère (date/)heure) dans le temps. De sorte que si on ajoute à un repère un réel positif, on obtient un nouveau repère (date/)heure). Par ailleurs si on fait la différence entre deux repères on obtient un réel égal au décalage du temps.

Exemple :

25 juin + 10 = 5 juillet

Autres possibilités :

25 juin à 10 heures + 10,5 = 5 juillet à 22 heures

8 avril 1999 - 50 = 17 février 1999



2 octobre 1999 - 8 mars 1999 = 208

Dans le dernier exemple, 208 représente le nombre de jours écoulés entre deux dates. Toute autre opération arithmétique (par exemple multiplier une date par un réel ou additionner deux dates) ne provoquerait pas d'erreur mais n'aurait aucun sens. Nous retiendrons donc d'une façon axiomatique que les opérations possibles sont :

� Une date plus ou moins un nombre de jours donne une nouvelle date.

� Une date moins une autre date donne un nombre de jour.

Les applications de calcul sur les dates sont particulièrement nombreuses. Nous avons par exemple :

� Calcul de la date d'échéance d'une facture avec une formule du type : [DateFacture] + nombre de jours de délais accordé au client.

� Calcul du nombre de jours de découvert bancaire.

� Ventilation de chiffre d'affaire par mois.

Enfin les logiciels d'application possèdent aussi de puissantes fonctions de calcul de décalage de date.


Les types de données principalement utilisées sont :

� Texte � Numérique � Date



Incidence sur le rôle théorique de la base de données :

La description des types de données se retrouve dans les métadonnées. Leur rôle, dans une base de données, est donc de décrire non seulement les tables (noms de tables et de colonnes) mais aussi le type de donnée de chaque champ. En plus de cette tâche de description, les métadonnées vérifieront la validité des données avant leur ajout dans la base. Par exemple, il ne sera pas possible de faire entrer du texte dans un champ numérique.

Ne pas se tromper :

Au moment de la structuration de la base, il est très important d'être attentif au choix du type de chaque champ. Toute rectification ultérieure peut être très coûteuse. Le changement de type de données est facile à effectuer dans les tables. Cependant les traitements (programmes, requêtes, écrans, états mais surtout communications avec d'autres processus externes à l'application) sont toujours prévus pour fonctionner avec un type précis de données. En cas de changement, il faut donc réécrire l'application ou du moins la vérifier. Ceci représente un travail énorme et peu fiable.

L'exemple le plus monstrueux est celui du passage à l'an 2000 de certaines applications un peu anciennes. Changer la structure des fichiers pour que ceux-ci acceptent la date avec le siècle ne pose pas de problème. En revanche, il a fallu vérifier une à une des millions de lignes de programme ! De coûteuses méthodes spécifiques d'adaptation de ces programmes ont dû être mises au point sans que l'on puisse être certain de leur totale efficacité.




Me contacter

Site hébergé

par


� Cours 0 1 2 3



� Fichiers TD :

� TD01 � TD02 � TD03 � TD04





Page 1 sur 1Accueil

15/12/2004http://www.brunocollin.com/default.htm

Nicolas Revault

Nicolas Revault

POURQUOI LES DONNÉES SONT-ELLES STRUCTURÉES DE FACON RELATIONNELLE ?

1) Causes originelles :

Les bases de données sont difficiles à structurer. Ceci n'est pas le fruit de l'imagination sadique de quelques chercheurs en informatique mais imposé par de fortes contraintes techniques et logiques :

1. Contrainte technique :

Les données sont stockées sur des disques (magnétiques ou optiques). Pour retrouver une information, un nom par exemple, il faut que la tête de lecture la cherche sur le disque. Si les données ne sont pas structurées, chaque mot va être examiné et comparé au nom recherché. C'est le système de recherche séquentielle. Il est utilisé pour rechercher un mot dans un document de petite taille (quelque dizaines de pages). Ce système ne peut pas être utilisé pour faire une recherche dans un fichier comportant des millions de noms. Le temps d'attente de la réponse serait trop important. En revanche, il existe une possibilité intéressante de lecture du disque : l'accès direct. La tête de lecture peut accéder directement à une information se trouvant à un endroit quelconque d'un fichier. Pour cela, elle utilise un nombre de caractères (octets) à passer pour accéder directement à l'endroit recherché dans le fichier. Si par exemple une information à retrouver se trouve à partir du 50.000ème caractère, alors elle va passer les 49.999 caractères précédents en une seule fois sans les examiner (contrairement à l'accès séquentiel). L'astuce consiste à déterminer la longeur fixe d'un enregistrement. Si un fichier est structuré en enregistrement de 100 caractères chacun, alors pour accéder directement à la fiche N°17.232, il suffit à la tête de lecture de "sauter" (17.232 - 1) X 100 caractères soit : 1.723.100 caractères. Cette opération est réalisée instantanément en utilisant la table d'allocation de place au fichier (FAT) du système d'exploitation. Dans l'exemple ci-dessous, pour accéder à la fiche de THEODULE qui est la N°3, il faut passer les deux enregistrements précédents. Si chaque enregistrement fait 35 caractères, il faut donc passer 70 caractères pour accéder aux nom et téléphone de la fiche recherchée.

Page 1 sur 5


En conclusion, pour pouvoir rechercher efficacement une information dans un fichier, il faut que celui-ci soit structuré en enregistrement à longueur fixe. Remarque : la rigueur m'oblige à dire que ce shéma est, depuis les années 1990, amélioré par des techniques permettant une bien meilleure gestion de la "consommation" en octets. Cependant, son développement ici n'apporterait aucun élément supplémentaire d'explication quant à la structuration des SGBD.

2. Contrainte logique d'unicité et de maintenance de l'information : Dans toute organisation, une information quelconque (adresse d'un client par exemple) ne devrait être écrit qu'une seule fois. Ceci serait le cas idéal. Chaque fois qu'un service aurait besoin de l'information, il consulterait le fichier central. Par exemple, le service commercial enregistre au fichier l'adresse d'un nouveau client. Le service livraison consulte son adresse pour expédier la marchandise et le service comptable fait de même pour envoyer la facture. Inversement si chaque service tient son propre fichier client, l'adresse doit être recopiée plusieurs fois (premier risque d'erreur) et surtout, lorsque l'adresse du client change, il est très probable que son adresse ne soit pas mise à jour dans les services (oubli de transmission de l'information). Le principe d'unicité de l'information permet de dire : "il n'y a qu'un seul endroit qui détient l'information et c'est à cet endroit qu'elle doit être cherchée" Ce principe est applicable pour n'importe quel traitement de l'information. Prenons comme exemple un journal simplifié d'entrée en stock de marchandises. Celui-ci, tenu dans une base de données simpliste se présente en une seule table :

Pour chaque entrée en stock, le magasinier est obligé de d'écrire, entre autres informations, le nom du fournisseur et du produit. Même si le nom du fournisseur ou de l'article est utilisé plusieurs fois, il doit être ré-écrit. Le risque d'erreur est trop important.

Page 2 sur 5


2) Structuration en tableaux de même nature :

Pour répondre à la contrainte d'unicité d'information, on rassemble les informations dans des listes. Chaque liste représente une catégorie d'information. Par exemple on aura la liste des étudiants inscrits en MSG, la liste des cours proposés en MSG, la liste des professeurs, la liste des inscriptions etc. Le résultat doit être que chaque information n'est écrite qu'une fois. Ceci est bien le cas : dans la liste des professeurs ou des étudiants, chaque nom n'est écrit qu'une fois. Dans l'exemple du journal de livraison, il faut créer trois listes : fournisseurs, articles et livraisons. Nous avons donc :

C'est de loin la phase la plus délicate. Elle dépend entièrement de la bonne analyse du système d'information. Dans cet exemple, une erreur aurait pu être de considérer que les livraisons du 15/02/02 sont identiques alors qu'elles concernent des marchandises différentes. Les listes sont donc les tables de notre base de données.

3) Nécessité de la clé primaire

Le critère d'unicité est bien rempli. Cependant, un nouveau problème se pose alors : il n'est pas possible de faire la relation entre ces tables. Dans notre exemple, pour la livraison du 17/02/02 il n'est pas possible de dire quel fournisseur a fait la livraison ni quel article a été livré. D'un point de vue pratique, il nous manque le numéro du fournisseur et le code de l'article. Ces données nous permettraient d'aller chercher le nom du fournisseur d'une part et le libellé de l'article d'autre part. On doit pouvoir retrouver la référence de chaque élément d'une liste ; c'est à dire la référence de chaque enregistrement. Pour cela, on va, avant toute chose, implanter l'identification unique des enregistrements dans toutes les tables : la clé primaire. Nos tables vont donc se présenter de la façon suivante :

Page 3 sur 5


La champ clé primaire est ici représenté en rouge.

4) Utilisation de la clé primaire pour la connexion

La mise en relation d'une table T1 vers une table T2 se fait par copie de la clé primaire de la table T1 dans un champ de même nature de la table T2 appelé clé externe. Dans notre exemple, chaque enregistrement de livraison doit comporter le numéro du fournisseur (champ CptFourn) et le numéro de l'article (champ CptArt). Nos tables se présentent maintenant de la façon suivante :

Les clés externes sont ici représentées en vert. L'enregistrement de la livraison du 17/02/02 peut maintenant se "lire" de la façon suivante : "La livraison N° 5 (CptLivr) a été faite le 17/02/02 (DateDeLivr) par le fournisseur Vladimir (CptFourn = 2) de 25 (Qté) articles Glablutz (CptArt = 3)."

Page 4 sur 5


5) Vérification par application du contrôle d'intégrité référentielle

Si une table T2 comporte un champ clé externe prévu pour contenir la valeur d'une clé primaire d'une table T1 alors : - ce champ clé externe dans T2 ne peut pas être vide - la valeur contenue dans ce champ correspond à la valeur d'une clé primaire de T1 existante - il n'est pas possible de supprimer un enregistrement de la table T1 si sa clé primaire est utilisée dans la table T2 Dans notre exemple, on peut dire qu'il ne peut pas exister de livraison sans fournisseur ! donc : - le champ CptFourn ne peut pas être vide. - le champ CptFourn ne peut contenir que les valeurs "1" ou "2" ; à savoir les clés d'Arthur ou de Vladimir. Il n'est pas possible d'indiquer "789" qui ne correspond à aucun fournisseur. - il n'est pas possible de supprimer le fournisseur Vladimir car sa clé primaire est utilisée dans la table des livraisons.


La structuration des bases de données en tables reliées entre elles s'explique de la façon suivante :

1. Le stockage des données sur disque impose que ces données soient structurées pour être retrouvées facilement d'une part et chaque information ne doit être écrite qu'une seule fois dans la base de données (cas idéal).

2. Puisque les informations ne doivent être écrites qu'une fois, il faut les structurer en tableaux de même nature.

3. Afin de connecter les tables entre elles, on doit pouvoir retrouver la référence de l'enregistrement d'une table dans une autre table donc dans chaque table on implantera un champ spécial qui contiendra la référence unique de chaque enregistrement : la clé primaire .

4. La mise en relation d'une table T1 vers une table T2 se fait par copie de la clé primaire de la table T1 dans un champ de même nature de la table T2 appelé clé externe .

5. Vérification du mécanisme relationnel par application du contrôle d'intégrité référentielle : un enregistrement dans la table T2 doit obligatoirement comporter une clé primaire existante de la table T1 dans son champ clé externe .

Page 5 sur 5


ANALYSE DE LA STRUCTURE DES DONNÉES

Tableau des données "à plat" :

Principe :

Ce n'est pas une méthode très scientifique. Cependant, appliquée avec rigueur, elle est efficace.

Le système consiste à recenser toutes les données que l'on veut enregistrer dans la base et les présenter dans un tableau à deux dimensions.

Exemple de journal des entrées en stock :

Il se pose alors deux problèmes :

1. Il n'est pas possible d'écrire réellement toutes les données dans le tableau. Imaginons que nous ayons des centaines de milier de lignes d'informations, il n'est pas question de les y mettre toutes. Il faut donc choisir un échantillon limité mais représentatif. En général, quelques lignes suffisent.

2. Si le système d'informations est un peu complexe (beaucoup de types différents d'information) alors le nombre de colonnes est grand et le tableau illisible. La solution consiste à faire une série de petits tableaux par thèmes. Pourquoi ne pas laisser ce tableau tel quel ?

� Avant tout pour une question d'unicité et de maintenance de l'information. Dans notre exemple, le nom d'un fournisseur est répété autant de fois qu'il intervient dans les livraisons. On imagine très bien qu'il est répété de la même façon dans le journal des achats en comptabilité générale. Le risque d'erreur à la recopie manuelle est très élevé (garantie d'unicité de l'information). Si une rectification doit être apportée à un fournisseur, il faudra reporter cette rectification partout où est utilisé le nom de ce fournisseur

Page 1 sur 5


(maintenance de l'information). � Parce que nous voulons disposer d'une liste de nos fournisseurs et la manipuler en dehors de ce tableau : liste de référence,

mailing, statistiques par fournisseur. � Idem pour la liste de nos articles : faire un catalogue, une liste de tarif, statistiques par article. � Et en fait pour tous les usages que nous ne connaissons pas encore mais qui se révèlent en cours d'utilisation.

Pour cela, nous devons décomposer ce tableau en plusieurs tableaux (tables)

Étape 1 du découpage : l'analyse des colonnes

Chaque COLONNE de tableau doit être soumise aux questions suivantes :

1. Dans une même colonne, la même information peut-elle figurer sur différentes lignes ? En d'autres termes : arrive-t-il qu'elle soit répétée dans différentes cases de la même colonne ?

2. Si on modifie une information dans une case du tableau, la modification doit-elle aussi être faite à toutes les informations identiques de la colonne ?

3. L'information ne résulte pas d'un calcul dépendant d'autres données figurant déjà dans la base.

� Si la réponse est OUI à chaque question, alors la colonne doit être mise dans une table séparée � Si une des réponses est NON alors on laisse la colonne dans le tableau d'origine

Application de cette technique à notre exemple :

Page 2 sur 5


Nous avons donc :

� À sortir de ce tableau : {Fournisseur, Référence, Article} � À laisser dans ce tableau : {LivréLe, Quantité, PrixUnitaire}

Traitement du champ calculé :

Par principe, on ne stocke pas une information calculée. Comme dans un tableur, c'est l'ordinateur qui recalcule à chaque fois la valeur en applicant la formule. Il existe quelques exceptions que nous n'aborderons pas ici.

Étape 2 du découpage : la répartition dans des ensembles

Les colonnes vont êtres réparties dans différents ensembles

Choix des ensembles

Page 3 sur 5


On construit les ensembles en fonction du classement logique des éléments. Ici on choisira :

� Un ensemble "Fournisseurs" � Un ensemble "Articles" � Un ensemble "Livraisons"

Ces ensembles sont reliés entre eux :

Vérification de la pertinence :

Dans ces ensembles, chaque élément doit être absolument unique. Dans notre exemple, {Tyristor} ne se trouve qu'à un seul endroit : l'ensemble "Articles". Il est en relation avec l'ensemble "Livraisons" mais il n'en fait pas partie.

Et l'élément {référence} ? il viendrait naturellement dans l'ensemble "Articles". Il ne figure pas dans le schéma car il est synonyme du libellé de l'article : on peut désigner l'article par son libellé (unique) ou sa référence (unique aussi).

Page 4 sur 5



On part du principe qu'une information, pour être exploitée correctement, ne doit pas figurer à plusieurs endroits (il n'y a qu'une seule vérité !)

La préparation de la structuration d'une base de données passe par :

� La "mise à plat" dans un tableau des données qui seront utilisées. � La répartition de ces données dans des ensembles où chaque élément d'information est unique. � La présence physique des éléments dans le tableau de mise à plat est remplacée par les relations entre les ensembles.

Consignes concernant le développement pratique d'un SGBD (en TD ou pour le dossier) :

� Réaliser le tableau de mise à plat au brouillon � Il est inutile de faire figurer ce travail de préparation dans les devoirs ou dans le dossier. En effet, les schémas de structure

des tables de la base seront suffisant pour montrer si votre analyse est bonne.

Page 5 sur 5


STRUCTURATION DES DONNÉES EN TABLES

Étape 1 - la création des tables :

Les ensembles déterminés dans la section précédente sont transformés en tables

Tables de références :

Ce sont les tables qui contiennent des informations de base pour l'organisation : clients, fournisseurs, articles, taux de tva, commerciaux, etc.

Ces tables sont surtout sollicitées en lecture et peu en mise à jour

Dans notre exemple, nous avons donc deux tables de références, "Fournisseurs" et "Articles", structurées de la façon suivante :

Tables d'activité :

Ce sont les tables qui enregistrent l'activité proprement dite de l'organisation : commandes, factures, livraisons. Ces tables sont fortement sollicitées.

Dans notre exemple, il n'y a qu'une seule table d'activité "Livraisons" structurée de la façon suivante :

Page 1 sur 5Cours02_02


Étape 2 - les clés primaires :

Chaque table doit posséder une clé primaire. Le plus simple est de laisser le SGBD numéroter les enregistrements en utilisant un champ à incrémentation automatique. Nos tables possèdent maintenant un champ supplémentaire chacune :

Étape 3 - les relations :

Principe :

Les informations des tables de références sont retirées des tables d'activité. Elles sont remplacées par des relations. Dans notre



exemple, le nom du fournisseur, la référence de l'article et le nom de l'article ne figurent pas dans la structure de la table des livraisons.

Dans la table d'activités doit figurer une information permettant de retrouver sans ambiguïté l'enregistrement de la table de référence. Il faut donc utiliser la clé primaire de la table de référence. Pour recevoir la clé primaire d'une autre table (de références), il faut créer (dans la table d'activité) un champ de même nature et dimension que la clé primaire. Si la clé primaire est un numéro auto, alors il faut créer un champ numérique entier long pour la stocker.

Concrètement :

Dans notre exemple, la table d'activité ("Livraisons") doit recevoir les clés primaires des tables "Fournisseurs" et "Articles". Il faut donc ajouter deux champs à la table "Livraisons" qui devient :

Les champs CptFournisseur et CptArticle sont maintenant "Clé externe"

Enfin nous avons le schéma relationnel suivant :



Astuce pour réussir les relations :

En général, les relations vont des tables de références vers les tables d'activité.

Notion d'intégrité référentielle :

Si on considère qu'une table de référence est, en quelque sorte, une table mère et qu'une table d'activité est une table fille, alors l'intégrité référentielle permet de dire :

"il ne peut pas y avoir de fille sans mère"

Dans notre exemple, on dirait :

� "il ne peut pas y avoir de livraison sans fournisseur" � "il ne peut pas y avoir de livraison sans article"



Donc les champs "clé externe" devront recevoir obligatoirement une clé valide. La plupart des SGBD (Oracle, Sql serveur, Access) permettent d'implanter facilement cette contrainte sur une table.

La manipulation d'implantation de l'intégrité référentielle entre deux tables dans Access est abordée pendant les TD.


La structuration des tables d'une base de données comporte :

� Définition des tables : choix des champs avec leurs types de données, clé primaire � Mise en relation des tables : implantation de clés externes dans les tables qui doivent les recevoir et mise en relation des

tables



QUELQUES EXEMPLES

Pour travailler la méthode, voici quelques exercices. Essayez tout d'abord sur papier puis regardez les solutions.

Livraison de mobilier par un magasin :

Énoncé

Les livreurs ont une liste journalière d'objets à livrer avec l'adresse.

Un bon de livraison-type se présente comme suit :

Solutions

� Tableau de données � Structure des tables et relations

Tableau des leçons de conduite dans une auto-école :

Énoncé



Une auto-école a deux moniteurs {Lucien, Alméric} et deux véhicules {Peugeot 206, Mégane}. Les véhicules ne sont pas affectés à un moniteur particulier. De même, un élève peut avoir l'un ou l'autre moniteur en fonction des disponibilités. Les rendez-vous pour les leçons de conduites sont enregistrés dans un cahier. Pour chaque rendez-vous, la secrétaire inscrit :

� Le nom du moniteur � Le véhicule utilisé � Le nom de l'élève � La date et l'heure de l'inscription

Solutions

� Tableau de données � Structure des tables et relations

Facturation des clients :

Énoncé

Les factures d'une entreprise se présentent sous la forme :



Précisions :

� Les éléments variables de la facture sont en noir et les éléments fixes en vert. � Pour des raisons de simplification, on suppose que la tva est invariable. � On suppose aussi que le prix d'un article est invariable d'un client à l'autre et n'est jamais changé. � Les clients sont réguliers. � L'entreprise a un catalogue de ses produits.

Solutions

� Tableau de données

� Structure des tables et relations




Me contacter

Site hébergé

par


� Cours 0 1 2 3



� Fichiers TD :

� TD01 � TD02 � TD03 � TD04





Page 1 sur 1Accueil


Nicolas Revault

Nicolas Revault

FONCTIONNEMENT D'UN SGBD

Attentes de l'utilisateur :

Quand on utilise un SGBD, c'est pour y réaliser des opérations simples : ajout, consultation, modification ou suppression de données existantes. Et pour effectuer ces opérations, il faut pouvoir rechercher facilement et rapidement les données. On voudra aussi pouvoir faire des extractions de données sur une partie seulement de la base ou encore regrouper les données sous forme de statistiques.

Par ailleurs, il faut que le système ne perde aucune données et qu'il soit capable d'interdire la saisie de données incohérentes (une facture sans client par exemple). Si les utilisateurs sont nombreux, le système doit garantir l'accès à chacun "comme si il était le seul utilisateur" et ne pas mélanger les saisies !!!. Le système doit également vérifier les droits d'accès des utilisateurs.

Programmes d'application :

Aujourd'hui, une même base de données doit pouvoir être utilisable par des outils variés :

� Un programme d'application écrit en C++ ou en Visual Basic pour saisir les données � Un traitement de texte pour faire un publipostage (mailing) � Un tableur pour faire des statistiques � Un site web pour consultation par les clients

En effet, le scénario-type est le suivant :

� Une entreprise met en place une base de données qui prend en charge la gestion commerciale (articles, stocks, clients, commandes, bons de livraisons, facturation). Trois programmes d'applications vont utiliser la même base de données :

� La saisie des documents commerciaux est assuré par le service facturation grâce à un premier programme. � La tenue des stocks est assuré par les magasiniers grâce à un autre programme d'application. � La comptabilité récupère le journal de vente grâce à un troisième programme d'application.

� Après quelques temps d'utilisation le service marketing souhaite utiliser le fichier client pour faire un publipostage ciblé sur une catégorie de client. Il doit donc pouvoir connecter son traitement de texte à la base.

� Par ailleurs, le directeur commercial souhaite suivre sur un tableau de bord l'évolution mensuelle des ventes par objectifs et par commerciaux. Il doit donc pouvoir se connecter à la base avec son tableur.

� Enfin, il est possible de rendre le catalogue articles consultable par internet. Il faut donc que le serveur internet (spécifique) puisse se connecter à la base.




Fonctions d'un SGBD :

Pour répondre aux attentes de l'utilisateur, le SGBD doit :

� Décrire la structure de la base (métadonnées). En effet, la base doit être utilisable par différents programmes d'application ou par des logiciels standards (tableur, traitement de texte). Le SGBD doit donc communiquer à ces programmes la description des tables et des champs disponibles.

� Effectuer les opérations de recherche et de mise à jour sur les données. � Contrôle de cohérence : le SGBD vérifie, avant toute opération de mise à jour, l'applicatoin des règles de cohérence des données. Par exemple,

on ne pourra pas faire de facture sans client (intégrité référentielle) ou encore on ne pourra pas passer d'écriture déséquilibrée dans un journal en comptabilité.

� Traitement correct des mises à jours concurrentes par plusieurs utilisateurs. � Vérification des permissions des utilisateurs (consultation seulement ou autorisation de mettre les données à jour).

Les outils d'un SGBD :

� Le SGBD possède un langage de description des données (LDD) pour construire les métadonnées et un langage de manipulation des données (LMD) pour l'interrogation et la mise à jour des données. Bien souvent ces langages passent complètement inaperçus. On utilise en fait le langage SQL qui est capable d'assurer la création des tables et la manipulation des données. Dans une utilisation standard, on peut même se contenter des interfaces graphiques (très au point) ne nécessitant pas la connaissance de SQL.

� Le contrôle de cohérence sur les données sera assuré de plusieurs façons : � Pour l''intégrité référentielle, il suffit qu'elle soit spécifiée sur la table pour qu'elle soit mise en œuvre immédiatement (pas de

programmation nécessaire) � Pour des contrôles de validité (égalité entre débit et crédit par exemple), il est presque toujours nécessaire de recourir à la

programmation. Pour ce type d'opération, les SGBD clients/serveur type Oracle ou SQL serveur sont nettement avantagés car ils peuvent associer une programmation qui se déclenche automatiquement lors de la mise à jour d'un enregistrement (trigger). Ils peuvent annuler cette mise à jour si elle n'est pas conforme aux règles de la base.

� Lors de la mise à jour des données, le SGBD utilise un système de transactions du type "tout ou rien". Si par exemple une opération porte sur la mise à jour de plusieurs enregistrements, le SGBD vérifie que chaque enregistrement est bien validé.

� Si c'est le cas alors la transaction est validée et la mise à jour est disponible dans la base. � Si un problème est survenu (un enregistrement non conforme par exemple) alors l'ensemble de l'opération est annulée et la

base est restaurée dans son état antérieur.



LES TYPES D'INSTALLATION

Objets logiciels composant une installation

La panoplie des outils est la suivante (on n'est pas obligé de tout utiliser) :

� Le fichier physique de la base (tel qu'il est visible depuis le système d'exploitation). C'est lui que l'administrateur de base de données a la charge de surveiller : vérification du volume occupé, sauvegarde régulière, ...

� Le SGBD (Access, Oracle, SQL Serveur, Sybase, MySql, ...) � Le programme d'application du poste de travail. C'est un ensemble de formulaires/écran, d'états et de traitements qui va permettre à l'utilisateur de travailler

avec la base (mise à jour, interrogation, ...). Il est important de noter qu'il est possible d'avoir plusieurs programmes d'application pour une même base de données. Avec une base de données de gestion commerciale, il est pratique d'avoir une application pour la gestion des stocks, une autre pour la facturation et une troisième pour le marketing. Chacune de ces applications est utilisée par des personnes spécialisées dans des tâches distinctes mais elles partagent la même base de données.

� Des logiciels standard (tableur, traitement de texte, ...) pour des usages spécifiques de la base de données. � Le logiciel réseau (Novell, NT serveur, ...). Indispensable si, comme c'est souvent le cas, l'installation est faite sur réseau local (LAN). � Le pilote (driver) ODBC. C'est un système qui assure la connexion entre le programme d'application et la base de donnée. Il permet de créer des liens vers

des bases de données. Dans la pratique, quand on crée un lien ODBC, on lui donne un nom caractéristique du type "GestionCommerciale" ou "BaseMarketing". Le lien contient toutes les informations nécessaires pour accéder à la base : emplacement du serveur, type de base de donnée, nom de la base, type d'autorisation. Pour connecter un tableur ou un traitement de texte à une base, on le connecte au lien ODBC et la liste des tables et des champs est disponible.

En outre, si les données doivent être accessibles depuis internet, il faut ajouter :

� Le logiciel serveur internet. C'est lui qui est capable d'envoyer des pages internet (format HTML) aux navigateurs clients. � Le développement des pages web avec un langage permettant l'accès au SGBD (ASP, PHP, ...) � On suppose que les postes des internautes sont équipés de navigateurs (Netscape, Opéra, Internet Explorer)

N'est pas mentionné ici les systèmes d'exploitation, pourtant indispensables, mais qui ne rentre pas dans l'analyse des bases de données.

Monoposte :

C'est une configuration assez rare. Elle répond à un besoin individuel : profession libérale ou tâche très spécifique dans un service.



On peut imaginer une base de données qu'un commercial indépendant (VRP) a développé pour lui-même. S'il a utilisé Access, il aura pris soin de séparer le fichier contenant les données (tables) de celui contenant l'application (requêtes, formulaires, états, macros, ...). De sorte que nous avons :

� Programme application : fichier Access ne comportant que des objets requêtes, formulaires, états, macros et modules. � SGBD : Access � Système d'exploitation : Windows � Base de données : fichier Access ne contenant que des tables.

La connexion entre le fichier base de données et l'application sera étudié en TD.

Base Access multi-utilisateurs :

C'est une extention sur réseau local de ce qui précède. C'est une configuration du type "serveur de fichier"



La base de données est simplement installée sur le serveur de domaine. Cette installation permet à plusieurs postes d'utiliser différents programmes d'application partageant la même base de données.

Sur cet exemple, chaque poste doit être équipé d'Access ou du pilote ODBC pour que le programme d'application ou le tableur puisse accéder à la base.

Avantages du système : peu coûteux, développé rapidement (quelques semaines), facile à maintenir.

Inconvénients du système : les contrôles de cohérence de données doivent être soigneusement observés par les programmes d'application (lourdeur de développement). Par ailleurs, rien n'empêche un utilisateur, pour peu qu'il en ait l'autorisation, de modifier la base de données directement avec Access sans



contrôle (il est même possible de détruire complètement la base). Enfin cette configuration ne supporte pas les fortes charges (taille de la base limitée et nombre d'utilisateurs limité).

Système client / serveur sur réseau local :

Le SGBD est placé maintenant sur le serveur. Dans l'exemple ci-dessous, un serveur spécial est dédié à la base de données ce qui soulage le travail du serveur de domaine.



Toute connexion avec la base se fait maintenant au travers d'un lien ODBC

Avantages du système : supporte bien les charges importantes, centralisation de la cohérence des données, bien meilleur contrôle d'accès (on peut rendre la base invisible par les utilisateurs qui n'y accède plus que par le lien ODBDC)

Inconvénients du système : coût beaucoup plus élevé du SGBD (facturé en général au nombre d'utilisateurs) et coût de développement plus élevé des triggers et procédures stockées sur le serveur (nécessite des compétences assez pointues).

Extension internet :

C'est une extension de la configuration précédente. Elle répond au besoin du type "consultation du catalogue articles par les clients" ou encore "consultation de compte pour une banque".

Dans cet exemple, un serveur dédié internet a été ajouté. Certains éléments sont absents du schéma : routeur, modem, firewall qui ne rentre pas dans l'analyse de l'utilisation des bases de données.






Me contacter

Site hébergé

par


� Cours 0 1 2 3



� Fichiers TD :

� TD01 � TD02 � TD03 � TD04





Page 1 sur 1Accueil


Documents

par Site hébergé - revault.u-cergy.fr · 1 2 3 Compléments au cours SGBD Contenu du dossier de fin de semestre Examen partiel janvier 2000 Examen partiel janvier 2001 Fichiers