Les compétences informatiques souvent limitées des historiens et la relative imperméabilité des informaticiens aux problématiques historiques ont fortement limité leur collaboration, forçant souvent les historiens à concevoir eux-mêmes leurs bases de données et à résoudre les problèmes spécifiques à leur discipline par des méthodes plus ou moins heureuses. Leur manque de formation les orienta souvent vers des approches simplistes, privilégiant des structures peu rationnelles et non normalisées, ne comportant qu’un faible nombre d’entités – quand ce n’est pas une seule –, généralement exploitées dans des logiciels peu adaptés127.
Au contraire, et en relation directe avec la complexité des informations à analyser, la structure de ma base de données repose sur un grand nombre d’entités organisées dans un souci constant de normalisation. La traduction du schéma Entités / Associations en un modèle relationnel128 exploitable dans un logiciel de base de données s’est faite avec la même orientation (annexe 3, figure 20)129. Bien qu’elle soit loin d’être parfaite, cette structure ainsi définie a démontré une efficacité certaine dans l’utilisation que j’en ai faite.
Dans le modèle relationnel, chaque entité est traduite par une table (ou « relation ») dont la clé primaire (ou « identifiant unique ») est définie par un numéro d’identification arbitraire, l’attribut id (il est incrémenté automatiquement à la saisie de chaque nouvelle feuille). La clé primaire des tables traduisant les entités faibles est définie par l’id de la table à laquelle elles sont liées (par exemple, id_feuille dans le cas de feuille_zone ou feuille_tirage) et par un autre attribut qui permet de différencier plusieurs enregistrements (par exemple, id_typezone dans le cas de feuille_zone, ou annee dans le cas de feuille_tirage). Chaque association binaire de plusieurs à plusieurs est traduite par une table qui associe deux autres tables, comme par exemple feuille_triangulation ou feuille_zone_relief : le couple de clés primaires des tables associées forme la clé primaire de cette table. Les associations complexes, comme Sources ou Opérations, sont traduites par des tables associant plusieurs tables (id_acteur, id_structure, id_fonction, id_nomleve par exemple, pour operations) : la clé primaire de ces tables complexes est formé non seulement par les clés primaires des tables associées, mais aussi parfois par des attributs supplémentaires, comme annee et coupure pour la table operations 130.
Un grand nombre d’études historiques ont été réalisées en exploitant des bases de données réalisées avec le logiciel Excel, qui, s’il propose effectivement des fonctions de gestion de bases de données, reste avant tout un tableur et ne dispose pas de fonctions d’interrogation suffisamment puissantes.
Type de base de données le plus utilisé actuellement, basé sur l’utilisation d’une seule structure : la relation. Une relation peut être représentée sous la forme d’une table contenant, comme une feuille de calcul, des colonnes, les attributs ou champs (fields en anglais), et des lignes, les enregistrements (rows ou records en anglais), chaque ligne correspondant à une entité.
La normalisation de la structure doit beaucoup au soutien conceptuel de mon beau-frère Brian McAllister, programmeur spécialisé dans les bases de données qui travailla notamment au sein d’Oracle.
Ce choix de conception alourdit la base avec des tables dont la clé primaire est très complexe, mais si, d’un point de vue technique, il est envisageable d’utiliser un numéro d’identification (id) pour la clé primaire de ces associations complexes, cette solution n’est pas conforme aux critère de normalisation des structures de base de données et ne s’accorde pas avec le schéma logique de la structure (annexe 3, figures 19 et 20).