Les systèmes de gestion de bases de données relationnelles
La partie "Traitements" de la méthode MERISE est généralement enseignée aux
.... Voici par exemple un MCD qui représente une entreprise avec ses employés.
..... Un club de vente de livres par correspondance propose à ses membres l'
achat ..... Un club de tennis vous demande d'informatiser la gestion des
réservations ...
part of the document
LES SYSTEMES DE GESTION DE BASES DE DONNEES
Symboles utilisés à l'intérieur de cet ouvrage:
Paragraphe importantExercice
Table des matières:
TOC \o "1-4" 1. Analyse des systèmes d'information PAGEREF _Toc525445858 \h 9
1.1 Introduction PAGEREF _Toc525445859 \h 9
1.2 Définition de l'information et des systèmes d'information PAGEREF _Toc525445860 \h 10
1.3 Les données, les traitements et les informations PAGEREF _Toc525445861 \h 11
1.4 La représentation informatique des données PAGEREF _Toc525445862 \h 12
2. Démarche de modélisation des données PAGEREF _Toc525445863 \h 13
2.1 Le groupe d'étude (angl. Project group) PAGEREF _Toc525445864 \h 13
2.2 Les étapes PAGEREF _Toc525445865 \h 14
2.3 Sources d'information PAGEREF _Toc525445866 \h 15
3. Méthode de modélisation des données PAGEREF _Toc525445867 \h 16
3.1 Définition PAGEREF _Toc525445868 \h 16
3.2 Pourquoi modéliser ? PAGEREF _Toc525445869 \h 18
3.3 Le modèle conceptuel des données (MCD) PAGEREF _Toc525445870 \h 20
3.3.1 Définition PAGEREF _Toc525445871 \h 20
3.3.2 La notion d'entité PAGEREF _Toc525445872 \h 21
3.3.3 La notion de propriété PAGEREF _Toc525445873 \h 22
3.3.4 La notion d'identifiant PAGEREF _Toc525445874 \h 24
3.3.5 La notion de relation PAGEREF _Toc525445875 \h 25
3.3.5.1 Définition PAGEREF _Toc525445876 \h 25
3.3.5.2 Les cardinalités d'une relation PAGEREF _Toc525445877 \h 26
3.3.5.3 Propriétés d'une relation PAGEREF _Toc525445878 \h 30
3.3.6 Exemple "KaafKaaf" PAGEREF _Toc525445879 \h 32
3.3.7 Exemple "Gestion d'école" PAGEREF _Toc525445880 \h 35
3.3.8 Lutilisation dune relation ternaire PAGEREF _Toc525445881 \h 37
3.3.9 Les contraintes d'intégrité fonctionnelle (CIF) PAGEREF _Toc525445882 \h 39
3.3.10 Exercices PAGEREF _Toc525445883 \h 40
3.3.11 Cas particuliers du MCD PAGEREF _Toc525445884 \h 48
3.3.11.1 Plusieurs relations différentes entre deux entités PAGEREF _Toc525445885 \h 48
3.3.11.2 Relation réflexive et rôle d'une patte de relation PAGEREF _Toc525445886 \h 48
3.3.11.3 La notion d'identifiant relatif PAGEREF _Toc525445887 \h 49
3.3.11.4 Historisation PAGEREF _Toc525445888 \h 50
3.3.12 Exercices PAGEREF _Toc525445889 \h 52
3.4 Le modèle logique des données (MLD) PAGEREF _Toc525445890 \h 57
3.4.1 Définition PAGEREF _Toc525445891 \h 57
3.4.2 Règles de transformation du MCD au MLD PAGEREF _Toc525445892 \h 59
3.4.2.1 Transformation des entités PAGEREF _Toc525445893 \h 59
3.4.2.2 Transformation des relations binaires du type (x,n) (x,1) PAGEREF _Toc525445894 \h 59
3.4.2.3 Transformation des relations binaires du type (x,1) (x,1) PAGEREF _Toc525445895 \h 60
3.4.2.4 Transformation des relations binaires du type (x,n) (x,n) PAGEREF _Toc525445896 \h 61
3.4.2.5 Transformation des relations ternaires PAGEREF _Toc525445897 \h 61
3.4.2.6 Transformation de plusieurs relations entre 2 entités PAGEREF _Toc525445898 \h 62
3.4.2.7 Transformation des relations réflexives PAGEREF _Toc525445899 \h 62
3.4.2.8 Transformation de l'identifiant relatif PAGEREF _Toc525445900 \h 63
3.4.2.9 Transformation de l'historisation PAGEREF _Toc525445901 \h 64
3.4.3 Exemple "KaafKaaf" PAGEREF _Toc525445902 \h 66
3.4.4 Exercices PAGEREF _Toc525445903 \h 67
3.5 Le modèle physique des données (MPD) PAGEREF _Toc525445904 \h 70
3.5.1 Définition PAGEREF _Toc525445905 \h 70
3.5.2 Passage du MLD au MPD PAGEREF _Toc525445906 \h 70
4. Utilisation d'un outil de modélisation PAGEREF _Toc525445907 \h 74
4.1 Définition PAGEREF _Toc525445908 \h 74
4.2 Fonctionnalités PAGEREF _Toc525445909 \h 76
5. Les systèmes de gestion de bases de données PAGEREF _Toc525445910 \h 78
5.1 Définitions PAGEREF _Toc525445911 \h 78
5.2 Un peu d'histoire PAGEREF _Toc525445912 \h 80
5.3 Les composants d'une base de données relationnelle PAGEREF _Toc525445913 \h 82
5.4 Structures physiques et logiques PAGEREF _Toc525445914 \h 84
5.5 Les réseaux informatiques PAGEREF _Toc525445915 \h 86
5.6 L'approche Client/Serveur PAGEREF _Toc525445916 \h 90
5.6.1 La période des ordinateurs du type "Mainframe" PAGEREF _Toc525445917 \h 90
5.6.2 L'approche Client/Serveur PAGEREF _Toc525445918 \h 92
6. Les tables (angl. tables) PAGEREF _Toc525445919 \h 94
6.1 Définition PAGEREF _Toc525445920 \h 94
6.2 Les champs d'une table PAGEREF _Toc525445921 \h 96
6.3 Clé primaire PAGEREF _Toc525445922 \h 98
6.4 Relations entre tables - clé étrangère PAGEREF _Toc525445923 \h 101
6.5 Index PAGEREF _Toc525445924 \h 102
7. Les requêtes (angl. queries) PAGEREF _Toc525445925 \h 104
7.1 Définition PAGEREF _Toc525445926 \h 104
7.2 Introduction au langage SQL PAGEREF _Toc525445927 \h 106
7.2.1 Généralités PAGEREF _Toc525445928 \h 106
7.2.2 Syntaxe SQL de base PAGEREF _Toc525445929 \h 106
7.2.3 Les critères de sélection PAGEREF _Toc525445930 \h 109
7.2.4 Comparaison à un filtre PAGEREF _Toc525445931 \h 111
7.2.5 Les opérateurs logiques PAGEREF _Toc525445932 \h 112
7.2.6 Valeur zéro, chaîne vide et valeur indéterminée (NULL) PAGEREF _Toc525445933 \h 115
7.2.7 Comparaison à une fourchette de valeurs PAGEREF _Toc525445934 \h 117
7.2.8 Comparaison à une liste de valeurs PAGEREF _Toc525445935 \h 118
7.2.9 Définir l'ordre d'une requête de sélection PAGEREF _Toc525445936 \h 119
7.2.10 Les valeurs calculées PAGEREF _Toc525445937 \h 122
7.2.11 Les fonctions d'agrégation PAGEREF _Toc525445938 \h 123
7.2.12 Requêtes sur les groupes PAGEREF _Toc525445939 \h 125
7.2.12.1 La clause GROUP BY PAGEREF _Toc525445940 \h 125
7.2.12.2 La clause HAVING PAGEREF _Toc525445941 \h 128
7.2.13 Exercices PAGEREF _Toc525445942 \h 131
7.3 Les requêtes SQL multitable PAGEREF _Toc525445943 \h 137
7.3.1 La jointure PAGEREF _Toc525445944 \h 138
7.3.1.1 Exemple d'introduction PAGEREF _Toc525445945 \h 138
7.3.1.2 Création d'une jointure PAGEREF _Toc525445946 \h 141
7.3.2 Auto- jointure PAGEREF _Toc525445947 \h 144
7.3.3 Les requêtes imbriquées PAGEREF _Toc525445948 \h 147
7.3.3.1 La requête imbriquée renvoie une seule valeur PAGEREF _Toc525445949 \h 147
7.3.3.2 La requête imbriquée renvoie un ensemble de valeurs PAGEREF _Toc525445950 \h 150
7.3.4 Exercices SQL PAGEREF _Toc525445951 \h 154
7.4 La méthode QBE PAGEREF _Toc525445952 \h 163
7.5 Les contraintes d'intégrité PAGEREF _Toc525445953 \h 165
7.5.1 Définition PAGEREF _Toc525445954 \h 165
7.5.2 Les types de contraintes d'intégrité PAGEREF _Toc525445955 \h 165
7.5.2.1 La contrainte d'intégrité des tables (angl. Table Integrity Constraint) PAGEREF _Toc525445956 \h 165
7.5.2.2 La contrainte d'intégrité référentielle (angl. Referential Integrity Constraint) PAGEREF _Toc525445957 \h 166
7.5.2.3 La contrainte d'intégrité générale (angl. General Integrity Constraint) PAGEREF _Toc525445958 \h 166
7.5.3 Exercice modèle PAGEREF _Toc525445959 \h 167
8. Les formulaires (angl. forms) PAGEREF _Toc525445960 \h 169
8.1 Définition PAGEREF _Toc525445961 \h 169
8.2 Types de formulaires PAGEREF _Toc525445962 \h 173
8.3 Création d'un formulaire PAGEREF _Toc525445963 \h 175
9. Les rapports (angl. reports) PAGEREF _Toc525445964 \h 177
9.1 Définition PAGEREF _Toc525445965 \h 177
9.2 Création d'un rapport PAGEREF _Toc525445966 \h 182
10. Sécurité des données PAGEREF _Toc525445967 \h 184
10.1 Définition PAGEREF _Toc525445968 \h 184
10.2 Les manipulations malveillantes PAGEREF _Toc525445969 \h 184
10.2.1 Définition PAGEREF _Toc525445970 \h 184
10.2.2 La protection contre les manipulations malveillantes PAGEREF _Toc525445971 \h 185
10.3 Les accès non autorisés PAGEREF _Toc525445972 \h 186
10.3.1 Définition PAGEREF _Toc525445973 \h 186
10.3.2 La protection contre les accès non autorisés PAGEREF _Toc525445974 \h 186
10.3.2.1 Mot de passe PAGEREF _Toc525445975 \h 186
10.3.2.2 Droits d'accès aux objets d'une BD PAGEREF _Toc525445976 \h 186
10.3.2.3 Sécurisation du système d'exploitation PAGEREF _Toc525445977 \h 189
10.4 Les incohérences et pertes de données accidentelles PAGEREF _Toc525445978 \h 190
10.4.1 Définition PAGEREF _Toc525445979 \h 190
10.4.2 La protection contre les incohérences et pertes de données accidentelles PAGEREF _Toc525445980 \h 191
10.4.2.1 Les pertes provoquées par des erreurs humaines PAGEREF _Toc525445981 \h 192
10.4.2.2 Les pertes des données en mémoire interne (RAM) PAGEREF _Toc525445982 \h 192
10.4.2.3 Les pertes des données stockées sur disque dur PAGEREF _Toc525445983 \h 192
10.4.3 Les mesures de prévention contre la perte de données PAGEREF _Toc525445984 \h 193
10.4.3.1 La sauvegarde des données (angl. backup) PAGEREF _Toc525445985 \h 193
10.4.3.2 La réplication du disque dur (angl. mirroring) PAGEREF _Toc525445986 \h 195
10.4.3.3 Réplication du serveur (angl. Backup server) PAGEREF _Toc525445987 \h 195
10.4.3.4 Les systèmes RAID-5 PAGEREF _Toc525445988 \h 195
11. Annexes PAGEREF _Toc525445989 \h 196
11.1 Bibliographie PAGEREF _Toc525445990 \h 197
11.2 Sites sur Internet PAGEREF _Toc525445991 \h 199
11.3 Index PAGEREF _Toc525445992 \h 200
Partie 1 : Modélisation d'un système d'information
Analyse des systèmes d'information XE "systèmes d'information"
Introduction
La compétitivité d'une entreprise ainsi que sa valeur sur le marché sont déterminées par plusieurs éléments, d'une importance différente selon le secteur d'activité. On peut généralement regrouper ces éléments en deux classes:
Les éléments matériels
L'infrastructure
Les supports financiers
Les éléments intellectuels
La compétence des employés
La motivation des employés
Le recueil et l'exploitation optimale des informations utiles
Depuis quelques années, les responsables des entreprises (banques, assurances, industrie etc. ) ont davantage reconnu et admis que la gestion et l'exploitation des informations sont un facteur de compétitivité à ne pas négliger.
Le développement rapide de l'informatique a donné aux entreprises la possibilité d'utiliser des moyens avancés et puissants pour gérer et exploiter de très grands volumes de données. Il y a quelques années, le domaine de la gestion informatique des données était réservé aux informaticiens. Actuellement, les tendances à l'intérieur des entreprises ont changé de façon à ce que tous les employés soient de plus en plus impliqués dans les différents procédés liés à la gestion et l'exploitation des données. De cette façon, un certain niveau de connaissance des principes et des outils standards de l'informatique est aujourd'hui requis pour la plupart des postes disponibles dans les entreprises.
Toutefois, il ne suffit pas d'utiliser les ressources informatiques les plus sophistiquées pour exploiter au mieux les données. En parallèle avec les outils informatiques utiles pour gérer des données, tels que les ordinateurs de plus en plus puissants et les logiciels adaptés (SGBD, Tableur etc.), ont été développées des méthodes d'analyse et de conception de systèmes d'information XE "systèmes d'information" . Ces méthodes nous offrent la possibilité d'analyser un système d'information naturel, tel que par exemple la gestion des livres d'une librairie ou la gestion des sinistres d'une compagnie d'assurances, de concevoir ensuite un modèle qui représente ce système et d'implémenter finalement un système informatique, basé sur ce modèle.
Définition de l'information et des systèmes d'information XE "systèmes d'information"
Une information XE "information" est un élément qui permet de compléter notre connaissance sur une personne, un objet, un événement
.
Exemple: Le nom d'une personne est une information concernant cette personne.
La couleur d'une voiture est une information concernant cette voiture.
La date de la fête scolaire est une information concernant cet événement.
Un système d'information est constitué par l'ensemble des informations relatives à un domaine bien défini.
Exemple: Toutes les informations relatives à la gestion d'une librairie constituent le système d'information de cette librairie. Ce système peut couvrir le simple stockage des livres, mais également la gestion des commandes, des ventes et même des clients.
Un système d'information ne doit pas nécessairement être informatisé. Bien que la plupart des systèmes actuels se basent sur la technologie de l'informatique, il existe encore des systèmes d'information XE "systèmes d'information" où l'information est stockée, manipulée et communiquée à l'aide de moyens "traditionnels" tels que armoires, classeurs, calculatrices, fiches sur papier etc. .
Un système d'information existe indépendamment des techniques informatiques.
Le système d'information ne doit pas être confondu avec le système informatique qui est constitué par les éléments suivants:
Les ordinateurs
Les programmes
Les structures de données (Fichiers, Bases de données)
Dans ce chapitre nous allons découvrir une démarche d'informatisation, qui nous permet de modéliser un système d'information et de le représenter à l'aide d'un système informatique. Le but de cette démarche est de concevoir des systèmes stables et optimisés en termes de performance, de fiabilité et de convivialité.
Les données, les traitements et les informations
Bien que les deux termes "informations XE "informations" " et "données XE "données" " soient souvent utilisés comme synonymes, il existe une différence subtile entre eux.
Prenons un exemple:
Dans une librairie, un client demande au vendeur si le livre "L'étranger" (Albert Camus) est disponible en stock. Le vendeur conseille la base de données de la librairie à l'aide de son ordinateur et confirme au client que le livre est disponible. Le vendeur a donc donné au client l'information que le livre est en stock. Afin de pouvoir donner cette information, le vendeur a du consulter les données qui représentent le stock de la librairie. Le fait de consulter le stock constitue un traitement sur les données du stock.
Nous pouvons généraliser:
Un système d'information contient les données et les traitements nécessaires pour assimiler et stocker les informations entrantes et produire les informations sortantes.
Dans les systèmes d'information XE "systèmes d'information" nous retrouvons généralement les traitements suivants:
Consultation des données;
Ajout de données;
Suppression de données;
Modification de données.
Exemple:
Le propriétaire d'une vidéothèque reçoit une livraison avec des nouvelles cassettes vidéo. Pour chaque cassette vidéo, il lit le titre, la langue et la durée et sauvegarde ces informations dans la base de données de la vidéothèque. Il a donc utilisé un traitement d'ajout de données afin de transformer les informations entrantes (titre, langue, durée) en données.
La représentation informatique des données
Les données d'un système d'information peuvent être stockées et manipulées à l'aide d'un outil informatique spécialisé dans ce domaine. Actuellement les Systèmes de Gestion de Bases de Données (SGBD) XE "Systèmes de Gestion de Bases de Données (SGBD)" constituent le type de logiciel le mieux adapté pour implémenter la plupart des systèmes d'information XE "systèmes d'information" . Sachant que les tables forment la base de stockage d'une base de données, on peut représenter n'importe quel système d'information par un ensemble de tables dont chacune contient un certain nombre de champs de données. Nous allons voir qu'on peut même définir des liens entre ces tables via des champs communs.
Démarche de modélisation des données
Le groupe d'étude (angl. Project group)
Un système d'information qui n'est pas trop complexe et volumineux en terme d'informations, peut facilement être informatisé par une seule personne, qui ne doit pas nécessairement être un informaticien. Il suffit d'être un peu familiarisé avec une méthode de modélisation, et de savoir manipuler un SGBD pour réaliser une implémentation informatique, cohérente et fonctionnelle, d'un tel système d'information.
Dès que le système d'information atteint une certaine envergure (par exemple: informatiser la gestion des sinistres d'une compagnie d'assurances), un groupe d'étude est généralement créé.
Ce groupe ne devra en aucun cas contenir seulement des informaticiens mais également:
Un ou plusieurs représentants des futurs utilisateurs du système informatisé
(Par exemple: Un employé du service qui gère les sinistres) ;
Un ou plusieurs représentants de chaque département impliqué
(Par exemple: Un employé du service des contrats ) ;
Un représentant de la direction.
Généralement, un responsable du groupe (angl. Project Manager) est nommé, afin de coordonner les travaux effectués par le groupe et de suivre le déroulement à partir de l'analyse jusqu'à la mise en place du système informatisé.
Les étapes
Chaque projet d'informatisation, qu'il soit exécuté par une seule personne, ou géré par un groupe d'étude, prévoit plusieurs étapes.
En général, nous avons les étapes suivantes:
Analyse de la situation existante et des besoins
Création d'une série de modèles qui permettent de représenter tous les aspects importants
A partir des modèles, implémentation d'une base de données
Sources d'information
La première étape de chaque projet est donc l'analyse de l'existant et des besoins. Afin de pouvoir réaliser une analyse correcte sur laquelle on peut baser la suite du projet, il faut d'abord identifier les sources d'information, et puis collectionner exactement les informations importantes pour le projet.
Sources d'information primaires:
L'interview avec les utilisateurs;
L'étude de documents provenant du système d'information actuel (Rapports, Bons de commandes, Factures
).
Pour les projets d'une certaine envergure s'ajoutent:
L'interview avec les responsables des services impliqués;
Pourvu que la tâche d'analyse soit partagée entre plusieurs membres du groupe d'études, il faut coordonner les actions et comparer les résultats avec les autres membres.
Pour les projets qui se basent sur un système déjà partiellement informatisé s'ajoute:
L'étude de l'application informatique existante.
Méthode de modélisation des données
Définition
Nous avons vu que la démarche classique d'un projet informatique comprend les étapes suivantes:
Analyse de la situation existante et des besoins;
Création d'une série de modèles, qui permettent de représenter tous les aspects importants;
A partir des modèles, implémentation d'une base de données XE "base de données" \t "See BD" .
En ce qui concerne la première étape, nous n'allons pas introduire de vraies règles, mais simplement utiliser nos connaissances de gestion d'une entreprise, notre esprit ouvert et même notre fantaisie pour analyser correctement la situation existante et les besoins des utilisateurs. Le résultat de l'analyse est généralement un ou plusieurs documents, qui contiennent les indications principales sur le fonctionnement désiré du système informatisé. Le document d'analyse contient souvent déjà des prototypes de certains documents importants, que le futur système devra être capable de produire.
Une fois que l'analyse est terminée, il s'agit d'élaborer une série de modèles, basés sur le document d'analyse. Ces modèles nous permettront plus tard d'implémenter une base de données, qui contiendra toutes les informations nécessaires au bon fonctionnement du système informatisé.
La création de ces modèles se fait selon une certaine méthode. Nous allons baser notre cours sur la méthode MERISE XE "MERISE" (Méthode d'Etude et de Réalisation Informatique de Systèmes d'Entreprise), qui a été développée pendant les années '70 sous l'impulsion du ministère français de l'industrie. Merise est aujourd'hui largement répandue au Luxembourg, mais également dans beaucoup d'autres pays européens.
MERISE XE "MERISE" prévoit une conception par niveaux, et définit pour cela 3 niveaux essentiels:
Le niveau conceptuel, qui se base directement sur l'analyse, décrit l'ensemble des données du système d'information, sans tenir compte de l'implémentation informatique de ces données. Ce niveau, qui représente donc la signification des données, se traduit par un formalisme que nous appelons:
Modèle conceptuel des données (MCD XE "MCD" \t "See Modèle conceptuel des données" )
Le niveau logique, qui se base sur le modèle conceptuel des données, prend en considération l'implémentation du système d'information par un SGBD. Ce niveau introduit la notion des tables logiques, et constitue donc le premier pas vers les tables des SGBD. Ce niveau est représenté par le:
Modèle logique des données (MLD XE "MLD" \t "See Modèle logique des données" )
Le niveau physique, qui se base sur le modèle logique des données, contient finalement les tables définies à laide dun SGBD spécifique (p.ex. MS Access, dBASE, Oracle
). Ce niveau est représenté par le:
Modèle physique des données (MPD XE "MPD" \t "See Modèle physique des données" )
Voici donc les 4 étapes nécessaires pour traduire un système d'information naturel en une base de données:
La partie "Traitements", qui décrit la manière d'exploiter les données, est complètement ignorée car les traitements auxquels les élèves seront confrontés se réduisent à de simples manipulations standards du type consultation, ajout, suppression et modification, qui ne justifient pas une méthode d'analyse et de modélisation d'une telle envergure. La partie "Traitements" de la méthode MERISE XE "MERISE" est généralement enseignée aux étudiants d'informatique pendant le premier ou deuxième cycle d'études universitaires.
Le modèle organisationnel des données, intercalé normalement entre le modèle conceptuel des données et le modèle logique des données, représente les aspects primaires suivants:
Où sont gérées les données ?
Qui manipule les données ?
Quelles données sont gérées manuellement et quelles données sont gérées sur ordinateur ?
etc.
Dans le contexte de ce cours, ce modèle est ignoré. Les questions traitées par ce modèle ne sont primordiales que pour les projets de grande envergure, et sont dans la plupart des cas résolues par des informaticiens. Tous les exercices de ce cours peuvent être résolus de façon propre et correcte sans se soucier de ces aspects.
Pourquoi modéliser ?
Nous avons vu quune base de données est constituée par un ensemble de tables qui contiennent toutes les données de la base. Une méthode de modélisation nous permet de trouver le bon nombre de tables pour une base de données et de déterminer quelles données sont représentées à lintérieur de quelle table.
Pour linstant, il nous suffit de savoir quune table est un ensemble denregistrements, dont chacun est composé par les mêmes champs de données. On pourrait comparer une table à une liste en MS-Excel. Les tables sont étudiées en détail dans le chapitre 6.
Voici un exemple dune table :
MarqueModèleCylindréePoids BMW525i25001360FordOrion18001080BMW320i20001200............
A laide dun exemple précis, nous allons voir pourquoi il est important de bien réfléchir sur le nombre de tables dune base de données et sur la structure de chaque table.
Il sagit de créer une base de données pour une caisse de maladie. On veut stocker tous les employés-membres de la caisse avec leur société-employeur. Afin de faciliter lexercice, nous allons uniquement stocker les informations suivantes pour chaque employé:
le numéro de lemployé
le nom de lemployé
le prénom de lemployé
le numéro de son entreprise
le nom de son entreprise
la localité où se trouve lentreprise
A première vue, la solution suivante simpose :
NoEmpNom_EmpPrénom_EmpNoEntrNom_EntrLocalité102BoeschEmil1Schaffgaer S.à r.l.Differdange103MiddErny2GudjärColmar Berg104WitzEvelyne1Schaffgaer S.à r.l.Differdange105KuhlMenn1Schaffgaer S.à r.l.Differdange106SuperJhemp2GudjärColmar Berg..................Nous voyons ici uniquement quelques enregistrements. Une caisse de maladie ayant des miliers de membres, et cette table possédant un enregistrement par membre, on peut bien simaginer la taille réelle de la table.
Hors cette solution, bien quelle soit correcte dans le sens le plus large du terme, nous impose un certain nombre de problèmes .
Exercice 1
Essayez de trouver en discussion quelques problèmes qui peuvent se manifester lors du travail journalier avec cette table.
Exercice 2
Comment est-ce quon pourrait éviter ces problèmes sans toutefois perdre des informations ?
Le modèle conceptuel des données XE "modèle conceptuel des données" (MCD)
Définition
En se basant sur un document d'analyse, le modèle conceptuel des données (MCD) fait référence à tous les objets du système d'information et à des relations entre ces objets. Le formalisme utilisé dans ce modèle est encore connu sous le nom de "Schéma Entité-Relation XE "Schéma Entité-Relation" ". Ce formalisme se base autour de 3 concepts principaux, les entités, les relations et les propriétés.
Voici par exemple un MCD qui représente une entreprise avec ses employés.
Nous allons par la suite détailler le rôle de ces 3 concepts de base du MCD.
La notion d'entité
Une entité XE "entité" permet de modéliser un ensemble d'objets concrets ou abstraits de même nature.
Dans l'exemple du chapitre précédent , l'entité Entreprise spécifie donc l'ensemble des entreprises, qui nous intéressent dans le contexte de notre système d'information. De même, l'entité Employés représente tous les employés de notre système d'information.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Une entité est caractérisée par son nom et ses propriétés.
Représentation graphique:
Prenons par exemple une entité Client:
Voici quelques exemples de clients:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Chacun de ces clients représente une occurrence XE "occurence d'une entité" de l'entité Client.
La notion de propriété
Une propriété XE "propriété d'une entité" est une donnée élémentaire d'une entité.
Une propriété est unique dans un MCD; et ne peut pas être rattachée à plusieurs entités différentes.
Représentation graphique d'une propriété:
Le nom de la propriété est indiqué à l'intérieur du rectangle qui représente l'entité correspondante.
Voici quelques exemples de propriétés:
Pour une entité Client:
Nom du client
No.Tél. du client
Pour une entité Salarié:
Nom du salarié
No. Matricule
Salaire mensuel
Pour une entité Contrat d'assurance:
No Contrat
Type d'assurance
Montant assuré
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT A l'intérieur des occurrences, les propriétés prennent des valeurs
Exemple:
L'entité Client est définie par les propriétés suivantes:
A l'intérieur de chaque occurrence, chaque propriété prend une valeur, qui est dans la plupart des cas une valeur numérique, une valeur sous forme de texte ou encore une date.
La propriété Nom prend p.ex. les valeurs "Meier", "Muller" et "Weber" dans les 3 occurrences.
A lintérieur de chaque occurrence, chaque propriété ne prend quune seule valeur au maximum.
Le client 002 par exemple ne peut pas avoir 2 adresses.
La notion d'identifiant XE "identifiant d'une entité"
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Afin de pouvoir distinguer les différentes occurrences d'une même entité, l'entité doit être dotée d'un identifiant. L'identifiant est composé d'une ou de plusieurs propriétés de l'entité. Chaque occurrence dune entité doit avoir une valeur différente pour lidentifiant Le choix d'un identifiant correcte est très important pour la modélisation:
Comme choix pour l'identifiant d'une entité nous distinguons généralement 3 possibilités:
Une propriété naturelle
Exemple: Le nom d'un pays pour une entité Pays
Une propriété artificielle qui est inventée par le créateur du MCD
Exemple: Le numéro d'un client pour une entité Client
Une propriété composée d'autres propriétés naturelles
Exemple: Le nom et la localité pour une entité Entreprise
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Représentation graphique de l'identifiant d'une entité:
La ou les propriétés qui constituent l'identifiant d'une entité sont soulignées.
Exercice
Indiquez graphiquement les entités qui représentent :
les passagers dun vol dune société aérienne.
les résultats sportifs de lentrainement dun coureur ;
les médicaments dune pharmacie.
La notion de relation
Définition
Une relation XE "relation" décrit un lien entre deux ou plusieurs entités.
Chaque relation possède un nom, généralement un verbe à l'infinitif.
Bien qu'une relation n'ait pas d'identifiant propre, elle est implicitement identifiée par les identifiants des entités auxquelles elle est liée.
Nous distinguons deux types de relations:
les relations binaires, qui sont liées à 2 entités;
les relations ternaires, qui sont liées à 3 entités.
Exemple d'une relation binaire:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324mn.gif" \* MERGEFORMAT
L'occurrence d'une relation est représentée par les occurrences des entités liées à la relation. Voici quelques occurrences de la relation Ecrire.
Une occurrence dune relation est uniquement déterminée par les occurrences des entités liées à la relation.
Pour chaque occurrence dune relation, lidentifiant composé des identifiants des entités liées à la relation doit être unique.
Les cardinalités d'une relation
Une relation XE "relation" est liée à chacune de ses entités par une patte XE "patte" . Sur la patte, on indique les cardinalités.
Les cardinalités précisent la participation de l'entité concernée à la relation. Le premier nombre indique la cardinalité minimale, le deuxième la cardinalité maximale.
Quelle est la signification des cardinalités ?
Exemple 1:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m14.gif" \* MERGEFORMAT
Dans le MCD précédent, entre l'entité Client et la relation Passer, nous avons les cardinalités suivantes:
Cardinalité minimale = 1 , ce qui veut dire que chaque client passe au moins une commande.
Cardinalité maximale = n , ce qui veut dire que chaque client peut passer plusieurs (n) commandes.
Entre l'entité Commande et la relation Passer, nous retrouvons les cardinalités suivantes:
Cardinalité minimale = 1 , donc chaque commande est passée par au moins un client.
Cardinalité maximale =1 , chaque commande est passée au maximum par un seul client.
Exemple 2:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m15.gif" \* MERGEFORMAT
Entre l'entité Employé et la relation Utiliser, nous avons:
Cardinalité minimale = 0 :
Certains employés n'utilisent pas d'ordinateur
Cardinalité maximale = n:
Entre l'entité Ordinateur et la relation Utiliser, nous avons:
Cardinalité minimale = 1 :
Cardinalité maximale = n :
De façon générale, on peut dire:
La cardinalité minimale XE "cardinalité minimale" exprime le nombre minimum de fois qune occurrence d'une entité participe à une relation. Cette cardinalité est généralement 0 ou 1.
Cardinalité minimale = 0 : Certaines occurrences de l'entité ne participent pas à la relation
Cardinalité minimale = 1 : Chaque occurrence de l'entité participe au moins une fois à la relation
La cardinalité maximale XE "cardinalité maximale" exprime le nombre maximum de fois qune occurrence d'une entité participe à une relation. Cette cardinalité vaut souvent 1 ou n, avec n indiquant une valeur >1 mais pas connue à priori.
Cardinalité maximale = 1 : Chaque occurrence de l'entité participe au maximum une seule fois à la relation.
Cardinalité maximale = n : Chaque occurrence de l'entité peut participer plusieurs fois à la relation.
En pratique, afin de déterminer les bonnes cardinalités, le concepteur doit se référer aux résultats de l'analyse.
Exemple 3:
Pour les deux cas suivants, on peut affirmer qu'une commande est toujours passée par au moins un client. Une commande est également passée au maximum par un client. Une commande est donc toujours passée par un et un seul client.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m16.gif" \* MERGEFORMAT
Un client passe au moins une commande et au maximum plusieurs (n) commandes.
Cette modélisation ne tient pas compte des clients qui ne passent aucune commande. Un client est uniquement considéré comme tel s'il passe au moins une commande.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m17.gif" \* MERGEFORMAT
Un client peut passer aucune commande et au maximum plusieurs (n) commandes.
Cette modélisation tient compte des clients qui ne passent aucune commande.
Exercice
Laquelle des deux modélisations est correcte ?
Exemple 4:
Interprétez cette modélisation :
On dit que Client est l'entité indépendante par rapport à la relation disposer (cardinalité minimale = 0) , tandis que Carte_membre est l'entité dépendante par rapport à la relation disposer (cardinalité minimale = 1).
Une occurrence d'un client peut donc très bien exister sans carte de membre, mais une carte de membre ne peut jamais exister sans client. La cardinalité minimale nous indique donc si une entité est indépendante ou dépendante.
On dit qu'une entité est indépendante par rapport à une relation lorsque sa cardinalité minimale vaut 0, et dépendante par rapport à une relation lorsque sa cardinalité minimale vaut 1.
Une relation ne peut pas être liée uniquement à des entités dépendantes ayant en plus une cardinalité maximale de 1 ! ! !
La modélisation suivante par exemple n'est pas correcte:
Dans ce cas, il faut réunir les propriétés des deux entités dans une seule.
Propriétés d'une relation XE "Propriétés d'une relation"
Une relation peut généralement être dotée de propriétés.
Exemple:
Exercice
Pourquoi est-ce quon ne peut pas associer la propriété Année à une des entités ?
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Attention: Cette propriété peut même devenir une partie de l'identifiant. Dans ce cas, elle doit être soulignée.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m18.gif" \* MERGEFORMAT
Comme un professeur peut avoir la même classe pendant plusieurs années (p.ex. Jos Weber àð 12CG2), un identifiant composé de No_Matricule et Code_Classe n'est pas suffisant, puisqu il ne garantit pas l unicité. On y ajoute l'Année.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Attention: Une relation à cardinalité (1,1) n'est jamais porteuse de propriétés. Dans ce cas, les propriétés migrent dans l'entité portant cette cardinalité (1,1).
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m19.gif" \* MERGEFORMAT
Cette modélisation n'est pas correcte ! Chaque facture ne possède qu'une et une seule date d'émission, ce qui fait que la propriété Date_émission doit migrer dans l'entité Facture.
Voici la modélisation correcte:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2324m20.gif" \* MERGEFORMAT
Exemple "KaafKaaf"
PARTIE 1
La société "KaafKaaf" désire informatiser son système de facturation. Les factures devraient se présenter de la façon suivante:
Créez un MCD, qui permet de modéliser correctement le système d'information nécessaire, sachant que:
Un client peut bien sûr recevoir plusieurs factures, mais il est uniquement considéré comme tel à partir du moment où il reçoit sa première facture.
Une facture concerne un et un seul client.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\Kaaf1.gif" \* MERGEFORMAT
Remarque:
Bien que le numéro du client n'apparaisse pas en tant que tel sur la facture, il est préférable d'ajouter cette propriété artificielle à l'entité Client, et de la définir comme identifiant de cette entité. Cela nous empêche de devoir définir un identifiant composé de trop de propriétés.
PARTIE 2
Il s'agit d'étendre le MCD de la partie 1.
Le responsable de la facturation de la société désire rendre les factures plus informatives. Comme un client peut acheter plusieurs articles différents en même temps, la facture devrait indiquer pour chaque article le numéro , un libellé, le prix unitaire, la quantité vendue et le prix total pour ce type d'article.
Voici l'aspect que la facture devrait avoir:
Proposez un nouveau MCD qui reflète ces modifications, en respectant que:
Tous les articles disponibles sont stockés (p.ex. No=234 Libellé="Marteau" PU=470 Luf.). Même si un article n'est pas encore considéré par une facture, il existe dans le système d'information.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\Kaaf2.gif" \* MERGEFORMAT
Remarques:
L'entité Facture ne contient plus la propriété Montant. Il existe une règle générale de conception qui dit:
Aucune propriété XE "propriété calculée" qui peut être calculée à partir d'autres propriétés existantes, ne devra être stockée dans le MCD.
Pour la même raison, on n'a pas besoin de modéliser explicitement le prix à payer pour l'achat d'une quantité d'articles donnés. Le prix pour chaque article figurant sur la facture peut être calculé à partir du prix unitaire et de la quantité
Nous retrouvons ici le cas d'une relation qui a une propriété. En fait, la propriété Quantité n'est pas spécifique à un article, mais à l'achat de cet article à l'aide d'une facture. Cette façon de modéliser la situation est la plus facile, mais il existe une alternative. On peut introduire l'entité abstraite Ligne_de_facture, qui représente une ligne de détail d'une facture, p.ex celle pour le marteau.
Exemple "Gestion d'école"
PARTIE 1
Dans une école, on veut informatiser le système d'information qui gère les classes.
Elaborez un MCD sachant que:
Un élève est caractérisé par son no. matricule, son nom et prénom, ainsi que sa date de naissance.
Une classe est caractérisée par le nom de la classe (p.ex 13CG2) et par une indication du cycle (valeurs possibles: "inférieur", "moyen", "supérieur").
Il faudra prévoir de connaître la fréquentation des classes des élèves sur plusieurs années consécutives.
Un élève enregistré dans le système fréquente au moins une classe au cours des années.
PARTIE 2
Il s'agit maintenant de concevoir une extension au MCD précédent qui permet de représenter la situation suivante:
La direction de l'école désire également saisir tous les professeurs dans le système d'information. Un professeur est caractérisé par un code interne unique (p.ex. Jemp Muller aura le code JEMU), son nom et prénom et la matière qu'il enseigne. Nous supposons que chaque professeur enseigne une seule matière.
Modélisez le fait que chaque classe est enseignée chaque année par un ou plusieurs enseignants. Un enseignant peut bien sûr donner des cours dans plusieurs classes, mais peut également ne pas donner des cours pendant une ou plusieurs années.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\mcdecol1.gif" \* MERGEFORMAT
Lutilisation dune relation ternaire
Lors de lintroduction des relations nous avons déjà mentionné la notion de relation ternaire. Une relation ternaire est une relation à laquelle sont liée 3 entités.
Bien que dans la pratique la plupart des relations soient binaires (2 entités) il existe cependant des situations où lutilisation dune relation ternaire simpose.
Exemple :
A partir des 3 entités Professeur (CodeProf, Nom, Prénom); Matière(CodeMatière, Libellé) et Classe(Nom,Cycle) il sagit de créer un MCD qui renseigne sur le fait quelle matière est enseignée dans quelle classe par quel professeur pour une année scolaire donnée.
Exercice
Essayez de montrer les limites/défauts dun MCD qui représente lénoncé de lexemple précédent en utilisant uniquement des relations binaires.
Solution de lexemple précédent :
Voici une solution qui utilise une relation ternaire
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\reltern1.gif" \* MERGEFORMAT
Il existe 3 façons pour lire/interpréter ce modèle:
Un professeur peut enseigner 1 à n fois une matière dans une classe.
Une matière peut être enseignée 1 à n fois par un professeur dans une classe.
Une classe peut être enseignée 1 à n fois dans une matière par un professeur.
On peut dire que chaque occurrence de la relation enseigner associe un professeur à une matière et une classe pour une année donnée. Ou encore, ce modèle nous permet de montrer pour chaque année scolaire quelle matière est enseignée dans quelle classe par quel professseur.
Il nest pas toujours facile de déterminer quand il faut utiliser une relation ternaire. Généralement, on peut déjà affirmer que si une ou plusieurs des entités liées à une relation ternaire possèdent une cardinalité maximale de 1, la modélisation nest pas optimisée dans le sens quil faudrait mieux décomposer la relation ternaire, c.à.d. la représenter par 2 relations binaires.
Exemple :
La direction dune chaîne dhôtels désire gérer les séjours des clients dans les différents hôtels. Comme on peut effectivement dire "Un client effectue un séjour dans un hôtel" on est ammené à proposer la modélisation suivante.
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\hotel2.gif" \* MERGEFORMAT
Il existe 3 façons pour lire/interpréter ce modèle:
Un client peut effectuer 1 à n fois un séjour dans un hôtel.
Dans un hôtel peut être effectué 0 à n fois un séjour par un client.
Un séjour peut être effectué une et une seule fois par un client dans un hôtel.
Chaque occurrence de la relation effectuer associe donc un séjour à un client et à un hôtel.
Hors, cette modélisation porte une contrainte supplémentaire, puisque la cardinalité 1,1 entre l'entité Séjour et la relation nous indique que pour chaque occurrence de Séjour il ne peut exister qu'une et une seule occurrence de la relation. Donc chaque séjour est associé une et une seule fois à une combinaison client/hôtel. Dans ce cas il vaut mieux décomposer la relation ternaire de la façon suivante:
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\hotel3.gif" \* MERGEFORMAT
Les contraintes XE "contrainte d'intégrité fonctionnelle" d'intégrité fonctionnelle (CIF XE "CIF" \t "See Contrainte d'intégrité fonctionnelle" )
Quand on détermine entre une relation et une entité une cardinalité qui présente les valeurs 0,1 ou 1,1, alors cette relation est particulière et on dit qu'elle représente une Contrainte d'Intégrité Fonctionnelle (CIF).
Exemple:
La relation Obtenir représente une CIF.
Une CIF indique que l'une des entités est totalement déterminée par la connaissance de l'autre. Dans notre exemple on peut dire que connaissant une facture bien précise, on connaît avec certitude le client correspondant.
Comment est-ce qu'on représente une CIF dans un MCD ?
Une CIF est représentée par une flèche sur la patte opposée à celle ayant une cardinalité 0,1 ou 1,1. L'entité qui est attachée à cette patte est appelée entité cible de la CIF, tandis que l'autre entité constitue l'entité émettrice de la CIF.
Exercices
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 1
Voici le résultat simplifié d'une analyse faite auprès d'une compagnie d'assurance qui désire informatiser la gestion des contrats auto.
Un client peut assurer plusieurs voitures auprès de la compagnie. Chaque voiture est assurée par un seul contrat. Un contrat assure une seule voiture.
En ce qui concerne un client, la compagnie désire connaître son nom, prénom, adresse complète, numéro de téléphone ainsi qu'un numéro de compte bancaire avec indication de la banque.
Chaque contrat contient un numéro de contrat unique, la prime annuelle à payer, la date de paiement annuel, la marque de la voiture, le modèle de la voiture, le numéro d'immatriculation de la voiture, la valeur de la voiture et la date d'acquisition de la voiture.
En ignorant la méthode de modélisation, on pourrait créer une BD avec une seule table ayant un champ pour chaque donnée indiquée dans l'analyse. On aurait donc les données des clients et des contrats dans une seule table. Quelles en seraient les inconvénients ?
Créez le modèle conceptuel des données correspondant à cette situation
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 2
Le responsable d'un magasin de location de cassettes vidéo désire informatiser le système de gestion des locations. Voici les informations recueillies pendant l'analyse:
Un membre est caractérisé par son numéro membre, son nom, son prénom, son adresse ainsi que sa date de naissance. Dès que la carte de membre est payée (paiement unique), le membre est enregistré dans le système et il peut désormais louer des cassettes vidéo.
Un film est caractérisé par un numéro film, un titre, un code langue, un code genre et une durée. Le même film peut être disponible en plusieurs exemplaires. Un exemplaire est déterminé par un numéro exemplaire ainsi que la date d'achat de l'exemplaire.
Lors d'une location, un membre peut louer plusieurs films en même temps. En principe, une location a une durée d'un jour, mais cette durée peut être prolongée. Nous supposons qu'un membre rend tous les exemplaires loués en une seule fois.
Créez le modèle conceptuel des données
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 3
Afin d'informatiser la gestion des séances du cinéma Limelight, vous disposez des informations suivantes.
Un film est enregistré dans le système d'information dès que la (les) copie(s) sont arrivées au cinéma. A partir de ce moment, on commence à programmer des séances pour le film en question. Comme le même film n'est jamais joué dans deux séances parallèles, on peut ignorer la gestion des copies.
Un film est représenté par un numéro courant interne, qui lui est affecté par le gestionnaire des séances. En plus, on s'intéresse pour le titre, la langue et la durée du film. Lorsqu'un film apparaît en plusieurs langues différentes, on crée dans le système d'information simplement un enregistrement par langue.
Chaque film est accompagné en général d'une fiche technique, qui renseigne en outre sur le système son du film (p.ex. DOLBY, THX etc.). Cette information est importante, puisque les capacités en ce qui concerne la reproduction du son varient d'une salle dans une autre. Une salle peut supporter plusieurs systèmes différents, tandis qu'un film est tourné en utilisant un seul système son. Un système son est caractérisé par un code identificateur ainsi qu'un libellé.
Le cinéma dispose actuellement de 12 salles, avec 3 nouvelles salles en construction. Une salle est prise en compte dans le système d'information, dès qu'elle est prête pour accueillir des séances. Une salle est caractérisée par son numéro, sa capacité ainsi que des informations concernant le support des différents systèmes son.
Le système d'information doit permettre de vendre des tickets pour une séance donnée, même plusieurs jours en avance. La réservation des sièges n'étant pas demandée, il est toutefois nécessaire que le système soit capable de prévenir un excès de la capacité d'une salle en ce qui concerne le nombre de tickets vendus.
La gestion des prix pour les tickets se fait au niveau des séances, puisque le prix pour voir un même film peut varier d'une séance à une autre (p.ex. Tarif réduit les lundis à 16h00).
Une séance, qui se déroule évidemment dans une seule salle, est identifiée par un numéro courant.
Créez le modèle conceptuel des données
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 4
Un club de vente de livres par correspondance propose à ses membres l'achat d'un ou de plusieurs livres via des bons de commandes. Pour cela, des bons de commandes ainsi qu'un catalogue sont envoyés à tous les membres deux fois par an.
Le responsable du club désire informatiser la gestion des commandes de livres. Voici à titre d'exemple un bon de commande:
Bicherwuerm S.à r.l.
Commande de livres
Votre numéro membre : 123578
( Veuillez nous indiquer des changements éventuels de vos coordonnées personnelles.
Nom: _________________ Prénom: _____________
Adresse: _________________ CP: _____________
Localité: _________________ No. Téléphone: _____________
Votre commande :
( Indiquez s.v.p. pour chaque livre le numéro ISBN et le titre (voir catalogue).
Numéro ISBNTitre12345
Cher membre
Les livres commandés vous seront envoyés le plus vite possible. Une facture vous parviendra après livraison complète.
Au moment où un membre retourne un bon de commande, une nouvelle commande est créée dans le système. Une commande est identifiée par un numéro de commande et caractérisée en plus par une date de commande. Les livres disponibles de la commande sont envoyés tout de suite au membre.
Pour devenir membre du club, il suffit d'effectuer une fois une commande via des bons de commandes légèrement modifiés (p.ex. pas de numéro de membre), et d'indiquer les coordonnées personnelles.
Tous les livres présents dans le catalogue sont également stockés dans le système. Un livre est identifié par son numéro ISBN et caractérisé en plus par un titre, un genre (p.ex. ROMAN, HISTOIRE, BIOGRAPHIE, TECHNIQUE ...), une langue (p.ex. ALL, FRA ...), le nom de l'auteur, le prix de vente et le nombre d'exemplaires disponibles en stock.
Une facture est identifiée par un numéro de facture et caractérisée en plus par une date de facture.
Afin de garantir qu'une facture n'est créée et envoyée au membre qui a effectué la commande correspondante qu'au moment où tous les livres de la commande ont été livrés, le système doit être capable de vous informer quels livres de la commande ont déjà été envoyés au membre et quels livres n'ont pas encore été envoyés au membre (p.ex. livre non disponible en stock au moment de la réception de la commande).
A chaque commande est affectée un seul employé. Un employé est identifié par un code employé (p.ex. WEBJO = Weber Jos). Le responsable du club de vente veut également savoir quel employé (Nom & Prénom) traite quelle commande. Nous supposons que chaque employé a déjà traité des commandes.
De temps en temps, le responsable de la facturation désire avoir un relevé des factures non encore payées.
Créez le modèle conceptuel des données
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 5
Le commandant de la brigade municipale des Sapeurs-Pompiers d'Esch-sur-Alzette se propose d'informatiser la gestion des différentes interventions. Etant responsable de l'administration de la brigade, vous êtes en charge de créer une base de données pour stocker les informations relatives aux interventions.
PARTIE 1
Voici le résultat de l'analyse préliminaire menée auprès des responsables de la brigade (p.ex. le commandant, le sous-commandant
)
Chaque intervention est identifiée par un numéro unique
Une intervention est en plus caractérisée par une date, une adresse et un type d'intervention (p.ex. Incendie, Accident, Inondation)
Pour chaque intervention, on veut savoir quels sapeurs-pompiers y ont participé
Un sapeur-pompier est caractérisé par un numéro d'identification, son nom, son prénom, son âge ainsi qu'un grade (p.ex. sapeur, chef de section, sous-commandant, commandant)
Travail à réaliser:
Créez le modèle conceptuel des données
PARTIE 2
Le commandant vous demande de représenter également l'utilisation des véhicules de la brigade. Lors d'une intervention, les sapeurs-pompiers sont affectés aux différents véhicules selon les circonstances. Jusqu'à présent, le commandant a rempli une fiche pour chaque intervention (Exemple: voir page suivante)
Un véhicule est identifié par son numéro d'immatriculation
Un véhicule est en plus caractérisé par un type de véhicule (p.ex. Echelle, Transport ...), une marque, et le nombre de places disponibles
Travail à réaliser:
Créez le modèle conceptuel des données
Service Incendie Esch-sur-Alzette
Fiche d'intervention
No-Intervention: FORMTEXT 00235 Date: FORMTEXT 11/11/1997 Type: FORMDROPDOWN
Adresse: FORMTEXT 12, bvd. Hubert Clement L-4076 Esch-Sur-Alzette
VéhiculeSapeurEchelle Magirus-DeutzEmilio PegasoJang van der HeckCamion à double pompeToto AlnassoJemp GrisuTransport Ford TransitEmil ZweemilKathrin AllburnMetti PalettiJacques GuddebuerHary Beau
Signature responsable: _____________________
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 6
Il s'agit d'informatiser la gestion des séjours des patients d'un hôpital, ainsi que la gestion des interventions effectuées par les médecins. Jusqu'à présent, cette gestion s'est effectuée à l'aide des fiches suivantes.
Hôpital Municipal de Heinerscheid
Gestion des séjours et interventions
PATIENTSEJOURNo Matricule:No Séjour:Nom:Date Arrivée:Prénom:Date Départ:Adresse:Frais à charge du patient:Code Postal:No Chambre:Localité:Etage:Caisse de maladie:Classe:
INTERVENTION(S):Code intervention:Description:Date:Code Médecin:Nom:Prénom:
Nous supposons qu'un patient occupe la même chambre pendant toute la durée de son séjour.
A part des informations concernant les médecins, qui se trouvent déjà sur les fiches, on désire stocker dans le système d'information le numéro de téléphone et la spécialité de chaque médecin.
Les interventions sont identifiées par un code et une description. L'hôpital dispose d'une liste d'interventions prédéfinies. (p.ex. 0236 Tomographie du crâne)
Les données actuelles sont migrées dans la nouvelle application informatique.
Cas particuliers du MCD
Plusieurs relations différentes entre deux entités
Exemple:
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\possess.gif" \* MERGEFORMAT
Une personne, qui habite dans une maison n'est pas toujours propriétaire de cette maison, tandis que le propriétaire d'une maison ne doit pas nécessairement habiter dans celle-ci. Il incombe donc de représenter le fait de posséder une maison par une relation séparée et le fait d'habiter dans une maison par une relation séparée.
Relation réflexive XE "Relation réflexive" et rôle XE "rôle" d'une patte de relation
Exemple 1:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2326mc2.gif" \* MERGEFORMAT
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Une relation réflexive, est une relation, dont les deux pattes sont liées à une même entité. En général, la signification des pattes d'une relation réflexive devrait être clarifiée par l'indication d'un rôle.
Nous avons donc:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2326m2b.gif" \* MERGEFORMAT
Exemple 2:
Afin d'obtenir une licence pour piloter un avion de ligne, un pilote doit effectuer un certain nombre de brevets. Il existe une hiérarchie prédéfinie en ce qui concerne les brevets (structure arborescente). A chaque fois qu'un pilote a réussi un brevet, il a la possibilité d'effectuer un certain nombre d'autres brevets, qui sont dépendants du brevet réussi. Tous les brevets sont dépendants du brevet de base.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\brevet.gif" \* MERGEFORMAT
La notion d'identifiant relatif XE "identifiant relatif"
Sachant que chaque entité doit obligatoirement être dotée d'un identifiant, certaines entités ont cependant une existence complètement dépendante et liée à une autre entité. Une entité A est complètement dépendante d'une entité B, c.à.d. qu'une occurrence de l'entité A ne peut pas exister sans être reliée à une occurrence de l'entité B, lorsque les deux conditions suivantes sont vraies:
L'entité A est émettrice d'une CIF tandis que l'entité B est cible de la même CIF.
L'entité A n'est pas indépendante par rapport à la CIF (Cardinalité minimale = 1)
Exemple:
L'entité Tâche est complètement dépendante de l'entité Projet.
Dans le cas d'une telle dépendance complète, on peut avoir recours à un identifiant relatif. Dans notre exemple, la propriété No_Tâche constitue l'identifiant relatif de l'entité Tâche. Cette propriété ne remplit dans ce cas pas les conditions pour devenir identifiant absolu (Le même numéro de tâche est susceptible d'apparaître dans plusieurs projets). Toutefois, on peut affirmer qu'en relation à un certain numéro de projet, le numéro de tâche est un identifiant absolu.
On note cette identification relative par la lettre (R) sur la patte reliée à l'entité qui contient l'identifiant relatif.
Historisation XE "Historisation"
Pour certaines propriétés, entités ou relations, on désire parfois conserver les valeurs antérieures en cas de modification. On parle dans ce contexte d'historisation. Théoriquement, cette idée n'est pas tout à fait en accord avec les règles de conception d'un système d'information. Prenons l'exemple suivant:
Pour une occurrence de cette entité, c.à.d. pour un assuré spécifique, il existe uniquement une seule valeur pour chaque propriété. Selon cette modélisation, un assuré ne peut par exemple pas habiter en même temps dans deux localités différentes. En général, ceci ne pose aucun problème, comme un assuré indique normalement une seule adresse de référence.
Toutefois, cette modélisation ne permet pas de représenter le tracé historique des adresses, lorsqu'un assuré déménage une ou plusieurs fois. Dans la plupart des cas, cette modélisation de l'historique n'est pas demandée, mais elle est quand même réalisable à l'aide de la méthode Merise. Au niveau conceptuel, nous indiquons simplement ce que nous voulons historiser.
Nous distinguons 3 cas:
Propriété historisée XE "Historisation:d'une propriété"
La conservation des valeurs historiques s'applique à une ou plusieurs propriétés d'une entité ou d'une relation. Dans le MCD, on indique une historisation de propriété par la lettre (H) derrière la resp. les propriétés concernées.
Exemple:
Entité historisée XE "Historisation:d'une entité"
La conservation des valeurs s'applique à toutes les propriétés d'une l'entité. On indique l'historisation par la lettre (H) derrière le nom de l'entité.
Exemple:
Relation XE "Historisation:d'une relation" historisée
La conservation des valeurs s'applique à toutes les propriétés d'une relation. On indique l'historisation par la lettre (H) derrière le nom de la relation.
Exemple:
On ne peut pas historiser une relation sans propriétés, puisque l'expression 'historiser une relation' n'est qu'un abus de langage, il s'agit en fait d'historiser toutes les propriétés d'une relation. On peut remarquer à ce moment que la méthode MERISE XE "MERISE" présente une particularité en ce qu'elle ne prévoit pas l'historisation d'une propriété individuelle d'une relation
Exercices
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 1
Un club de tennis vous demande d'informatiser la gestion des réservations des différents terrains. A ces fins, vous disposez des informations suivantes.
Le club dispose d'une liste de membres. Quiconque veut jouer sur un des terrains, doit devenir membre du club.
Un membre est caractérisé par un numéro interne au club, par son nom, prénom, adresse, code postal, localité, numéro de téléphone ainsi qu'une indication s'il est un joueur licencié auprès de la fédération de tennis ou non.
Pour chaque réservation, on désire connaître l'identité des deux joueurs membres. Au cas où quatre joueurs réserveraient un terrain, uniquement deux joueurs sont enregistrés dans le système.
Le club dispose de plusieurs terrains, dont certains sont couverts. On distingue en plus le type du terrain selon la nature du sol (p.ex. Sable, Herbe etc.)
Une réservation se fait pour une date précise par tranches d'une heure.
Créez le MCD correspondant.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 2
Une société aérienne utilise à présent les fiches suivantes pour la gestion des ressources.
Vol No. : 98-8-798
DateHeureCode AéroportNom AéroportVillePaysDépart24/08/987h45FINFindelLuxLuxArrivée24/08/989h00LHRHeathrowLonUK
AvionNoMarqueTypePortée (km)Capacité Passagers23Boeing737-4003810147
CommandantNoNomPrénomDate de naissanceBrevet726WeberJos13/06/65PP-IFR/EP/DA
Co-piloteNoNomPrénomDate de naissanceBrevet813MeierEmil23/04/73PP-IFR
Personnel de cabineNoNomPrénom1072FellerNathalie1014PintoTania1103WeisLaurent
Sachant que la société entretient déjà une BD avec tous les pilotes et qu'un pilote peut être commandant d'un vol et co-pilote d'un autre vol, proposez un MCD, qui permet l'informatisation de la gestion des ressources.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 3
Un nouveau parc de vacances va prochainement ouvrir ses portes au Luxembourg. Dans ce parc, les visiteurs sont logés dans des bungalows. Vous êtes chargé de l'implémentation d'un système informatisé pour gérer les réservations des bungalows.
Après plusieurs réunions avec les responsables de la gestion du parc, vous avez collectionné les informations suivantes.
Le parc est subdivisé en plusieurs zones, dont chacune contient environ 40 50 bungalows. Chaque zone dispose de ses propres magasins, restaurants, piscines etc. .
Pour l'ouverture du parc, les zones suivantes sont prêtes à accueillir des visiteurs.
ZoneSituationDescriptionTexasNordImitation "Kloondike-City" avec Saloon, Sheriff Office . . . ChineEstChine traditionnelle avec temple, palais . . . HawaïSud-estAtmosphère tropicale avec palmiers, mer artificielle . . .CamelotSudAmbiance médiévale autour d'un magnifique château ...LiliputCentreZone comportant plein d'éléments des contes bien connus
Les bungalows sont parfaitement intégrés dans l'atmosphère correspondante de leur zone.
Chaque bungalow du parc appartient à une des catégories suivantes, de façon indépendante à sa situation (zone).
CatégorieDescriptionCapacité Prix par nuitABain ou douche / WC sép. / TV31200BBain et douche / WC sép. / TV / Terrasse31500CBain ou douche / WC sép. / TV52000DBain et douche / WC sép. / TV / Terrasse52300EBain et douche / WC sép. / TV / Terrasse73000
Afin de faciliter la gestion des bungalows, le responsable du service Comptabilité vous demande de prévoir uniquement des nombres avec 2 positions pour numéroter les bungalows.
Les clients peuvent effectuer des réservations. Une réservation concerne un seul bungalow. Suite à une réservation, une fiche de réservation est immédiatement envoyée au client. Deux semaines avant la date d'arrivée au parc, une facture correspondante est envoyée au client. Cette facture doit être réglée avant l'arrivée au parc. Le responsable de la facturation veut évidemment garder trace des informations contenues sur les factures. Le responsable de la réception désire voir dans le système si une facture correspondant à une réservation a déjà été payée ou non.
Lors de la réservation d'un bungalow, le client a le choix entre les suppléments suivants.
Code supplémentDescriptionPrix (par personne)
par jour01Literie10002Livraison à domicile du petit déjeuner30003Livraison à domicile du quotidien50
Voici un modèle d'une fiche de réservation
Wonderland S.à r.l.
Parc de bungalows
3, am Boesch
L-8899 Schlindermanderscheid
G.D.Luxembourg
Tél: (Lux)+345566 / Fax: (Lux)+345567
Fiche de réservation
ClientRéservationNuméro: 340No: 589Nom: WeberDate d'arrivée: 03/09/98Prénom: JosDate de départ: 07/09/98Adresse: 23, rue PrincipaleNombre de personnes: 4Code postal: L-8765BungalowLocalité: GrevenmacherZone: LiliputPays: LuxembourgNuméro: 19No. Passeport: 87699Catégorie: Bain et douche / WC sép. / TV / TerrasseNo. Téléphone: (Lux)+348845Capacité: 5
SupplémentsCode supplémentDescription01Literie03Livraison à domicile du quotidien
Une facture vous sera envoyée environ 2 semaines avant votre arrivée au parc. Cette facture est à régler avant l'arrivée au parc. Nous vous souhaitons un beau séjour au parc Wonderland. Si vous avez encore des questions, n'hésitez pas à nous contacter.
Arsène Lupin
RESERVATION MANAGER
Une facture reprend exactement les mêmes informations, avec en plus la date d'envoi de la facture et le prix total à payer.
Afin d'établir des statistiques, la direction du parc est intéressée de sauvegarder dans le système l'évolution des prix par nuit pour les différentes catégories de bungalows.
Un client est uniquement considéré comme tel à partir de la première fois qu'il effectue une réservation.
Créez le modèle conceptuel
Le modèle logique des données XE "modèle logique des données" (MLD)
Définition
Jusqu'à présent nous avons établi des MCD basés sur une analyse d'un domaine bien défini (p.ex. Gestion des séances d'un cinéma, Gestion des séjours des patients d'un hôpital etc.). La finalité d'un MCD est de nous faciliter la création d'une base de données pour gérer un tel domaine.
Nous savons également qu'une base de données est constituée par un ensemble de tables, dont chacune est composée de champs de données.
Hors le MCD ne connaît pas la notion de table, tandis qu'une base de données ne connaît pas le concept des entités reliées entre-elles via des relations portant des cardinalités.
Pour cela, il existe un autre modèle, le modèle logique des données (MLD), qui utilise essentiellement le formalisme des tables logiques. Un MLD, qui est toujours basé sur un MCD donné, contient donc toutes les informations de ce MCD, mais les représente à l'aide d'un formalisme différent qui est très adapté aux structures d'une base de données.
Tandis que le MCD représente un système d'information d'une façon générale et indépendante d'un système informatique, le MLD tient compte de la réalisation par le biais d'un SGBD.
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Un MLD est essentiellement composé de tables logiques reliées entre elles par des flèches.
Voici un exemple qui montre un MCD avec son MLD correspondant:
MCD
MLD
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice
En vous référant à l'exemple précédant, répondez brièvement aux questions suivantes.
Comment est-ce qu'on traduit une entité du MCD dans le MLD ?
Comment est-ce qu'on traduit une propriété d'une entité du MCD dans le MLD ?
Comment est-ce qu'on traduit un identifiant d'une entité du MCD dans le MLD ?
Comment est-ce qu'on traduit la relation Ecrire avec ses cardinalités du MCD dans le MLD ?
Le MCD nous dit que chaque livre est uniquement écrit par un seul auteur (cardinalité max.), tandis qu'un auteur peut écrire plusieurs livres. Comment est-ce qu'on peut retrouver ces informations dans le MLD ?
Remarque:
La méthode MERISE définit de façon générale certaines règles qui nous permettront de transformer n'importe quel MCD en MLD.
Règles de transformation du MCD au MLD
Nous allons définir les règles de transformation pour le passage du MCD au MLD, en respectant les différents cas qui se posent.
Transformation des entités
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Toute entité est transformée en table XE "table (MLD)" . Les propriétés de l'entité deviennent les attributs XE "attributs (MLD)" de la table. L'identifiant de l'entité devient la clé primaire XE "clé primaire (MLD)" de la table.
Exemple:
Entité "Entreprise"
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n1.gif" \* MERGEFORMAT Table "Entreprise"
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n2.gif" \* MERGEFORMAT
Transformation des relations binaires du type (x,n) (x,1)
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Afin de représenter la relation, on duplique la clé primaire de la table basée sur l'entité à cardinalité (x,n) dans la table basée sur l'entité à cardinalité (x,1). Cet attribut est appelé clé étrangère. Les deux tables sont liées par une flèche nommée selon la relation, qui pointe de la table à clé étrangère vers la table qui contient la clé primaire correspondante.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n3.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n4.gif" \* MERGEFORMAT
L'attribut No_Auteur qui est clé primaire de la table Auteur, devient clé étrangère dans la table Livre.
Transformation des relations binaires du type (x,1) (x,1)
Nous devons distinguer plusieurs cas. Sachant qu'une relation binaire du type (1,1)-(1,1) ne doit pas exister il nous reste les 2 cas suivants:
Relation binaire (0,1)-(1,1)
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT On duplique la clé de la table basée sur l'entité à cardinalité (0,1) dans la table basée sur l'entité à cardinalité (1,1).
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n7.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n8.gif" \* MERGEFORMAT
Le No_Client, qui est clé primaire de la table Client, devient clé étrangère dans la table Carte_Membre.
Relation binaire (0,1)-(0,1) !!! Ne figure actuellement pas au programme de la classe 13CG
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT On duplique la clé d'une des tables dans l'autre. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent également attributs de la table dans laquelle a été ajoutée la clé étrangère.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n9.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n10.gif" \* MERGEFORMAT
ou
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n11.gif" \* MERGEFORMAT
Soit on migre la clé primaire de la table Entreprise dans la table Salarié, soit on fait l'inverse.
Transformation des relations binaires du type (x,n) (x,n)
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires des 2 tables. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n12.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2326mc9.gif" \* MERGEFORMAT
On crée une table Porter, qui contient comme clé primaire une clé composée de No-Commande et Code_Article. Elle contient également la propriété Quantité issue de la relation Porter.
Transformation des relations ternaires
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT On crée une table supplémentaire ayant comme clé primaire une clé composée des clés primaires de toutes les tables reliées. Cette règle s'applique de façon indépendante des différentes cardinalités. Lorsque la relation contient elle-même des propriétés, celles-ci deviennent attributs de la table supplémentaire. Une propriété de la relation qui est soulignée devra appartenir à la clé primaire composée de la table supplémentaire.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n14.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n15.gif" \* MERGEFORMAT
La table Enseigner contient une clé composée de No_Enseignant, Code_Matière et Nom_Classe.
Transformation de plusieurs relations entre 2 entités
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Les règles générales s'appliquent
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n16.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n17.gif" \* MERGEFORMAT
La relation habiter du type (x,n)-(x,1), est traduite par la migration de l'attribut Adresse dans la table Personne. La relation posséder du type (x,n)-(x,n) est traduite par la création d'une table supplémentaire du même nom. Cette table contient comme clé primaire composée, les clés des deux tables reliées Personne et Maison. On a donc simplement appliqué 2 fois de façon indépendante les règles de transfert MCD àð MLD.
Transformation des relations réflexives
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Nous appliquons les règles générales avec la seule différence que la relation est 2 fois reliée à la même entité
Exemple 1:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n18.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n31.gif" \* MERGEFORMAT
Comme il s'agit d'une relation (x,n)-(x,n), une table supplémentaire est créée. Cette table contient comme clé primaire composée, la clé des "deux" entités reliées. Comme la même entité est liée 2 fois à la relation, on ne peut pas utiliser 2 fois le même nom pour la clé. Dans ce cas il convient d'utiliser des rôles dans le MCD, et d'intégrer le rôle dans le nom d'une des clés migrées dans le MLD.
Exemple 2:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n20.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n21.gif" \* MERGEFORMAT
Comme il s'agit d'une relation (0,1)-(0,1), nous avons en général le choix en ce qui concerne quelle entité contiendra la clé étrangère. Comme cette relation est liée deux fois à la même entité, il est évident que nous devons dupliquer la clé primaire, tout en veillant que le même nom de clé ne sera pas utilisé pour la clé primaire et la clé étrangère. Dans notre exemple, tous les hommes mariés, ont comme valeur de la clé étrangère la matricule de leur épouse actuelle. Pour les hommes non mariés et les femmes, la clé étrangère est sans valeur. On pourrait bien sûr utiliser la modélisation inverse avec une clé étrangère NO_MATRICULE_MARI, qui indique pour chaque femme mariée, la matricule de son mari.
Transformation de l'identifiant relatif
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Sachant que l'entité dépendante est toujours liée à la relation par les cardinalités (1,1), nous pouvons appliquer les règles générales. Dans chaque cas, la table issue de l'entité dépendante contient donc comme clé étrangère, la clé primaire de l'autre table.
L'identification relative est représentée par le fait que la table issue de l'entité dépendante contient une clé primaire composée, constituée de la clé primaire transformée de l'identifiant de cette entité et de la clé étrangère.
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n22.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n23.gif" \* MERGEFORMAT
Tout en respectant les règles générales du passage MCDàðMLD, la clé primaire de la table Projet migre comme clé étrangère dans la table Tâche. L'identification relative est représentée par le fait que la table tâche contient une clé primaire composée de No_Tache et No_Projet.
Transformation de l'historisation
Historisation d'une propriété
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Pour chaque propriété à historiser, on crée une table qui contient:
Une clé primaire composée de la clé primaire de la table qui contient la propriété à historiser et de la date d'historisation.
La propriété à historiser
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n24.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n25.gif" \* MERGEFORMAT
Historisation d'une entité
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Pour toute modification de valeur d'une des propriétés de l'entité, on historise l'ensemble des valeurs des propriétés dans une table qui contient:
Une clé primaire composée de la clé primaire de l'entité à historiser et de la date d'historisation
Toutes les autres propriétés de l'entité à historiser
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n26.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n27.gif" \* MERGEFORMAT
Historisation d'une relation
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Pour toute modification de valeur d'une des propriétés de la relation, on historise l'ensemble des valeurs des propriétés dans une table qui contient:
Une clé primaire composée de la clé primaire de la table qui représente la relation à historiser et de la date d'historisation
Toutes les autres propriétés de la relation à historiser
Exemple:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n28.gif" \* MERGEFORMAT INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\c2332n29.gif" \* MERGEFORMAT
Exemple "KaafKaaf"
Transformez le MCD suivant, qui représente la facturation de la société "KaafKaaf" (voir chapitre 3.3.6 Exemple "KaafKaaf"), en un MLD en respectant toutes les règles du passage MCD àð MLD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\Kaaf2.gif" \* MERGEFORMAT
Voici une solution:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\KaafMLD1.gif" \* MERGEFORMAT
Exercices
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 1
Transformez les MCD que vous avez réalisés pour les exercices 1 à 6 du chapitre 3.3.10 et les exercices 1 à 3 du chapitre 3.3.12 en MLD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 2
Transformez le MCD suivant en MLD en respectant toutes les règles de passage MCDàðMLD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\medtrav1.gif" \* MERGEFORMAT
Remarques:
En ce qui concerne le rapport médical, une conclusion médicale pourrait par exemple être "Infection" ou "Cancer de la gorge", tandis que la conclusion professionnelle qui s'en suit serait par exemple "Apte" ou "Inaptitude temporaire jours". Les occurrences de cette entité représentent plutôt des types de rapports médicaux standardisés et non pas des rapports médicaux précis.
L'entité Salarié est historisée.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 3
Voici un MCD qui représente de façon très simplifiée la gestion d'une compagnie d'assurances. Transformez le MCD en MLD en respectant toutes les règles de passage MCDàðMLD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\assur1.gif" \* MERGEFORMAT
Remarques:
Le type de contrat indique les garanties prévues.
Exemple: Type AUTO-SIMPLE contient (RC-AUTO et Protection juridique)
Type AUTO-SPECIAL contient (Garanties AUTO-SIMPLE + FEU + VOL)
Type AUTO-DELUXE contient (Garanties AUTO-SPECIAL + Dégâts matériels)
Un contrat couvre un seul risque. Ce risque peut être une voiture ou une habitation.
Afin d'améliorer l'exploitation statistique des données concernant les garanties, le tarif d'une garantie est historisé.
Le modèle physique des données XE "modèle physique des données" (MPD)
Définition
Le modèle physique des données (MPD) est la traduction du modèle logique des données (MLD) dans une structure de données spécifique au système de gestion de bases de données (SGBD) utilisé.
Le MPD est donc représenté par des tables définies au niveau du système de gestion de bases de données. C'est donc au niveau du MPD que nous quittons la méthode générale de création d'un MCD et de sa transformation en MLD, pour nous tourner vers la manipulation d'un SGBD spécifique.
Passage du MLD au MPD
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Le passage MLD àð MPD se fait par les étapes suivantes:
Implémentation physique de chaque table du MLD dans le SGBD utilisé.
Pour chaque table, indiquer au SGBD quel(s) champ(s) constitue(nt) la clé primaire.
Pour chaque table, indiquer au SGBD la (les) clé(s) étrangère(s), et la (les) clé(s) primaire(s) correspondante(s).
Pour ce faire, la plupart des SGBD actuellement sur le marché nous offrent 2 possibilités.
Prenons à titre d'exemple l'implémentation du modèle logique suivant.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\mldmpd1.gif" \* MERGEFORMAT
Utilisation d'une ou de plusieurs interfaces graphiques, qui nous aident dans la création des tables physiques, dans la définition des clés primaires et dans la définition des relations.
Exemple:
Définition de la table des employés avec le champ idEmployé étant défini comme clé primaire.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\mldmpd2.gif" \* MERGEFORMAT
Définition de la relation entre les deux tables.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\mldmpd3.gif" \* MERGEFORMAT
Remarquez que les noms des différents champs ont été modifiés lors de l'implémentation du modèle logique. Cette mesure dépend uniquement de la convention des noms utilisée et n'affecte pas du tout le fonctionnement correcte de la BD.
Utilisation de commandes spéciales, faisant partie d'un langage de définition de données XE "langage de définition de données" (p.ex. SQL-DDL)
Exemple:
Implémentation du même modèle logique à l'aide de commandes spécifiques
REM -----------------------------------------------------------------------------
REM Génération d'une base de données
REM SQL Générique (SQL 2)
REM (6/9/1998 17:03:24)
REM -----------------------------------------------------------------------------
REM Nom de la base : Entreprises
REM Projet :
REM Auteur : Pierre Stockreiser
REM Date de dernière modification : 6/9/1998 17:03:13
REM -----------------------------------------------------------------------------
REM -----------------------------------------------------------------------------
REM TABLE : tblEntreprises
REM -----------------------------------------------------------------------------
CREATE TABLE tblEntreprises
(
idEntreprise INTEGER NOT NULL ,
fldNom CHAR (20) NOT NULL ,
fldAdresse CHAR (25) NOT NULL ,
fldCodePostal CHAR (7) NOT NULL ,
fldLocalité CHAR (20) NOT NULL ,
PRIMARY KEY (idEntreprise) CONSTRAINT PK_ENTREPRISE
);
REM -----------------------------------------------------------------------------
REM INDEX DE LA TABLE tblEntreprises
REM -----------------------------------------------------------------------------
CREATE UNIQUE INDEX I_PK_ENTREPRISE
ON tblEntreprises (idEntreprise ASC);
REM -----------------------------------------------------------------------------
REM TABLE : tblEmployes
REM -----------------------------------------------------------------------------
CREATE TABLE tblEmployes
(
idEmploye INTEGER NOT NULL ,
fiEntreprise INTEGER NOT NULL ,
fldNom CHAR (32) NOT NULL ,
fldPrénom CHAR (32) NOT NULL ,
fldDateNaissance DATE NOT NULL ,
PRIMARY KEY (idEmploye) CONSTRAINT PK_EMPLOYÉ
);
REM -----------------------------------------------------------------------------
REM INDEX DE LA TABLE tblEmployes
REM -----------------------------------------------------------------------------
CREATE UNIQUE INDEX I_PK_EMPLOYÉ
ON tblEmployes (idEmploye ASC);
CREATE INDEX I_FK_EMPLOYER
ON tblEmployes (fiEntreprise ASC);
REM -----------------------------------------------------------------------------
REM CREATION DES REFERENCES DE TABLE
REM -----------------------------------------------------------------------------
ALTER TABLE tblEmployes ADD (FOREIGN KEY (fiEntreprise)
REFERENCES tblEntreprises (idEntreprise)
CONSTRAINT FK_EMPLOYER
ON UPDATE RESTRICT
ON DELETE RESTRICT);
REM -----------------------------------------------------------------------------
REM FIN DE GENERATION
REM -----------------------------------------------------------------------------
Que vous avez utilisé l'une ou l'autre des 2 méthodes, le résultat sera toujours un ensemble de tables physiques reliées entre elles, dans lesquelles vous pouvez stocker des données.
Utilisation d'un outil de modélisation
Définition
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Un outil de modélisation XE "outil de modélisation" est un programme spécialisé dans le support de la conception d'un système d'information.
Il existe actuellement sur le marché une offre très diverse d'outils de modélisation. Chaque outil de modélisation implémente une méthode de modélisation. Comme la méthode MERISE XE "MERISE" est très répandue dans nos régions, il est évident qu'il existe un certain nombre d'outils basés sur MERISE.
En principe, les outils de modélisation sont intégrés dans des applications capables de ne supporter pas uniquement la conception d'un système d'information (BD), mais également le développement complet de programmes de gestion d'une certaine envergure. Ces applications, appelées "Ateliers de génie logiciel" (angl. CASE Tool : Computer Aided Software Engineering Tool), sont généralement utilisés par les informaticiens afin de réaliser des grands projets.
Exemples:
L'outil Win'Design constitue une mise en uvre de la méthode MERISE XE "MERISE" . Notons que Win'Design a été utilisé pour créer les modèles conceptuels et logiques présentés dans cet ouvrage.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\case1.gif" \* MERGEFORMAT
L'application Designer de la société Oracle, constituant un atelier de génie logiciel très répandu, implémente une méthode plus ou moins compatible à MERISE XE "MERISE" en ce qui concerne la modélisation des données (Entity Relationship Modelling).
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\case2.gif" \* MERGEFORMAT
Fonctionnalités
Bien que les différents outils de modélisation, actuellement disponibles sur le marché, varient considérablement en termes de caractéristiques et fonctionnalités, ils offrent cependant les fonctions de base suivantes.
Représentation graphique des modèles conceptuels et logiques avec les différents objets (p.ex. entités, relations, propriétés, identifiants, tables, attributs, clés etc.).
Vérification des règles de construction des différents modèles (p.ex. Une relation ne peut pas être liée à deux entités via des cardinalités 1,1).
Transformation automatique d'un MCD en MLD en respectant toutes les règles de transformation.
Génération automatique d'une BD à partir d'un MLD. Après avoir indiqué le SGBD cible (p.ex. Oracle, MS-Access, Informix), le concepteur peut demander à l'outil de créer la BD. Pour ce faire, il existe deux alternatives:
l'outil de modélisation accède directement au SGBD cible afin de créer la BD en question;
l'outil de modélisation génère un script, qui est à la suite exécuté sur le SGBD afin de créer la BD.
Génération automatique de rapports imprimés concernant l'état actuel d'un travail de conception. Ces rapports contiennent en général la représentation graphique des modèles, des listes avec tous les objets des différents modèles et des explications supplémentaires concernant certains objets.
Gestion des objets de conception (p.ex. entités, relations, propriétés, identifiants, tables, attributs, clés etc.) dans un dictionnaire. Pour des petits projets de conception, effectués par un seul concepteur sur un ordinateur, le dictionnaire est simplement un fichier stocké localement. Toutefois, pour les grands projets, effectués par plusieurs concepteurs, certains outils de modélisation permettent la gestion d'un dictionnaire sur un serveur en réseau (voir chapitre 5.5). Dans ce cas, plusieurs concepteurs peuvent travailler en même temps sur un modèle, l'outil de modélisation veillant à chaque moment que le modèle reste cohérent. L'intégration de plusieurs modèles en un seul modèle, et la gestion des versions d'un objet ou d'un modèle constituent d'autres caractéristiques supportées par un tel système.
La plupart des outils de modélisation sont capables de créer un MLD et un MCD à partir d'une BD existante. Ce procédé, connu sous le nom de "Reversement d'une BD" (angl. Database Reverse Engineering), est souvent utilisé à la base d'un projet d'amélioration ou d'extension d'un système d'information existant déjà sous forme informatique.
Partie 2 : Exploitation des bases de données relationnelles
Les systèmes de gestion de bases de données
Définitions
Une base de données XE "base de données" (BD XE "BD" \t "See base de données" ) est un ensemble bien structuré de données relatives à un sujet global. Ces données peuvent être de nature et d'origine différentes.
Exemple: Une banque peut avoir une BD, qui contient les informations nécessaires sur tous les clients et leurs dépôts d'épargne.
Une société d'assurances peut stocker les données relatives aux contrats d'assurances ainsi qu'aux sinistres dans une BD.
Un système de gestion de bases de données XE "système de gestion de bases de données" (SGBD XE "SGBD" \t "See système de gestion de bases de données" ) est un programme qui nous permet de créer, de modifier et d'exploiter des bases de données. Ce système constitue donc notre interface pour accéder aux données.
Un utilisateur utilise un SGBD pour accéder aux données d'une base de données.
Par analogie:
Un utilisateur utilise un tableur pour accéder aux données d'une feuille de calcul, respectivement un traitement de texte pour accéder le texte d'un document.
Exercice
Discutez les avantages et désavantages d'une gestion de données informatisées à l'aide d'un SGBD, et comparez cette gestion à la gestion non informatisée.
Un peu d'histoire
Avant les années '70, la plupart des systèmes qui permettaient de gérer des grands volumes de données d'une façon plus ou moins cohérente étaient basés sur de simples fichiers séquentiels. Ces systèmes de gestion de fichiers (SGF) s'avéraient particulièrement limités lorsqu'il s'agissait de gérer une grande masse de données comportant des liens entre elles.
Classiquement, cette masse de données était répartie dans différents fichiers. L'utilisation de ces données n'était possible que par le biais de programmes spécialisés, qui ont du être réalisés par des programmeurs ayant une connaissance technique approfondie de la structure des fichiers. Chaque nouvelle interrogation du SGF nécessitait donc l'intervention d'un programmeur.
En plus, les SGF n'ont pas assuré la cohérence des données. Le programmeur était seul responsable pour garantir l'intégrité des données. Prenons l'exemple d'un SGF qui était utilisé dans une banque pour la gestion des clients et de leurs dépôts. Rien n'empêchait un programmeur de créer dans le fichier des dépôts un nouveau dépôt pour un client qui n'existait pas du tout dans le fichier des clients etc. .
Ceci étant seulement quelques exemples des inconvénients des SGF, nous remarquons qu'il était difficile pour un utilisateur d'utiliser directement un tel système. Il fallait souvent l'intervention d'un programmeur, qui devait faire bien attention à préserver la structure des données dans un rapport cohérent, tout en satisfaisant les besoins d'informations de l'utilisateur.
Déjà vers la fin des années 60, les premiers systèmes qui étaient capables de cacher la représentation interne des données à l'utilisateur, apparaissaient sur le marché. Ces systèmes, qui offraient à l'utilisateur une certaine structure logique pour stocker les données, étaient déjà équipés de certains mécanismes de base pour assurer la cohérence des données via des règles qui pouvaient être définies par l'utilisateur. Le système vérifiait ces règles lors de chaque modification des données. Dans un système de gestion des dépôts d'une banque, une telle règle pouvait par exemple exprimer le lien explicite entre un dépôt client et une personne. Ces systèmes étaient essentiellement basés sur les deux modèles de données suivants:
Modèle réseau développé initialement par la "Conference On Data Systems and Languages" (CODASYL) en 1961
Modèle hiérarchique développé pour la plus grande partie par la société IBM pendant les années 1965 - 1970
C'était en 1970 qu'un nouveau modèle pour représenter les données, le modèle relationnel, fut proposé par E.F.CODD. Le but de ce modèle, était d'accroître l'indépendance vis-à-vis de l'implémentation interne des données. Du point de vue de l'utilisateur, les données sont stockées dans un ensemble de tableaux, appelées "tables relationnelles" ou simplement "tables". Le stockage ainsi que la manipulation des données se basent sur le concept mathématique de l'algèbre relationnelle et du calcul relationnel. Ces concepts proviennent de la théorie mathématique des ensembles, et on y retrouve des notions telles que "Union", "Intersection" ou "Produit cartésien".
Il a fallu attendre le milieu des années 70 pour voir apparaître les premiers systèmes qui étaient basés sur le modèle relationnel, les "Systèmes de Gestion de Bases de Données Relationnelles (SGBDR)".
En 1976 apparaît le modèle Entité-Association, proposé par P.CHEN, qui donnait aux concepteurs des bases de données relationnelles une méthode adéquate pour modéliser des données d'un domaine quelconque (banques, assurances, industrie
) par une structure bien cohérente de tables relationnelles. Le modèle Entité - Association devenait ainsi le modèle théorique de conception de données sur lequel se basaient beaucoup de bases de données relationnelles.
Pendant les années '80 et '90, beaucoup de SGBDR étaient commercialisés pour les différentes plates-formes informatiques (Mainframe, Serveurs UNIX, Serveurs VMS, PC...). Citons quelques exemples de SGBDR populaires qui tournent actuellement sur PC:
Personal ORACLE
MS-ACCESS
Visual dBASE
Visual FOXPRO
Borland PARADOX
Lotus APPROACH
Aujourd'hui, les bases de données relationnelles se réjouissent d'une grande popularité. Surtout le domaine de la gestion des données à l'intérieur des entreprise est entièrement dominé par ces systèmes.
Pour la suite de ce cours, nous allons nous limiter à l'étude des bases de données relationnelles. Nous entendons donc par chaque référence à une base de données (BD), la notion de base de données relationnelle. Il est également sous-entendu que les deux notions SGBD et SGBDR dénotent un système de gestion de bases de données relationnelles dans le contexte de ce cours.
Les composants d'une base de données relationnelle
Une base de données relationnelle contient en général quatre types de composants (d'objets). Nous allons brièvement introduire ces types d'objets sans aller trop dans les détails. A chacun de ces objets sera consacré un chapitre séparé.
1. Les données sont stockées à l'intérieur de tables. Une table peut être comparée à une liste, qui contient des enregistrements relatifs à un domaine bien défini.
Exemple: Le service du personnel de l'entreprise SCHAFFGAER S.à r.l. entretient une BD avec en outre une table pour les données des employées. Cette table contient un enregistrement pour chaque employé, avec le nom, le prénom, l'adresse, la localité, la date de naissance, la date d'entrée en service, le salaire mensuel et le nom du département auquel l'employé est actuellement affecté.
2. Les requêtes constituent dans un certain sens des "questions" qu'on pose au SGBD. Le résultat d'une requête est toujours un sous-ensemble d'une ou de plusieurs tables.
Exemple: Le chef du personnel de l'entreprise SCHAFFGAER S. à r.l. désire connaître les noms, prénoms, adresses et localités des employés recrutés en 1996. Il doit formuler une requête qui sera exécutée par le SGBD, et qui donnera comme résultat une liste semblable à la table des employés, mais contenant uniquement les employés qui vérifient le critère de sélection de la requête, et pour chacun de ces employés seulement les informations demandées.
Voici le résultat de cette requête:
3. Les formulaires sont utilisés pour ajouter, modifier ou supprimer des données dans les tables. Bien que la plupart des SGBD nous permettent d'accéder les données directement dans les tables, les formulaires nous offrent certains avantages en ce qui concerne la facilité d'utilisation, mais également la sécurité des données.
Exemple: La secrétaire du chef du personnel utilise un formulaire pour ajouter ou supprimer un employé de la BD. Ce formulaire lui permet également de modifier les données d'un employé.
4. Souvent on veut imprimer des statistiques; concernant certaines données d'une BD. C'est ici qu'interviennent les rapports. Les rapports sont similaires aux formulaires, à la différence près, qu'ils sont uniquement destinés à être imprimés et qu'il n'y a pas de dialogue interactif avec l'utilisateur. Un rapport se base généralement sur une ou plusieurs tables ou bien le résultat d'une requête.
Exemple: A la fin de chaque mois le chef du personnel reçoit un rapport avec pour chaque département, la liste des employés, leur salaire mensuel ainsi que le salaire mensuel total payé par département.
Structures physiques et logiques
Un SGBD utilise les ressources de l'ordinateur sur lequel il est exécuté. Les données des SGBD sont ainsi stockées par exemple sur un disque dur ou sur un autre support de stockage, de la même façon que les autres fichiers, générés par les autres programmes (p.ex. Traitement de texte, Tableur
) qui tournent sur l'ordinateur.
Qu'est-ce qu'on entend par structure physique ?
Le système d'exploitation (p.ex. DOS, Windows, Windows NT
), qui connaît seulement la notion de fichier en ce qui concerne le stockage des données, ignore en principe le contenu de ces fichiers. Les fichiers constituent dans un certain sens la structure physique des données.
Chaque programme crée des fichiers ayant un format spécifique à ce programme. L'utilisateur peut reconnaître le format par l'extension derrière le nom du fichier.
Par exemple: .doc ( fichier MS-Word
.xls ( fichier MS-Excel
Qu'est-ce qu'on entend par structure logique ?
Chaque programme offre également à l'utilisateur la possibilité de manipuler des composants, qui existent seulement dans le contexte de ce programme.
Par exemple: Document ( Composant logique de MS-Word
Feuille de calcul ( Composant logique de MS-Excel
Classeur ( Composant logique de MS-Excel
Ces composants ou structures logiques sont uniquement visibles par le biais du programme correspondant. On vient de définir les composants standard d'un SGBD dans le chapitre précédent:
Les tables
Les requêtes
Les formulaires
Les rapports
Quelle est la relation entre une structure logique et sa structure physique correspondante ?
Cette relation dépend du programme.
MS-Word: Chaque document (composant logique) correspond en principe à un fichier .doc (structure physique).
MS-Excel: Chaque classeur (composant logique) correspond à un fichier .xls (composant physique). Attention: Un classeur peut contenir plusieurs feuilles de calcul.
En ce qui concerne les SGBD, il existe deux variantes:
Chaque composant (table, formulaire
) d'une BD est stocké dans un fichier séparé. Une base de données constitue donc un ensemble de fichiers. Exemple: dBASE
Tous les composants d'une BD sont intégrés dans un seul fichier. Exemple: MS-Access
Exercice
Discutez les avantages et désavantages des deux concepts d'implémentation possibles pour les composants d'une BD.
Les réseaux informatiques
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT A son niveau le plus élémentaire, un ré XE "réseau informatique" XE "réseau" \t "See Réseau informatique" seau se compose de plusieurs ordinateurs reliés entre eux par un câble, afin de pouvoir échanger des données et partager des ressources, tels que des imprimantes, de l'espace disque etc. .
Dans le contexte d'un réseau, ces ordinateurs sont appelés postes de travail (angl. workstation). Les postes de travail peuvent être répartis sur plusieurs étages d'un bâtiment ou même sur plusieurs bâtiments voisins. Un tel réseau est appelé réseau local (angl. LAN = Local Area Network).
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\reseau1.GIF" \* MERGEFORMAT
Afin de pouvoir être connecté à un réseau, un ordinateur doit disposer d'une carte réseau.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\reseau2.gif" \* MERGEFORMAT
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT La plupart des réseaux locaux contiennent des ordinateurs très puissants en termes de vitesse d'exécution et de capacité de stockage. Ces ordinateurs, encore appelés serveurs XE "serveur" dédiés (angl. Server), ne sont généralement pas utilisés comme poste de travail, mais ils doivent effectuer un certain nombre de tâches variées.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\reseau3.gif" \* MERGEFORMAT
On distingue plusieurs types de serveurs.
Les serveurs de fichiers (angl. File Server) contiennent généralement des fichiers appartenant aux différents utilisateurs du réseau. Par exemple, si vous utilisez un programme de traitement de texte sur un poste de travail, ce programme se trouve localement sur le poste. Cependant, le document sur lequel vous désirez effectuer des modifications, stocké sur le serveur, est chargé dans la mémoire locale de votre poste de travail, afin que vous puissiez l'utiliser. Lors de chaque opération de sauvegarde (angl. Save/Save As), le fichier est effectivement sauvegardé sur le serveur. Le serveur gère bien sûr l'accès des utilisateurs, qui doivent généralement s'identifier par un nom et un mot de passe, afin de garantir une certaine sécurité des données.
Les serveurs d'impression (angl. Print Server) effectuent la gestion des imprimantes connectées au réseau. Lorsque le réseau comporte une multitude d'imprimantes différentes, un utilisateur sur son poste de travail peut sélectionner une imprimante en fonction des caractéristiques (p.ex. impression couleur/NB), des capacités (p.ex. nombre de pages imprimées par minute) et de l'emplacement physique (p.ex. imprimante à la même étage que le poste de travail). Lors de l'impression (angl. Print), le document à imprimer est d'abord envoyé dans une file d'attente (angl. Print Queue) qui se trouve sur le serveur d'impression. Le serveur d'impression contient généralement une file d'attente par imprimante. Les documents d'une file d'attente sont envoyés un après l'autre vers l'imprimante correspondante.
Les serveurs d'applications (angl. Application Server) contiennent des applications ou programmes destinés à l'utilisation en réseau. Un exemple populaire constituent les applications du type "Groupware", qui permettent aux utilisateurs du réseau d'échanger des messages électroniques (angl. E-Mail), d'entretenir un agenda électronique commun et de travailler soi-disant en même temps sur des document partagés. Les serveurs de bases de données (angl. Database Server), appartenant également à cette catégorie, sont très répandues. Avant la période où les PC devenaient populaires, les bases de données ainsi que les programmes pour les manipuler, se trouvaient sur des grands ordinateurs puissants du type "Mainframe". L'utilisateur était connecté au mainframe à l'aide d'un terminal composé d'un clavier et d'un écran. Contrairement à un PC, un terminal peut uniquement envoyer des caractères au mainframe et afficher les caractères, qui lui sont envoyés par le mainframe. Avec l'arrivée des PC, dont les fonctionnalités ne se limitent pas à l'envoi et à l'affichage de caractères, le rôle des serveurs a considérablement changé. Actuellement, dans les environnements dits "Client/Serveur", les PC constituent des clients "intelligents", qui sont en parfaite communication avec les serveurs, dont le but principal est de "répondre" aux questions qui leurs sont posées par les clients. L'architecture Client/Serveur est explicitée plus en détail dans le chapitre 5.6 .
Les réseaux informatiques ayant une certaine taille, en termes du nombre de postes et de serveurs, sont généralement gérés par un administrateur réseau, personne (ou groupe de personnes) en charge de la gestion, du contrôle et de l'entretien du réseau.
Lorsque la distance géographique couverte par un réseau augmente en connectant des utilisateurs situés par exemple dans des villes ou même des pays différents, plusieurs réseaux locaux sont connectés en un seul réseau étendu (angl. WAN = Wide Area Network), qui peut ainsi regrouper plusieurs milliers d'utilisateurs.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\reseau4.gif" \* MERGEFORMAT
En utilisant de l'équipement réseau spécialisé dans ce domaine, on peut connecter plusieurs réseaux locaux via un réseau public. Ce réseau public peut par exemple être constitué du réseau téléphonique public, d'un ensemble de lignes louées (lignes dédiées), d'un réseau de câbles en fibre optique, d'un réseau rapide de commutation de paquets ou même d'une liaison par satellite.
A titre d'exemple, on peut mentionner l'Internet, qui n'est rien d'autre qu'un gigantesque réseau étendu.
Pour un utilisateur, le travail dans un réseau local ou étendu est tout à fait transparent. Il peut par exemple accéder à des fichiers distants de la même manière qu'à des fichiers qui se trouvent sur son disque dur local.
L'approche Client/Serveur
La période des ordinateurs du type "Mainframe"
Avant la période où les PC devenaient populaires, les bases de données ainsi que les programmes pour les manipuler; se trouvaient sur de grands ordinateurs puissants du type "mainframe". On parlait d'une architecture centralisée, puisque les BD, le SGBD et les objets tels que requêtes, formulaires, rapports étaient stockés sur le "mainframe".
L'utilisateur était connecté au "mainframe" à l'aide d'un terminal composé d'un clavier et d'un écran. Contrairement à un PC, un terminal ne possède aucune "intelligence" propre, c.à.d. qu'il peut uniquement envoyer des caractères au "mainframe" et afficher les caractères, qui lui sont envoyés par le "mainframe", et ceci en plus uniquement en mode caractère.
Lorsque l'utilisateur veut par exemple afficher un formulaire, la construction du formulaire se fait complètement sur le "mainframe". Ensuite, le formulaire où plutôt l'apparence du formulaire est envoyé via le réseau vers le terminal de l'utilisateur.
Exemple d'un formulaire en mode caractère:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\cs1.GIF" \* MERGEFORMAT
Architecture "mainframe":
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\cs2.GIF" \* MERGEFORMAT
Avantages de l'architecture "mainframe":
Les "mainframe" étant de grands ordinateurs très puissants, les systèmes atteignent de très belles performances, d'autant plus qu'il n'y a pas de représentation graphique sur les terminaux.
Désavantages de l'architecture "mainframe":
Aucune capacité de calcul sur le terminal, donc impossible d'exécuter des programmes sur le terminal.
Pas de représentation graphique sur le terminal. Formulaires etc. moins faciles à utiliser.
Le "mainframe" étant sous la seule gestion du service informatique, les utilisateurs peuvent uniquement accéder les BD via des formulaires etc. créés par les informaticiens. (Cette mesure s'avère parfois avantageuse ()
Le réseau est assez chargé, surtout lorsque le nombre de terminaux accroît.
Les requêtes, formulaires etc. sont fortement couplés au SGBD ce qui les rend pratiquement inutilisable lorsqu'une société veut migrer vers un autre SGBD.
Exemples de SGBD pour "Mainframe":
DB2 de IBM
RDB de DEC
En fait, les informaticiens sont depuis longtemps à la recherche de systèmes ouverts. La finalité d'un système ouvert consiste dans le fait que ses composants (ordinateurs, SGBD etc.) sont échangeables sans que tous les objets en utilisation (requêtes, formulaires etc.) doivent être complètement redéfinis resp. reprogrammés. Tous les éléments d'un tel système doivent donc supporter au maximum possible certains standards. Un élément important de la philosophie des systèmes ouverts est constitué par l'approche Client/Serveur.
L'approche Client/Serveur XE "Client/Serveur"
L'évolution historique des architectures informatiques vers les architectures du type Client/Serveur (angl. Client/Server) dans les années '90; peut être ramenée surtout aux facteurs suivants.
L'arrivée au marché des PC.
L'apparition de serveurs, machines moins chères et moins spacieuses que les "mainframe", avec cependant une capacité de calcul et de stockage analogue à celle des "mainframe".
L'émergence de systèmes d'exploitations standardisés tels que UNIX ou Windows NT.
L'apparition des SGBD indépendants de la plate-forme et disponible pour tous les systèmes d'exploitation standardisés
L'approche Client/Serveur implémente une décentralisation des applications BD. En fait, les BD sont gérées sur un serveur BD, tandis que les interfaces pour visualiser et manipuler les données (p.ex. formulaires, rapports) se trouvent sur les PC client, dans un environnement ergonomique.
Sur le poste client se trouve donc en principe un SGBD client, offrant toutes les fonctionnalités requises, qui émet des requêtes formulées dans un langage d'interrogation de données au serveur BD via le réseau. Le serveur exécute les requêtes qui lui ont été transmises et renvoie le résultat au client. Le client représente alors le résultat en se servant par exemple d'un formulaire ou d'un rapport qui a été défini antérieurement.
Architecture Client/Serveur:
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\cs3.GIF" \* MERGEFORMAT
Avantages de l'architecture Client/Serveur:
Les utilisateurs deviennent des clients avec des postes de travail intelligents (PC), à l'aide desquels ils peuvent connecter les applications bureautiques directement aux serveurs BD, afin de gérer dans un environnement convivial les données de l'entreprise, sans être dépendant des services d'un informaticien pour résoudre le moindre problème.
Les réseaux informatiques modernes permettent un accès transparent à plusieurs serveurs BD, et ceci même de façon simultanée.
Une partie de la capacité de travail est partagée entre les serveurs et les clients, ce qui crée un certain équilibre.
Une panne du serveur n'empêche pas nécessairement tous les utilisateurs de travailler avec l'outil informatique. Certains travaux peuvent être exécutés sans connexion au serveur.
L'architecture Client/Serveur, reposant sur les systèmes ouvert, offre en plus l'avantage qu'il existe toute une panoplie de logiciels standards, ce qui crée un marché multivendeur et une offre de produits équilibrée.
Exemples de SGBD Client/Serveur:
Côté serveur: Oracle, Sybase, Informix, MS-SQL-Server
Côté client: BORLAND Paradox, Personal Oracle, MS-Access
Les tables XE "table d'une base de données" (angl. tables)
Définition
Une table est une collection de données relatives à un domaine bien défini, par exemple les employés d'une société ou les livres d'une bibliothèque. Elle contient des enregistrements dont chacun est composé par les mêmes champs de données.
Voici, à titre d'exemple, quelques employés d'une société:
Jos Weber
Age: 34
Salaire: 68000 Luf.
Service: Comptabilité
Antonio Da Costa
Age: 27
Salaire: 70000 Luf.
Service: Informatique
Emil Feller
Age: 43
Salaire: 65000 Luf.
Service: Expédition
. . .
Voici la table nécessaire pour stocker les informations concernant ces employés dans une BD:
Propriétés des tables:
Les champs de données définissent les informations, qu'on veut stocker dans la table (p.ex. des informations concernant les employés d'une société).
Chaque enregistrement représente une occurrence de ce qu'on veut stocker (( p.ex. un employé).
Chaque table possède un nom unique (p.ex. : tblEmployés).
Chaque enregistrement correspond à une ligne de la table.
Chaque champ correspond à une colonne de la table.
Chaque champ peut représenter des données de nature différente (Nom, Salaire, Date de naissance
).
Chaque champ peut représenter des données de type différent (Texte, Nombres, Dates
).
Convention des noms:
Il existe une convention concernant les noms des objets des BD. Généralement, les noms des objets ne contiennent ni d'espaces, ni de caractères spéciaux. En plus, chaque nom d'un objet est précédé par un préfixe bien déterminé pour chaque type d'objet. Cette convention fait partie d'une convention des noms générale pour les programmes tournant sous une interface graphique du type Windows.
Les noms de tables sont précédés du préfixe tbl (angl.: table).
Par exemple: tblLivres, tblEmployés
Le nom d'une table doit être unique à l'intérieur d'une BD.
Une BD peut contenir une ou plusieurs tables, mais les tables sont généralement la condition nécessaire pour la création d'autres objets tels que les requêtes, formulaires et rapports.
Exercice
Déterminez les champs nécessaires pour une table qui contiendra des données concernant :
les élèves d'une école (nous ignorons la gestion des classes);
les livres d'une bibliothèque (nous supposons qu'un livre est rédigé par un seul auteur);
les produits d'un supermarché.
Les champs d'une table XE "champ d'une table d'une base de données"
Une table reprenant les données concernant les voitures d'une société de taxis contient par exemple pour chaque enregistrement (= chaque taxi) les informations suivantes:
Marque
Modèle
Cylindrée
Poids
Il est évident que les informations sont de types différents. Tandis que la marque et le modèle sont représentés par des chaînes de caractères (p.ex. "Ford", "BMW",
), la cylindrée et le poids sont représentés par des valeurs numériques.
Voici, à titre d'exemple, une table qui représente les taxis dans une BD:
MarqueModèleCylindréePoidsBMW525i 25001360FordOrion18001080BMW320i20001200
.
Afin de pouvoir représenter des données de types différentes, les SGBD offrent des types de données XE "types de données" standards pour les champs de données. Voici les types de données connus par la plupart des SGBD:
Type de donnéesDescriptionDate/HeureDate et heureValeur booléenneSeulement les 2 valeurs Oui/Non (Yes/No) sont possiblesTexteChaînes de caractères NumériqueNombres entiers ou décimauxMémoDocuments (textes long)
Consultez le manuel d'utilisation de votre SGBD pour trouver des informations plus détaillées concernant les types de données supportés.
Remarque: Les nombres qui ne sont pas utilisés lors de calculs numériques (p.ex. No.Tél) sont généralement représentés à l'aide du type de données "Texte".
Convention des noms:
Les noms des champs sont précédés du préfixe fld (angl.: field).
Par exemple: fldMarque, fldModèle
Exercice
Réfléchissez pour chaque champ des 3 tables, que vous avez défini dans l'exercice du chapitre 6.1, sur le type de données approprié.
Lors de la création d'une table, nous devons indiquer au SGBD, pour chaque champ:
Le nom du champ, qui doit être unique dans la table
Le type de données du champ
Clé primaire XE "Clé primaire (base de données)"
Dans la plupart des cas, on désire pouvoir identifier de manière unique chaque enregistrement de la table. Ceci n'est pas possible pour notre table avec les taxis. Il se peut très bien que le propriétaire de la société achète par exemple une deuxième BMW 320i , qui possède bien sur également une cylindrée de 2000 ccm et un poids de 1200 kg. Dans ce cas nous avons 2 enregistrement complètement identiques dans notre BD. Cela nous empêche d'identifier clairement un des 2 enregistrements.
Il nous faut donc un moyen, qui nous permet d'adresser sans ambiguïté chaque enregistrement dans la table ( une clé primaire !
La clé primaire, constituée d'un ou de plusieurs champs, nous permet d'identifier de manière unique chaque enregistrement d'une table.
Examinons notre cas de la société de taxis. Aucun des 4 champs seuls, et aucune combinaison des 4 champs ne se prêtent comme candidats pour devenir clé primaire, car aucun de ces champs ne contient des valeurs uniques à un et un seul taxi. Supposons par exemple la marque et le modèle comme clé primaire. Au cas ou la société achète un deuxième BMW 320i, on ne pourrait plus distinguer entre les deux voitures.
Le ou les champs, qui forment la clé primaire doivent impérativement avoir des valeurs qui sont uniques pour toute la table, et qui permettent donc d'identifier chaque enregistrement.
Exemples:
Le numéro de la matricule pour les assurés des caisses de maladie.
Le numéro client pour les clients d'une vidéothèque.
En ce qui concerne les taxis, nous avons deux possibilités:
Analyser s'il n'existe pas d'information concernant les taxis qui ne soit pas encore stockée dans la table et qui ferait une clé primaire valable. Une telle information serait par exemple le numéro de chassis, unique pour chaque voiture. On pourrait donc ajouter un champ fldNochassis et définir ce champ comme clé primaire. Ceci a comme désavantage que le numéro de chassis d'une voiture est un numéro assez long et compliqué, ce qui défavorise une utilisation conviviale de la table.
On pourrait inventer un numéro de taxi allant simplement de 1 jusqu'au nombre de taxis que la société possède. Le premier taxi enregistré serait le numéro TAXI=1, le deuxième le numéro TAXI=2 etc. . Bien que ce numéro n'ait aucune signification réelle, cette méthode de création de clés primaires artificielles est très répandue, et la plupart des SGBD offrent même un type de données prédéfini pour générer des valeurs uniques pour de telles clés primaires. Notre table aurait dans ce cas la structure suivante:
idTaxifldMarquefldModèlefldCylindréefldPoids1BMW525i250013602FordOrion180010803BMW320i20001200...............
Convention des noms:
Les noms des champs qui forment la clé primaire sont précédés du préfixe id (angl.: identifier).
Par exemple: idTaxi, idEmployé
Exercice
Définissez pour chacune des 3 tables, que vous avez défini dans l'exercice du chapitre 6.1, une clé primaire parmi les champs existants, resp. créez un nouveau champ qui assumera le rôle de clé primaire. Indiquez dans la grille suivante pour chaque table toutes les informations nécessaires.
Nom de la table:Membre de la clé primaire (Cochez la case si OUI )Nom du champType de donnéesDescription FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX
Nom de la table:Membre de la clé primaire (Cochez la case si OUI )Nom du champType de donnéesDescription FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX
Nom de la table:Membre de la clé primaire (Cochez la case si OUI )Nom du champType de donnéesDescription FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX FORMCHECKBOX
Relations XE "Relations entre tables" entre tables - clé étrangère
Une base de données bien concipée est rarement composée d'une seule table, mais d'un ensemble de tables, entre lesquelles il existe certaines relations (voir Partie1: Modélisation d'un système d'information).
Exemple:
Soit la BD suivante d'un organisme de sécurité sociale.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\tabl1.gif" \* MERGEFORMAT
La table tblEmployés contient certaines informations concernant les employés, mais pas le nom de la société, qui emploie un employé en question. Les informations des sociétés se trouvent dans la table tblSociétés. Cependant, dans la table tblEmployés se trouve le champ fiSociété, qui contient pour chaque employé le numéro de la société patron. On peut retrouver chaque numéro de société encore une fois dans le champ idSociété, qui constitue la clé primaire de tblSociétés.
Les deux tables sont donc logiquement liées via les champs fiSociété et idSociété.
On dit que fiSociété est une clé étrangère, qui fait référence à la clé primaire idSociété de la table tblSociétés.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Clé étrangère XE "Clé étrangère"
Un champ qui, dans une table, fait référence à la clé primaire d'une autre table est appelé clé étrangère (angl.: foreign key). Ainsi sont définies les relations entre les tables.
Index XE "Index d'une table"
Une des utilisations fréquentes des tables consiste dans la recherche et le tri des enregistrements.
Lorsque les tables contiennent un grand nombre d'enregistrements, la recherche de certains enregistrements ainsi que le tri d'enregistrements nécessitent de plus en plus de temps. Les index sont des structures qui accélèrent les tris et recherches dans les tables, ainsi que l'exécution de certaines requêtes (voir chapitre 7).
Exemple:
Reprenons notre exemple des employés d'une société. Une recherche intéressante serait par exemple: Montre-moi tous les employés du service Informatique !
Il serait aussi intéressant de trier les employés sur leur nom de famille. Au cas ou la table contient beaucoup d'enregistrements, on devrait d'abord créer un index sur le champ fldNom, afin d'accélérer le tri.
Créer par exemple un index sur le champ fldNom veut dire que le SGBD copie toutes les valeurs existantes du champ fldNom dans une liste spéciale à 2 colonnes. La deuxième colonne contient les noms triés en ordre alphabétique, et la première contient une référence vers l'enregistrement correspondant de la table.
Il est évident que par la suite de la création de cet index, toutes les recherches et les tris concernant le nom de l'employé sont accélérées, puisque le SGBD consulte uniquement l'index pour retrouver le bon nom, pour ensuite utiliser la référence de l'index vers l'enregistrement correspondant de la table.
Un index peut aussi comporter plusieurs champs comme par exemple fldService et fldNom.
Propriétés importantes des index:
Un index est toujours lié à un ou plusieurs champs d'une table.
Un index peut seulement contenir des champs ayant un des types de données Texte, Numérique ou Date/Heure.
Un index est automatiquement mis à jour par le SGBD lors d'un ajout, d'une modification ou d'une suppression d'enregistrements dans la table. Ceci est transparent pour l'utilisateur de la BD.
Il existe deux types d'index:
Index avec doublons (Les valeurs doubles sont permises)
Index sans doublons (Les valeurs doubles ne sont pas permises)
Voici quelques règles qui nous aident à déterminer les champs d'une table qui ont besoin d'être indexés:
La puissance des index joue uniquement pour des tables qui contiennent beaucoup d'enregistrements (Consultez la documentation de votre SGBD afin d'avoir des précisions).
Un champ sur lequel on ne fait que rarement ou pas du tout de recherche ou de tri n'a pas besoin d'index.
Les champs référencés fréquemment dans les recherches et tris doivent par contre être indexés.
Pour les index multi-champs, il faut veiller à ce que la combinaison des champs dans l'index corresponde exactement au critère de recherche. Un index sur nom&prénom n'accélère pas une recherche du type prénom=Jos & nom=Weber.
Un index sans doublons sur un champ empêche l'utilisateur d'entrer la même valeur dans ce champ, dans deux enregistrements différents.
Définir trop d'indexes sur une table ralentit en général les opérations d'ajout, de modification et de suppression, parce que le SGBD doit mettre à jour la table et l'index.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT La clé primaire est toujours indexée à l'aide d'un index sans doublons !
Les requêtes XE "requêtes" (angl. queries)
Définition
Nous avons vu que la plupart des SGBD offrent la possibilité d'effectuer des recherches directement dans les tables. Les possibilités de formuler des critères de recherche sont cependant souvent assez limitées. Heureusement, la plupart des SGBD nous offrent également la possibilité de poser pratiquement n'importe quelle "question" à nos tables, sous forme de requêtes.
Les requêtes servent donc à répondre aux questions basées sur le contenu d'une ou de plusieurs tables. Nous allons plus tard étudier des requêtes, qui se basent sur plusieurs tables, mais pour l'instant nous allons nous limiter aux questions simples basées sur une seule table.
Exemple:
Reprenons notre table avec les taxis:
Taxi fldMarquefldModèlefldCylindréefldPoids1BMW525i250013602FordOrion180010803BMW320i20001200
.
Une requête simple serait par exemple:
Quelles sont les marques et modèles des voitures ayant une cylindrée supérieure à 2000 ?
Le résultat serait un sous-ensemble de la table avec seulement les enregistrements qui vérifient le critère de sélection (( cylindrée > 2000). Pour chacun de ces enregistrements, le SGBD affiche en plus seulement les champs explicitement demandés (( fldMarque et fldModèle).
Une requête simple produit donc comme résultat un sous-ensemble des enregistrements d'une table. En plus, une requête nous permet d'afficher seulement certains champs pour les enregistrements appartenant à ce sous-ensemble.
On appelle ces requêtes "Requêtes de Sélection", puisqu'il s'agit d'une sélection de certains enregistrements.
Il n'existe cependant pas seulement des requêtes de sélection, mais également:
Des requêtes d'insertion ( insérer des enregistrements dans la table.
p.ex. Insérer un nouveau taxi : 4, BMW, 325i, 2500, 1270.
Des requêtes de modification ( modifier des enregistrements dans la table.
p.ex. Modifier la cylindrée des Ford Orion de façon à ce qu'elle devienne 2000.
Des requêtes de suppression ( supprimer des enregistrements de la table.
p.ex. Supprimer toutes les BMW.
Les requêtes possèdent l'avantage de pouvoir manipuler facilement un grand nombre d'enregistrements sans que l'utilisateur ne doive s'occuper de sélectionner enregistrement par enregistrement. Il lui suffit de spécifier des critères de sélection pour la requête, ainsi que l'opération à effectuer (( simple sélection et affichage, insertion, modification ou suppression).
Bien que les requêtes de sélection soient implémentées d'une manière plus ou moins cohérente à travers les SGBD actuels, il existe des différences subtiles en ce qui concerne les requêtes d'insertion, de modification ainsi que de suppression. En plus, l'insertion et la suppression se font souvent de manière plus facile directement dans la table.
Il existe 4 types de requêtes:
Requêtes de sélection.
Requêtes d'insertion.
Requêtes de modification.
Requêtes de suppression.
Pour chaque requête nous retrouvons le cycle suivant:
Exercice
Quel est en général le résultat d'une requête:
de sélection :
d'insertion :
de modification :
de suppression :
Introduction au langage SQL XE "SQL"
Généralités
Nous avons vu au chapitre précédent qu'il faut d'abord formuler une requête et puis l'exécuter, afin d'avoir des résultats. Vous pouvez probablement bien vous imaginer que les SGBD actuels ne comprennent pas le langage naturel. Aucun SGBD n'offre une possibilité d'écrire p.ex. Je veux voir tous les taxis dont la marque est Ford Pour formuler une requête, l'utilisateur doit donc utiliser un langage spécialisé pour ce domaine.
Le langage SQL (Structured Query Language XE "Structured Query Language" \t "See SQL" ) est un standard international, en ce qui concerne les langages de manipulation des BD. SQL est connu par tous les SGBDR. Il faut cependant mentionner que, désormais la présence de standards internationaux tels que SQL-86, SQL-89 ou SQL-92, chaque SGBD sur le marché utilise un peu son propre dialecte du langage SQL.
Syntaxe SQL de base
Nous distinguons les 4 types de requêtes suivants.
Requêtes de sélection.
SELECT
FROM
WHERE ;
Requêtes d'insertion.
INSERT INTO (()(
VALUES ( );
Attention: Lorsque vous n'indiquez pas la liste des champs derrière INSERT INTO , vous devez spécifier une valeur pour chaque champ de la table derrière VALUES . Les parenthèses derrière VALUES sont obligatoires. La liste des champs, lorsqu'elle est indiquée, contient les noms des champs, séparés par une virgule, et doit également être entourée de parenthèses.
Requêtes de modification.
UPDATE
SET ={valeur}, . .
WHERE ;
Requêtes de suppression.
DELETE FROM
WHERE ;
Soit une table des employés d'une entreprise avec la structure suivante:
Voici le code SQL nécessaire pour effectuer quelques requêtes élémentaires:
Afficher le prénom et le nom de tous les employés
SELECT fldPrénom, fldNom
FROM tblEmployés;
Insérer une nouvelle employée:
20AngelaPortanteITA27FComptabilité25.3.1997
INSERT INTO tblEmployés
VALUES (20, 'Angela', 'Portante', 'ITA', 27, 'F', 'Comptabilité', #3/25/97#);
Remarques:
Les valeurs sont séparées par des virgules.
Les données du type TEXTE sont entourées d'apostrophes.
Les dates sont entourées du caractère # et indiquées dans le format américain #Mois/Jour/Année#
Exemple: 20.4.98 àð #04/20/98# ou #4/20/98# ou #04/20/1998# ou #4/20/1998#
Afficher toutes les nationalités représentées dans la société
SELECT fldNationalité
FROM tblEmployés;
Quel est l'inconvénient de cette requête ? ______________________________________
Soit l'adaptation suivante de la requête:
SELECT DISTINCT fldNationalité
FROM tblEmployés;
Expliquez l'utilité de l'option DISTINCT
Afficher tous les champs pour tous les employés
SELECT idEmployé, fldPrénom, fldNom, fldNationalité, fldAge, fldSexe, fldService, fldEntréeService
FROM tblEmployés;
ou
SELECT *
FROM tblEmployés;
Remarque:
L'opérateur * permet d'afficher tous les champs définis dans la table.
Les critères de sélection XE "critères de sélection"
Les critères de sélection constituent une expression logique; qui peut prendre la valeur 'Vrai' ou 'Faux'. Les critères de sélection sont appliqués à chaque enregistrement d'une table. Lorsque pour un enregistrement donné, l'expression logique prend la valeur 'Vrai', cet enregistrement :
fait partie du résultat pour une requête de sélection;
est modifié pour une requête de modification;
est effacé pour une requête de suppression;
Comparaison à une valeur donnée.
Pour chaque enregistrement, la valeur d'un champ donné est comparée à une valeur fixe. Cette valeur fixe est généralement une valeur numérique, une date ou un texte.
Voici les opérateurs de comparaison:
= "est égal"
> "strictement supérieur"
< "strictement inférieur"
>= "supérieur ou égal"
=#1/1/95#;
Les requêtes paramétrées XE "requêtes paramétrées"
Imaginez que de temps en temps on voudrait réexécuter cette requête avec une date d'entrée en service différente. Au lieu de modifier à chaque fois le critère de sélection on peut dans la plupart des SGBD définir une requête paramétrée, c.à.d. une requête qui ne contient pas directement une valeur (ici: date d'entrée en service) comme critère de sélection mais un paramètre. Ce paramètre est représenté par un texte entouré de crochets.
Ainsi, la requête suivante provoque d'abord l'affichage d'une boîte de dialogue:
SELECT fldNom, fldPrénom, fldAge
FROM tblEmployés
WHERE fldEntréeService>=[Indiquez une date d'entrée au service];
Une requête peut contenir plusieurs paramètres.
Comparaison à un filtre
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Parfois, on ne connaît pas la valeur exacte à laquelle on veut comparer la valeur d'un champ. Dans ce cas on peut utiliser un filtre. Un filtre est une expression qui peut contenir des lettres, des chiffres et en plus les 2 caractères spéciaux (angl. Wildcards) suivants:
% représente n'importe quelle séquence de 0 ou plusieurs caractères;
_ représente un seul caractère quelconque.
Exemple: Pour rechercher des personnes dont le nom est 'SCHMITZ' ou 'SCHMITT' ou 'SCHMIT' etc. on définit par exemple le filtre suivant : 'SCHMI%'
Exemple: Le filtre 'BL__' sélectionne par exemple les valeurs 'BLEU' ou 'BLUE' mais pas 'BLANC'
Les filtres sont utilisés ensemble avec le mot réservé LIKE. Voici la syntaxe:
. . .
WHERE LIKE
Exemples:
Afficher le nom et le prénom des employés dont le prénom contient un trait d'union (p.ex. Jean-Jacques)
SELECT fldNom, fldPrénom
FROM tblEmployés
WHERE fldPrénom LIKE '%-%';
Afficher le nom, le prénom et l'âge des employés dont le nom commence par 'W', est composé de 5 lettres et se termine par 'R'
SELECT fldNom, fldPrénom, fldAge
FROM tblEmployés
WHERE fldNom LIKE 'W___R';
Remarque
Pour les manipulations pratiques, il faut se rendre compte que certains SGBD utilisent des caractères spéciaux différents pour représenter une séquence de caractères respectivement un caractère quelconque. MS-Access par exemple utilise les caractères suivants:
SQLMS-AccessSéquence de 0 ou plusieurs caractères%*Un seul caractère quelconque_?
Les opérateurs logiques
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Il existe 3 opérateurs logiques:
NOT (Négation logique)
L'opérateur NOT inverse le résultat d'une expression logique.
AND (Et logique)
L'opérateur AND nous permet de combiner plusieurs conditions dans une expression logique. L'expression logique retourne uniquement la valeur 'Vrai' lorsque toutes les conditions sont remplies.
OR (Ou logique)
L'opérateur OR nous permet de combiner plusieurs conditions dans une expression logique. L'expression logique retourne la valeur 'Vrai' lorsque au moins une des conditions est remplie.
Priorité des opérateurs logiques
Lorsqu'on combine plusieurs conditions par des opérateurs logiques, le résultat final de l'expression logique dépend de l'ordre d'exécution des différentes conditions. Cet ordre est déterminé par la priorité des opérateurs logiques. Voici l'ordre prédéfini en SQL:
Déterminer le résultat logique ('Vrai','Faux') des comparaisons (=, etc.)
Effectuer les négations (NOT)
Effectuer les AND
Effectuer les OR
Pour modifier cet ordre d'exécution, nous pouvons utiliser des parenthèses afin de grouper les différentes conditions logiques.
Exemples
Afficher le prénom et le nom de tous les employés qui ne travaillent pas dans le service "Marketing"
SELECT fldPrénom, fldNom
FROM tblEmployés
WHERE NOT fldService='Marketing';
Formulez une requête qui affiche exactement le même résultat, sans utiliser l'opérateur NOT.
SELECT fldPrénom, fldNom
FROM tblEmployés
WHERE fldService'Marketing';
Afficher le numéro d'employé, le prénom et le nom de tous les employés dont le nom ne commence pas par la lettre 'W'
SELECT idEmployé, fldPrénom, fldNom
FROM tblEmployés
WHERE NOT fldNom LIKE 'W%';
Afficher le numéro de l'employé, le prénom et le nom pour les employés du service Informatique qui ont moins de 30 ans.
SELECT idEmployé, fldPrénom, fldNom
FROM tblEmployés
WHERE fldService='Informatique' AND fldAge= #7/1/97# AND fldEntréeService [ASC/DESC],
=
BETWEEN ... AND
IN
LIKE
Dans ce cas, on parle d'une jointure par non égalité. Ces conditions de jointure sont surtout employées en relation avec une auto-jointure.
Voici un autre exemple d'une auto-jointure:
Affichez les numéros des comptes ayant une agence différente que le compte numéro 101.
SELECT CO1.idCompte
FROM tblComptes CO1, tblComptes CO2
WHERE CO2.idCompte=101 AND CO1.fiAgenceCO2.fiAgence;
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT A faire : Exercice 4
Les requêtes imbriquées XE "Les requêtes imbriquées"
Nous savons qu'une requête de sélection se base sur une ou plusieurs tables pour afficher un résultat. En SQL, on peut imbriquer plusieurs requêtes, c.à.d. le résultat d'une requête imbriquée sert comme base pour une deuxième requête. Une requête imbriquée est encore parfois appelée 'SELECT interne' ou 'sous-requête'.
On distingue généralement deux types de requêtes imbriquées:
les requêtes imbriquées, qui renvoient comme résultat une seule valeur;
les requêtes imbriquées, qui renvoient comme résultat un ensemble de valeurs.
La requête imbriquée renvoie une seule valeur
Exemple:
Soient les trois tables suivantes.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\comptes2.gif" \* MERGEFORMAT
tblComptes
idComptefiAgencefldValeurfiClient101122000031062448000211212900031253050001
tblClients
idClientfldNomfldPrénomfldAdressefldCPfldLocalité1PegasoEmilio25, rue de la Gare2278Diekirch2WeberJos66a, Cité Paerchen1234Schifflange3MullerKetty102, av G.Diederich6690Luxembourg
tblAgences
idAgencefldAdressefldCPfldLocalité1215, bvd Royal5377Luxembourg2467, rue de l'Alzette8765Esch-s-Alzette302, Grand Rue6678Ettelbruck
La requête:
SELECT fldNom, fldPrénom
FROM tblClients
WHERE idClient = (SELECT fiClient
FROM tblComptes
WHERE idCompte=106);
retourne le nom et prénom du client qui est le propriétaire du compte numéro 106.
Analysons le fonctionnement de cette requête:
Le requête imbriquée:
SELECT fiClient
FROM tblComptes
WHERE idCompte=106;
retourne simplement la valeur 2
On peut donc traduire la requête de niveau supérieur en
SELECT fldNom, fldPrénom
FROM tblClients
WHERE idClient = 2;
Cette requête retourne finalement le nom et prénom du client correspondant, c.à.d. 'Weber' 'Jos'
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT La requête imbriquée doit renvoyer au maximum une seule valeur. Si tel n'est pas le cas, SQL ne pourra pas exécuter la requête de niveau supérieur, et génère un message d'erreur.
Dans la clause WHERE de la requête de niveau supérieur, le résultat de la requête imbriquée doit obligatoirement être comparé à un champ de type de données compatible avec la valeur retournée.
Comme la requête imbriquée doit retourner une seule valeur, on utilise souvent des fonctions d'agrégation dans la clause SELECT de la requête imbriquée.
On peut avoir plusieurs niveaux d'imbrication de requêtes. Une requête imbriquée peut donc déjà se baser sur le résultat d'une autre requête imbriquée
Exemples:
Reprenons les 3 tables tblComptes, tblClients et tblAgences
Affichez le numéro du(des) compte(s) avec la plus grande valeur.
SELECT idCompte
FROM tblComptes
WHERE fldValeur=(SELECT MAX(fldValeur)
FROM tblComptes);
Remarque:
Dans une requête imbriquée, vous n'avez pas besoin d'utiliser des alias lorsque la même table est utilisée plusieurs fois.
Affichez les numéros des comptes et la valeur actuelle pour les comptes dont la valeur est supérieure à la moyenne des valeurs.
SELECT idCompte, fldValeur
FROM tblComptes
WHERE fldValeur > (SELECT AVG(fldValeur)
FROM tblComptes);
Affichez le nom, le prénom, l'adresse, le code postal et la localité du client, qui possède le compte avec la plus petite valeur. Nous supposons qu'il existe uniquement un seul compte avec la plus petite valeur.
SELECT fldNom, fldPrénom, fldAdresse, fldCP, fldLocalité
FROM tblClients
WHERE idClient=(SELECT fiClient
FROM tblComptes
WHERE fldValeur=(SELECT MIN(fldValeur)
FROM tblComptes));
Pour effectuer des statistiques, on vous demande la requête suivante. Affichez le numéro de compte et la valeur actuelle pour les comptes dont la valeur est plus petite que la moyenne des valeurs pour les comptes dont les clients habitent au Luxembourg, mais plus grande que la moyenne des valeurs pour les comptes dont les clients habitent à Diekirch ou Ettelbruck.
SELECT idCompte, fldValeur
FROM tblComptes
WHERE fldValeur< (SELECT AVG(fldValeur)
FROM tblComptes, tblClients
WHERE fiClient=idClient
AND fldLocalité='Luxembourg')
AND fldValeur> (SELECT AVG(fldValeur)
FROM tblComptes, tblClients
WHERE fiClient=idClient AND fldLocalité IN ('Diekirch','Ettelbruck'));
Remarque:
Comme cet exemple nous le montre, on peut avoir plusieurs requêtes imbriquées dans une seule clause WHERE.
La requête imbriquée renvoie un ensemble de valeurs
Exemple:
Reprenons les trois tables suivantes
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\comptes2.gif" \* MERGEFORMAT
tblComptes
idComptefiAgencefldValeurfiClient101122000031062448000211212900031253050001
tblClients
idClientfldNomfldPrénomfldAdressefldCPfldLocalité1PegasoEmilio25, rue de la Gare2278Diekirch2WeberJos66a, Cité Paerchen1234Schifflange3MullerKetty102, av G.Diederich6690Luxembourg
tblAgences
idAgencefldAdressefldCPfldLocalité1215, bvd Royal5377Luxembourg2467, rue de l'Alzette8765Esch-s-Alzette302, Grand Rue6678Ettelbruck
La requête
SELECT idCompte, fldValeur
FROM tblComptes
WHERE fiClient IN (SELECT idClient
FROM tblClients
WHERE fldLocalité='Luxembourg' OR fldLocalité='Diekirch');
retourne le numéro de compte et la valeur actuelle pour les comptes dont le client habite à Luxembourg ou Diekirch
Analysons le fonctionnement de cette requête:
Le requête imbriquée:
SELECT idClient
FROM tblClients
WHERE fldLocalité='Luxembourg' OR fldLocalité='Diekirch';
retourne tous les numéros de clients habitant à Luxembourg ou Diekirch. Cette requête retourne donc l'ensemble de valeurs [1, 3].
On peut donc traduire la requête de niveau supérieur en
SELECT idCompte, fldValeur
FROM tblComptes
WHERE fiClient IN (1, 3);
Cette requête retourne finalement le numéro de compte et la valeur des comptes correspondants.
idComptefldValeur1012000011290001255000
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT La requête imbriquée renvoie un ensemble de n valeurs. Cet ensemble peut bien sûr être vide (n=0) ou être composé d'une seule valeur (n=1).
Dans la clause WHERE de la requête de niveau supérieur, le champ pour lequel on vérifie l'appartenance à l'ensemble de valeurs retourné par la sous-requête, doit avoir un type de données compatible avec les valeurs de l'ensemble.
Parfois, il est convenable d'utiliser l'option DISTINCT dans la clause SELECT de la sous-requête, afin d'éviter des doublons dans l'ensemble résultat. Toutefois, ceci est uniquement une mesure d'optimisation des requêtes imbriquées.
On peut avoir plusieurs niveaux d'imbrication de requêtes. Une requête imbriquée peut donc déjà se baser sur le résultat d'une autre requête imbriquée
Exemples:
Reprenons les 3 tables tblComptes, tblClients et tblAgences
Affichez les numéros des comptes qui sont gérés par une agence située à Luxembourg.
SELECT idCompte
FROM tblComptes
WHERE fiAgence IN (SELECT idAgence
FROM tblAgences
WHERE fldLocalité='Luxembourg');
Affichez le nom et le prénom de tous les clients ayant un compte géré par une agence située à Luxembourg ou à Esch-s-Alzette.
SELECT fldNom, fldPrénom
FROM tblClients
WHERE idClient IN (SELECT fiClient
FROM tblComptes
WHERE fiAgence IN (SELECT idAgence
FROM tblAgences
WHERE fldLocalité IN ('Luxembourg',
'Esch-s-Alzette')));
Affichez le nom et le prénom de tous les clients n'ayant pas de compte.
SELECT fldNom, fldPrénom
FROM tblClients
WHERE idClient NOT IN (SELECT DISTINCT fiClient
FROM tblComptes);
Remarque:
A l'intérieur d'une requête imbriquée, on peut faire référence à un champ d'une table définie dans la requête de niveau supérieur. Dans ce cas on parle d'une requête imbriquée corrélée XE "requête imbriquée corrélée" . Une valeur retournée par ce type de requête dépend donc d'un champ qui reçoit ses valeurs à partir d'une requête de niveau supérieur.
Exemple:
Affichez le nom et le prénom des clients ayant au moins un compte avec une valeur de 9000 Luf.
SELECT fldNom, fldPrénom
FROM tblClients C
WHERE 9000 IN (SELECT fldValeur
FROM tblComptes
WHERE fiClient=C.idClient);
L'ensemble de valeurs retourné du SELECT imbriqué dépend de la valeur de C.idClient. SQL exécute cette requête de la façon suivante:
C.idClient est substitué par sa valeur pour le premier enregistrement de la table tblClients. C.idClient prend donc la valeur 1.
La requête imbriquée
SELECT fldValeur
FROM tblComptes
WHERE fiClient=1;
est exécutée avec comme résultat l'ensemble [5000].
La requête de niveau supérieur ne retourne donc aucun résultat
C.idClient est maintenant substitué par sa valeur pour le deuxième enregistrement de la table tblClients. C.idClient prend donc la valeur 2.
La requête imbriquée
SELECT fldValeur
FROM tblComptes
WHERE fiClient=2;
retourne l'ensemble [48000]
La requête de niveau supérieur ne retourne donc aucun résultat
C.idClient est ensuite substitué par sa valeur pour le troisième enregistrement de la table tblClients. C.idClient prend donc la valeur 3.
La requête imbriquée
SELECT fldValeur
FROM tblComptes
WHERE fiClient=3;
retourne l'ensemble [20000 , 9000]
La requête de niveau supérieur retourne le résultat 'Muller' 'Ketty' puisque effectivement le troisième enregistrement de la table tblClients contient une valeur de idClient (3) , qui produit dans la requête imbriquée un ensemble contenant la valeur 9000.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Formulez cette requête sans utiliser le principe de la requête corrélée
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT A faire : Exercice 5
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Répétition générale en SQL : Exercice 6 et Exercice 7
Exercices SQL
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 4: Assurance bagages (Les jointures)
Une société d'assurances offre une formule 'Assurance Bagages'. Cette formule garantit pendant une durée limitée un remboursement intégral de la valeur des bagages avec contenu en cas de vol ou de perte.
Voici la BD utilisée pour gérer ce type d'assurances.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\cJoin1.gif" \* MERGEFORMAT
Remarques:
Comme certains noms de champs sont identiques pour les tables tblAgents et tblClients, vous devez veiller à employer les noms des tables resp. des alias aux bons endroits dans les requêtes.
Le champ fldAgentgénéral est du type booléen (valeurs VRAI/FAUX resp. YES/NO)
Utilisez le mécanisme des jointures afin de répondre aux questions suivantes.
Affichez pour les contrats qui couvrent la France comme pays de destination, le nom de l'agent.
Affichez le numéro de contrat, les dates de début et de fin du contrat ainsi que le nom, prénom, adresse, code postal et localité du client pour tous les contrats qui couvrent la période entre le 14 juillet et le 20 juillet 1998 et dont le pays de destination était l'Italie. Utilisez des alias partout dans la requête.
Déterminez la plus grande prime parmi celles où le pays de destination est la Belgique et l'agent n'est pas un agent général.
Affichez le numéro de contrat, la prime, le nom et prénom du client ainsi que le nom et prénom de l'agent pour tous les contrats ou l'agent a le même nom que le client.
Affichez toutes les informations concernant les clients ayant un agent qui habite à Capellen. Eliminez un effet indésirable qui peut se produire à cause du fait qu'un client peut avoir conclu plusieurs contrats avec le même agent.
Affichez pour chaque client, le numéro de client, son nom, le nom de son agent et la somme des primes de tous les contrats qu'il a conclu avec cet agent. Appliquez une clause GROUP BY sur le résultat de la jointure des tables impliquées. Au cas ou un client a conclu des contrats avec plusieurs agents différents, vous devez afficher un groupe pour chaque agent.
Soient les valeurs suivantes pour les deux tables tblContrats et tblAgents:
idContratfldDébutfldFinfldPrimefldPaysfiAgentfiClient100022/07/199803/08/19982300France210100112/07/199822/07/19981750Italie111100219/07/199818/08/19984500Belgique111
idAgentfldNomfldPrénomfldAdressefldCPfldLocalitéfldNoTelfldAgentGénéral1PezzottoAlfredo23, rue de Mamer6555Capellen238987No2KremerPierre2, bvd de la liberté9980Luxembourg228890Yes
Expliquez pour la requête suivante, les étapes d'exécution, en précisant à chaque fois les résultats intermédiaires.
SELECT IdContrat, fldPrime, fldNom
FROM tblContrats, tblAgents
WHERE fiAgent=idAgent
AND fldAgentGénéral=No;
Elaborez une liste qui affiche pour chaque agent son nom ainsi que le nombre de contrats par pays de destination.
Indiquez le nom, le prénom, l'adresse, le code postal et la localité des clients ayant conclu un contrat qui a une prime strictement inférieure à celle du contrat numéro 1003.
Classez les agents par ordre descendant sur le nombre de contrats qu'ils ont conclus. En tenant uniquement compte des agents qui ont conclu au moins 2 contrats, affichez pour chaque agent, son numéro, son nom et prénom ainsi que le nombre de contrats qu'il a conclu.
Affichez le nom et prénom des agents ayant conclu un contrat avec un client, qui a encore conclu un contrat avec au moins un autre agent.
Affichez le nom et prénom de tous les agents ayant conclu un contrat avec un client habitant dans la même localité que le client numéro 11.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 5: Facturation (Les requêtes imbriquées)
Un magasin spécialisé dans la vente d'appareils électroménagers entretient la BD suivante afin de gérer la facturation.
Utilisez le mécanisme des requêtes imbriquées afin de répondre aux questions suivantes.
Affichez le libellé et le prix unitaire de l'article (des articles) qui est le plus cher.
Affichez le numéro de l'article ainsi que le libellé pour les articles moins cher que le prix moyen de tous les articles.
Affichez le numéro et la date de toutes les factures dont le client habite à Luxembourg.
Affichez le nom et le prénom des clients qui habitent à Luxembourg et qui sont concernés par une facture etablie au cours du mois d'août 1998.
Affichez le numéro et le libellé des articles qui sont plus cher que le prix moyen de tous les articles, et pour lesquels il existe une ou plusieurs factures avec une quantité >1.
Affichez le nom, le prénom, l'adresse, le code postal et la localité de tous les clients ayant déjà acheté un article plus cher que 3000 Luf.
Exprimez la même requête sans utiliser les requêtes imbriquées
Affichez le nom, le prénom, l'adresse, le code postal et la localité de tous les clients ayant uniquement acheté des articles plus cher que 3000 Luf.
Proposez une solution alternative en vous servant du mécanisme de la requête imbriquée corrélée.
Affichez le nom, le prénom, l'adresse, le code postal et la localité de tous les clients ayant déjà acheté pour une somme > 3000 Luf. par facture. Utilisez au maximum possible les requêtes imbriquées.
Affichez le nom et le prénom de tous les clients ayant une facture, qui concerne un seul article. La facture ne doit donc ni concerner plusieurs articles différents ni avoir une quantité >1 pour un seul article.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 6: Bibliothèque
Une bibliothèque utilise la BD suivante.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\BiblioSQL.gif" \* MERGEFORMAT
Remarques:
Un auteur peut rédiger plusieurs livres et un livre peut être rédigé par plusieurs auteurs.
La bibliothèque peut disposer de plusieurs exemplaires du même livre.
Un prêt concerne un seul exemplaire d'un livre.
Le champ fldDateRetour de la table tblPrêts reste indéterminé (NULL) tant que l'exemplaire emprunté n'a pas été retourné à la bibliothèque.
Formulez en SQL les requêtes suivantes:
Affichez le numéro, le titre et le genre de tous les livres allemands (Code=ALL). Classez la liste par ordre alphabétique sur le genre (p.ex. 'Roman' avant 'Technique') et à l'intérieur d'un genre par ordre ascendant sur les numéros.
Affichez une liste triée par ordre alphabétique de tous les genres de livres disponibles.
Affichez une liste de toutes les localités où habite un membre dont l'adresse contient l'abréviation 'bvd' , indiquant que le membre habite sur un boulevard.
Affichez toutes les informations de la table tblAuteurs concernant les auteurs ayant une des nationalités suivantes.
Nationalité (Pays d'origine)CodeAllemagneALLAngleterre ANGFranceFRAAutricheAUTItalieITASuisseSUIRussieRUS
Effacez tous les membres n'ayant pas encore effectué un prêt.
Affichez le nom, le prénom, l'adresse, le code postal et la localité de tous les membres habitant à Luxembourg ou à Esch-s-Alzette, n'ayant pas encore retourné un exemplaire emprunté.
Affichez pour chaque livre le titre, le genre, la langue et le nombre d'exemplaires disponibles (emprunté ou non). Triez la liste par ordre alphabétique sur la langue, sur le genre et finalement sur le titre. Le champ indiquant le nombre d'exemplaires disponibles doit avoir l'en-tête 'Exemplaires disponibles'.
Affichez le nom et le prénom des auteurs ayant écrit un livre français dont le titre contient le mot 'passage', et dont la bibliothèque possède au moins 3 exemplaires.
Affichez tous les livres (Titre et genre) de l'auteur 'Alexandre Dumas'. Triez la liste par ordre alphabétique sur le titre.
Affichez le nom, le prénom et le nombre de prêts effectués, pour tous les membres qui habitent à Esch-s-Alzette ou à Luxembourg, ayant déjà effectué au moins 2 prêts. Triez la liste par ordre alphabétique sur le nom.
Créez une liste qui affiche pour chaque exemplaire actuellement emprunté (pas encore retourné), le numéro du prêt, le numéro, le nom et le prénom du membre ayant emprunté le livre ainsi que le titre et le genre du livre en question. Triez la liste par ordre alphabétique sur le nom et le prénom du membre.
Quels sont les auteurs (Nom et prénom) ayant déjà écrit un livre ensemble avec l'auteur 'Margaret Gibson' ?
Quels sont les auteurs (Nom et prénom) n'ayant pas encore écrit un livre ensemble avec l'auteur 'Margaret Gibson' ?
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice 7: Gestion d'une école
Voici une BD qui représente une gestion simplifiée des cours d'un lycée technique.
Remarques:
Une classe est représentée par un code interne (idClasse) , un nom de classe (fldNomClasse) tel que '13CG2' ou '11CM1' , un niveau (fldNiveau) tel que 10 pour la classe '10GE2' ou 13 pour '13CG1' , et un champ indiquant le cycle (fldCycle) avec les valeurs possibles 'Inférieur', 'Moyen' et 'Supérieur'.
Nous supposons qu'un élève ne change pas de classe pendant l'année scolaire. Les champs fiElève et fldAnnée forment donc la clé primaire de la table tblFréquenter. Cependant, un élève peut fréquenter la même classe pendant plusieurs années consécutives (redoublants).
De même nous supposons qu'une matière est enseignée pendant une année par un seul prof dans une classe. Les champs fiMatière, fiClasse et fldAnnée forment donc la clé primaire de la table tblEnseigner. Toutefois, un prof peut enseigner la même matière pendant plusieurs années dans une même classe ou la même matière pendant une année dans plusieurs classes.
Les champs fldAnnée des tables tblfréquenter et tblEnseigner font référence à des années scolaires. On y retrouve des valeurs telles que '97/98' ou '95/96'. La BD ne contient pas uniquement la situation de l'année scolaire actuelle, mais également celle des années précédentes.
Formulez en SQL les requêtes suivantes:
Affichez pour l'année scolaire '97/98' , le nom de chaque classe ainsi que le nombre d'élèves.
Affichez par année scolaire et par niveau le nombre d'élèves. Triez la liste par ordre ascendant sur l'année scolaire et par ordre ascendant sur le niveau.
Affichez le nom et le prénom de tous les profs ayant enseigné une matière dans une classe de 13ème pendant les 5 dernières années scolaires (à partir de l'année scolaire '97/98'). Triez la liste par ordre alphabétique sur le nom du prof.
Dressez une liste avec le nom, le prénom, l'adresse, le code postal, et la localité pour tous les élèves qui ont fréquenté la classe '08TH1' pendant l'année scolaire '96/97'. La liste doit être triée par ordre alphabétique sur le nom des élèves. Utilisez au maximum possible le mécanisme des requêtes imbriquées.
Créez une liste, qui montre pour l'année scolaire '97/98', pour chaque classe, les matières enseignées avec les noms et prénoms des profs correspondants. Triez la liste par ordre alphabétique sur les noms des classes et à l'intérieur d'une classe par ordre alphabétique sur les matières. Utilisez uniquement des jointures en définissant des alias pour toutes les tables impliquées.
Créez une liste des profs (nom & prénom) qui est triée par ordre descendant sur le nombre de cours enseignés pendant les 3 dernières années scolaires (à partir de l'année scolaire '97/98'). La notion de cours est définie par le fait d'enseigner une matière dans une classe.
Affichez le nom et le prénom des profs qui enseignent au moins une matière dans une classe pendant l'année scolaire '97/98'.
Formulez la même requête en utilisant le mécanisme de la requête imbriquée corrélée.
Affichez le nom, le prénom, l'adresse, le code postal et la localité de tous les élèves ayant fréquenté pendant l'année scolaire 96/97 une classe du cycle inférieur. Utilisez au maximum les requêtes imbriquées.
Affichez le nom, le prénom et la dénomination de la classe actuelle des élèves qui sont actuellement (Année '97/98') des redoublants. Attention: Un élève est actuellement un redoublant s'il a fréquenté l'année scolaire passée une classe de même niveau, mais pas nécessairement la même classe.
Sachant qu'une classe ne devrait avoir un effectif supérieur à 21 élèves, le directeur vous demande d'établir une liste avec les noms des classes du cycle inférieur, qui pourraient encore accepter des nouveaux élèves pendant l'année scolaire '97/98'. Utilisez uniquement des requêtes imbriquées.
Formulez la même requête en utilisant uniquement des jointures
Formulez la même requête en utilisant le mécanisme de la requête corrélée.
Affichez le nom et le prénom, ainsi que le nom, le niveau et le cycle de leur classe actuelle (année = '97/98') de tous les élèves qui n'ont jamais redoublé une classe dans notre lycée.
Affichez parmi tous les profs, qui ont déjà enseigné la même matière que le prof numéro 10001, ceux n'ayant pas encore enseigné la même matière au même niveau que le prof numéro 10001 pendant les années scolaires '96/97' et '97/98'.
La méthode QBE XE "QBE"
Bien que le langage SQL soit le standard unanime en ce qui concerne l'extraction de données d'une BD ainsi que leur manipulation, les informaticiens étaient déjà pendant les années '70 à la recherche d'une possibilité de créer des requêtes sans faire recours à un langage d'interrogation. Etant d'accord sur la flexibilité et les nombreuses possibilités de SQL, on voulait quand même combler au grand désavantage de ce langage, à savoir une syntaxe assez rigide et surtout pas uniforme à travers les différents SGBD.
Les chercheurs voulaient créer une possibilité de spécifier graphiquement tous les éléments d'une requête c.à.d. la ou les tables cibles, les critères de sélection et les champs concernés. Le standard QBE (Query By Example XE "Query By Example" \t "See QBE" ) était né. Pourtant, QBE tout comme SQL n'est pas implémenté de façon uniforme dans les différents SGBD. Ce n'est qu'en 1985, que QBE devenait vraiment populaire avec son introduction dans le SGBD PARADOX, qui fut commercialisé par la société BORLAND. Actuellement, tous les SGBD qui tournent sous une interface graphique du type Windows offrent le système QBE. Citons par exemple dBASE, Visual FOXPRO, Superbase et surtout MS-Access qui offre actuellement selon les experts l'implémentation la plus conviviale du standard QBE.
Prenons comme exemple les requêtes de sélection. QBE offre à l'utilisateur une interface graphique qui lui permet de :
Sélectionner une table sur laquelle la requête sera basée ((SQL : FROM
).
Choisir parmi les champs de cette table ceux qui vont être affiché (( SQL : SELECT
).
Définir pour un ou plusieurs champs des critères de sélection (( SQL : WHERE
).
Définir un ordre de tri (( SQL : ORDER BY
).
etc.
Voici à titre d'exemple un écran QBE de MS Access :
La requête correspondante en SQL serait:
SELECT idLivre, fldTitre, fldAuteur, fldLangue
FROM tblLivres
WHERE fldGenre="Roman"
ORDER BY fldLangue DESC;
Les SGBD actuels offrent de plus en plus des possibilités QBE avancées telles que l'utilisation des fonctions d'agrégation, l'implémentation des requêtes d'insertion, de modification et de suppression etc. .
Référez-vous à la documentation de votre SGBD pour voir comment QBE est implémenté et quelles sont les fonctionnalités et les limites.
Il est cependant important de savoir que les requêtes QBE sont toujours exécutées via SQL, parce qu'un SGBD ne comprend pas vraiment QBE. QBE n'est qu'une interface graphique couplée à un interpréteur, qui transforme les indications de l'écran QBE en SQL. La partie du SGBD, qui exécute la requête (appelée le moteur SQL), utilise le code SQL généré par l'interpréteur de la même façon que celui entré directement par l'utilisateur.
Nous avons l'architecture suivante:
Les contraintes d'intégrité
Définition
Une modélisation correcte et cohérente est sans doute une condition nécessaire pour créer une BD fonctionnelle, mais ne vaut pas grande chose lorsque le SGBD utilisé pour implémenter la base ne garantit pas l'intégrité de celle-ci lors du travail journalier avec les données. Contrairement aux requêtes de sélection, qui ne modifient pas le contenu d'une base de données, les requêtes d'insertion, de modification et de suppression peuvent par leur nature endommager l'intégrité des données. Pour éviter ce cas les SGBD nous offrent le mécanisme de vérification automatique des contraintes d'intégrité.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Les contraintes d'intégrité constituent l'ensemble des règles qui vérifient que les données d'une BD:
correspondent à tout moment aux prémisses définies par la modélisation de la base;
sont à tout moment cohérentes, c'est à dire sans perte d'information et sans contradiction.
Exemples:
Le système doit empêcher un utilisateur à entrer une valeur double ou indéterminée (NULL) pour un champ déclaré comme clé primaire.
Le système doit vérifier qu'une quantité livrée est toujours inférieure ou égale à une quantité commandée.
Afin de mieux pouvoir regrouper les différents scénarios qui peuvent se poser nous distinguons généralement 3 types de contraintes d'intégrité.
Les types de contraintes d'intégrité
La contrainte d'intégrité des tables XE "contrainte d'intégrité des tables" (angl. Table Integrity Constraint)
Cette contrainte vérifie qu'il n'existe jamais des doublons ou des valeurs indéterminées pour le(s) champ(s) qui constitue(nt) la clé primaire. La clé primaire doit donc toujours être unique et bien définie. Il sagit simplement de la définition-même de la clé primaire.
Exemples de violation de cette contrainte
L'ajout d'une valeur de clé primaire qui existe déjà dans la table.
La modification d'une valeur de clé primaire vers une valeur qui existe déjà dans la table.
L'ajout d'une valeur indéterminée pour une clé primaire.
La modification d'une valeur de clé primaire vers une valeur indéterminée.
Méthodes pour vérifier cette contrainte d'intégrité dans un SGBD
Dans un SGBD il suffit généralement de déclarer un ou plusieurs champs comme clé primaire d'une table pour que cette contrainte soit automatiquement vérifiée lors d'une insertion ou modification d'une valeur dans la table.
La contrainte d'intégrité référentielle XE "contrainte d'intégrité référentielle" (angl. Referential Integrity Constraint)
Par contrainte d'intégrité référentielle, on entend l'obligation qu'à chaque valeur d'une clé étrangère correspond une valeur de la clé primaire associée. Cette obligation doit toujours être vérifiée lors de l'ajout, de la suppression ou de la modification de données.
Exemples de violation de cette contrainte
L'ajout d'une clé étrangère pour laquelle il n'existe pas de valeur correspondante dans la clé primaire associée.
La modification d'une clé étrangère vers une valeur pour laquelle il n'existe pas de valeur correspondante dans la clé primaire associée.
La suppression d'une clé primaire référencée par une ou plusieurs valeurs d'une clé étrangère.
La modification d'une clé primaire référencée par une ou plusieurs valeurs d'une clé étrangère.
Méthodes pour vérifier cette contrainte d'intégrité dans un SGBD
Un SGBD nous offre généralement une ou plusieurs des quatre méthodes suivantes pour spécifier à tout moment l'intégrité référentielle des données d'une BD. Les opérations A et B sont interdites doffice car elles conduiraient directement à une violation des contraintes dintégrité. En ce qui concerne les opérations C et D, il existe des alternatives.
Interdiction des opérations C et D.
Cascade des opérations du type C et D vers les clés étrangères correspondantes. Une modification d'une clé primaire aurait comme conséquence la modification de toutes les clés étrangères correspondantes. Une suppression d'une clé primaire aurait comme conséquence la suppression automatique de tous les enregistrements dont la clé étrangère a la même valeur. Cette option est à utiliser avec précaution !
Affectation d'une valeur par défaut aux clés étrangères concernées par une opération du type C ou D.
Affectation d'une valeur indéterminée (NULL) aux clés étrangères concernées par une opération du type C ou D.
En pratique, les méthodes 1 et 2 sont utilisées dans la majorité des cas. Pour cette raison nous allons ignorer les méthodes 3 et 4 dans les exercices.
La contrainte d'intégrité générale XE "contrainte d'intégrité générale" (angl. General Integrity Constraint)
Une contrainte d'intégrité générale est utilisée pour limiter les valeurs possibles d'un champ quelconque d'une table en fonction de la nature de celui-ci et de son rôle dans le système d'information.
Exemples de violation de cette contrainte
Il existe plusieurs variantes de cette contrainte.
A chaque champ correspond un type de données, une longueur et un format bien définis.
Exemples: Le numéro client doit être une valeur numérique.
Le nom du client ne doit pas dépasser 25 caractères.
Un numéro de compte doit respecter le format X-XXX/XX-X
Un champ peut avoir un domaine de valeurs prédéfini (une plage de valeurs possibles) et/ou une valeur par défaut.
Exemples: Une note d'un devoir en classe doit être entre 0 et 60
La prix d'une facture ne doit pas être un nombre négatif.
La date d'une commande doit automatiquement être la date actuelle à moins que l'utilisateur n'entre une autre date.
La valeur d'un champ peut limiter les valeurs possibles pour un autre champ d'une table/d'une BD.
Exemple: La valeur du champ fldDatePaiement est supérieure ou égale à la valeur du champ fldDateFacture pour une table tblFactures.
Méthodes pour vérifier cette contrainte d'intégrité dans un SGBD
En principe, tout SGBD moderne devrait offrir des moyens pour spécifier les propriétés dun champ de table, en tenant compte des contraintes ci-dessus.
Exercice modèle
Soit la BD suivante.
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\contrn1.gif" \* MERGEFORMAT
Quelle(s) contrainte(s) est(sont) concernée(s) lors de l'ajout d'un client ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d'un client ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de l'ajout d'une facture ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d'une facture ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de l'ajout d'un enregistrement dans la table tblConcerne ? Par quel moyen est-ce que le SGBD peut vérifier le domaine de valeurs du champ ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de la suppression d'un enregistrement de la table tblConcerne ?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro d'un article dans la table des articles?
Quelle(s) contrainte(s) est(sont) concernée(s) lors de la modification du numéro client d'une facture ?
Les formulaires XE "formulaire" (angl. forms)
Définition
L'affichage, la saisie et la modification des données ont été réalisés jusqu'à maintenant directement dans les tables. Même les requêtes ont soit affiché leurs résultats sous forme de feuilles de données ( = sous-table), soit modifié directement le contenu des tables. Les formulaires représentent un autre outil de manipulation de données des SGBD.
Un formulaire est une aide utile pour consulter et modifier rapidement et facilement les données d'une table. Les diverses facilités mises à notre disposition par les formulaires nous offrent un bon confort ainsi qu'une très grande sécurité des données lors des manipulations.
En général on utilise un formulaire pour:
Entrer des données.
Consulter des données.
Modifier des données.
Voici à titre d'exemple un formulaire, qui affiche toutes les données d'une table qui contient des livres:
Vous remarquez que ce formulaire affiche un enregistrement à la fois.
Un formulaire est toujours lié à une table ou bien à une requête. Il ne représente donc qu'une interface entre l'utilisateur et les tables. Toutes les données saisies sur un formulaire sont donc inscrites dans la (les) table(s) correspondante(s).
Chaque formulaire est composé de contrôles. Voici une liste non exhaustive des contrôles XE "contrôles d'un formulaire" les plus répandus dans les SGBD actuels:
Nom du contrôleDescriptionUtilisationEtiquette XE "Etiquette"
(angl. Label)
Exemple:
Affiche du texte fixe.Ce type de contrôle n'est pas lié à un champ d'une BD. Il sert uniquement à fournir des informations à l'utilisateur.
Zone de texte XE "Zone de texte"
(angl. Text Box)
Exemple:
Contient des données de la BD. Ce contrôle affiche par exemple la valeur d'un champ pour l'enregistrement actuel.Peut représenter des champs de tout type.
Bouton d'options XE "Bouton d'options"
(angl. Option Button ou Radio Button)
Exemple:
Utilisés en groupe, ces boutons permettent de choisir une seule valeur parmi plusieurs possibles. Un bouton sélectionné signifie que la valeur associée à ce bouton est sélectionnée comme valeur pour le champ correspondant au groupe de boutons.
Les options dans un groupe représentent donc les valeurs possibles pour UN champ donné de la table.
Exemple: Le bouton Féminin sélectionné veut dire que le sexe de cet employé est féminin.
Ce contrôle représente de préférence des champs de type numérique, texte ou date.
On utilise des groupes de boutons d'options pour représenter des champs pouvant contenir seulement quelques valeurs prédéfinies, qui ne changent pas souvent ou pas du tout comme par exemple le sexe (masculin/féminin), le résultat d'un examen (Admin/Ajourné/Ecarté) etc. .
Case à cocher XE "Case à cocher"
(angl. Check Box)
Exemple:
Utilisé pour afficher le contenu d'un champ de type Oui/Non (Yes/No). La différence par rapport aux boutons d'option est qu'il est possible de cocher simultanément plusieurs cases dans un groupe. En plus, les cases à cocher apparaissent souvent seules et indépendant d'un groupe.
Chaque case concerne UN champ de la table.
Exemple: La table contient 3 champs à valeurs Oui/Non (fldCaracGras, fldItalique, fldSouligné).Représente des champs à valeurs logiques (Oui/Non).
Zone de liste XE "Zone de liste"
(angl. List Box)
Exemple:
Permet d'afficher une liste de valeurs parmi lesquelles l'utilisateur peut en choisir une.
On utilise des zones de liste pour représenter des champs qui contiennent plusieurs valeurs possibles. Lorsque la nature des données fait que des nouvelles options deviennent indispensables, il suffit de les ajouter dans la liste et chaque utilisateur pourra les sélectionner.Ce contrôle représente de préférence des champs de type numérique, texte ou date.
On utilise des zones de liste pour représenter des champs pouvant contenir beaucoup de valeurs qui ne changent pas souvent ou pas du tout comme par exemple les noms des différents pays de l'Europe.
Liste modifiable XE "Liste modifiable"
(angl. Combo Box)
Exemple:
Combinaison entre une zone de liste et une zone de texte. L'utilisateur peut sélectionner une valeur de la liste ou entrer un texte de son choix.Ce contrôle représente de préférence des champs de type numérique, texte ou date.
Utilisation pareille à la zone de liste mais avec l'option pour l'utilisateur d'entrer une valeur non prédéfinie.
Bouton de commande XE "Bouton de commande"
(angl. Command Button)
Exemples:
Exécuter une ou plusieurs commandes systèmes respectivement lancer des modules de programmes créés par l'utilisateur.
Exemple1: Visualiser toutes les commandes d'un client.
Exemple2: Arrêter l'action en cours.Ce type de contrôle n'est pas lié à un champ d'une BD.
La plupart des SGBD offrent encore des contrôles pour améliorer la présentation des formulaires (contrôles graphiques, images, liens OLE
).
Convention des noms:
Les noms des formulaires sont précédés du préfixe frm (angl.: Form)
Quand est-ce qu'on utilise des formulaires ?
Lorsqu'on ne veut pas que les utilisateurs travaillent directement dans les tables. Les formulaires offrent généralement des mécanismes de sécurité plus sophistiqués tels que les zones de listes qui empêchent les utilisateurs d'entrer n'importe quelle valeur dans un champ etc.
Lorsqu'on veut présenter les données sous une forme plus conviviale. On peut par exemple utiliser des cases à cocher pour les champs à valeur Oui/Non (Yes/No).
Lorsqu'on désire afficher les enregistrements un à la fois (( Formulaires Colonne Simple)
Le principe de conception d'un bon formulaire est toujours de minimiser le nombre de frappes afin de minimiser les erreurs possibles.
Quelle est la base de création d'un formulaire ?
Tout comme les tables et les requêtes, un formulaire est un composant d'une BD, qui doit être crée et défini avant de pouvoir être utilisé pour manipuler les données.
Chaque formulaire se crée à partir d'une table ou d'une requête.
Les données affichées dans un formulaire proviennent donc de tables ou de requêtes, tandis que certaines informations spécifiques à l'apparence du formulaire (p.ex. couleur de l'arrière plan
) sont stockées dans la définition du formulaire.
Types de formulaires
En général nous distinguons 3 types de formulaires:
Formulaire Colonne Simple XE "Formulaire Colonne Simple" (angl. Single Column Form)
Dans un formulaire Colonne Simple, les valeurs des enregistrements sont affichées dans une seule colonne. Chaque valeur d'un enregistrement se trouve dans un champ de formulaire dédié. Un seul enregistrement est donc représenté à chaque fois.
Formulaire Tabulaire XE "Formulaire Tabulaire" (angl. Tabular Form)
Dans un formulaire tabulaire, les enregistrements sont représentés sur des lignes et des colonnes. Ce type de formulaire a une apparence similaire à celle de la vue d'un tableau ou d'un résultat d'une requête.
3. Formulaire Graphique (angl. Graphical Form)
La plupart des SGBD offrent une multitude d'options de représentations graphiques (Histogrammes 2D, Histogrammes 3D, Diagrammes circulaires
).
Création d'un formulaire
Avant de créer un formulaire, quelques réflexions s'imposent:
Comment est-ce qu'on veut représenter les données et quel type de formulaire est le plus adéquat ?
Est-ce que l'utilisateur aura la possibilité d'ajouter, de modifier respectivement de supprimer des données ?
Quels sont les contrôles appropriés pour représenter les différents champs de la table respectivement de la requête ?
Voici quelques règles générales d'utilisation des différents contrôles standard.
Pour représenter un champ à valeur logique (Oui/Non), employez impérativement une case à cocher. Plusieurs cases à cocher peuvent être regroupées afin de représenter plusieurs champs à valeur logique.
Exemple: L'utilisateur, qui est dans ce cas un employé d'une société d'assurances, peut indiquer si un client à inclus dans son contrat une assurance auto supplémentaire du type "Défense & Recours" .
Pour représenter un champ, qui ne peut contenir qu'un nombre très limité (max 5) de valeurs prédéfinies du type numérique, texte ou date, qui sont en plus mutuellement exclusives, utilisez un groupe de boutons d'options.
Exemple: L'employé choisit si la carte verte est envoyée à l'agent ou directement au client.
Un champ, qui peut contenir un nombre limité (> 5) de valeurs prédéfinies du type numérique, texte ou date, qui sont en plus mutuellement exclusives, devra être représenté par une zone de liste.
Exemple: L'employé peut étendre la couverture de l'assurance auto sur un pays supplémentaire.
Lorsque pour un champ, représenté normalement par une zone de liste, vous voulez donner à l'utilisateur la possibilité d'entrer des valeurs outres que celles prédéfinies, utilisez une liste modifiable.
Exemple: L'employé peut soit sélectionner une des marques prédéfinies, soit entrer lui-même un nom de marque.
Pour les champs ou vous ne pouvez pas du tout anticiper les valeurs, et qui ne sont pas du type logique, utilisez une zone de texte.
Exemple: L'employé doit entrer le nom du client.
Lors de la conception d'un formulaire, le respect de ces quelques règles garantit à l'utilisateur le principe de la saisie minimale. Partout ou une sélection de valeurs prédéfinies est possible, l'utilisateur n'a pas besoin d'entrer les données au clavier.
Avantages:
La rapidité de la saisie des données augmente ( meilleure productivité.
Elimination de beaucoup de sources d'erreur.
Les rapports XE "rapport" (angl. reports)
Définition
Avec les formulaires, nous avons introduit un outil puissant pour consulter et manipuler les données d'une BD. Il est également possible d'imprimer les formulaires, mais les SGBD nous offrent un outil beaucoup plus puissant en termes de fonctionnalités pour imprimer les données et effectuer des calculs sur ces données. Il s'agit des rapports (ou états) (angl. reports), qui ont l'avantage d'être très flexibles en ce qui concerne la création de listes et de statistiques imprimées, mais qui ne permettent pas de dialogue interactif avec l'utilisateur. L'important pour l'utilisateur d'une BD est donc de savoir quand il faut utiliser un formulaire et quand un rapport.
En général, on utilise un rapport pour:
Imprimer des listes et statistiques concernant les données;
Regrouper les données et créer des calculs sur les données;
Créer des factures, bons de livraisons et autres pièces de gestion importantes.
Reprenons notre table avec les livres d'une librairie
Exemple 1:
Le rapport suivant affiche simplement une liste avec tous les livres en stock. Cette liste est triée par ordre alphabétique sur le titre.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\rapp1.gif" \* MERGEFORMAT
Exemple 2:
Un SGBD nous offre généralement la possibilité de regrouper les données. Chaque groupe XE "groupement de données" est défini selon les valeurs d'un ou de plusieurs champs. Un groupe contient normalement 3 parties; une en-tête de groupe, une section détail et un pied de groupe. Dans notre exemple, nous allons créer des groupes basés sur la valeur du champ fldGenre, donc un groupe par genre. Pour chaque groupe, donc pour chaque genre, nous allons afficher les libellés des champs dans l'en-tête du groupe et les livres appartenant au groupe dans la section détail. A la fin de chaque groupe (dans le pied de groupe) sera affiché en plus, le total des exemplaires en stock pour ce groupe.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\rapp2.gif" \* MERGEFORMAT
Exemple 3:
Dans ce rapport, les livres sont groupés par genre et à l'intérieur d'un genre par langue. Chaque groupe est donc défini par le genre et la langue.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\rapp3.gif" \* MERGEFORMAT
Exemple 4:
On pourrait envisager de représenter le même groupement (genre & langue) d'une autre façon.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\rapp4.gif" \* MERGEFORMAT
Quelle est la base de création d'un rapport ?
Tout comme les tables, les requêtes et les formulaires, un rapport est un composant d'une BD, qui doit être créé et défini avant de pouvoir être utilisé pour afficher les données et les calculs sur les données.
Chaque rapport se crée à partir d'une table ou d'une requête.
Les données affichées dans un rapport proviennent donc de tables ou de requêtes, tandis que certaines informations spécifiques à l'apparence du rapport (p.ex. Titre dans l'en-tête
) sont stockées dans la définition du rapport.
Chaque rapport est composé de contrôles XE "contrôles d'un rapport" . Puisque les rapports ne sont pas prévus pour le dialogue interactif avec l'utilisateur, ils contiennent dans la plupart des cas seulement 3 types de contrôles:
Nom du contrôleDescriptionExempleZone de texte XE "Zone de texte"
(angl. Text Box)Affiche les données de la BD, ainsi que les résultats de calculs sur ces données. Les zones de textes constituent les contrôles les plus importants et les plus utilisés dans les rapports.
Etiquette XE "Etiquette"
(angl. Label)Affiche du texte fixe.
Contrôles graphiques XE "Contrôles graphiques"
(angl. Graphical Controls)Ces contrôles, dont le seul but est l'amélioration de la présentation des rapports peuvent être de types différents, comme par exemple des lignes , des éléments graphiques élémentaires tels que carrés ou rectangles, mais également des images importées.
Néanmoins, beaucoup de SGBD prévoient également l'utilisation d'autres contrôles, comme par exemple les boutons d'options ou les cases à cocher.
Convention des noms:
Les noms des rapports sont précédés du préfixe rpt (angl.: report)
Structure d'un rapport
Chaque rapport est subdivisé en différentes parties, appelés sections XE "sections d'un rapport" . Un rapport peut contenir les sections suivantes:
En-tête/Pied de rapport
L'en-tête de rapport apparaît une seule fois au début de la première page, et le pied de rapport apparaît une seule fois à la fin de la dernière page. L'en-tête de rapport est souvent utilisé pour afficher des logos ou la date actuelle. Le pied de rapport contient souvent des grand totaux.
En-tête/Pied de page
Contient du texte, qui sera affiché/imprimé à chaque nouvelle page du rapport. L'en-tête de page contient généralement les noms des champs affichés dans la section détail. Le pied de page est souvent utilisé pour afficher le numéro de page.
En-tête/Pied de groupe
Dans un rapport on peut faire un regroupement d'enregistrements selon les valeurs d'un ou de plusieurs champs spécifiés (p.ex. Regrouper une liste de voitures par marque). Chaque groupe défini peut disposer d'un en-tête et d'un pied de groupe. L'en-tête de groupe affiche par exemple une ou plusieurs zones de texte indiquant le contenu du groupe (p.ex. Nom de la marque), ou les étiquettes de la section détail. Le pied de groupe contient des calculs (p.ex. sous totaux, moyennes) pour ce groupe. Entre l'en-tête de groupe et le pied de groupe se trouve la section détail, avec tous les enregistrements faisant partie du groupe.
Section Détail
Cette section est la plus importante. Elle contient la plupart des zones de texte et affiche les données et les calculs pour chaque enregistrement. Il existe toujours une seule zone détail, indépendant du fait qu'il y a des groupes ou non.
Création d'un rapport
Voici quelques points de réflexion avant la création d'un rapport:
Quelles données est-ce qu'on veut représenter ? (Dressez la liste des champs)
Quelles informations supplémentaires sont utiles (p.ex. groupements, sous totaux, moyennes, pourcentages)
Quel est le format approprié en terme de disposition des informations ?
Partie 3 : Protection des données
Sécurité des données
Définition
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Par sécurité des données XE "sécurité des données" , on entend toutes les mesures prises pour que les données d'une BD soient protégées contre:
les manipulations malveillantes
les accès non autorisés;
les incohérences et pertes de données accidentelles.
Les manipulations malveillantes
Définition
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Par manipulation malveillante, on entend la lecture, la modification ou la destruction non autorisée de données.
EMBED MS_ClipArt_Gallery
Exemple:
Sachant qu'une BD est implémentée par un ou plusieurs fichiers, au niveau du système d'exploitation, une personne peut effacer une BD complète au niveau de la gestion des fichiers (p.ex. Explorer) sans même avoir besoin de démarrer le SGBD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice
Donnez un exemple supplémentaire d'une manipulation malveillante.
La protection contre les manipulations malveillantes
Il est difficile d'empêcher une personne autorisée dans le système à effectuer une manipulation malveillante.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Toutefois, la plupart des SGBD exécutés sur un serveur offrent à l'administrateur d'une BD la possibilité de stocker toutes les manipulations effectuées dans une BD spécialisée, appelée journal des opérations effectuées (angl. auditing).
A l'intérieur du journal, l'administrateur peut à chaque moment vérifier quel utilisateur a effectué quelle manipulation sur quelle table à quel moment.
Avantages:
Transparence totale concernant les manipulations effectuées.
Identification des coupables en cas de problèmes.
Le fait de rendre l'existence d'un tel journal public possède un certain effet psychologique sur les malfaiteurs potentiels.
Désavantages:
Les conclusions tirées de la consultation d'un journal, sont à considérer avec précaution puisqu'un utilisateur en possession d'un mot de passe d'une autre personne peut effectuer des manipulations malveillantes sous l'identité de celle-ci.
Les performances d'une BD peuvent être dégradées puisque pour chaque manipulation d'une table, une inscription dans le journal doit être effectuée.
Un journal permet le contrôle total du travail des utilisateurs d'une BD.
Les accès non autorisés
Définition
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Par accès non autorisé à une BD on entend le fait qu'une personne lit, modifie, insère ou efface des données d'une BD sans avoir une autorisation préalable respectivement un accès électronique (Nom utilisateur & Mot de passe)
La protection contre les accès non autorisés
Il existe un certain nombre de mesures de protection contre les accès non autorisés.
Mot de passe XE "Mot de passe"
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Une BD peut être protégée par un mot de passe. L'utilisateur désirant travailler avec la BD; doit indiquer un mot de passe avant d'ouvrir celle-ci.
Une fois la BD ouverte, l'utilisateur peut accéder à tous les objets.
Avantage:
Une personne ne disposant pas du mot de passe correspondant ne peut pas du tout accéder à une BD.
Désavantage:
Les mots de passe sont évidemment stockés dans un fichier spécial au niveau du système d'exploitation. Une personne ayant des connaissances approfondies d'un système d'exploitation n'a généralement aucun problème d'afficher le contenu d'un tel fichier. Pour cela, la plupart des SGBD utilisent un procédé d'encryptage afin de rendre les mots de passe illisibles avant de les stocker dans un fichier.
Droits d'accès XE "Droits d'accès" aux objets d'une BD
Au niveau des BD, qui se trouvent localement sur un PC, un mot de passe est généralement suffisant pour garantir une certaine sécurité. Par contre pour les BD, qui se trouvent sur un serveur géré par un administrateur, et qui sont accédées par une multitude d'utilisateurs, d'autres mécanismes plus variés s'imposent.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Certains utilisateurs autorisés de la base peuvent être limités, dans leur accès, à quelques tables de celle-ci.
Exemple:
Soit une BD pour la gestion des comptes d'une banque, implémentée sur un serveur BD, auquel tous les employés (même ceux des agences) ont un accès via un réseau informatique.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\comptes2.gif" \* MERGEFORMAT
Un stagiaire auprès de la banque aura un login afin d'accéder la base de données, mais l'administrateur de la base lui accorde uniquement un accès en lecture aux tables tblAgences et tblClients. En plus, l'administrateur crée une vue, qui contient tous les enregistrements de la table tblComptes, toutefois sans afficher le champ fldValeur.
Le stagiaire, avec les connaissances acquises pendant le cours d'informatique en classe de 13CG, peut créer sur son PC des requêtes, formulaires et rapports, mais il sera limité à l'utilisation des données pour lesquelles il est en possession des droits nécessaires.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT En ce qui concerne les tables et vues d'une BD sur un serveur, l'administrateur n'a pas uniquement la possibilité de limiter les objets qu'un utilisateur peut accéder, mais il peut également définir pour chaque objet, le type d'accès auquel un utilisateur a le droit .
Parmi les types d'accès nous distinguons:
Autorisation de lecture (angl. select)
L'utilisateur peut uniquement lire des données.
Autorisation d'insertion (angl. insert)
L'utilisateur peut lire et insérer des données.
Il ne peut cependant pas modifier ou effacer des données existantes.
Autorisation de mise à jour (angl. update)
L'utilisateur peut lire et modifier des données.
Il ne peut cependant pas insérer ou effacer des données.
Autorisation d'effacement (angl. delete)
L'utilisateur peut lire et effacer des données.
Il ne peut cependant pas insérer ou modifier des données.
Le SGBD sur le serveur garantit que les restrictions définies pour un utilisateur ne sont pas violées.
Exemple:
L'administrateur d'une BD gérée par un SGBD serveur Oracle peut par exemple exécuter des commandes comme:
GRANT insert, update ON tblComptes,tblAgences TO JWEBER;
Cette commande donne à l'utilisateur identifié au système par le nom JWEBER, le droit de lire les données des tables tblComptes et tblAgences, d'insérer de nouveaux enregistrements dans ces tables et de modifier les enregistrements existants dans les deux tables.
La commande suivante enlève le droit d'insertion dans la table tblComptes à l'utilisateur.
REVOKE insert ON tblComptes FROM JWEBER;
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\pen.GIF" \* MERGEFORMAT Exercice
En vous référant à la syntaxe présentée dans cet exemple, et en supposant que le nom utilisateur du stagiaire de l'exemple précédent est EMULLER, indiquez les commandes nécessaires pour donner les droits d'accès au stagiaire de la banque au début de la période de stage, et celles nécessaires pour lui enlever ces droits à la fin de la période de stage. Nous supposons que la vue créée par l'administrateur s'appelle vComptesSansValeurs.
Avantage de la gestion des droits d'accès:
Les droits d'accès sont un outil parfait pour personnaliser l'accès à une BD de façon à ce que chaque utilisateur puisse uniquement effectuer les opérations en relation avec sa fonction et compétence à l'intérieur de l'entreprise. Ceci restreint les possibilités d'effectuer des manipulations malveillantes et limite en plus le nombre des suspects en cas d'une telle manipulation.
Désavantage de la gestion des droits d'accès:
En fait, il n'existe pas vraiment un désavantage, mais la gestion des droits d'accès nécessite un effort de gestion supplémentaire considérable, surtout pour les sociétés où les compétences des employés varient beaucoup.
Sécurisation du système d'exploitation
Un SGBD, tout comme les autres applications informatiques, utilise les services d'un système d'exploitation.
Une BD est toujours implémentée à l'aide de un ou de plusieurs fichiers. Le contenu de ces fichiers est normalement illisible pour chaque application outre que le SGBD à l'aide duquel le fichier (la BD) a été créé.
Toutefois, il est possible d'endommager et même d'effacer complètement un tel fichier, ce qui aurait comme conséquence la destruction partielle ou totale de la BD, de façon indépendante des mécanismes de sécurité implémentés au niveau du SGBD.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Il convient donc de protéger même l'accès au système d'exploitation, c.à.d. l'accès général au PC par un mot de passe.
Au niveau d'un PC, qui contient une BD locale, la plupart des systèmes d'exploitation prévoient deux types de mot de passe:
Un mot de passe pour démarrer le PC (angl. Power On Password)
Un mot de passe couplé à un économiseur d'écran (angl. Screen Saver Password)
Pour les serveurs BD, quelques mesures supplémentaires, telles que l'emplacement dans une salle protégée par une clé électronique, s'imposent.
Avantages:
L'existence d'un mot de passe au niveau du système d'exploitation augmente le niveau de sécurité du système.
Désavantage:
Un utilisateur doit indiquer son nom d'utilisateur ainsi que son mot de passe deux fois, la première fois pour accéder au système d'exploitation et la deuxième fois pour accéder à la BD à l'aide du SGBD. Certains SGBD sont cependant capables de reconnaître le nom d'utilisateur ainsi que le mot de passe indiqué au système d'exploitation et de le reprendre lorsque l'utilisateur veut accéder à une BD.
Les incohérences et pertes de données accidentelles
Définition
INCLUDEPICTURE "D:\\Data\\Mémoire\\Librairie d'images\\attent.GIF" \* MERGEFORMAT Par incohérence accidentelle, on entend toute coupure non intentionnelle des liens logiques entre les données d'une BD.
Exemple d'une incohérence accidentelle:
Dans les systèmes multi-utilisateur, il se peut que deux utilisateurs accèdent en même temps, aux mêmes enregistrements d'une BD sur le serveur. On parle d'un accès concurrent.
INCLUDEPICTURE "C:\\DATA\\Mémoire\\Librairie d'images\\reseau3.gif" \* MERGEFORMAT
Nous supposons, que les deux utilisateurs exécutent en même temps, de façon indépendante l'un de l'autre, les deux requêtes suivantes:
Utilisateur 1Utilisateur 2
UPDATE Employés
SET fldDépartement="CPT"
WHERE fldDépartement="Comptabilité";
UPDATE Employés
SET fldSalaire=fldSalaire*1.1
WHERE fldDépartement="Comptabilité"
AND fldDateNaisshÕ1 UmHnHu j>hÕ1 UmHnHu j=hÕ1 UmHnHu j=hÕ1 UmHnHu j:öèöèö×èöèöÏËÅË»¶¯¶»ËªËªË»¶»Ë»¶¯¶»Ë ª¶¯¶ªË˪ËË»¶j²UhÕ1 5U hÕ1 >*jhÕ1 5Uj%PhÕ1 5U hÕ1 5 hÕ1 5 hÕ1 jhÕ1 U
hÕ1 CJ0hÕ1 jhÕ1 U j¨OhÕ1 UmHnHujhÕ1 UmHnHuhÕ1 mHnHu4L-M--Ã-Ð-Ñ-´.µ.Ì.Ý.õ.ö./,/G/
//l0m0&3'366p6q6úúøöôïôêÞÞÙÔÞÞÞôïïïïïïöô
& F
& F
& Fë^ëgd
`¡
& F$a$$a$q677O77â7ã7Q8R8S9T9U9à:á:ÛÙÓÓÓÙÛÙÂÙÙ¹¨$
Ævú^`vúa$$
Æa$$
Æáá ü^á` üa$
Æá#$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ
>:?:á:â:0; =¡=´=µ=Â=Ã=Ñ=Ò=û=ü=,>@>]?j?Í?Õ?,@6@o@r@t@u@z@{@&A(A)AJAKAhAiAþABB>DmDnD£D¤D E E)E*EJJeLfLÄLöòèãòöÞöòöÞöòÔòÏòãòãòãòÁòÁò·ãò㢢ãòÏòãöÞöòöÞöòòòjõ±hÕ1 UjækhÕ1 U hÕ1 5jhÕ1 5UjYfhÕ1 5UjÌ`hÕ1 5UjhÕ1 UmHnHu hÕ1 >*jhÕ1 0J U hÕ1 hÕ1 5j?[hÕ1 5UhÕ1 jhÕ1 U4á:1;2;¯;°;Á;Ð;WDWEWRWSW£W§W¸WÊXËXïXòXóXøXûXYY$Y%Y'Y,Y:YLZMZnZqZrZwZ÷óëóáÜÕÜáóÐóÐáÜáóËóËóËóËóËóËóÐÀÜÀÐóÐó¶Ð¯¢ÜÜÕÜ¢¯óÐóЯ¢ÜjdjhÕ1 5UhÕ1 5CJjhÕ1 5CJU
hÕ1 5CJj×dhÕ1 5UjhÕ1 5U hÕ1 >* hÕ1 5 hÕ1 6 hÕ1 jhÕ1 Uj hÕ1 UhÕ1 jãhÕ1 U8wP¨P©PÎPÙPÚP:Q;QmQÉQ)R*R~TTUU=W>W£W¤WÉXÊX÷òðîìêìåàÛìòìêòòìììÓË$
& Fa$$
& F"a$
& F!
& F
& F $a$$
& Fa$ÊX'Y(Y)YKZLZ£Z¤Z¥Zs[t[Í[Î[9\ÍÅŽÅÅÅÅÍzx $a$$
& F$a$6$
& F
ÆïÙ
$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ]Ù
^ a$$
& F#a$$
& Fa$2$
& F $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ] ^ a$
wZzZZZ Z¡Z¢Z£Z¨Z·Zt[u[[[[ [£[©[¬[Ê[Ë[Ì[:\;\Ú]Û]è]é]ccBcacbcdcechcccccc`fféhêhëhõh÷òëòÞ×ÒÎÒÎÄÒ×Þò÷òëòÞ×ζάò¬Î¢Î¶Î¶Î×ζζÎ×ÎzhÕ1 5>*CJhÕ1 >*mHnHu jhÕ1 >*UmHnHu hÕ1 >*jhÕ1 0J UjhÕ1 UjhÕ1 UmHnHujñohÕ1 5UhÕ1 hÕ1 5
hÕ1 5CJjhÕ1 5CJU hÕ1 6 hÕ1 hÕ1 5CJ.9\:\\?\@\A\B\C\D\E\F\G\H\I\J\K\L\M\N\O\P\Q\a^b^_úõõõõõõõõõõõõõõõõõõõõõúììì$Ð^Ða$$a$$a$_0_K_¤_©_ó`ô`
a a>b?bAcBcacccdcfcgchcocvcccììÙìÐÐÎÌÊÅÅÅÅÅÅÅÅÅ¿¿¿¿$If$a$ $Ð^Ða$$
& Fáäþ^á`äþa$gd
`¡$
& FÐõÿ^Ð`õÿa$gd
`¡cccccc*,yizi{i|i}i~iiʼ¼R¼4kdê$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kd$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$4kd4$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laöiiiiiiiiîiïiðiñiòiÊÁ¿¿¿¿¿ÁÁ±|±4kd$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$ $
Æ9r a$4kdE$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö òióiôiõiöi÷iøiʼ¼R¼4kd $$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kdÃ$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$4kdh$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laöøiùiúiûiüiýiÿijjOjZj[jʼpnlj$
Æ9r Å;ý^Å`;ýa$
Æ9r 4kdÔ$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$4kdy$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö [jìkík8l9l>l?llll¢l£lmmnnn¬núøøøóøøøøñøÊøúøø¢'
ÆÅÀ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ &$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$$a$knlnmnpn©nÉnÊnënñnônõn o o o!otouovowoo¨o©o®oÄoÆoÇoÔoÚoÛoõoöoùopp$p%pOp»påpLqqq¿qÆqrrGrHrròêæáæÙæÔæÌæÄæêæê¶êᯢ¢ááæ
æázzáæ¯áæÔæÔæÔæêæjhÕ1 5UjÎhÕ1 U hÕ1 56hÕ1 mH sH hÕ1 jhÕ1 5>*U hÕ1 5>*jÉhÕ1 UmHnHujì¼hÕ1 Uj¸¶hÕ1 U hÕ1 6j¢°hÕ1 U hÕ1 5hÕ1 jhÕ1 Uj «hÕ1 UmHnHu0¬nnÈnÉnËnÌnónônön÷no o o o oÕ+
ÆÅÀÅ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ `Å'
ÆÅÀ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ )
Æ 9r ÅÀ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ oÜoôoõoOpPp·pºpåpLqMqNquqvqqq®q¯qÈqÛÙׯ¡¡¡¡¡¡××××××
& F0
#
Æ7À7Éý^7`Éý'
Æ7À$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ #$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ Èq×qåqõqöqr&r7rFrGrärårîrïr*s+s-s.sÞsßsásâs@tAtúúúøøóîîøÊøøøøøøøÈøøøøø #$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ
& F3
& F2
& F1rrrrärårìrørþr+s,ss©sÄsÉsØsÜsßsàsïsòsAtBtCt¡töt÷tütuuuuumunuoupuv7w@wBwIwlwrwwwµw¼wäwëwúwx"x)xQx÷é÷äàÛàÖàÎàäàäàäàÆàäà¸àäன¢©®àääàäàÛàÖàäàÛàÖàäàÛà jkñhÕ1 5UmHnHujhÕ1 5U hÕ1 5 hÕ1 jhÕ1 UjéëhÕ1 UmHnHujÍßhÕ1 UjÙhÕ1 U hÕ1 6 hÕ1 >*hÕ1 hÕ1 5jÔhÕ1 UmHnHujhÕ1 U6At¡t¢tÚtÛtÜtÝtÞtuuÍvÎv(w)wBwqwrwµwëwØÖÐËËËËÉËØÖÖÖ¹¬¬§
& F`
& F&
& Fªqÿ^ª`qÿ
& F% äþ^ `äþgd
`¡$a$
Æ9r &$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$ëwìw"x\x]xîx?y@yAyByMyNyy
yµy¶yîyïyzz)z4zöñëéÅÅéééééééÀéÀéÀé¾¼
& F#$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ^
& F'
& F`Qx\x]x^x±x²x³x´xîxByCyDyLyMyNy5z6z8zDzEzFzKzSzUzVz`{a{b{c{ö{÷{|||m|n|úöìçìØìçöÇ»»¤ööç
y
çöqöçölödödj¥ hÕ1 U hÕ1 >*jw hÕ1 U hÕ1 5 hÕ1 jhÕ1 5UjhÕ1 0J 5UjêhÕ1 UhÕ1 mHnHuhÕ1 5>*CJmHnHuhÕ1 5>*mHnHu joühÕ1 5>*UmHnHu jíöhÕ1 5UmHnHu hÕ1 5jhÕ1 5UhÕ1 hÕ1 6#4z5zzÍz`{a{{Á{ö{÷{|ýÙ²²\\*$
& F/$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$#$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ
||q|r|}}} }w}ù}ú}~~¦~OPUVWúõúúúõúúÎÉÇúÎÅúõÃÃÃÃÃÃ)
& F&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$$a$n|o|p|ý|}}}w}x}y}ù}~ ~ ~)~*~9~:~j~k~w~x~OPSTêëìí+1u¶Ñ*2BHÈã òêæáæÙæÑæÌæÄæ̹²¹Ì¹²¹Ìæ¤ææææáæáæáæáæáæáæáæáæjQGhÕ1 UmHnHujzzhÕ1 U hÕ1 >*jÍ9hÕ1 UjhÕ1 UmHnHu hÕ1 5jhÕ1 5Uj@4hÕ1 U hÕ1 5j¾.hÕ1 Uj¡hÕ1 U hÕ1 6hÕ1 j¥ hÕ1 UjhÕ1 UmHnHu2îïZ¶vÉ *+
ÃÄß)*úøóëëøøøææøøøøúøøøøæÝØæÒ$If
& F
& F`
& F$
& Fa$$a$$a$ *+,µßª«æçJ
a
b
}
~
9 vwÌÍÎÏâêëïûÄÅ **9*+,-lm¦§ÌÊÊÊÊÅ¿Å¿
& F2kd[i$$IflÖ 4"!öÖÿÖÿ Öÿ Öÿ4Ö
laö$If
& F2kdÿh$$IflÖ 4"!öÖÿÖÿ Öÿ Öÿ4Ö
laö §¨©ªÎÏçJ
9ÌÊʦ¦¦T¦+
& F
Æ
@$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ '
& F$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ #$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ 2kd·i$$IflÖ 4"!öÖÿÖÿ Öÿ Öÿ4Ö
laö 9¥
stuvÐØØÖÖÔÔÔÎÎÎtÎÎYkd o$$IflÖÖÿ4" "Ö0ÿÿÿÿÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laö$If '
& F$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ
ÐÑÒ ÂÃÄ mnº»¼ùùðððùùùùððððùlkd$$IflÖÖ0ÿ&4" Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö $$Ifa$$If¼½¾ÉÊùúûü}H4kdö$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$$a$lkd±$$IflÖÖ0ÿ&4" Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöa¾¿ÀÈMSXm¹ÅÊÝø¨¾¿À>?yz{äåêBILMPüëßÑüÌüÄü¿üºü¿ü¿üºü¿üºü°ºü¦ºüÌüüüÌüüjOÈhÕ1 U hÕ1 5 hÕ1 jhÕ1 Ujû¸hÕ1 Ujn³hÕ1 5UjáhÕ1 5U hÕ1 5 hÕ1 6j.hÕ1 U hÕ1 >*hÕ1 5>*CJmHnHuhÕ1 5>*mHnHu j{hÕ1 5>*UmHnHuhÕ1 +üýþÿñ¼ññRñ4kd $$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kdª$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kdW$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$:;ʼ}$a$$a$4kdÍ$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
Æ9r $Ifa$4kdl$$Ifl¤Öÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö
;?@AB öÁööWRRR$a$4kd$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kd $$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kd̬$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö $$Ifa$ ¾¿>?yz|}~ÊËABKLNOP[\úÓúÓÑÑÑÌÑÑÑÑÊÑÑúúúÌúúúú$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$PQRZ[½¾êëìíH`h~"$ÊÌÎÐÔðñòóz¢©ÍÎïèßèÛÖÛÎÛÎÀλ۶ÛÎÛΨÎÛ ÛÖÛÖÛÖÛÎÛÎÎÛ»¶ÛÎÛÎÎÛ»ÛÖÛÖÛÎjÀùhÕ1 UmHnHuj>ôhÕ1 UmHnHuhÕ1 OJQJjåhÕ1 UmHnHu hÕ1 >* hÕ1 5jàhÕ1 UmHnHujhÕ1 U hÕ1 6hÕ1 hÕ1 5>*CJ hÕ1 5>* jSÖhÕ1 5>*UmHnHu4\®¯°±²³´µ¶úúñ¼ññRñ4kdÞ$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kd!Þ$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kdÎÝ$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö $$Ifa$$a$ ¶·¸¹º»¼½ÊÁÁWRR$a$4kd¥ß$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö4kdDß$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö $$Ifa$4kdãÞ$$IflÖÿå Q!öÖÿÖÿ Öÿ Öÿ4Ö
laö½îïð "ôõ«¬ÌÍ'(ÐËËËÆËËËËËÐËËËÆËËËËËÆË$a$$a$.$¥[ù$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ^¥`[ùa$Î#$%&=FÈÉñòDEFGKSèîx *+}~¾Åûüý)*Øüôæôüßü×üÏüÏÁÏü¼ü·üß®ü¦üüü¼ü·ü·üvqvü hÕ1 jhÕ1 5Uj1nhÕ1 5U hÕ1 5jÌXhÕ1 UmHnHujD©
hÕ1 UjÓ;hÕ1 UhÕ1 5>*CJ hÕ1 6 hÕ1 >*j,,hÕ1 UmHnHujl}
hÕ1 UjhÕ1 U
hÕ1 >*CJjY hÕ1 UmHnHujhÕ1 UhÕ1 ,(*mHnHu j²hÕ1 >*UmHnHu hÕ1 6>* hÕ1 56j°hÕ1 UmHnHujhÕ1 U hÕ1 5 hÕ1 >*jfhÕ1 UjhÕ1 UmHnHu
hÕ1 >*CJj¾shÕ1 UhÕ1 hÕ1 62 ¢t¢u¢x¢y¢z¢{¢|¢
¢¢ø¢ù¢.¤/¤!¥"¥|¥}¥~¥¥¥¨¥©¥O¦P¦÷òéòòòòòòòò÷ò÷òéòòàòÞÜòÖ
Æ9r $ ^ a$$ ^ a$$a$$
& Fa$P¦õ¦ö¦§§¨¨¨¨¤¨¥¨¦¨§¨¨¨©¨ª¨«¨¬¨¨®¨¯¨°¨Ò¨Ó¨© ©c©d©ýûûõððððýððððððððððððððððëð$a$$a$
Æ9r _©`©a©b©Ã©ß© ª-ªYª|ªª¯ª¸ªêª«ç«¡Ë®®U®V®W®X®¶®Í®ü®¯J¯e¯¯¯/°5°p°v°_±`±³±´±µ±¶±È±É±Î±ò±ô±õ±²²² ²#²&²K²M²N²÷é÷åàåàåàåÛÔÛåÛåÛåÏå÷å÷Á÷åàåàåàåÏåÏåÏå÷å÷³÷婤¤©å©¤¤¤©hÕ1 56 hÕ1 5 hÕ1 jhÕ1 Uj
ãhÕ1 UmHnHujÎhÕ1 UmHnHu hÕ1 6 hÕ1 6>* hÕ1 >* hÕ1 5hÕ1 jºhÕ1 UmHnHujhÕ1 U:d©©©à©.ª}ª««®®Y®Z®®®Ï®¯g¯h¯Æ¯Ç¯úúòòæúúúúúúúúáúúúÙÙÍúúú $
& F@ÿ]@ÿa$$
& Fa$$a$ $
& F@ÿ]@ÿa$$
& Fa$$a$ǯ^±_±·±¹±P²Q²0³1³:³;³=³>³g³h³E´F´|´}´qµrµ}µúúõìêä½»»»õ»»»ú»»»úìê&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$
Æ9r $Ð^Ða$$a$$a$N²Q²R²0³1³8³;³*UmHnHu hÕ1 5>* j(hÕ1 >*UmHnHuhÕ1 mH sH hÕ1 5>*CJ j hÕ1 >*UmHnHujhÕ1 >*U$jhÕ1 5>*CJUmHnHu hÕ1 6j¹ýhÕ1 U hÕ1 >* hÕ1 5j,øhÕ1 5UhÕ1 -}µµÞµßµàµj¶k¶·º·Ã¸Ä¸Ê¹Ë¹Ì¹Í¹ýýýýýýõõõýðêµê4kd$$IflôÖÿ4" "öÖÿÖÿ Öÿ Öÿ4Ö
laö$If$a$$
& Fa$͹ιϹйѹºººzº|º}º'»*¼(½¾ÊÄ
}}}$
& Fa$
Æ9r 4kdÇ$$IflôÖÿ4" "öÖÿÖÿ Öÿ Öÿ4Ö
laö$If4kdf$$IflôÖÿ4" "öÖÿÖÿ Öÿ Öÿ4Ö
laö¾¾A¾B¾C¾D¾E¾¥¾§¾¨¾¿¿;ÀvÁJÃÄÓÅÆîÆïÆÇÇxÇyÇzÇfÈúøòòðððòòçòÚÚÚÚÚÚÚòøòòòòú $
& Fg
Æ9r a$ $
Æ9r a$
Æ9r $a$¾¾¾¤¾¥¾¦¾Ý¾æ¾ïÆÇÇÇÇÇjÇkÇlÇmÇwÇxÇzÇáÈâÈãÈøÈùÈ É
É#É)ÉðæÝÖÇøðëÇæ«ææݫð°°t°fN.hÕ1 5CJOJQJehmH rÊÿsH hÕ1 CJOJQJmH sH hÕ1 5>*CJ$mH sH hÕ1 5CJ(OJQJmH sH jhÕ1 UmH sH j $hÕ1 >*UmHnHu hÕ1 >*hÕ1 mH sH hÕ1 5CJOJQJhÕ1 jhÕ1 >*UmHnHu
hÕ1 >*CJhÕ1 5>*CJjhÕ1 >*U j£ hÕ1 >*UmHnHu fÈáÈãÈøÈùÈ É
É*É+ÉÉɲÉßÉÊÊÊ+Ê,Ê}Ê~ÊÊÊÊúúõúõúúúúúéÝÝúúúúúúÔÔÔ $$Ifa$ $
Æ nFy@a$ $
Æ nFya$$a$$a$)É+É,É-ÉÉÉÉ,Ê-Ê}ÊÊÊÊÊÊʡʣʦʨʬʹÊÒ Ò Ò ÒoÒpÒqÒrÒ|ÒéÛÊÛ´é¦ÊÛ¦¦¦¦¦¦}xnxn_nVhÕ1 5>*CJ j/hÕ1 >*UmHnHujhÕ1 >*U hÕ1 >*hÕ1 hÕ1 mH sH hÕ1 CJOJQJmH sH hÕ1 5CJOJQJmH sH hÕ1 CJOJQJmH sH +hÕ1 CJOJQJehmH rÊÿsH j*ðhÕ1 CJOJQJmH sH hÕ1 CJOJQJmH sH +hÕ1 CJOJQJehmH rÊÿsH ÊÊÊÊÊvmm $$Ifa$ $$Ifa$kd+$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöÊÊÊÊÊvmm $$Ifa$ $$Ifa$kdA,$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöÊÊÊÊ Êvmm $$Ifa$ $$Ifa$kdé,$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö ʡʣʤʥÊvmm $$Ifa$ $$Ifa$kd-$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö¥Ê¦Ê¨Ê©ÊªÊvmm $$Ifa$ $$Ifa$kd9.$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöªÊ«Ê¬Ê¸Ê¹Ê/Ë0Ë1ËJÌÍfÎÌÎfÐÑzzzxxxssssss
& F $a$kdá.$$IflÖÖFÿ7
¬ £O&Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö
ÑòÑóÑÒÒ Ò Ò}Ò~Ò²Ó³Ó¼Ó½ÓAÔBÔzÔÿÔOÕþÕÿÕÖÖÖ=Ö>Ö?ÖúøøòòòððççççççÝÝÝÝòòòòòòò
& F4
Æ9r $
Æ9r a$
Æ9r
& F|Ò}Ò~Ò³Ó¼ÓÖÖÖ@ÖIÖIØ]ØØØذرزØÇØÈØÉØËØÜØÝØçØèØéØîØïØ÷ØøØÙÙÙÙÙÙùõíâíÔËíâíËíÔíÀÔíµíÔí«}p«]p«$jx7hÕ1 5CJUmH sH hÕ1 5CJmHnHu$j7hÕ1 5CJUmH sH hÕ1 5CJmH sH jhÕ1 5CJUmH sH hÕ1 CJmH sH hÕ1 5CJ mH sH hÕ1 5CJ(mH sH hÕ1 >*mH sH jhÕ1 UmHnHuhÕ1 5>*mH sH hÕ1 mH sH hÕ1 hÕ1 5>*$?Ö@ÖIÖJÖ××½×HØIØ]Ø^Ø
ØØØØØذزØÇØÈØÊØËØ)Ù*ÙsÙùùùððããðððððððùÚÚùÚùùùùùù $
Æ9r a$ $
& F5
Æ9r a$ $
Æ9r a$
Æ9r ÙÙ&Ù'Ù(Ù)Ù3Ù4Ù>Ù?Ù@ÙHÙqÙrÙsÙtÙuÙxÙÙÙÙ®ÙÁÙÂÙåÙæÙòÙóÙÚÚ)Ú*Ú9Ú:ÚMÚNÚYÚZÚ\Ú]Ú_Ú`ÚbÚiÚÚÚÚÚÚðåÒðåÈðåµðå¨ðåÈÈ
hÕ1 >*hÕ1 hÕ1 5mH sH hÕ1 mH sH jhÕ1 UmHnHuhÕ1 5CJmHnHu$jÖ8hÕ1 5CJUmH sH hÕ1 CJmH sH $jì7hÕ1 5CJUmH sH hÕ1 5CJmH sH jhÕ1 5CJUmH sH 0sÙtÙvÙwÙxÙÙÙÙÙÙùùùùëëbWW
Æ9r $IfkdJ9$$IflÖÖ0ÿ*hÕ1 5>*CJ$jWÂhÕ1 5>*CJ UmHnHuhÕ1 5>*CJ jhÕ1 5>*CJ UhÕ1 jhÕ1 UmHnHu0Ë÷Í÷Î÷Ï÷Ð÷Ñ÷Ò÷Ó÷Ô÷Õ÷7ø9øøøø«øööööööíööëëëëëå$If $
Æ9r a$ $
Æ9r a$«ø¬øø®ø³ø¹øÇøÔøÚøßøàøçøðøõøùøùù£¡
Æ9r $IfFfpÓ$If[kdMÑ$$IflÖ @Öÿ
ò
Ö0ÿ ÿ ÿ ÿ ÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laöùù ùùù ùÛkd©Õ$$IflÖÖÿS3m
ù° ¿à:¥à ÖÖ
ÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÿÖ ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ4Ö
laöpÖ
ÿÿÿ$Ifùù ù#ù,ù0ù3ùùùùùùù$If3ù4ù5ù$
Æ9r ÛkdÈÖ$$IflÖÖÿS3m
ù° ¿à:¥à ÖÖ
ÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÿÖ ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ4Ö
laöpÖ
ÿÿÿ5ù;ù*CJ$j[ähÕ1 5>*CJ UmHnHujhÕ1 5>*CJ UhÕ1 5>*CJ hÕ1 5CJOJQJhÕ1 5OJQJhÕ1 hÕ1 OJQJhÕ1 CJOJQJ0JúKúNúRúYú$Iflkd'à$$Ifl4ÖÖÿfÒ ÖÖ
ÿÿÿÖ0ÿÿÿÿÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laöf4pÖ
ÿÿÿYúZú_úfúoúZOII$If
Æ9r $If¥kdÈà$$IflÖÖFÿSÜf¿ ÖÖ ÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöpÖ ÿÿÿÿÿÿÿÿÿoúpúuú{úútnn$If
Æ9r $Ifkd»á$$IflÖÖFÿSÜf¿Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöúúúúútnn$If
Æ9r $Ifkdcâ$$IflÖÖFÿSÜf¿Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöúúúúútnn$If
Æ9r $Ifkd ã$$IflÖÖFÿSÜf¿Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöúúúúvûwû×ûØûËüÌüEýFýëý}xvv}}vxxxn$
& Fja$ $a$kd³ã$$IflÖÖFÿSÜf¿Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö ëýìýBþCþHþRþ^þ_þeþjþ¨þúñúèèèhèèèkdÖë$$IflÖÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö $$Ifa$$h^ha$$a$
¨þ©þ¯þ³þãþ}ttt $$Ifa$kdì$$IflÖ@ÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöãþäþêþòþ-ÿ}ttt $$Ifa$kd:í$$IflÖ@ÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö-ÿ.ÿ6ÿ:ÿpÿ}ttt $$Ifa$kdñí$$IflÖ@ÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöpÿqÿyÿÿ¹ÿ}ttt $$Ifa$kd¨î$$IflÖ@ÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö¹ÿºÿ»ÿ
¥³}xoxgx^^^^ $$Ifa$$
& Fja$$h^ha$$a$kd_ï$$IflÖ@ÖFª÷ó
MüÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö
³´¶ÔÖÛjaaaa $$Ifa$kdð$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laöÛÜÞ jaaaa $$Ifa$kdÝð$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laö/16jaaaa $$Ifa$kdªñ$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laö679bdijaaaa $$Ifa$kdwò$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laöijljaaaa $$Ifa$kdDó$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laöOPèéje]e]eeUe$
& Fla$$
& Fka$$a$kdô$$IflÖ@Ö\ªs ÚnÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿÿÿÿ Öÿÿÿÿ4Ö
laö é#$34bc¸¹º»½Ñã
EZ[\cdpqy|òîåîÛîÛîÛîÆî¯ wòîòîj\îåTåîTN
hÕ1 CJhÕ1 OJQJhÕ1 CJOJQJmH sH hÕ1 5>*CJ OJQJhÕ1 hÕ1 mH sH hÕ1 hÕ1 5mH sH #hÕ1 hÕ1 5CJ4OJQJmH sH jhÕ1 5UmHnHu,jhÕ1 5>*CJ OJQJUmHnHu)jhÕ1 5CJ4OJQJUmHnHuhÕ1 CJOJQJhÕ1 5OJQJhÕ1 jhÕ1 UmHnHu éù#$'/3öööövööökdÞô$$IflÖÖFª× ¯¬ -Ø
ýÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö $$Ifa$347^bvvv $$Ifa$kdõ$$IflÖÖFª× ¯¬ -Ø
ýÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöbcfvvv $$Ifa$kd>ö$$IflÖÖFª× ¯¬ -Ø
ýÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö¸ºÑãð
DEZzrzmmmmmmmm$a$$
& Fma$$a$kdñö$$IflÖÖFª× ¯¬ -Ø
ýÖ0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö Z[\cdpq}ù÷ìììEì§kd¤÷$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿ ÖÖ ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laöpÖ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
Æ9r $If
Æ9r }~¬ôôrôôôkd¯ø$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laö
Æ9r $If|
£«¬µ¸ÊÒÓÔÝï '(2>FMNOU_iklm|·¸¹ÈÔàáâäðñ
?@BDòüI V r K L P øòøîøòøòøîøòøòøîøòøòøîøòøåîøòøòøîøòøòøîøòøòøîøòøòøîåîøîòîòîòîÛÐÛÆÛî¼· hÕ1 jhÕ1 UhÕ1 CJOJQJhÕ1 5CJOJQJhÕ1 CJOJQJhÕ1 5OJQJhÕ1
hÕ1 CJhÕ1 OJQJE¬¹ºÓ}rrr
Æ9r $Ifkdoù$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laöÓÔðñ}rrr
Æ9r $Ifkd/ú$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laö '}rrr
Æ9r $Ifkdïú$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laö'(?@NXMMM
Æ9r $If§kd¯û$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿ ÖÖ ÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laöpÖ ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿNO`al}rrr
Æ9r $Ifkdºü$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laölm¸}rr_
Æ9r pû$If^`pû
Æ9r $Ifkdzý$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laö¸¹ÕÖâ}rrr
Æ9r $Ifkd:þ$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laöâãäð}wl
Æ9r $If
Æ9r kdúþ$$IflÖ@ÖFÿô `©ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖ ÿÿÿÿÿÿÖ ÿÿÿ Ö ÿÿÿÿÿÿ Ö ÿÿÿ4Ö
laöðñ
Æ9r $Ifnkdºÿ$$Ifl4Ö@Öÿ ÖÖ
ÿÿÿÖ0ÿÿÿÿÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laöf4pÖ
ÿÿÿ
Æ9r $Ifnkde$$IflÖ@Ö0ÿø d
&Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö ?
Æ9r $Ifnkd$$IflÖ@Ö0ÿø d
&Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö?@AB
Æ9r $Ifnkd$$IflÖ@Ö0ÿø d
&Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöBCDA B C V W r s _U
Æ9r Ð`Ð+$
Æ9r $d%d&d'dNÆÿOÆÿPÆÿQÆÿa$
Æ9r nkd9$$IflÖ@Ö0ÿø d
&Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö s t ð ñ ¡
¢
( ) * + , - u (
)
Ý
Þ
:;ðñùôòíòèùùùùùùùæäòßßßßßßßßßß$a$
& Fp
& Fo
& Fn
Æ9r P k m n : K X ½ õ 'HfxñòEFGHI¤¥äåéêëìîòóô÷øHIJKT¾ÄÐÚ#÷òèäßäßäßäÚäßäßäÒäÒÄÒäÚäßä¾µ§µä¾ääß}äxäßä hÕ1 6hÕ1 5>*CJ j %hÕ1 >*UmHnHujhÕ1 >*UjhÕ1 UjWhÕ1 UmHnHuhÕ1 mHnHu
hÕ1 CJ$jÕhÕ1 UmHnHujhÕ1 U hÕ1 5 hÕ1 >*hÕ1 jhÕ1 U hÕ1 hÕ1 56.ñ¤¥äåéêìíîòóõöØÖÖÖÈÈÈÈÈÈÈÈEkd¢$$IflÖ0ÿ¬ öÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö
$
Æ9r $Ifa$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$
ö÷TUª«èé¹³³³³©
Æ9r $If
& F
Æ9r
Æ9r Ekd¤$$$IflÖ0ÿ¬ öÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöéêëìíî£*hÕ1 hÕ1 5jEhÕ1 UmHnHujhÕ1 U3ËÌ%&'ÐÑabñë
Æ9r $a$XkdNd$$IflÖFÿô¹¬ `ÅóöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö$Ifÿú$If^ÿ`ú W X a b ¼ ½ ØÖÐÖÇÁÁhÖcÖ$a$Xkd$$IflÖFÿô¸¬ `ÄôöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö$If $$Ifa$
Æ9r &$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$ $ G M s ¡ ¥ Þ á â 5 6 7 8 h i j k m n Ã Ä Å Æ È Ë Ì Í " # $ % R \ k r Ë Ì ! !!!"!z"{"ü÷ü÷ü÷üòüíüãòãÔãòüíüƾü¾°¾ü¾ü¾¢¾üòü¾ü¾¾ü÷ü÷ü¾ü¾¾òüj`»hÕ1 UmHnHujŬhÕ1 UmHnHujhÕ1 UmHnHujhÕ1 UmHnHujhÕ1 UjhÕ1 UmHnHu jhÕ1 5UmHnHujhÕ1 5U hÕ1 >* hÕ1 5 hÕ1 6hÕ1 4 à á l m Ç È Ë Ì & ýýýÖýýÐÊÊÊÊÁÊÊ $$Ifa$$If
Æ9r &$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$& ' ( Ê Ë z"{""
"à"á";#¦¤¤¤¢¤{¤¤¤uuu$If&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$Xkdåº$$IflÖFÿô¸¬ `ÄôöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö
{""
"""Ü"Ý"Þ"ß"á"â"7#8#9#:#O#U####¦#Í#Õ#ì#ò# $!$t$u$v$w$*&+&2&5&6&&&&&&&&ç&è&é&ê&ö&ÿ& '*','8'*8;#* hÕ1 5jr
hÕ1 UmHnHujhÕ1 UhÕ1 1((c(d(¾(¿(À(Ð*Ò*Ô*$+&+],úñññúúúúúo&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$XkdI/$$IflÖFÿf¸9!ÒRöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö $$Ifa$$a$ ],^,_,j,k,Æ,Ç,!-"-#-µ.¶.Â.Ã. / /y/úúúúññëúúúúúñññXkdíQ$$IflÖFÿØ
Ç!D7¸öÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö$If $$Ifa$$a$Ä,Å,Ç,È, - - - -·.À.Ã.Ä.Å.// / / / /u/v/w/x/î1ÿ1l2m2À2Á2Â2Ã294N4²4´4»4¾4¿4À4555555p5q5r5s5÷ó÷ó÷å÷óàóÒ÷ó÷Ä÷ó÷ó÷¶÷ó±ó÷ó÷£÷óàóÒ÷ó÷÷ó÷ó÷{÷j-hÕ1 UmHnHujYrhÕ1 UmHnHu hÕ1 5>* hÕ1 5j×lhÕ1 UmHnHu hÕ1 6j|_hÕ1 UmHnHujhRhÕ1 UmHnHujhÕ1 UmHnHu hÕ1 >*jJChÕ1 UmHnHuhÕ1 jhÕ1 U0y/z/{/A2B2C2k2l2Ì3³4´4½4¾4¦¡¡¡¡¡xx¡¡¡&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$Xkdbl$$IflÖFÿf¸9!ÒRöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö ¾455t5u5v5¼7¾7À788#8$8ööö$
& Fqa$$a$Xkd'$$IflÖFÿf¸9!ÒRöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö $$Ifa$ s566D6P6¢6¬677¦7¸78#8$8%8x8y8z8{8Z9[9b9e9f9g9¼9½9¾9¿9Á9Â9:::: :9:::;:::::Ã;Ä;Ë;Î;Ï;Ð;%*CJ hÕ1 5>*jî] hÕ1 5>*U hÕ1 >* jàðhÕ1 hÕ1 -ÑáîïðNOtuá
½¾\°±¼½/01÷÷îîééçéÚÚééé˼éééééé$
& F^a$gd
`¡$
& F^a$gd
`¡ $O±÷^O`±÷a$ $a$$Ð^Ða$$
& Fa$1234OPQ×ØÙûüýWX³´ úúúøööÒÐÐÐööËöÐÐÆöö $a$$a$ # $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ $a$µ
d e f g ¡¡ ¡#¡%¡&¡¹¡º¡»¡¼¡¢¢¢¢D¢l¢=¥R¥S¥g¥d¨¨ª8ª¤®¹®ó¯°^°_°`°´°µ°¶°·°\²f²º²üôæôÜüÒÍÒ¾Òͳ®§®³ÍüôüôôüÍüÍüÍüÍüÍüÍüÍüôüô}ôüÍüj|L
hÕ1 UmHnHuj'
hÕ1 UmHnHujhÕ1 UmHnHu hÕ1 5 hÕ1 jhÕ1 5U j!
hÕ1 5UmHnHu hÕ1 5jhÕ1 5UjhÕ1 0J UjQt hÕ1 UmHnHujhÕ1 UhÕ1 1 ¹¡º¡¢¢?¢@¢7¥8¥9¥^¨_¨`¨!®"® ¯ ¯^°¸°¹°5²ØÓÎÓÓÓÆÓÓÆÓÓÆÀÓÀ·®À· $
Æ9r a$ $
Æ9r a$
Æ9r $
& Fta$$a$$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$5²6²¡²¢²³³³³³ ³Ï³Ð³*µ+µ¶¶···À·Á·¸¸2¸3¸¸¸ùðððùëëéçåçëëëëëççççççççàç$a$$a$ $
Æ9r a$
Æ9r º²Á²ñ²ü²³³¶¶·À·Á·Â·¸¸¸¸¸2¸3¸4¸¸
¸¸¸¸³¸s¹ ¹;»*Ujl× hÕ1 U hÕ1 5jìÑ hÕ1 5U hÕ1 >* hÕ1 6hÕ1 jàðhÕ1 8'IJawØØ®Z*$
& F $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$*$
& F $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$*$
& F
$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$ª«¬ãäæçèóô#$34Õ®©©©©©©§§§§§$If
& F$If$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$*$
& F
$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$45CDEWXYjkÊÀº
ÀºPÀº4kdúç $$Ifl þÖ3"¦!öÖÿÖÿ Öÿ Öÿ4Ö
laöù4kdç $$Ifl þÖ3"¦!öÖÿÖÿ Öÿ Öÿ4Ö
laöù$If
& F$If4kd*jr hÕ1 5>*UhÕ1 5CJOJ
QJ
hÕ1 hÕ1 mH sH hÕ1 hÕ1 5CJmH sH #hÕ1 hÕ1 5CJOJ
QJ
mH sH jÆè hÕ1 U hÕ1 >*hÕ1 OJ
QJ
j]ðhÕ1 5OJ
QJ
j[ðhÕ1 5OJ
QJ
hÕ1 5hÕ1 5OJ
QJ
hÕ1
hÕ1 5CJ,g ~ ´ µ ê
}~²ñ*+IhÕÕÐÈÀÕÕÀ³ÀÈÐÕÕÕÐÈÀÕÕ $û^`ûa$$
& Fa$$
& Fa$$a$*$
& F$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$hi´¶·67Pbc¬¶úúúúúúòúæÝúòú××××××××$If$h^ha$ $
& Fh^ha$$
& FPQ£~~u~~$h`ha$ $
& Fh^ha$$
& F?@ñòóóóêêâÝóóóÝÝÐÃ
$@ÿ$If]@ÿa$ $[][^a$$a$$
& F=a$$ ^ a$ $
& F^a$¨ªû-=@Añòóôö÷GHIJ©ª«¬ë* + , 5 6 > G R S T U ¶ è
õñßÔñÌñ̾Ìñ´ñ´ñÌñ̦Ìñ´ñ´ñÔññññß~rõñßÔñhÕ1 hÕ1 5mH sH hÕ1 hÕ1 5OJ
QJ
mH sH hÕ1 6 hÕ1 5 hÕ1 5>*
hÕ1 5CJj{ hÕ1 UmHnHuhÕ1 CJOJQJj² hÕ1 UmHnHujhÕ1 UhÕ1 5CJOJ
QJ
#hÕ1 hÕ1 5CJOJ
QJ
mH sH hÕ1 hÕ1 hÕ1 mH sH +òóôõö£:1$@ÿ]@ÿa$[kdÔ $$IflÖôÖ ÿÿÿÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿ Öÿÿÿÿ4Ö
laö
$@ÿ$If]@ÿa$[kd- $$IflÖôÖ ÿÿÿÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿ Öÿÿÿÿ4Ö
laöö©ª«¬òåå-[kd" $$IflÖôÖ ÿÿÿÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿ Öÿÿÿÿ4Ö
laö[kdö! $$IflÖôÖ ÿÿÿÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿ Öÿÿÿÿ4Ö
laö
$@ÿ$If]@ÿa$ $[ ][^ a$®êëþ + , 6 å æ 2 T U µ ¶ × è
öîéààààØØàîéààéîéàààé$
& Fa$$ ^ a$$a$$
& F=a$$@ÿ]@ÿa$ % & + ? A B C !.!±!º!ß!ø!M""À"Á"Â"###e#f#g#h#{$|$À$Á${%%%%6&a&c&m&×& ' 'ôíàÛÓÛàíÏÊÏÊÏÊϸÏÏ|ÏuÏuÏÏÏÏÊϸjhÕ1 hÕ1 mH sH
hÕ1 5CJj!1 hÕ1 UmHnHujhÕ1 U hÕ1 5jÑ( hÕ1 UjhÕ1 UmHnHuhÕ1 5CJOJ
QJ
#hÕ1 hÕ1 5CJOJ
QJ
mH sH hÕ1 >*hÕ1 hÕ1 5>* hÕ1 jhÕ1 5>*U hÕ1 5>*jD# hÕ1 5>*U) C û!ü!M"n""À"Ã"Ä"Å"õ"####z${$ØØÓÏÆÆ»ÓÓÓÓ¹ÓÓØØØ
$ ¤P^ a$$ ^ a$ ¤P$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a${$À$ë$ì$í$
%%æ%ç%ÕÕ®®[[®.$nû$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ^n`ûa$# $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ &$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$*$
& F9$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$ç%6&a$$ ^ a$$a$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$# $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ''ë'í'÷'ÿ(4)8)9)V)Z)w)x)y)Ì)Í)Î)Ï)Ñ)ó)÷) */*K*N*~**ý* +#+%+T+q+Æ+í+ð+,/.7..·.¸.È.É.ê.ë.ì.J/b/c/s/t//// 0[0^0×0üêßØüÓÌüÓÌüÓÄüĶÄÓüÓü±üÓü±ü±üÓü±ü±üÓü±üê£ê£êßüê£ê£êßüêßühÕ1 hÕ1 5mH sH hÕ1 hÕ1 5CJmH sH hÕ1 >*jª8 hÕ1 UmHnHujhÕ1 U
hÕ1 5CJ hÕ1 5 hÕ1 5>*hÕ1 hÕ1 mH sH #hÕ1 hÕ1 5CJOJ
QJ
mH sH hÕ1 :'¿'Ð'ë'ì'í'÷'ø'ý(þ(ÿ()
)óóóîîååååÜÓÓ $$Ifa$ $$Ifa$$^a$$a$ $
& F^a$
))4)6)8)vmm $$Ifa$ $$Ifa$kd£6 $$IflÖÖF¯FÐY Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laö8)9)V)X)Z)vmm $$Ifa$ $$Ifa$kdP7 $$IflÖÖF¯FÐY Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöZ)[)\)u)v)w)x)ò)ó)}{vvOOO&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$a$kdý7 $$IflÖÖF¯FÐY Ö0ÿÿÿÿÿÿöÖ ÿÿÿÖ ÿÿÿ Ö ÿÿÿ Ö ÿÿÿ4Ö
laöó) * *J*K*]*^*"+#+4+ÕªªªÕªwªÕ2$
ƪÀªVþ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ^ª`Vþa$*$h$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ `ha$*$
& F:$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$ 4+5+ï+ð+,,- -k---¬---...Ø¥ØØØØØ{{{{ØØØ*$
& F;$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$2$
ƪÀªVþ$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ ^ª`Vþa$&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$../.8.9...¸.É.ë.ì.I/J/c/t////
0 0/0@0\0]0^0úñúéáÕÕÕúÌúÕÕÕúúéúÕÕÕúú$^a$ $
& F^a$$
& Fa$$
& F?a$$ ^ a$$a$^0Ö0×0û0 1;1 hÕ1 UmHnHujhÕ1 U hÕ1 5 hÕ1 5>*hÕ1 hÕ1 mH sH hÕ1 hÕ1 5mH sH hÕ1 hÕ1 5CJmH sH #hÕ1 hÕ1 5CJOJ
QJ
mH sH hÕ1
hÕ1 5CJhÕ1 5CJOJ
QJ
4ê2 3 3 33 3³3Ñ3ü3þ34 4¸6¹6º65767?7P7óîîæÞóóóî°°°°îæîóó.$
& F$d%d&d'dNÆÿOÆÿPÆÿQÆÿ^a$$
& Fa$$
& F?a$$a$ $
& F^a$P777,8-8.8/808188ïêáÔÔj]U$
& F?a$ $
ÆïÀ^a$4kdÿE $$IflôÖ ¬ öÖÿÖÿ Öÿ Öÿ4Ö
laö4kd§E $$IflôÖ ¬ öÖÿÖÿ Öÿ Öÿ4Ö
laö
$
ÆïÀ$Ifa$$^a$$a$$
& Fá:ý^á`:ýa$ 88¾8Ï899;9L999@:s:Â:
;N;;¬;hU|}ÐÑÒÓ}èé _`abdeµ¶·¸»ôReùôðåÓÈÓÈ·Èùðôð¨ð ð ðÓÈð ð ðzôzkzôðÈÓ¨ jk
hÕ1 5UmHnHujhÕ1 5Uj5b
hÕ1 UmHnHujÜX
hÕ1 UmHnHujhÕ1 U hÕ1 5CJOJ QJ mH sH hÕ1 hÕ1 CJOJQJmH sH hÕ1 hÕ1 mH sH #hÕ1 hÕ1 5CJOJ QJ mH sH hÕ1 5CJOJ QJ hÕ1 hÕ1 5 hÕ1 5>*)ø| }},}-}.}H}X}Y}Z}[}õõõïõõõï lkdW
$$IflÖÖ0 F¦"*`Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö $If
h$If^h
[}\}]}g} ~2~3~34îï4£¡}}{¡¡¡¡¡¡¡uÐ^Ð# $d%d&d'dNÆÿOÆÿPÆÿQÆÿ [kd5X
$$IflÖÖã"ã"ÿÿÿÿÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿÿÿÿ Öÿ Öÿÿÿÿ4Ö
laöl
4CVW{|ÔÕ|}¬»Íèé
cdÿ/>Refùù÷ñ÷è÷÷÷ùùùù÷â÷â÷÷÷ùùùùÜ $If Ð^Ð $Ð^Ða$ Ð`Ð Ð^ÐefghijklnoÂÃÄÅÇØã
N
W
X
¡
¢
¿
À
PQSWa5¤©VÜáF` »À2JNöòöòöòöòêòêÜêò×ò×òÐòÅòžžŵªò¥òòyòyò hÕ1 5CJOJ QJ mH sH hÕ1 hÕ1 mH sH #hÕ1 hÕ1 5CJOJ QJ mH sH hÕ1 >*hÕ1 5CJOJQJhÕ1 5OJ
QJ
hÕ1 5CJhÕ1 5CJOJ
QJ
hÕ1 5>* hÕ1 5jât
hÕ1 UmHnHujhÕ1 UhÕ1 hÕ1 CJOJQJ/fghij£A[kd&s
$$IflÖÖÿÇ!3"ÿÿÿÿÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿ Öÿÿÿÿ Öÿ4Ö
laö $If[kdr
$$IflÖÖÿÇ!3"Ö0ÿÿÿÿÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laöjklmn£A? [kdNt
$$IflÖÖÿÇ!3"ÿÿÿÿÖ0ÿÿÿÿÿÿöÖÿÿÿÿÖÿ Öÿ Öÿ4Ö
laö $If[kdºs
$$IflÖÖÿÇ!3"Ö0ÿÿÿÿÿÿöÖÿÖÿ Öÿ Öÿ4Ö
laönØÙ´µM
N
W
X
¢
À
å
TUVÛÛÛÛÛÛÛÛ´´´Û & $$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$'
& F$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ # $d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ VWab45hw¤¥¨©Õä÷UV¯ÂÜÝýýýøýòòòòýìýòòòòýýýøýòòòòòý Ð^ÐÐ^Ð
& FK Ýàá
3F`abc >Mo»¼¿ÀÛê 2Jù÷ñññññ÷÷÷ì÷ññññññ÷ù÷ññññññ
& FKÐ^Ð Ð^ÐJKLMNÆÇÈÓÔGH½¾âã8ýûûûûûûùûôôôôôôôôìàØôØàÐ$
& Fa$$
& Fa$ $
& FÐ^Ða$$
& Fa$$a$ NO ¡¢£ÅÔÕ%&'()G½âã89]dhr-/0
¥åïñÃó/M!%°±ÏÓ¡¡öñöâöñÛ×öñöÈöñÁ×¹×Ûׯׯׯׯתת×ñöñööñÁ×ñ×ñ×Ûת××××ñhÕ1 OJQJ hÕ1 >* já
hÕ1 5UmHnHu hÕ1 6hÕ1 CJOJ
QJ
jZ
hÕ1 U
hÕ1 >*CJ jß
hÕ1 5UmHnHuhÕ1 hÕ1 5>* jdz
hÕ1 5UmHnHu hÕ1 5jhÕ1 5U889¹ºÀÎ×Ûåêì÷ïãÛ÷ÕÕÕÕÕÕÕ$If$
& Fa$ $
& FÐ^Ða$$
& Fa$$
& Fa$ ìíî3.&.$
& Fa$$a$Ëkd-
$$IflÖ Ö n ÎDÿ Æ!R¥»»»»ÇÖ0ÿ ÿ ÿ ÿ ÿÿöÖ ÿÿÿÿÿÿÿÖ ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ Ö ÿÿÿÿÿÿÿ4Ö
laö$-1;*hÕ1 hÕ1 mH sH #hÕ1 hÕ1 5CJOJ QJ mH sH hÕ1 5CJOJ QJ mH sH 4¸÷øøø ø øøøøøÀøÁøÊøËøðøñøKùLùMùõóóÏÏÏóóóÍÃóó½ó¸óó$a$
Æ9r ^`#$d%d&d'dNÆÿOÆÿPÆÿQÆÿ ¡ $÷^¡ `$÷MùXùYùbùkùuù~ùÏÍÄÄÄÄ $$Ifa$0}$d %d &d 'd -DMÆ
ÿÿÿNÆÿ OÆÿ PÆÿ QÆÿ ]}~ùùùùùùúBúUúZúfúF@@@@@@$If¸kd®_$$IflÖ ÖÿáOK
¬ MÿÿÿÿnÿÿÿÿüÿÿÿÿNÿÿÿÿnÿÿÿÿ¥ÿÿÿÿÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÖÿÿÿÿÿÿ Öÿÿÿÿÿÿ Öÿÿÿÿÿÿ4Ö
laöfúgúiúpúvúúúúF@@@@@@$If¸kd¦`$$IflÖ ÖÿáOK
¬ MÿÿÿÿnÿÿÿÿüÿÿÿÿNÿÿÿÿnÿÿÿÿ¥ÿÿÿÿÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÖÿÿÿÿÿÿ Öÿÿÿÿÿÿ Öÿÿÿÿÿÿ4Ö
laöúúúúFDD¸kda$$IflÖ ÖÿáOK
¬ MnüNn¥Ö0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÿÿÿÿÖÿÿÿÿÿÿ Öÿÿÿÿÿÿ Öÿÿÿÿÿÿ4Ö
laöú©úªú³ú¾úÄúÐúÏÉÀÀÀÀ $$Ifa$.].0ï$d %d &d 'd -DMÆ
ÿÿÿNÆÿ OÆÿ PÆÿ QÆÿ ]ïÐúÑúÔúâúçúòú*mH sH jhÕ1 UmHnHujhÕ1 UmH sH hÕ1 mH sH
hÕ1 >*CJ jhÕ1 5UmHnHu j"}hÕ1 5UmHnHu hÕ1 >* hÕ1 5>* j§uhÕ1 5UmHnHuhÕ1 j,nhÕ1 5UmHnHu hÕ1 5jhÕ1 5U*q
xy ij ¡ùúûõõóóóñóóóïóóóêóóÆÆ#$d%d&d'dNÆÿOÆÿPÆÿQÆÿ$a$ ^`ENR\ÎÝdèí·ÂÆÏÒ;'?'@'h'i'S(T(®(¯(M)N)Ä)Å)ýýðýýýëëëãýýýýýÛýÖýÛýÛý
& Fc$
& Fca$$
& Ffa$
& Ff $^`a$Å)â)ç)è)ò)ö)ñàYñàkdë$$IflÖ Ö0ªJ
Á ÖÖÿÿÿÿÿÿÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöpÖÿÿÿÿÿÿ $$If^`a$ $If^`ö)÷)**s $$If^`a$ $If^`lkdwì$$IflÖ Ö0ªJ
ÿÿÿÿÁÿÿÿÿÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÿÿÿÿÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö****s $$If^`a$ $If^`lkd í$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö** *!*s $$If^`a$ $If^`lkd³í$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö!*"*)*-*s $$If^`a$ $If^`lkdJî$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö-*.*5*9*s $$If^`a$ $If^`lkdáî$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö9*:*A*E*s $$If^`a$ $If^`lkdxï$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöE*F*G*
**>+?+x,y,!-"-- -y.z.yyyyy$
& Fca$
& Fc ^`lkdð$$IflÖ Ö0ªJ
ÁÖ0ÿ ÿ ÿ ÿ ÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöz.¬//00000000 1 1_1`1b1c1d1o1p1 2¬35)6÷ò÷ð÷æÜðððÜðððÏððððÇÇÇÇ$
& Fda$ $^`a$ ^`
Æ/ Ð^Ð$a$$
& Fca$è0é0ê0ë0 1`1a1c1d1o1p1 1¨1¾1Ê1ô1ý1V2^2ø2ÿ23 353B3 4(4*42464>4h4t4 5&525?5C5O5+6T6´6µ6±7´7ÞAìAIBJBTBUB'E* hÕ1 H* hÕ1 6 hÕ1 5>*hÕ1 mHnHuj!øhÕ1 5UhÕ1
hÕ1 >*CJ hÕ1 5jhÕ1 5U j¦ðhÕ1 5UmHnHu7)6*6+6T6U6´6µ6Q7R7@8A8z9{9ù:ú:
ß?ßqߣßÊßËßÌßÍßüßýß3á5á6árásáªáüáúúúúøúöúúúúúîîîúúúøúúúúúúîî$
& F~a$ $a$üáââIâââãã>äÆäÇäØåÙåææ¶æ·æãæç ç?ç¥ç÷õóñõõõÊÈõÆõÆõõõÁ»»Á»h^h
& F )&$$d %d &d 'd NÆÿ OÆÿ PÆÿ QÆÿ a$$
& F~a$qârâwâââââ¨âÚâîâããdãeãfãgãhããããoääæ·æºæÍæ ç#çÊçãçèÉèóè éééléménéoéééêêYêZê[ê\êøêùêMëNëOëPë}ëöñêñöæáæáæÙæÙËÙæÆæÆæÆæáæÆæÆæÆæáæ½æÙæÙ¯Ùæ¥æÙæÙÙæÙæÙÙæjxëhÕ1 UmHnHuj¶hÕ1 UmHnHujhÕ1 0J UjÀhÕ1 UmHnHuhÕ1 5OJQJ hÕ1 5j¬hÕ1 UmHnHujhÕ1 U hÕ1 >*hÕ1 hÕ1 5 hÕ1 jhÕ1 U6¥ç¦çèèèèñèòèóèûè é
éépéúúúúúúøøòò
ss$
Æ9r ¤x¤x$Ifa$lkd.$$IflÖÖ0ÿ½ ¬ )
ïÖ0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö$If$a$
péqé
éªéÔéðéñéóéê]ê^ê_êsêùïïïïssùùi
& F
$If
$¤x¤x$Ifa$lkd¶$$IflÖÖ0ÿ½ ¬ )
ïÖ0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö
& F$If$If sêêÁêÜêÝêøêQëRëSëgëëÉëàëõõõ{{uukkkk
& F$If$If
$¤x¤x$Ifa$lkdæê$$IflÖÖ0ÿ½ ¬ )
ïÖ0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö
& F
$If }ëëæëçë;ìì^ìì×ìØì,í-í.í/ídí
íûílïðGòIòNòfòjòªòòÛòßò6ó:ówó{óéóíó^ôbôô³ô·ôMõQõqõ¢õ¦õúõÿõcöhöÏöÔöT÷Y÷øøªø¯øù0ù1ùöòêòêÜêòöòêòêÎêòöòÈòÈòÂò½ò¸ò½ò½ò½ò½ò½ò½ò½ò½ò½½ò½ò½ò½ò½ò¥jhÕ1 OJ QJ UhÕ1 OJ QJ hÕ1 hÕ1 mH sH hÕ1 H* hÕ1 5
hÕ1 CJ0
hÕ1 CJjkhÕ1 UmHnHujÈhÕ1 UmHnHujhÕ1 UhÕ1 hÕ1 mHnHu$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöèóéóíóîóô3ôHô\ô]ô
t
Æ9r $If$If
$¤x¤x$Ifa$lkdÖ$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö]ô^ôbôcôkôôô±ô²ô
$If
$¤x¤x$Ifa$lkdn$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö²ô³ô·ô¸ôÄôòôõKõLõ
$If
$¤x¤x$Ifa$lkd$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöLõMõQõRõ^õqõõõõ
$If
$¤x¤x$Ifa$lkd$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöõ õ¢õ¦õ§õ´õÉõäõøõùõ}}}}}}$If
$¤x¤x$Ifa$lkd6$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö ùõúõÿõö ö>öMöaöbö
$If
$¤x¤x$Ifa$lkdÎ$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöböcöhöiönööÍöÎö
$If
$¤x¤x$Ifa$lkdf$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöÎöÏöÔöÕößö0÷A÷R÷S÷
$If
$¤x¤x$Ifa$lkdþ$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöS÷T÷Y÷Z÷r÷øø
$If
$¤x¤x$Ifa$lkd$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöøøøø øø¨ø©ø
$If
$¤x¤x$Ifa$lkd.$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö©øªø¯ø°øÈøïøðø
$If
$¤x¤x$Ifa$lkdÆ$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laöðøñøòøóøùù/ù0ù`ùaùùù½ù¾ùùùúù8úlkd^$$IflÖÖ0ÿáÈ!Mç Ö0ÿÿÿÿÿÿöÖÿÿÖÿÿ Öÿÿ Öÿÿ4Ö
laö1ùPùQùRù^ù_ùúùûù!ú"ú#ú6ú7úYúZú{ú|ú}úúúúú³ú´úµúÆúÇúÈúÒúÓúèúéúêúëúìúûûûxûyûzû£ý¤ý¥ýøéÝÓÝøÝøÄÝÓÝøÝøµÝÓÝøÝø¦ÝÓÝø¢¢wwww hÕ1 5OJQJmHnHuhÕ1 5mHnHuhÕ1 mHnHujhÕ1 UhÕ1 jChÕ1 OJ QJ U jhÕ1 OJ QJ U j¯hÕ1 OJ QJ UhÕ1 0J7OJ QJ jhÕ1 OJ QJ U jöhÕ1 OJ QJ UhÕ1 OJ QJ +8ú9úXúYúúúÈúÉúÊúËúÒúêúìúûûû2ûJûbûxûzûû¬û¿ûëûü,üOüýýýýýýýýøöýïééïééééïééééééé-
ÆÊ6$
ÆÊ
& FOüfüyüü»üäü ý3ýRýnýý£ý¥ý±ýÂýÎýâýäýïýþþþ4þNþPþkþmþþùùùùùùùùùùùòùùùùòùùòùùùòùòù6$
ÆÊ-
ÆÊ¥ý«ý±ý¼ýâýãýäýþþþNþOþPþkþlþmþ·þ¸þ¹þ&ÿ'ÿ(ÿ6ÿ7ÿ8ÿÿÿÿYf£¤¥ÃÄÅúûüVWX{|}WXY²³´ùúû"()*VWXY·¸äï òéòéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéòéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏéÞÏòéÞÏéÇùùùôà hÕ1 5jhÕ1 0J UhÕ1 jhÕ1 U hÕ1 5OJQJmHnHuhÕ1 5mHnHuhÕ1 mHnHuhÕ1 OJ
QJ
mHnHuGþþ¤þ·þ¹þÖþîþÿÿ&ÿ(ÿ6ÿ8ÿ]ÿzÿÿÿ¹ÿÔÿøÿ9Yl~£¥Ãùùùòìììììòìòìììòìììììììììòì-
ÆÊ6$
ÆÊ.
ÆÊÃÅàúü 8VXa{}²Îîü6NWYu«ÅÑøòòøòòòòøòòøòòòòòòòòòòøòòòòò-
ÆÊ6$
ÆÊ Ñ .Y²´Ääùû(*=UVX· 3uµ(
P(
ùùùùùùòùùùòùòùòùùððîîîîîîîî 6$
ÆÊ-
ÆÊ 34uvµ¶(
(
(
P(
Q(
(
(
²(
³(
Ø(
Ù(
:)
;)
À)
Á)
*
*
d*
e*
Á*
Â*
+
+
+
+
ö+
÷+
N,
O,
P,
R,
S,
U,
V,
X,
Y,
[,
],
`,
a,
b,
c,
d,
e,
,
,
,
,
,
,
,
,
õñõñõñõñïñõñõñõñõñõñõñõñõñõñõñõñõñõñëãëãëãëãëÝñÕËÃËñ¹«Õñ«Õ¹jhÕ1 0JCJUjhÕ1 UmHnHuhÕ1 CJmH sH hÕ1 0JCJhÕ1 CJmH sH hÕ1 mH sH
hÕ1 CJjh
`¡Uh
`¡UhÕ1 jhÕ1 0J U< Inc. ISBN 2-87691-321-6
un terminal est incapable d'afficher des graphiques
par plate-forme, on entend l'ordinateur sur lequel est exécuté le SGBD
plus facile à utiliser
par exemple SQL (voir chapitre 7.2)
pour une clé primaire composée de plusieurs champs, la combinaison des valeurs doit être unique
Pour la plupart des SGBD, ceci est fait de façon automatique lors de la définition d'un ou de plusieurs champs comme clé primaire .
programme de gestion des fichiers sous Windows 95 et Windows NT
personne (informaticien) responsable de la gestion du serveur, du SGBD sur le serveur et des BD
nom utilisateur & mot de passe à l'aide duquel un utilisateur peut s'identifier au système
terme généralisé pour une requête de sélection stockée et réaffichable
programme affichant une animation à l'écran, qui s'exécute automatiquement après un nombre prédéfini de minutes sans activité de l'utilisateur
une requête n'est exécutée qu'au moment où la requête précédente a terminé son exécution
1KB = 1Kilobyte = 1024 Byte / 1MB = 1 Megabyte = 1024KB / 1GB = 1Gigabyte = 1024MB
Modélisation d'un système d'information
PAGE 154
Exploitation des bases de données relationnelles
Exploitation des bases de données relationnelles
PAGE 198
Protection des données
Informatique 13CG Annexes
Système d'information
Informations entrantes
Informations sortantes
Cardinalité minimale
Patte
Cardinalité maximale
Propriété
Relation
Entité
Champ à valeur calculée
tblComptes
tblClients
Analyse
Réseau public
Serveur dédié
Poste de travail
En-tête
Détail
Pied
BD
L'utilisateur de la requête indique ensuite une date dans la boîte de dialogue et sélectionne le bouton OK
Finalement la requête est exécutée avec comme date la valeur entrée par l'utilisateur.
Code
L-XXXX
Clé primaire
Si le nom du champ à valeur calculée contient des espaces, on doit l'entourer d'apostrophes.
p.ex. ... AS 'Prix TTC'
Lettres majuscules
Un champ de données
Un enregistrement
MPD
MLD
MCD
Champ à valeur calculée
