La base de données Carolus

La base de données Carolus

Index de l'article

 

 

 

II. Modélisation de la base statistique

La conception d'un modèle d'organisation des données est une question centrale. Il fonde les qualités de la base qui en découle, telles que la robustesse, la cohérence, l'évolutivité ou la facilité d'exploitation. Le modèle, sous différentes formes qui s'enchaînent (conceptuelle, logique, physique) repose sur une analyse préalable menée selon un processus et des principes aujourd'hui bien établis.

• On peut concevoir le modèle en fonction de deux contextes :

Dans une première approche, on se limite au domaine statistique concerné – ici des séries annuelles sur l'éducation en France par départements. La base de données sera assez simple dans la mesure où toutes les séries ont une structure analogue. On envisagera ensuite l'intégration d'un tel modèle limité à un domaine dans une structure plus vaste apte à stocker des séries de structures plus hétérogène. On regroupera alors dans une même base plusieurs domaines statistiques, même s'ils n'ont a priori pas de rapport direct entre eux, dès lors que leur structure logique est identique, ou partiellement identique. Ainsi, la base CAROLUS regroupe des séries longues dans les domaines de l'économie de l'éducation, de la démographie, de l'emploi, de la protection sociale, des indices de prix, des brevets, ou des données sur les transports, qui ne sont pas a priori reliées entre elles (mais qui pourraient l'être). On pourra éventuellement prévoir plusieurs interfaces distinctes pour tenir compte des différences de contenu, ou d'intérêt pour les utilisateurs, mais l'organisation des données restera simple et unifiée. On retrouve ici une distinction entre base de données et entrepôt de données, ce dernier permettant de regrouper des données d'origine diverses et de nature hétérogène tout en assurant à l'utilisateur des possibilités d'exploration performantes.

Dans une base (ou un entrepôt), les données sont stockées dans des tables. On évitera de confondre cette notion avec celles de tableaux statistiques, ou de fichiers élémentaires (feuilles Excel par exemple). Une même table peut stocker des données issues de plusieurs tableaux (ou séries) relevant de domaines différents, à condition qu'elles aient une structure en partie commune. L'un des objectifs est de limiter le nombre de ces tables pour simplifier l'organisation de l'ensemble. Ainsi, on placera dans une même table toutes les données (ou ensembles de données) ayant la même structure logique (liste de champs typés) : une table est définie par son organisation et non par son contenu statistique. L'analyse conceptuelle et logique des données doit donc conduire à définir des tables et des relations entre elles autour d'un petit nombre de structures. On peut regrouper par exemple, dans une même table, toutes les données annuelles par département (ou par pays) quel que soit le domaine concerné.

• Avec un tableur, l'organisation des tableaux est calquée sur la présentation des séries primaires sur papier. Le décalage est généralement plus prononcé dans le cas d'une base de données relationnelle : la dimension visuelle devient secondaire, traitée dans un second temps, au niveau de l'interface. Priorité est donnée à la cohérence et à la robustesse de la structure de stockage des informations. La structure de la base doit permettre aux utilisateurs d'accéder aux données par des méthodes ‘presse-bouton', sans avoir besoin de connaître leur organisation et a fortiori sans avoir besoin d'intervenir sur cette structure : l'utilisateur n'est pas informaticien. En particulier, il faudra que la base se prête de manière transparente à des procédures (requêtes) de sélection des données selon diverses combinaisons de critères selon les besoins de l'utilisateur. Enfin, pour limiter la lourdeur des tâches d'administration, et viser l'efficacité, on cherchera à minimiser le nombre d'entités logiques (tables, fichiers..) et à normaliser leurs structures.

 

II-1 Entités fondamentales : données et séries

Les deux principaux objets statistiques pertinents pour l'utilisateur sont les séries et les données élémentaires qui les composent. Dans une base de données, il convient de distinguer ces deux entités, en identifiant d'une part les attributs propres aux séries, d'autre part les attributs caractéristiques des données. La liste et la nature des ces attributs doivent être définis au préalable, pour l'ensemble de la base, au terme d'une analyse qui peut admettre quelques variantes dans les choix possibles.

L'entité SERIE :

Elle correspond à une variable statistique observée dans le temps.
Les séries forment en quelque sorte une nomenclature des variables statistiques de la base.
Elle possède des propriétés spécifiques, indépendantes des valeurs de cette variable :

Code de la Série (identifiant unique)
Nom de la série
Unité de mesure, unique pour toutes les données de la série

On inclura également deux attributs intéressants pour les utilisateurs :

Code du Thème, renvoyant au thème de rattachement de la série ce qui permettra de travailler sur plusieurs séries simultanément (cf. infra)
Descriptif contenant informations diverses et commentaires éventuels
Source(s) des données primaires ( par exemple Annuaire Statistique…)
Auteur(s) ayant effectué le travail de saisie, correction, estimation, validation... pour transférer les données primaires vers des fichiers informatiques intermédiaires avant intégration dans la base.

En toute rigueur, une série peut avoir plusieurs sources (pour des périodes, donc des données différentes par exemple) ou plusieurs auteurs. Il faudrait donc considérer auteurs et sources comme des entités particulières, associées aux données plutôt qu'aux séries. Toutefois, l'indication des auteurs et des sources n'ont qu'un caractère informatif, peu structuré, qui n'exige pas le respect de normes strictes. En particulier, on suppose qu'ils ne serviront pas de critères pour sélectionner des données ou des séries dans la base. Pour simplifier, on stockera l'auteur (ou le groupe restreint d'auteurs) et l'énumération des sources directement dans l'entité Série, sous une forme textuelle libre. Tous les attributs de la Série sont de nature textuelle.


