[Ce billets constitue l’adaptation du quatrième chapitre du livret réalisé durant le Mooc ArchInfo de l’ENS de Lyon en mars 2016 : Savoir faire dialoguer et coopérer des métiers connexes. L’objectif dans ce chapitre était de concevoir une petite base de données relationnelle, dans le cadre d’un site web, qui permettrait à des enseignants de compiler les notes obtenues par leurs étudiants à différents travaux dans leurs cours.]
Savoir faire dialoguer et coopérer des métiers connexes est l’une des six compétences de l’architecte de l’information ci-dessous :
Sommaire :
1-Référentiel de compétences détaillé :
« Savoir faire dialoguer et coopérer des métiers connexes »
L’architecte de l’information pilote une équipe d’experts aux cultures diverses : des informaticiens, des documentalistes, des designers, des ergonomes, des professionnels du marketing, des juristes, des communicants ou encore des formateurs. Il doit les faire dialoguer, coopérer et participer à un projet commun.
Le système d’information qu’ils doivent concevoir peut, lui-même, s’appliquer aux domaines les plus divers. Il faut aussi comprendre la logique et le vocabulaire de chacun d’entre eux.
Cet ensemble de personnes et leurs interactions forment une sorte de tour de Babel, tout le monde ne parle pas la même langue. Pire, les mêmes mots disent parfois des choses différentes. L’architecte de l’information aura la charge de faciliter le dialogue pour un avancement du projet collectif le plus harmonieux possible.
1-Développer une bonne culture des métiers de l’interaction et du design numérique
2-Maîtriser les vocabulaires et les logiques des informaticiens, des documentalistes, des concepteurs (designers, ergonomes, monteurs), du marketing, des juristes, des communicants et des formateurs
3-Savoir intégrer les cultures métiers et les contextes des institutions
4-Avoir du leadership :
- Animer et motiver une équipe de professionnels de cultures différentes
- Savoir convaincre, expliquer et faire accepter des décisions
- Gérer des conflits
5-Participer à des séances de conception créative
6-Agir de manière éthique, citoyenne et responsable
2-Activité illustrative
L’objectif de cette activité est de concevoir une petite base de données pour consigner les notes obtenues dans le cadre de travaux étudiants. Votre travail sera à insérer dans le chapitre : « Savoir faire dialoguer et coopérer des métiers connexes » de votre livret.
Vous avez pour mandat de développer, pour le Collège XYZ, un site web qui permettra aux enseignants de compiler les notes obtenues par leurs étudiants aux différents travaux dans leurs cours. Le Collège XYZ est relativement modeste, avec quelque 200 enseignants offrant annuellement autour de 700 cours pour une clientèle étudiante variant entre 1 500 et 2 000 étudiants par année. Chacun des cours est sous la responsabilité d’un seul enseignant et tous les travaux se font individuellement. Un cours compte environ de 3 à 5 travaux et ne se donne qu’une fois par année.
Le site Web intégrera une base de données.
- Commencez par expliquer pourquoi ce contexte est propice à l’intégration d’une base de données.
- En vous basant sur le contexte décrit, évaluez s’il s’agit d’une base de données relationnelle ou plutôt une base de données NoSQL. Résumez, en un paragraphe, ce qui vous fait pencher vers l’une plus que l’autre.
- En vous aidant le cas échéant des références données ci-dessous, réfléchissez à la structure des données sous-jacente en précisant succinctement :
- les principales collections qu’on y retrouve,
- les tables nécessaires pour représenter ces collections,
- des exemples d’attributs que l’on pourrait retrouver pour ces tables et, en particulier, leur clé primaire, et les relations possibles entre ces tables en précisant leur cardinalité et l’impact qu’elles auront sur la structure des tables de données.
Votre rendu pour l’ensemble de cette activité ne devrait pas dépasser une page.
Ressources complémentaires pour vous aider
A priori, pour réaliser le travail demandé par le livret, le module S4.3.1 de la séquence suffit, en s’appuyant en outre sur l’exemple du module S4.3.2 et sur les notions générales des modules S4.1 et S4.2. Le mieux est de relire tranquillement les supports dans la version PDF pour bien comprendre les notions.
Cependant, au cas où vous auriez besoin de ressources supplémentaires, nous vous proposons des parties spécifiques des sites suivants :
- http://cyril-gruau.developpez.com/merise/ [se limiter à I Introduction, II-A Schéma Entités-associations et III-B Modèle logique relationnel]
- http://cerig.pagora.grenoble-inp.fr/tutoriel/bases-de-donnees/sommaire.htm [Se limiter à I Introduction, II Tables, V Mécanisme relationnel, VI Schéma relationnel]
Notons qu’il est difficile de trouver de bons tutoriels sur les bases de données qui ne se centrent pas sur un système donné (Access, MySQL, etc.).
3-Réalisation de l’activité
Un contexte propice à l’intégration d’une base de données
On peut calquer les éléments de cette étude de cas sur chaque caractéristique de la définition d’une base de données :
- Un ensemble de données persistantes :
La base de données va servir au moins une année. - Des données organisées par collections d’items en fonction de similitudes de structure ou selon d’autres critères de regroupement :
On voit des données qu’on peut réunir dans des ensembles ayant trait aux enseignants, aux travaux, aux étudiants… - Des collections qui peuvent être reliées :
Les étudiants réalisent des travaux, les travaux sont administrés par les enseignants, etc… - Le tout représentant une certaine réalité pour pouvoir agir dessus :
Attribuer une note à un travail, retrouver quels élèves ont réalisé tel travail, quel enseignant a attribué telle note, etc…
Une base de données relationnelle est suffisante pour répondre aux besoins de ce collège
Les effectifs sont modestes si on compare, par exemple, aux données manipulée par le site voyages-sncf.com. Si 11 millions de visiteurs uniques par mois (avec le nombre de trains, de lignes, de gares, d’horaires plus la gestion des correspondances) sont gérables avec une base de données relationnelle, alors les quelques centaines de cours et d’enseignants et les quelques milliers d’élèves de ce collège ne devraient pas poser de problème. La structure des collections est relativement simple et ne devrait pas changer substantiellement. Les temps de réponse ne sont pas déterminants.
D’autre part, quand bien même les étudiants viendraient des quatre coins de la planète, comme c’est le cas à Agropolis à Montpellier où j’ai travaillé, ils sont tous réunis dans l’enceinte de l’établissement, tout comme les enseignants. Par conséquent, un unique serveur de base de données peut suffire.
Pour toutes ces raisons, il n’est pas nécessaire de recourir à un modèle non-relationnel (NoSQL), qui serait largement surdimensionné et plus fastidieux à mettre en place.
Dans la mesure où il n’y a pas de nombreux serveurs coopérant à travers le monde, les contraintes ACID propres aux transactions des bases de données relationnelles (par opposition aux contraintes BASE des modèles non relationnels), seront respectées :
- Atomicité
- Cohérence
- Indépendance
- Persistance
Les propriétés ACID des transactions visent à garantir la cohérence la plus totale possible des données qu’une base contient et le maintien de cette cohérence au fil des opérations auxquelles cette base est soumise.
Structure de données de cette base de données : schéma relationnel
On entrevoit cinq collections. Pour une année scolaire on aura :
- Enseignants qui comprendra 200 lignes
- Cours qui comprendra 700 lignes
- Travaux qui comprendra 2100 à 3500 lignes (700 cours multipliés par 3 à 5 travaux)
- Notes qui comprendra entre 3,1 et 7 millions de lignes (le nombre d’élèves par le nombre de travaux)
- Etudiants qui comprendra 1500 à 2000 lignes
Autant dire qu’on ne s’en sortirait pas avec un simple tableur, surtout si plusieurs enseignants veulent utiliser le système en même temps. Encore un avantage des bases de données : elles sont multi-utilisateurs.
En fait, on peut se passer d’une table Travaux en en intégrant directement les notes sous forme d’attributs dans la table Notes. C’est une solution que je trouve plus élégante. Si l’année suivante il y a plus de 5 travaux par cours, il suffira d’ajouter autant d’attributs Note travail que nécessaire.
Cardinalité :
- 200 enseignants dispensent 700 cours par an, soit une moyenne de 3 à 4 cours par enseignant. Un enseignant donne 3 à 4 cours en moyenne, mais chaque cours ne dépend que d’un enseignant : 1-n
- A un cours ne peut correspondre qu’une série de 3 à 5 notes : 1-1
- A une série de notes d’un cours ne peut correspondre qu’un étudiant : 1-1
- Si on avait dû relier directement les tables Cours et Etudiants , on se serait retrouvés avec une cardinalité n-n, ce qui aurait nécessité l’ajout d’une table intermédiaire. Ici c’est la table Notes qui joue ce rôle.
Colonnes / attributs :
- Aucun des attributs n’est unique dans aucune table : un nom, un prénom voire une adresse peuvent être partagés par plusieurs étudiants et plusieurs enseignants, deux étudiants peuvent avoir une même note, la même note peut être attribuée pour plusieurs travaux, etc. J’ai donc décidé d’attribuer un identifiant unique (Id) à chaque entité, sous forme d’une numérotation incrémentielle qui sera arbitrairement fixée par l’informatique.
- Une seule exception : la clé primaire de Notes est formée par le couple de clés étrangères IdEtudiants et IdCours
- Les attributs Adresse, Téléphone et Courriel pourraient servir à proposer un annuaire, sous réserve d’ajouter des tables supplémentaires.
- Le login et le mot de passe de l’enseignant servent à sécuriser le système : il ne faudrait pas que n’importe qui puisse consulter les notes.
* Clé primaire
# Clé étrangère
(cliquez pour agrandir)
Il y aura différents profils avec des droits bien définis pour gérer la base de données :
- Un administrateur aura tous les droits pour ajouter/modifier/supprimer des tables, des enregistrements, des attributs, des relations
- Un profil « secrétariat » pourra ajouter/modifier/supprimer des enregistrements dans les tables Etudiants et Enseignants
- Un profil « enseignant » pourra ajouter/modifier/supprimer des enregistrements dans les tables Cours et Notes
Ces profils seront gérés de différentes manières selon le SGBD* choisi et éventuellement le logiciel de gestion de contenu (CMS) qui va englober le tout :
Les requêtes SQL permettant, par exemple, de récupérer des informations utilisées pour générer une page, n’y seront toutefois pas nécessairement visibles : les pages dynamiques qui les contiennent (par exemple en PHP) sont en effet interprétées par le serveur. Ce qui est affiché dans le navigateur, en ce cas, est du HTML produit par du PHP qui lui-même envoie des requêtes SQL et utilise les résultats retournés par une base de données. L’indice ici est l’extension .php qui peut nous mettre sur la piste de la présence d’une base de données.
Extrait du bilan du Mooc Archinfo 2016, Séquence 4, débat 4.2
* SGBD : Système de gestion de base de données, ici relationnel (SGBD-R). C’est le logiciel dans lequel s’inscrit la Base de données et qui va traiter les requêtes. MS Access, MS Sharepoint, PostgreSQL et MySQL sont des SGBD.
[Edit d’après le 1er mars]
Le corrigé propose une autre solution :
- Pas de table Notes
- Une table Travaux intégrant sa note associée et reliée à la fois à Etudiants (relation « remettre », 1-n) et Cours (relation « Évalué par », 1-n)
- La relation directe entre Cours et Etudiants, n-n, nécessite l’ajout d’une table Inscription
- Le numéro d’étudiant et le sigle du cours sont des clés primaires
- Chaque relation a un nom
- L’intitulé des champs contenant des clés étrangères sont explicites pour la table où ils se trouvent (ex : Auteur pour le numéro d’étudiant comme clé étrangère dans Travaux, Responsable pour l’ IdEnseignant dans Cours…)
[Fin Edit]
Page dédiée au Mooc Archinfo: https://infodocbib.net/mooc-archinfo/
Tous les chapitres du livret de l’architecte :
- Ce qu’organise l’architecte de l’information
- Une définition de l’architecture de l’information
- Comprendre et expérimenter les technologies numériques
- Savoir structurer l’information, les données et les ressources documentaires
- Représenter et organiser la connaissance
- Concevoir une base de données relationnelle
- La gestion dynamique des projets : prototypage web
- L’expérience utilisateur (UX)
- Épilogue : références en architecture de l’information
- Annexe : l’éthique de l’architecte
