Contrôle de connaissance
Dominante Informatique - Module Bases de Données
Lundi 9 mars 1998

Durée 1h30. Documents autorisés.

Bon courage...

A- requêtes relationnelles

Les informations concernant une base de données bibliographique sont stockées dans le schéma relationnel suivant:
Livres (numlivre, titre, annee)
Motsclefs (numlivre, motclef)
Coauteurs (numlivre, numaut)
Auteurs (numaut, nomaut, prenomaut, info)

A1- Requêtes relationnelles

Répondre en SQL aux questions suivantes :

• Quels sont les titres des livres dont les auteurs ne sont pas référencées dans la BD ?
• Combien d'auteurs ont signé un livre parlant de "relational data bases" ?
• Donner les titres des livres qui parlent à la fois de "relational join" et de "clustering" ?
• Donner les noms des auteurs qui n'ont jamais écrit un livre seul ?
• supprimer les auteurs qui n'ont écrit aucun livre.

A2- Vues

Créer une vue qui contient tous les auteurs qui ont écrit (ou coécrit) au moins un livre en 1997.

Peut on mettre à jour cette vue (insertion, suppression)? Pourquoi ? Cette caractéristique est elle liée à la façon dont la vue a été définie ?

Parmi ces auteurs, lesquels ont écrit plus de dix livres sur l'ensemble de leur carrière ?

B- Modélisation

Le fond documentaire décrit dans la partie A peut maintenant être utilisé au sein d'un service de prêts. On souhaite donc enrichir son schéma relationnel pour la gestion des adhérents de la bibliothèque.

Il y a deux types d'adhérents, enseignant ou élève, La durée standard d'un prêt est de 4 semaines. Un élève peut bénéficier d'un prêt de 3 mois, mais il doit alors faire garantir sa demande par un enseignant.

Pour créer cette base de données, on propose la relation universelle suivante :

RELUNIV (numlivre, numens, nomens, prenomens, adresseens, numeleve, nomeleve, prenomeleve, adresseeleve, datesortie, dateretour)

En cas d'emprunt d'un livre par un enseignant, seuls les attributs numlivre, numens, nomens, prenomens, adresseens, datesortie sont renseignés.

En cas d'emprunt standard d'un livre par un élève, seuls les attributs numlivre, numeleve, nomeleve, prenomeleve, adresseeleve, datesortie sont renseignés. En cas d'emprunt longue durée par un élève, les attributs numens, nomens, prenomens, adresseens sont aussi renseignés.

dateretour est mis à jour au moment où le document est rendu.

Hypothèse supplémentaire : on souhaite garder un historique des emprunts.

• Donner la liste des dépendances fonctionnelles en les validant par les hypothèses de l'énoncé ou par des hypothèses supplémentaires que vous préciserez.

• En déduire une cle de la relation RELUNIV.

• Proposer une décomposition en 3 FN, sans perte et qui préserve les DFs.

• Cette décomposition vous paraît elle perfectible ? Si oui, comment ?

• Un élève LAMBDA ayant suivi le cours de dominante informatique émet quelques critiques sur le schéma relationnel de la bibliothèque et suggère de partir plutôt d'une nouvelle liste d'attributs.

  RELUNIV2 (numlivre, numpers, nompers, prenompers, adrpers, typepers, numgarant, datesortie, dateretour)

  où typepers indique si la personne est enseignant ou élève et numgarant est le numéro de l'enseignant qui, en cas de prêt longue durée d'un élève, garantit ce prêt.

  A votre avis, LAMBDA a-t-il brillamment réussi le module de Bases de Données ? Expliquez pourquoi. (max 15 lignes et quelques DFs)

C- questions diverses

• SQL est il un langage déclaratif ou procédural ? Expliquez votre réponse. (5 lignes max)
• Supposons qu'on ait déclaré une contrainte de clé réferentielle entre l'attribut numauteur de la relation Coauteurs et l'attribut numauteur de la relation Auteurs. Quelles sont les deux manipulations permettant de vérifier que la contrainte est bien contrôlée par le SGBD ? Peut on vérifier une telle contrainte à l'aide de vues (définies avec des check option) ? (10 lignes max)