L'entité DONNEE :

C'est l'entité statistique minimale, considérée comme indivisible.
Outre son attribut essentiel (la valeur observée ou estimée), chaque donnée est identifiable par un code propre, dotée d'un statut, et doit être repérable dans le domaine couvert.

On distingue ainsi :

Code de la donnée (identifiant unique)
Valeur
Statut
{Coordonnées}

Valeur : il s'agit de la donnée statistique proprement dite, ici un nombre réel jusqu'à 15 chiffres, suffisant pour des données statistiques. L'unité de mesure est définie au niveau de la série.

Code ID : numéro identifiant unique attribué automatiquement à chaque donnée. Utile pour la gestion interne de la base, il n'apparaît pas à l'utilisateur.

Statut : origine de la donnée (0 = manquante, 1 = source externe, 2 = corrigée ou estimée par l'auteur, 4 = calculée d'après d'autres données de la base).
Cet indicateur permet notamment de ne pas créer de confusion entre données manquantes et donnés nulles, ou entre données observées et calculées. Il nous paraît d'autant plus pertinent que la base de données regroupe des informations d'origines diverses.

{Coordonnées} :
Elles situent chaque donnée particulière dans l'espace des observations : le temps, l'espace des variables, l'espace géographique.
Date : un nombre entier pour l'année puisque toutes nos données sont annuelles.
Pour d'autres échelles de temps, il faudra prévoir soit des tables de données distinctes (pour des séries trimestrielles, mensuelles etc.) soit plusieurs attributs de date (année, mois, jour, certains pouvant rester vides) qui seront combinés à la demande.
Code Série : renvoie à la série statistique d'appartenance de cette donnée, donc à la variable économique correspondante. Elle matérialise l'association donnée-série.
Code géographique : indique le département ou le pays de référence et renvoie à la nomenclature des zones géographiques. Les départements et les pays sont traités ici de la même manière, selon une nomenclature unique pour toutes les zones. Ce principe permet d'intégrer sans difficulté des maillages géographiques différent (Régions, Länder, ..), sans qu'il soit besoin de modifier la structure de la base pour la hiérarchiser.

Cette approche permet de traiter un découpage administratif instable, incluant des départements aujourd'hui disparus (Meurthe, Moselle, réunis en Meurthe & Moselle par exemple). Par son caractère général, cette nomenclature est également utilisable, telle quelle, pour d'autres domaines statistiques (brevets, transports,..) et pour d'autres bases de données [1].

Les statistiques que nous avons traitées, sur l'enseignement primaire en France, sont détaillées par Départements (zones administratives, au demeurant variables selon les périodes) ; pour d'autres pays, les statistiques sont nationales. Ainsi, pour l'Espagne, les données sont exclusivement fournies à l'échelle nationale. Pour la France il convient de distinguer les séries nationales qui se présentent comme telles à l'origine, et les statistiques nationales que nous pouvons calculer par agrégation de séries départementales. Les données nationales « primaires » et celles calculées par sommation peuvent différer, à la suite d'erreurs dans la source compilée. Pour éviter toute ambiguïté, les séries nationales calculables par sommation, mais ne correspondant pas à des documents primaires publiés, ne sont pas stockées dans la base ; seules y figurent les séries nationales d'origine. L'utilisateur devra donc, le cas échéant, consolider les séries détaillées.
A toutes fins utiles, rappelons que les séries et les valeurs calculées sont toujours « marquées » comme telles, par le code indicateur de leur ‘statut'.

La table des données est donc ainsi composée :

 

II-2 La structure centrale

Les entités Serie et Donnée étant ainsi définies, la base est structurée autour du modèle suivant (voir détails en annexe) :

On aurait pu associer la dimension géographique, non pas directement aux données, mais aux séries (séries départementales), selon un second modèle :

Cette spatialisation des séries et non plus des données entraîne deux inconvénients :

- La multiplication du nombre de séries, puisqu'il faudra autant définir autant de séries chronologiques distinctes que de départements différents, donc environ 100 fois plus, ce qui alourdit le travail de l'utilisateur, tant pour sélectionner que pour agréger les données.

- La reprise, pour chaque série départementale, de tous les attributs et propriétés spécifiques aux séries, avec les inconvénients liés à de telles redondances.

On peut quantifier facilement la différence entre les deux modèles :

Concernant l'espace de stockage, pour T années, D départements et V variables correspondant à S séries (non spatialisées), le premier modèle que nous avons adopté exige trois tables de taille respective:

T x V x D données spatio-temporelles, S = V pour la liste des séries, et D pour celle des départements, soit au total N = D x S x T + V + T lignes.

Dans l'hypothèse de séries spatialisées, leur nombre s'élèverait à S' = V * D et la table des données (avec le champ géographique en moins) contiendra encore T x S' = T x S x D lignes. Au total, on aurait alors multiplié par D le nombre apparent de séries, sans compensation significative.
Concernant le travail de l'utilisateur, la différence est également sensible, toujours au détriment du second modèle. L'accès aux données s'effectuant par la sélection préalable des séries (variables d'intérêt), l'utilisateur qui désire obtenir l'ensemble des données par départements, pour une variable, devra procéder, avec le second modèle, à D sélections successives parmi V x D séries, suivies d'autant d'exportations vers des feuilles de calcul, puis de la consolidation de la centaine de tableaux obtenus.

