Museo&Web

multilinguisme

métanavigation

Insertion d’une base de données dans un site Web

Il est indiqué dans cette page comment insérer une base de données déjà existante dans un site Web, de telle façon que son contenu soit aisément accessible/consultable à travers n’importe quel navigateur (user agent).

Il n’est pas tenu compte ici du format de la base de données, du support physique sur lequel est mémorisé la base de données, de la structure interne de la base de données, ni du système opérationnel dans lequel elle a été réalisée.

À ce propos, il est tenu pour acquis que la base de données est déjà optimisée et que son organisation interne est satisfaisante pour les objectifs que nous nous fixons ; autrement dit, ce document n’indique pas comment organiser logiquement (à travers des entités et des relations), comment structurer ou comment optimiser la base de données.

Par format de la base de données, on entend le format dans lequel sont mémorisées les données dans la base de données ; cette information concerne essentiellement le logiciel (RdatabaseMS ; Relational Date Base management System) avec lequel la base de données a été créée et avec lequel elle est gérée.

Le niveau de complexité informatique suggère qu’afin d’obtenir une meilleure réussite, le travail doit être accompli conjointement par un informaticien/technicien et par un responsable des contenus : la fonction du responsable des contenus est fondamentale, surtout dans la phase préliminaire, de conception de la base de données et des modalités d’interrogation et de visualisation des données de la base de données à travers le site Web.

a) Opérations préliminaires concernant la structure, le format, la complexité de la base de données

1. Comprendre dans quel format et avec quel RdatabaseMS a été réalisée la base de données

C’est-à-dire comprendre dans quel format et avec quel RdatabaseMS (ou programme) est réalisé la base de données. Cette information sert à comprendre comment il faut traiter les données et comment on peut éventuellement transformer la base de données en un format adapté aux objectifs que nous nous sommes fixés. Il est également important de comprendre sur quel support physique réside actuellement la base de données : dans le cas de vieilles bases de données, il est possible que le support utilisé pour sa mémorisation soit tellement obsolète que l’on ne trouve plus dans le commerce de matériel adapté à sa lecture (par exemple de vieux floppy disk de 5,25 pouces, des disques plasmon, des bandes, etc.).

2.Comprendre/Décider dans quel format transformer la base de données

C’est-à-dire comprendre s’il est possible de le faire et à quel coût.

• La simplicité de gestion de la base de données « en plein fonctionnement » : c’est-à-dire quelle sera la complexité de la gestion de la nouvelle base de données en termes de professionnalités impliquées;
• Le coût de la gestion de la base de données « à plein rendement » : c’est-à-dire quel sera le coût de la gestion de la nouvelle base de données en termes de dépenses pour l’achat et l’entretien de matériel et de logiciel adaptés, en tenant compte également, bien sûr, des options de logiciels open source, qui ont, comme on sait, des coûts de licences nuls;
• Le type de serveur dont on dispose pour « publier »/mettre en ligne la base de données;
• Le coût nécessaire pour la transformation, en tenant compte du point 1 : dans le cas où la base de données est encore sur de vieux supports, il faut évaluer attentivement la possibilité/intérêt de récupérer cette base de données;
• Les prestations que l’on entend assurer dans l’accès à la base de données en ligne, en termes de nombre de connexions simultanées et de vitesse de réponse des pages Web.
  Pour cette opération, il existe actuellement deux possibilités, compte tenu des considérations exposées ci-dessus:
  • pour des bases de données n’ayant pas de dimensions excessives, simples à gérer, d’un transport et d’un entretien facile, le choix porte sur des produits du type Access ou Filemaker : la base de données réside dans un seul fichier qui contient « tout le nécessaire » à son fonctionnement (tableaux, query (« interrogation »), masques éventuels pour l’insertion et la modification des données);
  • pour des bases de données de moyennes ou grandes dimensions et/ou de type professionnel, de dimensions importantes, qui assurent des prestations, la sécurité, une efficacité élevée et dont les formats de données doivent être interopérables et plus conformes aux standards, le choix doit porter sur des produits du type SQLServer, MySQL, Oracle;
    mais ce choix implique un coût plus élevé en termes de professionnalités nécessaires pour leur utilisation/entretien, et en termes de puissance de calcul/élaboration nécessaires à leur fonctionnement;

3. Comprendre la structure de la base de données et sa complexité

C’est-à-dire connaître le nombre de tableaux qui composent la base de données et le nombre de relations entre ceux-ci. Cela est nécessaire si l’on veut arriver à réaliser aisément le point 5. Il s’agit d’analyser la structure de la base de données (nombre de tableaux, nombre et type de relations existantes entre les tableaux, indexation, nomenclature des tableaux et des champs, etc.) et sa complexité.

4. Convertir la base de données

C’est-à-dire convertir la base de données depuis son format original dans le nouveau format. Ce point varie évidemment en fonction des caractéristiques de la base de données « destination » et de la base de données « origine ». Sa complexité peut être très variable selon les cas : par exemple, dans le cas de RdatabaseMS « évolués » (SQL Server ; MySQL ; Oracle), l’importation depuis des formats « inférieurs » (Access ; Filemaker ; Excel) est normalement très simple et guidée pas à pas.

Nous résumons ici deux cas particuliers : le premier est important pour la diffusion des produits concernés (Access), le second en raison de l’implication d’un logiciel libre de plus en plus répandu (MySQL).
4.1 d’Access 97 à Access 2000
4.2 d’Access 2000 à MySQL

