-------------------------------------------------------------------------------
-- corr_maj.txt
-- 12/9/2012
-------------------------------------------------------------------------------

Le directeur de la SSII ou travaille le programmeur redige avec son client le
CC (enonce TD). Il le donne au programmeur qui doit l'implanter.

(a) Les acteurs de l'application sont : 
programmeur, n employes e1, e2, ..., en, m clients c1, c2, ..., cm
donc 1 + n + m acteurs regroupes en 3 familles.

Les actions de chaque acteur vont etre bien sur des ordres SGBD. 

(b) Cas particulier pour commencer : ordres tapes par le programmeur :
creer les 3 tables du CC, avec les types des colonnes, et un 
"default 2000" sur avoir. 

(c) Cas general : qui fait quoi :
Ces actions se deduisent du CC, principalement de la section "acces aux
donnees". Le "qui" a ete identifie en (a), et les actions du programmeur deja
identifiees en (b). 

Apres avoir cree les tables, le programmeur prepare dans un fichier les 
"modeles d'ordres" ci-dessous, qui implantent les actions des utilisateurs de 
l'application. Ces modeles d'ordres contiennent des "valeurs parametres" qui 
doivent etre adaptees lors de chaque frappe par les employes et les clients. 
Tables et modeles d'ordres composent l'application. 

A ce moment, l'application est operationnelle et entre en production. Le 
fichier contenant la creation des tables et celui contenant les modeles 
d'ordres sont envoye au client de la SSII, qui possede un SGBD. Les tables sont
creees. Chaque employe ou client utilise un client interactif dans lequel il 
fait un copie-colle des ordres dont il a besoin en adaptant les valeur
parametres, meme s'il n'est pas un expert SGBD et qu'il n'a pas besoin de 
comprendre la syntaxe des ordres. Il lit les resultats a l'ecran. 

Remarque : Noter que le mot "client" apparait ci-dessus dans trois sens 
differents. 

Modeles d'ordres :
  parametres atuels x, y, z, etc., sont tapes par l'acteur
  retours lu a l'ecran avec yeux 

employes :
  village : 
    insert
    select *
    update capacite, activite, prix avec x, y, z
  sejour : 
    select *
    delete where jour < x

clients :
  traitement 1 : 
    insert ic, nom, age (sans avoir, cf default), ou ic est quelconque
      -- Rem : a ce stade du cours, dans ce chapitre, on ne cherche pas encore
         a gerer la coherence, et on ne gere simplement pas le cas ou i existe
         deja, cf. aussi remarques en fin de correction.
  authentification en debut de session :
    ic, n ->
    select client where idc = i et nom = n : si n'existe pas alors arret session
  traitement 2 :
    ville v, jour j ->
    idv dont la ville est v, classes par prix decroissants
      -> iv, p (quelconque de prix max, par exemple le premier), sinon arret
    insert sejour is, ic, iv, j, ou is choisi comme ci-dessus
    decrementer avoir client du prix de i
    rem : on a bien les retours de t2 : iv, is, activite
  consulter villages pour lesquels aucun sejour achete :
    idv de village - idv de sejour
  consulter ses infos :
    client : select where idc = i
    sejour : select where idc = i
    village : select where village.idv = sejour.idv et idc = i

Remarques :
Cette situation ne correspond pas totalement au CC. Par exemple, d'une part
employes et clients devraient avoir des comptes SGBD. D'autre part, des erreurs
des utilisateurs et du programmeur peuvent mettre la base dans un etat 
incoherent. Il sera possible de gerer correctement ces points quand on
disposera de plus d'outils SGBD. A titre d'exercice de travail personnel, 
listez tous les problèmes que peut rencontrer l'application ci-dessus.  
    
(d) voir corr_maj.sql ci-joint

-------------------------------------------------------------------------------