Module D318 Méthodologies Bases de Données Relationnelles

Transcription

1 Module D318 Méthodologies Bases de Données Relationnelles 1 - Définition et historique 2 - Dépendance fonctionnelle 3 - Modèle Relationnel 4 - SQL Bibliographie Exercices Solution des Exercices Gérard-Michel Cochard cochard@u-picardie.fr

2 Bases de Données Relationnelles Définition et historique Comme on le verra plus loin, la séparation des données et des traitements dans la conception et le développement d'application a conduit au concept de base de données. On peut résumer ce qu'est une base de données en disant qu'il s'agit d'un "ensemble cohérent et structuré de données non redondantes". On pourrait ajouter qu'une base de données doit aussi être sécurisée sous deux aspects : en cas de destruction, on doit pouvoir récupérer les informations, ce qui entraîne la nécessité de sauvegardes régulières ; par ailleurs, les accès aux données de la base doivent être contrôlé ce qui entraîne l'octroi de droits limités aux usagers par l'administrateur de la base de données. Les premières bases de données ont été construites suivant le modèle hiérarchique qui correspond à une organisation arborescente des entités. exemple : Supposons qu'une maison de négoce en vins répertorie ses clients dans une base de données faisant apparaître les produits commercialisés (numéro de vin, type, millésime, ), et les clients (nom, prénom,) ainsi que les achats de ces clients : numéro de vin acheté, date d'achat, nombre de bouteilles. Le modèle hiérarchique peut correspondre au schéma ci-dessous dont quelques occurrences sont données ci-dessous : Sur cet exemple, on peut constater qu'il ne peut exister de feuille sans racine, mais que, par contre, il peut y

3 avoir des racines sans descendants (cas de Dubalai). Les recherches séquentielles dans une base de donnée de type hiérarchique s'effectuent en partant de la racine et en suivant un chemin comme indiqué sur le schéma ci-dessous : Mais une recherche directe sur critère peut être très différente suivant que l'objet de la recherche est près de la racine ou des feuilles. exemple : Supposons que l'on désire rechercher les vins acquis par le client "Dubois" Cette recherche se traduira par l'algorithme suivant : procédure recherche_vin("dubois") début TantQue il y a des vins sous "Dubois" faire Trouver n vin ; Imprimer n vin FinTantQue fin Si, par contre, on recherche les clients qui ont acheté le vin numéro "154", la requête est plus compliquée : procédure recherche_client ("154") début TantQue il y a des clients faire TantQue il y a des vins sous le client faire Lire numéro de vin sous le client Si numéro="154" alors imprimer le nom du client Fin Si FinTantQue FinTantQue fin Il est évident que la seconde requête est nettement plus longue que la première à cause de la structure hiérarchique. Le modèle réseau apporte une amélioration en "symétrisant" l'arborescence du modèle hiérarchique par adjonction du connecteur "date achat, nombre de bouteilles". Les associations entre l'entité VIN et le connecteur, d'une part, et entre l'entité CLIENT et le connecteur, d'autre part, correspondent à deux familles de pointeurs (organisés en boucles généralement comme indiqué ci-dessous).

4 exemple : modèle réseau appliqué à l'exemple précédent : Les deux requêtes précédentes s'expriment alors de la manière suivante : procédure recherche_vin("dubois") début Trouver client "Dubois" ; TantQue il y a des connecteurs faire Trouver le n vin associé au connecteur ; Imprimer n vin ; FinTantQue fin procédure recherche_client("154") début Trouver le vin numéro "154"; TantQue il y a des connecteurs sous ce vin faire Trouver nom du client associé au connecteur ; Imprimer nom du client ; FinTantQue fin On notera la symétrie de ces deux requêtes. On notera aussi les nombreux pointeurs nécessaires à l'implémentation de la base de données réseau ce qui rend la mise à jour assez lourde (gestion de nombreux pointeurs). Les modèles de base de données hiérarchique et réseaux sont maintenant abandonnés au profit du modèle relationnel que nous allons expliciter en détail plus bas. Il faut aussi noter que de nos jours sont apparus d'autres modèles de base de données, le plus connu étant le modèle objet qui souffre encore d'un défaut de normalisation et que nous étudierons plus loin.

