Examen Administration BD (Module FMIN363)

Transcription

1 Examen Administration BD (Module FMIN363) 1. Optimisation de requêtes (I. Mougenot) Un caviste veut gérer l ensemble des vins référencés au sein de sa cave. L information associée à la cave est volontairement simplifiée. Les vins sont caractérisés par une appellation, un millésime, un nom de domaine, une couleur (blanc, rouge, rosé), un type de vinification (standard, pétillant, crémant, champagne, clairette,...). Les vins sont produits par des domaines viticoles qui sont identifiés par un nom et caractérisés par une région, une adresse postale et un nom de propriétaire. 1.1 Modèle Entité-Association Un modèle entité-association vous est donné ci-dessous : Domaine nom region adresse proprietaire Vin appellation millesime couleur typevinification prix Fig. 1 Modèle Entité-Association Cave à vins Dans le schéma entité-association, Vin est un type d entité faible qui dépend de Domaine. 1.2 Enoncé Schéma Relationnel Les attributs portant les contraintes de clés primaires sont en gras. Les contraintes de clés étrangères vous sont données sous la forme contrainte d inclusion. Les types des attributs vous sont également indiqués. Domaine(nom varchar(30), region varchar(20), adresse varchar(50), proprietaire varchar(20)) Vin (appellation varchar(30), millesime integer, nomdomaine varchar(30), couleur varchar(10), typevinification varchar(20), prix float) avec Vin(nomDomaine) Domaine(nom) A titre d illustration, quelques exemples de tuples des tables Domaine et Vin vous sont donnés : insert into domaine values ( Paul Jaboulet, Hermitage, Tain-l Hermitage,null); insert into domaine values ( Domaine du Grollet, Charentes, Segonzac,null); insert into domaine values ( Domaine Vico, Corse, Ponte-Leccia,null); 1

2 Mastère IC insert into domaine values ( Cave de Montlouis, Montlouis, Montlouis-sur-Loire,null); insert into vin values ( Les Choisilles,2006, Cave de Montlouis, rouge, standard,14); insert into vin values ( Le Village,2002, Cave de Montlouis, rose, standard,14); insert into vin values ( La Chapelle Rouge,2005, Paul Jaboulet, rouge, standard,161); insert into vin values ( Domaine de Roure,2005, Paul Jaboulet, rouge, standard,34.50); 1.3 Index Des index uniques sont posés de manière implicite sur les attributs porteurs de contrainte de clé unique. Ces index, créés par le système de manière automatique, portent le même nom que la clé et sont consultables depuis la vue système user indexes. Il vous est possible d ajouter notamment des index secondaires sur les attributs porteurs de contraintes de clés étrangères qui seront souvent impliqués dans des requêtes exprimant des conditions de jointure, afin d améliorer les perfomances d accès aux données. 1. La contraintes de clé primaires Domaine pk a été posée sur l attribut nom de la table Domaine. Un index nommé Domaine pk a donc été automatiquement défini sur l attribut nom. Trois requêtes vous sont données sur la table Domaine. Pour chacune de ces requêtes, vous indiquerez si l optimiseur Oracle exploite l index Domaine pk et vous justifierez en une ou deux lignes votre réponse. select distinct region from domaine select nom from domaine select * from domaine where nom= Paul Jalabert 2. Dans la table Vin, l attribut nomdomaine est porteur d une contrainte de clé étrangère qui référence l attribut nom dans la table Domaine. nomdomaine va être impliqué dans bon nombre des requêtes qui vont porter à la fois sur la table Vin et la table Domaine Donnez l écriture de l ordre SQL de création de l index secondaire nommé nomdomaine idx sur nomdomaine Montrez au travers d un ordre de consultation de la vue système user indexes comment vérifier la création de cet index 1.4 Plan d éxecution Vous allez considérer maintenant les effets potentiels de l index nomdomaine idx. Dans un premier temps, vous avez à traduire une requête en langage naturel sous ses différentes formes SQL, puis ensuite à commenter les plans d exécution générés par l optimiseur pour une de ces ordres SQL, en présence puis en absence de l index. 1. Donner l expression de la requête nom et région des domaines pour lesquels aucun vin rouge n est référencé sous trois écritures SQL différentes : au travers d une différence au travers d un test de non-appartenance (not in) au travers d un test de vacuité (not exists) 2. le plan d exécution ainsi que les statistiques obtenus pour la requête exprimée au travers d un test de vacuité (not exists) vous sont retranscrits en présence de l index nomdomaine idx. Vous expliquerez et commenterez les résultats obtenus Plan d exécution Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time

3 Mastère IC SELECT STATEMENT (0) 00:00:01 1 NESTED LOOPS ANTI (0) 00:00:01 2 INDEX FULL SCAN DOMAINE_PK (0) 00:00:01 * 3 TABLE ACCESS BY INDEX ROWID VIN (0) 00:00:01 * 4 INDEX RANGE SCAN NOMDOMAINE_IDX 1 0 (0) 00:00: Predicate Information (identified by operation id): filter("couleur"= rouge ) 4 - access("domaine"."nom"="vin"."nomdomaine") Statistiques 0 recursive calls 0 db block gets 20 consistent gets 0 physical reads 0 redo size 589 bytes sent via SQL*Net to client 380 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 7 rows processed 3. le plan d exécution ainsi que les statistiques obtenus pour la requête exprimée au travers d un test de vacuité (not exists) vous sont retranscrits en absence (avant création) de l index nomdomaine idx. Vous expliquerez et commenterez les résultats obtenus Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (20) 00:00:01 * 1 HASH JOIN ANTI (20) 00:00:01 2 INDEX FULL SCAN DOMAINE_PK (0) 00:00:01 * 3 TABLE ACCESS FULL VIN (0) 00:00: Predicate Information (identified by operation id): access("domaine"."nom"="vin"."nomdomaine") 3 - filter("couleur"= rouge ) Statistiques 0 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 589 bytes sent via SQL*Net to client

