2.3.2.3. La variable temporelle : l’année comme unité de temps.

La variable temporelle, évidemment fondamentale pour une étude historique, posait deux difficultés. La première, inhérente à toute utilisation historique d’une base de données, concernait le codage d’informations temporelles qui pouvaient être des dates précises ou des périodes continues ou discontinues. La gestion des périodes est un problème délicat puisqu’elles ne peuvent pas être saisies dans un attribut unique de type numérique ou date permettant des analyses quantitatives exploitant les données temporelles. La seule méthode efficace consiste à saisir autant d’enregistrements que le nombre d’unités temporelles dans une période : par exemple, un levé topographique exécuté entre 1925 et 1927 doit être saisie dans trois enregistrements distincts pour chacune des années. Dans la structure d’une base de données, cela revient soit à créer une entité faible pour l’information temporelle, soit à intégrer l’attribut temporel dans l’identifiant unique d’une entité125. La base de données se trouve relativement alourdie par une structure plus complexe et un nombre d’enregistrements plus important, mais il est alors possible, facile et particulièrement efficace, d’interroger la base de données en prenant en compte de manière rationnelle les données temporelles. Dans ma base de données, la structure est encore complexifiée par l’utilisation systématique d’entités pour gérer les énumérations, afin de faciliter le codage au cours de la saisie des variables prises en compte ; ainsi, la plupart des variables temporelles se trouvent en fait intégrées dans des associations complexes, comme Opérations ou Sources (annexe 3, figure 19), liant plusieurs entités.

Dans la plupart des cas, je n’ai conservé que l’année comme unité temporelle signifiante126, cette précision s’avérant largement suffisante pour des analyses portant sur plusieurs décennies. En particulier, j’ai décidé de ne pas saisir les informations contenues dans les dossiers topographiques avec tous les détails disponibles : si certains rapports de restitution précisaient le jour et la durée en heures pour des opérations portant sur quelques kilomètres carrés, cette précision n’aurait fait qu’alourdir la base en multipliant de façon exponentielle le nombre d’enregistrements nécessaires, tout en n’offrant qu’une matière très limitée à l’analyse puisqu’elle n’était disponible que pour certaines feuilles et certaines périodes peu étendues.

La deuxième difficulté que posait la variable temporelle tenait à la multiplicité des références temporelles pour une même feuille, liée aux spécificités du processus de production cartographique (date de levés, date de réalisation, date de dessin, date de gravure, date d’édition, date d’impression). Afin de ne pas multiplier inutilement le nombre d’enregistrements, j’ai décidé de concevoir l’entité Feuille comme un enregistrement de chaque publication d’une feuille comportant des modifications. Les tirages de simple réimpression ont été inclus dans l’entité faible Tirage, liée à Feuille par une association un à plusieurs. J’ai conservé les autres références temporelles liées aux feuilles, qui correspondaient à des données spécifiques éventuellement nécessaires pour certaines analyses, mais pour simplifier la recherche et le tri des feuilles ainsi que la plupart des requêtes, un attribut de référence (anneereference) a cependant été créé, déterminé en fonction des dates d’édition et de tirage.

Notes
125.

Identifiant unique (ou clé primaire) : attribut ou ensemble d’attributs assurant l’unicité de chaque enregistrement d’une entité, c’est-à-dire pour lesquels aucun enregistrement ne peut avoir les mêmes valeurs.

126.

Du moins dans les analyses, puisque la saisie de certaines données a tiré parti de la souplesse du type SQL Date pour conserver la précision des informations tirées des archives.