5 Dépendance fonctionnelle Relation Pour introduire la notion de dépendance fonctionnelle, qui est à la base du modèle relationnel, considérons l'exemple introductif suivant : exemple :Les vins de Bordeaux peuvent être caractérisés par trois propriétés : le nom du vin (nomvin), l'appellation (appellation) et l'année de production ou millésime (millésime). En ne considérant ici que les vins d'appellation contrôlée (AOC), rappelons qu'un tel vin appartient à une région de Bordeaux spécifique et délimitée qui justifie l'appellation. Soit A, l'ensemble des valeurs prises par la variable nomvin A = {..., Chateau Lafite, Chateau Latour, Chateau Yquem, Chateau La Gaffelière,...} Soit B, l'ensemble des valeurs de la variable appellation B = {..., Pauillac, Margaux, Sauternes, Graves, St Emilion,...} Soit C, l'ensemble des valeurs de la variable millésime C = {..., 1915, 1929, 1958, 1982, 1988, 1996,...} Effectuons le produit cartésien des trois ensembles A, B, C : AxBxC = {... ; Chateau Lafite, Pauillac, 1929 ; Chateau Lafite, Sauternes, 1958 ; Chateau Latour, Margaux, 1982 ; Chateau Latour, St Emilion, 1929 ; Chateau Yquem, Graves, 1988 ; Chateau La Gaffelière, Graves, 1915 ; Chateau Latour, Pauillac, 1988 ; Chateau Latour, Sauternes, 1982 ;...} Ce nouvel ensemble contient des triplets qui sont des valeurs de (nomvin, appellation, millésime) ; certains de ces triplets n'ont aucun sens. Ainsi (Chateau Latour,St Emilion, 1929) ne correspond à rien puisque le vin Chateau Latour étant un Pauillac ne peut être un St Emilion. Si on se restreint à l'ensemble des triplets qui ont un sens, une signification, une existence, on obtient une relation R, sous ensemble de AxBxC : R = {... ; Chateau Lafite, Pauillac, 1929 ; Chateau Lafite, Pauillac, 1958 ; Chateau Lafite, Pauillac, 1982 ; Chateau Lafite, Pauillac, 1988; Chateau Latour, Pauillac, 1929 ; Chateau Latour, Pauillac, 1958 ; Chateau Latour, Pauillac, 1982; Chateau Latour, Pauillac, 1988 ; Chateau Yquem, Sauternes, 1929 ; Chateau Yquem, Sauternes, 1958 ; Chateau Yquem, Sauternes, 1982 ; Chateau Yquem, Sauternes, 1988 ; Chateau La Gaffelière, St Emilion, 1929 ; Chateau La Gaffelière, St Emilion, 1958 ; Chateau La Gaffelière, St Emilion, 1982 ; Chateau La Gaffelière, St Emilion, 1988 ;...} En résumé, la relation R s'écrit, sous forme générique : R = (nomvin, appellation, millésime) où nomvin, appellation, millésime sont des attributs. En extension, la relation R peut s'exprimer comme ci-dessus avec des accolades, mais il est plus lisible de l'exprimer sous forme d'une table (d'ailleurs, on confond souvent relation et table) :

6 Une ligne d'une table, qui correspond à un multiplet spécifique est appelée un tuple dans le modèle relationnel. Un tuple correspond, en quelque sorte à un enregistrement de fichier et la table est assimilable à un fichier dont les attributs seraient les champs. Dépendance fonctionnelle On dit que deux attributs a et b d'une relation R sont liés par une dépendance fonctionnelle (DF) et on note : a > b si à une valeur de a correspond au plus une valeur de b. On peut distinguer une DF forte (chaque valeur de a correspond à une valeur unique de b) d'une DF faible (il y a des valeurs de a qui n'ont pas de correspondants en b). exemple : les vins de Bordeaux. Il y a une DF forte entre nomvin et appellation nomvin > appellation

