Le sujet comprend quatre dossiers indépendants

Mr Fischer Christian
BD50 : Conception des Bases de Données
Printemps 2002
Examen final du 22 juin 2000 de 9h à 12h
Support de cours et travaux dirigés de BD50 autorisés
Le sujet comprend quatre dossiers indépendants.
Rédiger chaque dossier sur une copie séparée.
Compléter le dossier 4 sur le sujet et joignez ce dossier à la copie.
Barème :
Dossier 1
Journal SIXVOIX
7 pts
MEA
Dossier 2
Gestion des appels d’offres
6 pts
Reverse du MLD
Requêtes SQL
Dossier 3
Gestion d’une mutuelle d’assurance
1
5
4 pts
MLD
Optimisation du MLD
Dossier 4
Client-Serveur
3 pts
A1
A2
A3
UTBM
3
1
BD50 P2002 Final
1
1
1
PAGE 1/7
Dossier 1 : Journal SIXVOIX
Le journal SIXVOIX est spécialisé dans la diffusion d'informations "people". Afin de
permettre à ses lectrice d'être informées au mieux sur la vie des VIP (Very Important Person),
la rédaction souhaite mettre en place un système d'information les concernant. Ce système
d'information devra permettre d'une part de suivre la carrière, d'autre part de gérer les
publications du journal traitant des VIP.
1/ SUIVI DE LA CARRIÈRE DES VIP
Un VIP est une personne publique appartenant au monde du show-biz , du cinéma, ou encore
de la mode.
Outre l'identité (nom et prénom usuels), le sexe, la nationalité et la date de naissance du VIP,
le journal SIXVOIX veut connaître un certain nombre d'événements liés à la vie du VIP :
-
son ou ses mariage(s), avec pour chacun d'eux, la date et le lieu de la cérémonie, l'identité
du conjoint (considéré également comme un VIP). Il est possible qu'un VIP se marie
plusieurs fois avec une même personne (par exemple les mariages célèbres du couple
mythique Richard Burton et Liz Taylor). En cas de séparation, la date de séparation et les
circonstances de la séparation sont également conservées.
-
Pour chaque liaison avec un autre VIP, on conserve la date d'annonce de la liaison.
-
selon le VIP, il est important de connaître
• pour un acteur de cinéma, la date de son premier tournage, les films long métrage
déjà réalisés (rôle joué, numéro de visa du film, date de réalisation, titre du film,
identité du réalisateur qui est un VIP).
• pour un chanteur ou un musicien, sa spécialité, les albums réalisés (date de
réalisation, titre de l'album, nom de la maison de disque).
• pour un mannequin (topmodel), sa taille, le nom de son agence, les défilés
auxquels le mannequin a participé (date du défilé, lieu, nom du couturier
également VIP).
Certes les stars sont immortelles mais si un VIP vient à disparaître, on conservera la date de
son décès.
-
UTBM
BD50 P2002 Final
PAGE 2/7
2/ GESTION DOCUMENTAIRE DES PUBLICATIONS
Pour la gestion de ses publications, la rédaction souhaite disposer d'une base documentaire
des photos et des exemplaires de la revue déjà publiés.
Pour chaque exemplaire de la revue, elle souhaite conserver :
- sa date de publication,
- son numéro de revue,
- pour chaque article : titre de l'article, numéro de la page où débute l'article, résumé.
Pour chaque photo, elle souhaite conserver :
- le numéro attribué à la photo par le journal,
- la photo sous forme d'image numérisée,
- la date de réalisation, le nom du photographe et de son agence de presse ;
- le lieu et les circonstances, les VIP présents sur la photo ;
- le (ou les) article(s) dans lesquels la photo a été publiée et le numéro de page dans
l'exemplaire de la revue concerné ;
- Pour chaque VIP, elle souhaite garder trace des articles qui lui ont été consacrés. Un
même article peut-être consacré à plusieurs VIP.
Travail à faire
Proposer un modèle entité-association étendu pour représenter le schéma conceptuel des
données manipulées dans le domaine de gestion décrit.
UTBM
BD50 P2002 Final
PAGE 3/7
DOSSIER 2 : Suivi des appels d’offres
Une base de données relationnelle a été implantée pour permettre le suivi des appels d’offres
et la réalisation des cahiers des charges destinés à y répondre. La description d’un extrait de
cette base est fournie
CLIENT (NumClient, NomClient, AdresseClient, ContactClient, CategorieClient)
EMPLOYE (NumEmploye, NomEmploye, PrenomEmploye, RoleEmploye)
APPEL (NumAppel, DateAppel, DescriptifAppel, EtatAppel, TypeAppel, NumClient,
NumResponsable)
CAHIER (NumCahier, DateCahier, MontantCahier, NumResponsable, NumAppel,
NumClient)
LIGNE_CAHIER (NumCahier, NumLigneCahier, DescriptionLigneCahier)
NumResponsable dans APPEL désigne le numéro de l’employé responsable de la réponse à
l’appel d’offre.
NumResponsable dans CAHIER désigne le numéro de l’employé responsable de la rédaction
du cahier des charges.
Dans la relation CAHIER, seulement l’un des deux attributs suivants est renseigné :
– soit NumAppel lorsque le cahier des charges répond à un appel d’offre préalable,
– soit NumClient dans le cas contraire.
Travail à faire
1
Construire le schéma entité-association correspondant à l’ensemble des relations
décrites ci-dessus.
2
Créer les tables CAHIER et LIGNE_CAHIER en précisant la clé primaire et clés
étrangères. Le choix du type de données est libre.
4
Écrire la requête SQL permettant d'obtenir la liste des cahiers des charges dans laquelle
chaque cahier des charges est caractérisé par son numéro, sa date et le nombre de lignes
qu’il contient.
5
Écrire la requête SQL permettant d'obtenir la liste des clients (nom et contact) pour
lesquels un cahier des charges a été rédigé par l'ingénieur Grimaud.
6
Écrire la requête SQL permettant d'obtenir le numéro et la date du cahier comportant le
plus de lignes.
7
On veut enregistrer le cahier des charges défini ci-dessous :
Le client MRSInfo, déjà enregistré sous le numéro CF3456, demande un devis le 24 janvier
2002 (n° D200201345) à l’ingénieur Alphonse Lepitre (déjà enregistré sous le matricule
DS453) pour l’extension de son parking visiteur d’une part et la réalisation d’un nouveau
portail automatique d’autre part, le tout pour un montant de 35 000 €. Il n'y a pas eu d'appel
d'offre préalable.
Rédiger les commandes SQL à exécuter pour ajouter le cahier des charges ci-dessus, en
indiquant dans quel ordre elles doivent être exécutées.
UTBM
BD50 P2002 Final
PAGE 4/7
DOSSIER 3 : MLD et Optimisation
Modèle conceptuel de données
Sociétaire
Projet
numéro sociétaire
nom sociétaire
prénom sociétaire
adresse sociétaire
date de naissance sociétaire
numéro tél sociétaire
date d'adhésion
Date
JJMMAAAA
1,n
date évaluation c oef fi ci ent
: Cie Assurance
Modèle : Mutuelle d' assurances
Auteur
: Fischer C.
Version:
1 16/06/2002
Compagnie
n° compagnie
adresse compagnie
tél compagnie
nom correspondant
A pour coefficient
coefficient évalué
nombre d'accidents période
0,n
1,n
Est traité avec
Sociétaire actif
Sociétaire radié
date radiation
motif radiation
coef en vigueur (C)
nb accidents période en cours (C)
date dernier passage coef max
mode de réglement
coordonnées bancaires
date appel période en cours (C)
montant cotis appelée (C)
1,1
Sinistre
1,1
1,n
Est géré
1,1
Souscrit
1,n
Bureau
n° bureau local
adresse bureau
tél bureau
responsable bureau
1,1
Contrat
num_immatriculation
date établissement
marque véhicule
modèle véhicule
qualificatif puissance
ident puissance
année de sortie
nom conducteur principal
prénom conducteur principal
année obtention permis
type de garantie
nature contrat
date dernier versement
n° sinistre
date sinistre
date enregistrement
identité du conducteur
degré responsabilité sociétaire
circonstances accident
identité du tiers
1,1
Conc erne
0,n
1,1
(1,1)
1,1
Est implanté
Appart ient
Es t uti li sé
Se s itue
1,n
Département
code département
nom département
0,n
Groupe
0,n
Nature
0,n
Zone
n° groupe
nat ure d'util is ation
zone d'util is ation
c aract éris ti ques groupe
dés i gnation uti lis ati on
dés i gnation zone
1,n
1,n
1,n
Détermi ne pri me
montant semestriel base
montant semestriel option
montant annuel base
montant annuel option
Travail à faire
1. Fournir le modèle relationnel associé au MEA ci-dessus (représentation graphique ou
textuelle)
2. Proposer différentes solutions pour l’optimisation de votre modèle.
UTBM
BD50 P2002 Final
PAGE 5/7
DOSSIER 4 : CLIENT - SERVEUR
La société SYSORG a développé une application client-serveur pour le compte d'une grande
administration.
Les utilisateurs utilisent des postes de travail sous Windows 9.x et sont reliés en réseau local qui
dispose d’un serveur Windows NT Server qui est utilisé comme serveur de fichiers et d’impression.
L’administration du réseau est effectuée à l’aide du logiciel SMS associé au SGBDR SQL Server
2000 sous Windows 2000 Advanced Server.
L’application client-serveur a été développée avec Visual Basic, elle utilise une base de données au
format Access (Jet) . La plupart des tables de cette base sont en fait attachées à des tables gérées par
le SGBDR Oracle 9i sous Linux (distribution Mandrake 7.2). Cependant, pour des raisons de
performance, certaines tables qui contiennent des données stables sont répliquées dans la base locale
au format Access.
De la même façon, les requêtes sont stockées, autant que possible, dans Oracle 9i de manière à être
exécutées plus rapidement sans transiter par le réseau et sans nécessiter de traduction ou de
compilation. Seules les requêtes qui changent en fonction des besoins de l'utilisateur sont construites
dynamiquement.
Le protocole réseau est TCP/IP.
A1. Pour mettre en oeuvre cette application client-serveur chez le client, quels éléments parmi les
suivants sont indispensables.
Le SGBDR SQL Server 2000
L’application développée avec Visual Basic
Le logiciel d’interrogation de base de données SQL*Plus
Le système d’exploitation Linux Mandrake 7.2
Le système d’exploitation Windows NT Server
Les tables stables de la base de données Jet
Le logiciel Access
Le SGBDR Oracle 9i
Le middleware Net Library et DB Library
Le middleware Net9 Client et Serveur
Un pilote ODBC pour SQL Server 2000
Un pilote ODBC pour Oracle 9i
UTBM
BD50 P2002 Final
PAGE 6/7
A2. Dans le contexte de cette application client-serveur, placez chaque composant ci-dessous côté
serveur ou côté client selon qu’il est utilisé sur un poste serveur ou sur un poste client. Cochez
les deux options quand le composant est utilisé à la fois côté client et côté serveur. Pour
chaque composant, cochez l’une, l’autre ou les deux options.
Composant
Client
Serveur
a) Une table contenant des données peu stables
b) Le système d'exploitation réseau
c) Une table contenant des données stables
d) Le système d'exploitation pour un poste de travail
e) Le SGBDR en partage de fichier
f) Le SGBDR Oracle 9i
g) Les requêtes stables
h) Le composant logiciel qui permet de saisir une date en simulant
le fonctionnement d'un calendrier
i) La base de données au format Access (Jet)
j) L’application Visual Basic
k) Le protocole TCP/IP
A3. Toujours à propos de cette application client-serveur, quelles affirmations parmi les suivantes
sont vraies ? Cochez uniquement les affirmations exactes.
Dans la base Jet, les tables sont attachées d’une source SQL Server
Une base de donnée Jet (fichier .MDB) est nécessaire
Il faut installer ODBC sous Linux
L'application Visual Basic peut utiliser les tables Oracle 9i comme s'il s'agissait de tables Access
En cas de modification de données stables, il faudra répercuter la modification sur tous les
postes client
Le fait d'utiliser des requêtes enregistrées sur le serveur limite le trafic sur le réseau
Il vaudrait mieux utiliser une base Access sur chaque poste client, cette base contiendrait toutes
les tables utilisées par l'application.
UTBM
BD50 P2002 Final
PAGE 7/7