Avec le modèle que nous avons adopté, il suffit de sélectionner une seule série parmi V, pour récupérer dans une feuille unique l'ensemble des données désirées, sous la forme d'un tableau à deux dimensions (D x T) directement exploitable : les tâches sont sont cent fois moins nombreuses.

 

II-3 Le modèle en étoile et ses extensions

Le modèle central obéit à un schéma en étoile :

Ce type de modèle offre une bonne souplesse pour exploiter les données, selon différentes vues fondées sur des combinaisons de critères faciles à définir. Il est toutefois possible de lui apporter des extensions, sans perdre ce caractère étoilé.

L'objectif est double :

D'une part, en prolongeant les branches, on peut définir des entités plus larges, à l'image des nomenclatures hiérarchisées. On permettra ainsi à l'utilisateur d'opérer des regroupements de données, unions ou agrégats de séries ou de zones.

D'autre part, en créant de nouvelles branches, on peut adjoindre d'autres dimensions, pour des données économiques d'une autre nature. On pourra ainsi intégrer, dans une même base (ou un même entrepôt), des séries de données comportant d'autres dimensions (secteurs, institutions...).

Regroupements de données

L'analyse cliométrique exige généralement l'exploitation conjointe de plusieurs séries de données. Les regroupements de données peuvent certes toujours s'effectuer a posteriori, après exportation des séries dans différents fichiers (feuilles de calcul, tables SAS..).
CAROLUS permet cependant d'opérer des regroupements avant exportation, en utilisant les outils de requêtes SQL. Le travail de l'utilisateur est alors simplifié.
La notion de regroupement possède plusieurs significations, qui sont traitées différemment.