7 exemple : Imaginons une commande d'articles. Un article peut être caractérisé par un numéro (numart), un nom (nomart) ; une commande est caractérisée par un numéro de commande (numcom), une date de commande (datcom) ; pour chaque article commandé, sa quantité (qtecom) est précisée. On peut distinguer les DF suivantes : DF forte : numcom > datcom DF forte : numart > nomart DF faible : numcom, numart > qtecom numcom définit de manière unique une commande, il ne lui correspond donc qu'une date unique (et il y a une date sur chaque commande) ; numart est l'identifiant de l'article, donc il lui correspond un nom unique nomart (et chaque article a un nom) ; le tandem numcom, numart peut correspondre à un article commandé et dans ce cas il lui correspond une quantité commandée qtecom mais il peut aussi ne correspondre à rien (simple juxtaposition de numcom et de numart). Il est souvent utile de représenter les dépendances fonctionnelles par un graphe appelé graphe des dépendances fonctionnelles : Dépendance fonctionnelle élémentaire Une dépendance fonctionnelle a,b > c est élémentaire s'il n'y a pas de dépendance fonctionnelle entre a et c et entre b et c. exemple : commande d'articles : numcom,numart > qtecom est une DF élémentaire car numcom >qtecom n'a pas de sens (une quantité d'article n'a rien à voir avec un numéro de commande) et numart >qtecom n'a pas de sens non plus (une quantité d'article n'a rien à voir avec le numéro de l'article) ; par contre l'association numcom, numart peut correspondre à un article commandé et dans ce cas qtecom est la quantité d'article commandé. exemple : vins de Bordeaux : nomvin, millésime > appellation n'est pas une DF élémentaire car nomvin > appellation est une DF. Dépendance fonctionnelle directe Une dépendance fonctionnelle a >b est directe s'il n'existe pas d'attribut c tel que a >c et c >b. exemple : commande d'article par des clients. Rajoutons les attributs numcli (numéro de client) et nomcli (nom de client).le graphe des dépendances fonctionnelle est :

8 Une commande étant pour un client unique, on a la DF numcom ----->numcli mais aussi numcom -----> nomcli ; le numéro de client permettant de définir parfaitement le client, on a la DF numcli > nomcli ; on voit ici que la DF numcom > nomcli n'est pas une dépendance fonctionnelle directe puisque il existe numcli tel que numcom > numcli et numcli > nomcli. Clé Dans l'étude des relations, on se borne à considérer les dépendances fonctionnelles qui sont élémentaires et directes. Par la suite, le signe > désignera uniquement les DF élémentaires directes. Dans une relation R, un attribut a est une clé si, pour tout attribut x de R, a >x est une DF élémentaire directe. Signalons que a peut être un attribut simple ou un ensemble d'attributs. exemple : vins de Bordeaux. Considérons les relations suivantes : R1 (nomvin, appellation, millésime) R2 (nomvin, appellation) R1 n'a pas de clé et R2 possède la clé nomvin, puisque nomvin >appellation. On souligne usuellement la clé d'une relation : R2 (nomvin, appellation) exemple : commande d'articles par des clients. Considérons les relations R3 (numcom, numcli, nomcli, datcom) R4 (numcom, numart, qtecom) numcom est une clé de R3, car numcom > numcli, numcom >nomcli, numcom >datcom. numcom,numart est une clé (composite) de R4 puisque numcom,numart >qtecom. On a donc R3 (numcom, numcli, nomcli, datcom) et R4 (numcom, numart, qtecom). Modèle relationnel Le modèle relationnel des bases de données consiste à définir la base de données comme une collection de relations obéissant chacune à une condition de normalisation. Cette condition est que dans une relation, les seules dépendances fonctionnelles qui doivent exister sont celles qui relient la clé (donc il doit y en avoir une) aux autres attributs. Une telle relation est dite normalisée.