À ce stade, à la fin du point a) notre base de données sera disponible et prête à être utilisée dans un site Web et nous disposerons de nombreuses informations sur sa structure, dont la connaissance est fondamentale pour la réalisation de la phase suivante b) : l’implémentation à proprement parler en site Web.

b) Opérations concernant l’accès aux données de la base de données

Une fois que la base de données a été convertie dans le format choisi, les opérations à effectuer concernent la manière pour faire consulter la base de données à travers le site Web, c’est-à-dire:

5. Décider le nombre et le type d’interrogations (query) à implémenter dans le site

Il s’agit de décider le type d’interrogation qu’il faut faire accomplir aux utilisateurs du site.
Pour chaque query, on doit décider:

• Comment organiser le formulaire (ou form) d’interrogation: quantité et type de champs (input text, combo box, check box, etc.).
  Ce choix doit tendre à permettre une interrogation assez articulée en fonction de la complexité de la base de données, mais pas excessivement dispersive et avec « trop » d’options.
  Il convient également de choisir et d’implémenter des instruments pour limiter le plus possible les possibilités d’erreur de l’utilisateur : par exemple, si celui-ci doit faire un choix à l’intérieur d’un ensemble restreint d’options, qui sont connues à priori, il faut utiliser le type de champ combo box, ou menu en descente, qui donne la possibilité de choisir seulement parmi les options déjà prévues, plutôt qu’utiliser un input box, dont le texte peut être libre (et donc davantage sujet à des erreurs de saisie);

• Comment organiser la Page des résultats : voir point 6
• Comment organiser la Page de détail : voir point 7
  

6. Page des résultats : décider les données à visualiser et sous quelle forme

Ce choix concerne le layout/mise en page de la page des résultats de la query, ainsi que l’opportunité et la manière d’implémenter le paging (organisation des résultats en page).
Les formats les plus communs sont:

• Format tabulaire : la page des résultats sera un tableau, c’est-à-dire que les résultats apparaîtront dans les cases d’un tableau, formaté en lignes et en colonnes. On indiquera sur la première ligne les noms de chaque champ, et sur les autres lignes les valeurs correspondantes;
• Format « plan » : chaque champ de la base de données que l’on a choisi de visualiser sera présenté sur une nouvelle ligne précédée d’un label/étiquette qui l’identifie;

Le paging concerne essentiellement le choix du nombre de résultats devant être visualisés sur chaque page : ce choix doit être un compromis entre un nombre trop limité (avec pour conséquence que l’utilisateur serait obligé de naviguer sur de nombreuses pages avant d’arriver, éventuellement, au résultat recherché), et un nombre trop élevé (plus grande charge de travail pour le serveur et donc plus grande lenteur dans la visualisation de la page, avec à la limite des problèmes de mauvaise visualisation de la page quand le nombre de résultats est excessivement élevé).

7. Il est possible de réaliser aussi éventuellement une page de détail de chaque résultat

Il s’agit de réaliser aussi une page avec des résultats plus détaillée, au cas où l’on aurait choisi de mettre dans la page précédente des résultats un sous-ensemble de toutes les informations extraites comme résultats de la query. C’est cette solution qui convient lorsqu’il y a une grande masse d’informations à visualiser et que l’on veut éviter de « surcharger » la page des résultats d’informations : ayant trouvé l’information qu’il cherchait, pour avoir des informations étendues l’utilisateur peut effectuer un approfondissement dans la page de détail. Dans ce cas aussi, il faut choisir la quantité d’informations à visualiser et le layout de visualisation.

Pour l’exemplification des points 6 et 7 et pour leur réalisation pratique, nous renvoyons à la section « Musées et monuments » du site de la Direction Générale pour les Biens Architecturaux et Paysagers (www.bap.beniculturali.it) auquel les figures suivantes se réfèrent.

Figure 1. Module de recherche des informations sur la base de données
http://www.bap.beniculturali.it/attivita/musei/index.asp

Figure 2. Page des résultats : liste des monuments visualisés à la suite d’une recherche
http://www.bap.beniculturali.it/attivita/musei/elenco.asp

Figure 3. Page de détail : informations exhaustives sur chaque monument recherché http://www.bap.beniculturali.it/attivita/musei/dettaglio.asp?id='212/13/dip'

c) Implémentation

À ce stade, il ne reste qu’à implémenter la fonctionnalité d’accès et de consultation de la base de données à travers le site Web. Autrement dit, il s’agit de réaliser les pages Web, dans un langage de script adapté, qui permettent la sélection et la consultation des informations présentes dans la base de données.

Ici aussi, le choix du langage de script à utiliser implique des considérations telles que:

• Le type de serveur Web que l’on a choisi pour publier le site ou que l’on a à disposition;
• Le type de RdatabaseMS que l’on a choisi;
• Des considérations concernant les coûts d’achat et/ou de gestion du site Web et du RdatabaseMS;

d) Entretien

8. À plein rendement, c’est-à-dire quand la base de données a été correctement insérée dans le site Web, il est nécessaire de prévoir des politiques de mise à jour périodique des données, d’entretien de la base de données, de backup/restore.

• Mise à jour veut dire planifier l’opportunité de mettre à jour les données en ligne, avec quelle fréquence, selon quelles procédures et avec quels logiciels;
• Entretien veut dire planifier des opérations de contrôle de cohérence des données et de qualité de la base de données;
• Backup/restore signifie planifier les opérations de copie périodique pour éviter la perte de données à la suite d’événements accidentels.

métanavigation   torna alla navigazione