Petit guide SGBD - Fin de modélisation (P. Ferré)
I) Les bienfaits du feed-back.
Au point où nous sommes parvenus, nous avons vu évoluer un projet. Les problèmes de salles, au fond, auront eu une vertu, « penser le modèle plus avant ». L’une des contraintes tenait aux limites de la méthode Merise, et sans doute à la crise des méthodes voir cours. Pourtant, nous arrivons à un résultat à deux conditions :
1er Nous solutionnons des objectifs
a) Nous pouvons interroger la base en SQL et plus tard avec une interface utilisateur, puisqu’on n’imposera pas à l’utilisateur en ligne la connaissance du SQL.
b) Mais avec des droits variés. Tout d’abord en qualité de visiteurs qui peuvent interroger la base puis en qualité de visiteurs privilégiés où l’interrogation doit permettre un historique / mémoire des fiches retenues, ce qui activera une création de fiches « surveillées » mais une création quand même.
Ce droit est ouvert aux étudiants au sein du département si vous avez suivi le raisonnement. Et enfin, en qualité d’utilisateurs privilégiés, mais il s’agit là de l’administration où selon l’octroi de droit un enseignant possédera des pouvoirs d’accès gradués.
Ces derniers s’étendent du droit à modifier les fiches, à les supprimer à en ajouter. Le droit ultime de supprimer « en vrac » des fiches ou de créer / supprimer des tables étant réservé à l’administrateur de la base. Ce sont ces raisons qui rendaient le modèle « difficile » à dégager lors d’un premier jet. C’était aussi le but de notre cheminement, où vous aviez relevé (je l’espère) les modèles « finalisés » entre guillemets.
c) On doit relever alors, que cela n’empêche pas de modéliser un premier jet, de le faire fonctionner voire même de le mettre en ligne la base de données, avec de simples droits de consultations octroyés à tous au début. L’on crée les droits les plus étendus, chemin faisant. C’est alors que le modèle se « finalise » jusqu’à l’apparition d’un nouveau besoin, qui fera à son tour évoluer le modèle. Soit une philosophie du prototypage, où je vous renvoie à mon cours. Et un exemple de feed-back de réalisation d’un projet. Il faut, en fait tout baser sur ce concept.
2er Nous acceptons une modélisation dynamique basée sur le prototypage.
a) Les visiteurs peuvent consulter les fiches et par menus déroulants choisir une recherche des fiches de poursuite d’études (table poursuite) par diplôme, par formation etc. Soit ce que proposent les menus de la base en ligne.
b) Les étudiants, peuvent réaliser les mêmes interrogations avec quelques droit en plus. Il est ajouté la mémorisation des fiches qu’ils auront retenues (expressément, par un bouton à cocher dans la fiche). Il sera nécessaire alors qu’ils se loguent avec la sécurité nécessaire. D’où les champs login, et password. Notons que l’absence de ces champs dans un premier temps n’empêche pas de modifier la base. On les ajoute, et pour le temps t+1 ces utilisateurs disposeront de la possibilité de se loguer. Le passé de l’application n’est pas perdu. C’est là l’un des intérêts des Bases de Données SQL.
c) Les autres droits seront implémentés en dernier lieu. Alors même que l’on se doute que ces droits existent, mais non accessibles, au début, par l’interface web. Ce serait suicidaire en terme de sécurité.
Nous avons donc les visiteurs qui consultent des fiches, les étudiants recherchent des formations et mémorisent leurs choix, les utilisateurs (privilégiés) administrent la base. Les anciens ont des activités, dont les données restent confidentielles. L’ensemble des connexions de tous les utilisateurs de l’application sont mémorisés (policer) dans des tables de log (compteurs, et surtout logcompteur). Les tables utilisateurs, anciens, activités, logcompteur entre autres, ne peuvent être consulter sans passer une sécurité particulière.
Ce qui permet de dégager un modèle Merise qui soit cohérent, comme ci-dessous 1
Petit guide SGBD - Fin de modélisation (P. Ferré)
II) Donc, le modèle « à la façon Merise » résultant. Note : Vous remarquerez que visiteurs n’est pas une table, c’est là une astuce purement logique.
Tout connecté qui n’est pas détenteur d’un droit à se loguer est un visiteur. Nous relevons au passage le nécessaire à sa connexion, et à la sécurité.
La différence d’avec les modèles successifs n’est pas un problème. Elle est marginale et se corrige par simples ajouts de champs. Et par la création d’une petite table qui peut se faire « à la main », à savoir liaisons. Ce Qu’il Fallait Démontrer
2