9 exemple : commande d'articles par des clients. Soit les relations R3 (numcom, numcli, nomcli, datcom) R4 (numcom, numart, qtecom) R5 (numart, nomart) Ces trois relations définissent-elles une base relationnelle? Il faut,pour cela examiner si chaque relation est normalisée. On constate que R4 et R5 le sont, mais pas R3 puisque on a la DF numcli >nomcli où numcli n'est pas une clé. On trouve assez simplement les relations normalisées en traçant le graphe des dépendances fonctionnelles en ne prenant en compte que les DF élémentaires directes et en recherchant, pour chaque source d'une DF, les cibles. exemple : commande d'articles par des clients. Le graphe des dépendances fonctionnelles (élémentaires et directes) fait apparaître les diverses relations normalisées : On a donc la base de données relationnelles suivante : CLIENT(numcli, nomcli) COMMANDE (numcom, datcom, #numcli) LIGNE_COMMANDE (numcom, numart, qtecom) ARTICLE (numart, nomart) On notera, dans la relation COMMANDE, l'attribut #numcli. Le signe # signifie simplement que numcli est une clé externe, c'est à dire une clé d'une autre relation. exemple : considérons un exemple plus complexe. Une entreprise désire automatiser la gestion commerciale. Cette entreprise vend des produits définis par une référence unique (numart), une désignation (désignation), un prix de vente unitaire (pu). Les produits sont proposés par des représentants possédant un numéro matricule (numrep) et un nom (nomrep). Les représentants prospectent des régions caractérisées par un nom (nomreg) et un nombre d'habitants (nbh). Une commande porte un numéro (numcom), une date (datcom), et la liste des articles commandés par un client avec la quantité commandée (qtecom). Un client est référencé par un numéro (numcli) et possède un nom (nomcli), une adresse (adcli). Le modèle relationnel est aisément obtenu si on trace le graphe des dépendances fonctionnelles :

10 On en déduit immédiatement la base de données (avec les relations normalisées) : CLIENT (numcli,nomcli, adcli) COMMANDE (numcom, datcom, #numcli, #numrep) LIGNE_COMMANDE (numcom, numart, qtecom) PRODUIT (numart, designation, pu) REPRESENTANT (numrep, nomrep) REGION (nomreg, nbh) PROSPECTION (nomreg, numrep) On notera que la dernière relation ne comporte qu'une clé (double). Cette relation provient du fait qu'un représentant peut prospecter dans une région quelconque et qu'une région peut être prospectée par plusieurs représentants. SQL Le modèle relationnel possède un immense avantage, celui de posséder un langage d'interrogation de la base (appelé aussi langage de requêtes ou langage de manipulation de données), SQL, qui est normalisé. En SQL, une requête s'exprime sous la forme d'une phrase type : SELECT nom_attribut1, nom_attribut2, FROM nom_table WHERE <condition > ; nom_attribut1, nom_attribut2, sont les noms des attributs que l'on recherche ; nom_table est le nom de la table dans laquelle on recherche ; <condition> définit les critères de recherche. Le signe ";" indique la fin de la requête. exemple : Pour obtenir le nom du client qui possède un numéro de client égal à 1587 et qui est enregistré dans la table CLIENT, la requête SQL s'exprimera comme suit : SELECT nomclient FROM CLIENT WHERE numclient="1587" ;

11 Il est possible de faire des requêtes sur plusieurs tables et ceci de plusieurs manières comme l'illustre l'exemple suivant. exemple : Considérons la base de données relationnelle définie par les relations suivantes : VIN(numvin, type, mil) CLIENT(numclient, nomclient, prenomclient, adresse) ACHAT(numachat, da, nbout, #numvin, #numclient) Cette base de données concerne le négoce de vins. Considérons les deux requêtes suivantes : Rq1 : Rechercher les vins achetés par le client "Dubois" Rq2 : Rechercher les clients qui ont acheté le vin n 154 Ces requêtes s'exprimeront en SQL de la manière suivante : Rq1 : Rq2 : SELECT numvin FROM CLIENT, ACHAT WHERE (CLIENT.numclient=ACHAT.numclient) AND (CLIENT.nomclient="Dubois") ; SELECT nomclient FROM CLIENT, ACHAT WHERE (ACHAT.numvin="154") AND (ACHAT.numclient=CLIENT.numclient) On remarquera que lorsqu'un nom d'attribut est le même pour deux tables différentes, on fait précéder le nom de l'attribut par le nom de la table pour éviter toute ambiguïté. On notera également la possibilité d'exprimer des conditions avec des "ET" logiques (AND) ou "OU" logiques (OR). On aurait pu aussi obtenir le même résultat en exprimant les requêtes Rq1 et Rq2 sous forme de requêtes en cascade : Rq1 : Rq2 : SELECT numvin FROM ACHAT WHERE numclient IN (SELECT numclient FROM CLIENT WHERE nomclient="dubois") ; SELECT nomclient FROM CLIENT WHERE numclient IN (SELECT numclient FROM ACHAT WHERE numvin="154") ; Toutes les bases de données relationnelles offrent la possibilité d'effectuer des requêtes dans le langage SQL, mais la plupart d'entre elles offrent à l'utilisateur une interface graphique qui facilite beaucoup l'utilisation et qui évite l'écriture de requêtes en SQL. Toutefois la requête de l'utilisateur est traduite en SQL de manière automatique. Bibliographie

12 C.J.DATE An introduction to Database Systems Addison-Wesley G. GARDARIN Bases de données ; les systèmes et leurs langages Eyrolles G. GARDARIN, P. VALDURIEZ Bases de données relationnelles ; analyse et comparaison des systèmes Eyrolles G. GARDARIN Bases de données objet & relationnel Eyrolles

13 Bases de Données Relationnelles Exercices Exercice 1 Le métro de Budapest comporte 3 lignes qui se coupent toutes la station Déak tér. Les lignes sont numérotés 1,2,3 et comportent chacune deux stations terminales. On désire établir une base de données relationnelle dans le but de construire un système d'information permettant de trouver son chemin connaissant la station de départ et la station d'arrivée. Faire une proposition de modèle relationnel. Solution Exercice 2 Une vinothèque est spécialisée dans les vins de Bordeaux. Un vin de Bordeaux est caractérisé par son nom nomvin), son appellation (appellation) et son millésime (millésime). Un vin particulier est aussi caractérisé par le nombre de bouteilles (nbout) que possède la vinothèque. Régulièrement, un vin est dégusté par un oenologue (dégustateur) qui fournit un avis (avis) à une date donnée (datdeg). Afin de mettre en oeuvre une base de données pour la gestion des vins de la vinothèque, déterminer les relations normalisées. Solution Exercice 3 Une compagnie de transport aérien propose quotidiennement des vols réguliers. Chaque vol est caractérisé par son numéro de vol (numvol), une heure de départ (hdep), une heure d'arrivée (harr), une ville de départ (vdep) et une ville d'arrivée (varr). Les avions de la compagnie portent un numéro d'identification

14 (numavion), un nom (nomavion) et régulièrement sont révisés dans un centre particulier (crev). Les avions appartiennent à un type donné (typavion) et pour un type donné, possède une capacité de transport (cap) qui est le nombre maximum de passagers. Un même avion est toujours affecté au même vol. Chaque membre du personnel navigant porte un numéro matricule (numnav), un nom (nomnav) et possède une fonction (foncnav). Un membre du personnel navigant est affecté toujours à la même ligne. Tracer le graphe des dépendances fonctionnelles et en déduire les relations normalisées du modèle relationnel. Solution Exercice 4 Un office HLM gère des cités composées de bâtiments, eux-mêmes composés d'appartements. Ces appartements sont libres ou loués à des locataires. Chaque cité est sous la responsabilité d'un gardien. Chaque appartement appartient à un type de logement (F1 à F6)correspondant à un certain nombre de caractéristiques précises. Des opérations d'entretien peuvent être effectuées sur les appartements par des artisans. Les règles de gestion sont les suivantes : Une cité n'est gardée que par un seul gardien Un bâtiment n'appartient qu'à une seule cité Une opération est relative à un seul appartement Un appartement, s'il est loué, n'a qu'un seul locataire Tracer le graphe des dépendances fonctionnelles. En déduire les relations normalisées du modèle relationnel. Solution Exercice 5 La société KICUITOU est spécialisée dans la préparation de plats pour des collectivités ou des particuliers. Elle possède des ateliers (cuisines) où travaillent des cuisiniers, dont l'un est responsable de l'atelier. Chaque atelier prépare à une date donnée un certain nombre de plats qui comportent eux-même des denrées suivant une quantité donnée. Pour chaque plat des vins sont proposés. Un plat appartient à une catégorie. Les règles de gestion sont les suivantes : Un cuisinier ne travaille que dans un seul atelier Un plat appartient à une seule catégorie

15 La société KICUITOU propose à ses clients des menus dans un catalogue ; ces menus comporte de 1 à 6 plats. Une commande comporte, outre un numéro de commande, une date de commande et une date de livraison et bien sûr les menus commandés avec les quantités correspondantes. On admettra que le modèle relationnel correspondant est le suivant. PREPARATION (numat, numplat, dateprep, nbplats) VIN_PROPOSE (numplat, numvin) COMPOSITION (numplat, numden, qteden) CARTE (nummenu, numplat) DEMANDE (nummenu, numcom, nbmenus) PLAT (numplat, nomplat, durprep, durcui, #numcat) ATELIER (numat, telat) CUISINIER (numcui, nomcui, datemb, #numat) CHEF(numat, numcui) COMMANDE (numcom, datecom, dateliv, #numcli) CATEGORIE (numcat, nomcat) DATE(dateprep) VIN (numvin, libvin) MENU (nummenu) DENREE (numden, libden) CLIENT (numcli, nomcli) Sur ce modèle relationnel, écrire en SQL les requêtes suivantes : 1) Quels sont les plats composant le menu n 24? 2) Quelles sont les denrées composant le menu n 24? 3) Quels sont les noms et date d'embauche des cuisiniers de l'atelier 6? 4) Quels sont les vins proposés pour le menu n 24? Solution Exercice 6 En reprenant l'exercice 1, exprimer en SQL, les actions de recherche de la procédure Itinéraire(départ, arrivée). Cette procédure indique, connaissant la station de départ et la station arrivée, le chemin à suivre pour arriver à destination. Solution

16 Bases de Données Relationnelles Solution des exercices Solution de l'exercice 1 Une ligne de métro est définie par son numéro de ligne (numligne). Chaque ligne comporte une station de début (début) et une station de fin (fin). Bien entendu, le choix de début et de fin est arbitraire, mais une fois qu'il est fait, il définit un sens de parcours (de début vers fin) ce qui permettra de numéroter les stations de la ligne. Une station peut appartenir à plusieurs lignes (en fait, il n'y en a ici qu'une seule : Déak tér). Une station, sur une ligne porte un numéro d'ordre (numéro). Le graphe des dépendances fonctionnelles est aisément tracé : d'où les relations normalisées : LIGNE (numligne, début, fin) POSITION (numligne, nomstation, numéro) d'où les tables suivantes table POSITION nomstation numligne numéro table LIGNE numligne début fin 2 Déli pu. Örs vezér tere 3 Ujpest-Központ Köbanya-Kispest 1 Vörösmarty tér Mexikoi ut Arany J. u. 1 9 Arpad hid 1 5 Astoria 2 6 Bajcsy-Zs. ut 1 2 Bajza u. 1 7 Batthyany tér 2 3 Blaha Luiza tér On trouvera une réalisation de cette base de données sous Access : base db2.mdb Téléchargement : bd2.mdb (558 Ko) Retour à l'énoncé

17 Solution de l'exercice 2 Pour déterminer le modèle relationnel, il faut bien comprendre qu'il y a une distinction à faire entre un "vin" caractérisé par un nom et donc une appellation et un "vin que l'on a en cave" qui est caractérisé par un nom de vin, un nombre de bouteilles et un millésime. Dans le second cas, on est conduit à identifier un vin en cave par un numéro de vin (numvin). Pour la dégustation, deux possibilités sont offertes. Si on considère que l'on a à une date donnée un seul dégustateur qui goûte le vin, on peut choisir la solution A, sinon, on est conduit à caractériser une dégustation par un numéro d'identification numdeg ce qui conduit à la solution B solution A solution B Relations : ORIGINE (nomvin, appellation) VIN (numvin, millésime, nbout, #nomvin) DEGUSTATION (numvin, datedeg, dégustateur, avis) Relations : ORIGINE (nomvin, appellation) VIN (numvin, millésime, nbout, #nomvin) DEGUSTATION (numdeg, datedeg, dégustateur, avis, #numvin) Il est à noter qu'il est possible d'approfondir cet exercice et d'y ajouter d'autres tables (comme une table DEGUSTATEUR par exemple) Retour à l'énoncé Solution de l'exercice 3 La seule difficulté de cet exercice est le fait qu'un personnel navigant est toujours affecté à la même ligne (et non pas au même vol). On est donc contraint de créer une relation avec une clé double sans autres attributs, la relation AFFECTATION.

18 modèle relationnel : VOL (numvol, hdep, harr, vdep, varr, #numavion) AVION (numavion, nomavion, crev, #typavion) GENRE (typavion, cap) NAVIGANT (numnav, nomnav, foncnav) AFFECTATION (numvol, numnav) Retour à l'énoncé Solution de l'exercice 4 graphe des dépendances fonctionnelles : d'où les relations normalisées : ARTISAN( num_art, nom_art)

19 OPERATION (num_op, lib_op, #num_app) LOGEMENT (type, caract) APPARTEMENT (num_app, num_étage, sup, état, loyer, garage, #num_imm, #num_loc, #type) BATIMENT (num_imm, #num_cité) CITE (num_cité, nom_cité, #num_gardien) LOCATAIRE (num_loc, nom_loc, revenu_loc) GARDIEN (num_gardien, nom_gardien) PRESTATION (num_art, num_op) Retour à l'énoncé Solution de l'exercice 5 1) SELECT numplat FROM CARTE where nummenu = "24" ; 2)SELECT libden FROM COMPOSITION, DENREE, CARTE WHERE nummenu="24" AND CARTE.numplat=COMPOSITION.numplat AND COMPOSITION.numden=DENREE.numden ; ou bien SELECT libden FROM DENREE WHERE numden IN (SELECT numden FROM COMPOSITION WHERE numplat IN (SELECT numplat FROM CARTE WHERE nummenu="24")) ; 3) SELECT nomcui, datemb FROM CUISINIER WHERE numat="6" ; 4) SELECT numvin, libvin FROM VIN, VIN_PROPOSE, CARTE WHERE CARTE.nummenu="24" AND CARTE.numplat=VIN_PROPOSE.numplat AND VIN_PROPOSE.numvin=VIN.numvin ; ou bien SELECT numvin, libvin FROM VIN WHERE numvin IN (SELECT numvin FROM VIN_PROPOSE WHERE numplat IN (SELECT numplat FROM CARTE WHERE nummenu="24")) ; Retour à l'énoncé Solution de l'exercice 6 Rappelons que dans l'exercice 1, la base relationnelle est : LIGNE (numligne, début, fin) POSITION (numligne, nomstation, numéro) Dans la procédure Itinéraire (départ, arrivée), on trouve les requêtes suivantes : 1) "Rechercher le numéro de ligne pour la station d'arrivée : numéro_a ;" et "Rechercher le numéro d'ordre de la station d'arrivée : ordre_a ;" en SQL : SELECT numligne,numéro FROM POSITION WHERE nomstation="arrivée" ;

20 2) "Rechercher le numéro d'ordre de Déak tér sur la ligne numéro_a : ordre_d;" en SQL : SELECT numéro FROM POSITION WHERE nomstation="déak tér" AND numligne=numéro_a ; 3) "Rechercher la station de fin de la ligne numéro_a : fin_a ;" en SQL : SELECT fin FROM LIGNE WHERE numligne=numéro_a ; 4) "Rechercher la station de début de la ligne numéro_a : début_a ;" en SQL : SELECT début FROM LIGNE WHERE numligne=numéro_a ; 5) "Rechercher le numéro de ligne pour la station de départ : numéro_d ;" et "Rechercher le numéro d'ordre de la station de départ : ordre_d ;" en SQL : SELECT numligne, numéro FOM POSITION WHERE nomstation=départ ; 6) "Rechercher le numéro d'ordre de Déak tér sur la ligne numéro_d : ordre_a ;" en SQL : SELECT numéro FROM POSITION WHERE nomstation="déak tér" AND numligne=numéro_d ; 7) "Rechercher la station de fin de la ligne numéro_d : fin_d;" en SQL : SELECT fin FROM LIGNE WHERE numligne=numéro_d ; 8) "Rechercher la station de début de la ligne numéro_d : début_d ;" en SQL : SELECT début FROM LIGNE WHERE numligne=numéro_d ; 9) "Rechercher le numéro de ligne pour la station de départ : numéro_d ;" et "Rechercher le numéro d'ordre de cette station sur la ligne : ordre_d ;" en SQL : SELECT numligne, numéro FROM POSITION WHERE nomstation=départ ; 10) "Rechercher le numéro de ligne pour la station d'arrivée : numéro_a ;" et "Rechercher le numéro d'ordre de cette station sur la ligne : ordre_a ;" en SQL : SELECT numligne, numéro FROM POSITION WHERE nomstation=arrivée ; 11) "Rechercher la station de fin de la ligne numéro_a : fin_a ;" voir 3) 12) "Rechercher la station de début de la ligne numéro_a : début_a ;" voir 5) 13) "Rechercher le numéro d'ordre de Déak tér sur la ligne numéro_d : ordredtd ;" voir 6) 14) "Rechercher le numéro d'ordre de Déak tér sur la ligne numéro_a : ordredta ;" voir 2) 15) "Rechercher la station de fin de la ligne numéro_d : fin_d ;"

21 voir 7) 16) "Rechercher la station de début de la ligne numéro_d : début_d ;" voir 8) 17) "Rechercher la station de début de la ligne numéro_a : début_a ;" voir 5) 18) "Rechercher la station de fin de la ligne numéro_a : fin_a ;" voir 3) On trouvera la réalisation de l'algorithme avec utilisation de la base de données (bd2.mdb de volume 558 Ko) et les ordres SQL ci-dessus dans le programme metro.exe. Pour l'exécution, créer un répertoire "Budapest" sous le disque dur "C:" et y placer bd2.mdb et metro.exe que l'on aura extrait de l'archive compressée metro.zip.. Téléchargement : metro.zip Retour à l'énoncé