4 Mastère IC bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 7 rows processed 2. Objet-Relationnel (I. Mougenot) Un diagramme de classes UML vous est donné. Ce diagramme reprend le même univers modélisé (cave à vins) avec une perception quelque peu différente.un domaine viticole st vu comme une composition de vins, qui constitue en quelque sorte son offre commerciale. Domaine nom region adresse 1.. Vin appellation millesime couleur typevinification prix 2.1 Types de données abstraits Fig. 2 Diagramme de classes Cave à vins A partir de ce diagramme UML, vous donnerez les ordres SQL de création : 1. le type de données vin t qui reprendra les attributs définis au sein de la classe Vin 2. le type de données offredomaine t qui est une collection (table) d instances de type vin t 3. la table domaine o qui reprendra les attributs définis au sein de la classe Domaine ainsi que l information liée à la collection de vins proposée par le domaine. Pour cette dernière information, vous définirez un attribut nommé offre domaine de type complexe offredomaine t au sein de la table domaine o Dans un second temps, vous proposerez deux tuples à l insertion dans la table domaine o en vous aidant des tuples exemples du premier exercice. Dans un troisième temps, vous exprimerez au travers du langage SQL, les requêtes suivantes portant sur la table domaine o : 1. donner pour chaque domaine, son nom, sa région et toutes les informations sur son offre en terme de vins proposés à la vente 2. donner le nom, et la région des domaines viticoles qui proposent des vins à plus de cent euros. 3. Droits et privilèges Usagers (T. Libourel) Le schéma d une base de données destinée à gérer des compétitions de diverses disciplines sportives a été créée et comporte les schémas de relation suivants :

5 Mastère IC Sportifs(ns,nom,prénom,pays, catégorie,datenais) Ns numéro, nom, prénom, pays, catégorie et date de naissance des sportifs (ns et nom prénom sont clés) Equipes(nequipe,ns) Le sportif de numéro ns appartient à l équipe de numéro nequipe. Inscriptions(ni,nEpreuve) L équipe ou bien le sportif de numéro ni est inscrit à l épreuve nepreuve Epreuves(nEpreuve,nomEpreuve,forme, discipline,catégorie,nbs) L épreuve de numéro nepreuve a le nom nomepreuve, est de forme (individuelle ou par équipe) forme, dans la discipline discipline et dans la catégorie (féminin, masculin) catégorie prévue dans la compétition. Si l attribut nbs est valué, il désigne le nombre de sportifs que doit contenir l équipe engagée dans l epreuve. Resultats(nEpreuve, or, ar,br) L épreuve nepreuve a un gagnant (sportif ou équipe) or, un second (sportif ou équipe) ar, un troisième (sportif ou equipe) br Locataires(ns,nLogement,nomBat) Le sportif ns est dans l appartement nlogement situé dans le bâtiment nombat. Batiments(nombat, numéro,rue, ville) Le bâtiment nombat est situé à l adresse numero, rue, ville. Divers services gèrent les informations de l application. Le service enregistrement (qui comporte divers membres ENR1 à ENR10) gère l enregistrement des sportifs et des équipes de chaque délégation ainsi que la répartition des sportifs dans les logements. Ce service est : Propriétaire des relations Locataires, Batiments, Sportifs, Equipes : il est donc responsable de l insertion et de la modification des données de ces relations Doit pouvoir interroger les noms des epreuves, leur discipline dans lesquelles les sportifs donnés par leur nom et prénom seulement sont engagés Le service Compétitions individuelles (qui comporte divers membres IND1 à IND8) gère les inscriptions et les résultats des compétitions individuelles. Ce service est : Propriétaire des relations Inscriptions, Epreuves : il est donc responsable de l insertion et de la modification des données de ces relations Doit pouvoir insérer des données dans Resultats, Inscriptions ne concernant que des épreuves individuelles Doit pouvoir interroger l adresse du logement, les noms, prénoms et pays des sportifs engagés dans des épreuves individuelles Le service Compétitions par équipes (qui comporte divers membres EQ1 à EQ5) gère les inscriptions et les résultats des compétitions par équipes. Ce service est : Propriétaire des relations Equipes, Resultats ; il est donc responsable de l insertion et de la modification des données de ces relations Doit pouvoir insérer des données dans Resultats, Inscriptions ne concernant que des épreuves par équipes Doit pouvoir interroger l adresse du logement, les noms, prenoms et pays des sportifs engagés dans des épreuves par équipes Les trois services sont coordonnés par l administrateur de la base de données (ADMIN) qui a des droits complets sur la base et qui définit le schéma, la gestion des usagers et leurs droits.

6 Mastère IC Questions 1. Donner la description des usagers de la base et de leurs privilèges 2. Description des vues nécessaires au partage de données 3. Quels droits doit donner l administrateur sur les relations et vues aux différents membres (usagers), comment procéder?