- Dans une base de données, une requête peut extraire, afin de les regrouper en une vue unique, des données issues de plusieurs tables liées, pour des champs sélectionnés dans chacune d'entre elles. Il s'agit de l'opération de projection. Dans le cas de CAROLUS, toutes les données observées sont stockées dans une même table DATA, et cette opération de projection n'est donc pas pertinente.

- Par regroupement, on peut aussi entendre « consolidation », agrégation, et plus généralement toute construction d'une nouvelle série de valeurs issue de calculs appliqués aux données initiales. Par exemple : population (Hommes) + population (Femmes) à population (Ensemble) ; ou encore : effectif enseignant / Effectif scolarisé à taux moyen d'encadrement, etc. Ces calculs sont légitimes mais risqués. Cette opération n'a de sens que s'il s'agit des mêmes années, mêmes secteurs, mêmes zones géographiques, et surtout s'il n'y a pas de données manquantes. Par prudence, ce type de regroupement n'est pas pris en charge par CAROLUS, l'utilisateur pouvant effectuer cette tâche cas par cas après exportation des séries concernées.

- On peut enfin regrouper des données en juxtaposant des séries.
Il s'agit plus précisément d'une opération d'union entre des ensembles de données qu'il est pertinent de visualiser ou traiter simultanément.

Regroupements de séries en thèmes

Sur l'axe des séries économiques, on rapprochera par exemple (sans calcul) des populations (hommes, femmes), ou des séries d'une même variable à des périodes différentes, ou encore des séries analogues mais de sources différentes. Dans le cas particulier de CAROLUS ou les données sont dans la même table, l'opération d'union s'effectue simplement par une sélection de séries, fondée sur la valeur d'un champ (‘sel') logique :

DATA X SERIE / SERIE.sel = true.

L'utilisateur n'a donc pas besoin d'intervenir dans la structure de la requête, il lui suffit de cocher les séries désirées, dans un formulaire construit à cette fin. La vue résultante fournira les données ‘empilées' des séries sélectionnées, qui peuvent être présentées dans un tableau à deux dimensions pour une meilleure lisibilité.
Certains regroupements de ce type paraissent naturels, et peuvent sont définis de manière permanente. Les regroupements de séries peuvent être prédéfinis, car ils se fondent sur une pertinence intrinsèque.
Un Thème correspond ainsi à un regroupement prédéfini de séries apparentées par leur contenu (par exemple : le thème « Dépenses pour l'enseignement primaire en France » contient plusieurs séries correspondant aux différentes origines ou destinations des dépenses).

Champs :
Code Thème (identifiant unique, cf. supra)
Nom du Thème
Rem (commentaires libres)

Cette entité THEME n'est pas indispensable à l'organisation logique fondamentale de la base. Sa fonction essentielle est de clarifier l'espace de travail des utilisateurs, en simplifiant leurs modalités d'accès à des données statistiques regroupées. Elle prolonge la branche DATA-SERIE, en introduisant en amont un niveau supplémentaire plus général.

Regroupements de zones géographiques

Sur l'axe géographique, l'utilisateur doit pouvoir construire à discrétion des zones (régions, groupes de pays..) par regroupement de zones élémentaires. On prévoira alors un niveau supplémentaire permettant de construire des espaces dont le contenu sera librement défini par l'utilisateur selon ses besoins. Selon le même principe que dans le regroupement de séries, il suffira de réunir toutes les données après avoir sélectionné et marqué les zones géographiques élémentaires : DATA X ZONE / Zone.sel = true.

 


Note :

[1] Cette approche efface toute hiérarchie a priori entre les zones géographiques. Dans le cas d'espèce, avec les seuls niveaux départemental et national, cet inconvénient est mineur. La solution consistera à établir une structure hiérarchisée de la nomenclature géographique, permettant à l'utilisateur de moduler la granularité spatiale de ses vues.

 

 

Migration Joomla effectuée par HOB France Services