OFROU Bern
STRADA
Version 2.01
Guide d'introduction et d'exploitation
Rosenthaler + Partner AG Management und Informatik
Feldrebenweg 16 CH-4132 Muttenz 2
INSER SA ch. de Maillefer 36 1052 Le Mont-sur-Lausanne
Table des matières
Préface à la deuxième édition ... iii
1 Introduction... 1-3 1.1 Rôle du guide... 1-2 1.2 Structure du guide... 1-3 1.3 Normes ... 1-4 2 Considérations générales sur les banques de données... 2-5 2.1 La notion de "Banque de données"... 2-5 2.2 Niveaux d'abstraction des données... 2-6 2.3 Terminologie du modèle de données relationnel... 2-9 3 La Banque de données routières STRADA-DB ... 3-13 3.1 Organisation et structure des données dans STRADA-DB ... 3-13 3.1.1 Organisation structurelle d'une banque de données réparties ... 3-13 3.1.2 Organisation fonctionnelle d'une banque de données réparties ... 3-14 3.1.3 Eléments constitutifs des enregistrements ... 3-15 3.2 Règles générales pour la création des clés d'identification... 3-17 3.2.1 Généralités ... 3-17 3.2.2 Règles de création... 3-17 3.3 Catalogues de connaissances (catalogues de textes) ... 3-18 3.3.1 Mode de fonctionnement des catalogues de textes... 3-18 3.4 Référence temporelle des données routières (historique)... 3-24 3.4.1 Référence temporelle ... 3-24 Historique / Versions... 3-26 3.4.2 ... 3-26 3.4.3 Aperçu référence temporelle/historique ... 3-27 3.4.4 Consistance temporelle dans STRADA-DB... 3-27 3.4.5 Paramètres temporels pour la sélection ... 3-28 3.4.6 Effektiv ... 3-32 3.4.7 Conclusions ... 3-32 4 Données : Aperçu des types d'objet... 4-33 4.1 Repérage dans l'espace des données routières...34
4.2 Description de la route...38
4.3 Evénements dans l’espace routier...40
4.4 Entretien d’exploitation ...40
4.5 Entretien constructir et reconstruction...40
4.6 Contrôles et relevés d'état...41
4.7 Modèles et simulation...41
4.8 Direction du SGE ...41
4.9 Administration de la banque de données...42
4.10Structure des types d'objets d'information dans l'annexe 1...42
5 Fonctions et traitements ...46
5.1 Aperçu du système général DB et View...46
5.2 La structure fonctionnelle (hierarchique) STRADA-DB ...46
5.3 Fonctions-hiérarchie (3 niveaux)...47
Versions et remarques
Version Date Commentaires Statut
1.80 30.11.2005 Übernahme Leitfaden 2002 und Korrekturen in Bearbeitung
1.90 03.01.2006 Review Ro/CM Zum Internen Review
2.00 03.01.2006 freigegeben
2.01 31.03.2006 Traduction française Libéré
Préface à la deuxième édition
La version 2.00 du présent guide d'introduction et d'exploitation STRADA, la banque de données routières pour la gestion des routes, est une version remaniée de la version 1.00 de janvier 2002.
Le mandant est l'OFROU. Les réflexions suivantes ont conduit à la mise à jour du présent guide:
− description de l'état actuel du projet de banque de données routière pour le SGE.
− mise à jour des références aux normes en vigueur actuellement.
− synchronisation des contenus avec le produit STRADA.
− publication conjointe d'une version française et d'une version allemande Changement de nom
STRADA (STRAssen-DAten) est le noyau du système d'information des routes pour l'ensemble du domaine de la gestion des routes, dont les principaux sous-systèmes sont:
− la banque de données routières STRADA-DB
− les applications de gestion on-line et les interfaces ASCII pour la saisie et l'échange des données routières
− les applications de gestion, en particulier STRADA-INFO pour la gestion combinée, de même que les outils d'édition correspondants.
− les applications de visualisation STRADA-View/AxeTendu et STRADA-View/Carto
− les modules spécifiques comme par exemple STRADA-PMS et STRADA-Trafic
Fig. 1: Architecture générale STRADA
1 Introduction
p:\9010\64\rm-g001a.dsf utilisateur
Interface STRADA / ASCII Interface STRADA / échange RADEF (TERN) Gestion (on-line) STRADA-INFO
STRADA- View
Listes, p. ex.
MS-Access
graphiques MS-Excel
...
p. ex. PMS p. ex.
Trafic -
STRADA-DB/Joker
données de base données générales
données et views (vues) compactées
ev. ev.
STRADA-DB Interface STRADA / ASCII
DB DB
Réseaux
Géométries ...
source des données utilisation des données
autres STRADA-DB
Données
spécialisées Données
spécialisées Données
spécialisées
...
STRADA-DB / trafic
1.1 ROLE DU GUIDE
La réalisation d'une banque de données routières (BDR) comme noyau du système d'information du domaine routier est une opération complexe de grande envergure. En effet, les données qui seront introduites et exploitées dans la banque de données ont une durée de vie très grande, dépassant largement celle des systèmes informatiques et celle des logiciels. Elles représentent par conséquent le véritable capital d'une banque de données.
Dès lors, il est indispensable de suivre un processus de modélisation rigoureux qui assure l'indépendance des données de toute contrainte informatique. Il devient ainsi possible de garantir à chaque utilisateur l'exploitation des données gérées dans la banque de données, quelle que soit l'évolution future des systèmes informatiques.
De plus, la réalisation et l'exploitation d'une banque de données routières implique que les différents partenaires intervenant dans un tel projet fassent preuve, à différents niveaux, de la maîtrise d'un large éventail de compétences. Il convient en effet de prendre en considération aussi bien les compétences qui relèvent du métier pour lequel les outils informatiques sont développés (pour STRADA-DB, compétences au niveau du SGE), que celles qui relèvent du domaine de l'informatique.
Le projet STRADA-DB prend en compte cette approche différenciée selon les compétences et les objectifs des différents partenaires et utilisateurs, notamment par la structure de la documentation qui accompagne à chaque niveau le développement du projet et la mise en oeuvre des applications. Pour les responsables du SGE, les utilisateurs et les informaticiens des services concernés, trois types de documents sont établis:
- Le guide d'introduction et d'exploitation décrit d'une part les aspects essentiels de la banque de données routières vus sous l'angle du spécialiste du domaine routier. Selon la terminologie propre à l'analyse des systèmes d'information, il recouvre la description sémantique d'une banque de données.
D'autre part, ce guide regroupe toute une série d'expériences d'utilisateurs permettant au responsable de l'introduction et de l'exploitation de la banque de données routières de faciliter l'accès de son contenu auprès de chacun au sein du service.
- Le manuel utilisateur décrit dans le détail toutes les procédures et les opérations nécessaires à l'utilisation des applications informatiques de STRADA-DB.
- Les manuels système rassemblent l'ensemble des thèmes nécessaires à la gestion informatique du système STRADA.. Ils portent sur le développement, l'installation et la maintenance des logiciels.
L'aperçu de la page suivante présente ces différents aspects en mettant en évidence les rôles des types de documents en regard des différents domaines d'utilisation.
Fig. 2: Documentation standard STRADA-DB
Le présent "Guide d'introduction et d'exploitation" s'adresse prioritairement aux utilisateurs concernés par STRADA-DB. Il a pour objectif premier de présenter une approche structurée qui va de la réalité des données routières à leur représentation abstraite et simplifiée dans la banque de données. Il aborde également les problèmes d'organisation liés à la mise en oeuvre, au levé, à la saisie et à la conservation de chaque objet d'information traité..
1.2 STRUCTURE DU GUIDE
Le "Guide d'introduction et d'exploitation" est composé d'un document principal et des annexes correspondantes. Le document principal s'ouvre sur une introduction (chapitre 1) suivie de la description de quelques notions fondamentales relatives aux banques de données (chapitre 2) complétées des aspects fondamentaux de la banque de données routières STRADA-DB (chapitre 3). Les données (chapitre 4) et les fonctions (chapitre 5) sont décrites ensuite avec un accent particulier sur la structures des données. Ces dernières sont par ailleurs décrites de manière très détaillée dans les annexes. Les chapitres 6 à 10 présentent pour leur part, les aspects de gestion de l'introduction et l'exploitation d'une banque de données routières: environnement du système, organisation, démarches et procédures, aspects
Hardware, réseaux, système d'exploitation, procédure d'installation, Updates, copies
de sécurité Compéte
nce informatiqueCompétence métierCoordination
Domaine
Maîtrise du domaine métier
Maîtrise de l'installation (plateforme)
Reconnaissance des problèmes et des solutions Connaissance des modes d'application des méthodes et des technologies
Formulation du problème conformément au modèle Choix de l'instrument adéquat
Aspects organisationnels Maîtrise de l'introductionde l'instrument
Usage correct et efficace des software
Garantie de la disponibilité et de la fiabilité des software
Objectifs pour STRADA-DB
Guide pour l'introduction et l'exploitation
Manuel utilisateur
Manuel système
Normes
Maîtrise des instruments au niveau fonctionnel
Maîtrise des
instruments au niveau opérationnel
Procédure d'utilisation Menu
Interface utilisateur Standards d'utilisation
Principes d'application des méthodes pour les fonctions et instruments
Terminologie, normes, connaissances de base, savoir méthodique et technique
juridiques et financiers, assurance qualité, aspects technologiques, administration et documentation. Les chapitres 6 à 10 ne contiennent pour l'heure que quelques exemples, de manière à indiquer la direction de l'évolution future du guide.
En raison de leur taille et de la dynamique importante de leur contenu, les informations qui décrivent le détail de chacun des domaines sont regroupé séparément dans l'Annexe 1 du présent guide.
Dans l'annexe 1, les données routières sont décrites au niveau sémantique. Afin d'assurer la cohérence du guide avec les normes VSS et donner une meilleure vue d'ensemble au lecteur, cette annexe du guide est divisée en chapitres. Chacun d'eux recouvre ainsi un des domaines du catalogue de données décrit au chapitre 9 de la norme VSS SN 640 909.
1.3 NORMES
Les normes suivantes recouvrent l'essentiel des connaissances du domaine des systèmes de gestion et d'information de la gestion des routes sous une forme standardisée. A ce jour, les normes traitant du domaine du repérage spatial des données routières font l'objet d'une importante révision. La liste n'est pas exhaustive:
SN 640 000 Planification et projets, recensement dans les transports
SN 640 900a Gestion de l'entretien (GE); norme de base, y compris annexe Systématique des termes
SN 640 901 SGE; Système des objectifs SN 640 902 SGE; guide pour la réalisation SN 640 909 Banques de données routières: base
SN 640 910 Système d'information de la route, norme de base
SN 640 911 Système d'information de la route, repérage linéaire; norme de base
SN 640 912 Système d'information de la route, repérage linéaire; système de repérage spatial de base SRB
SN 640 912-1 Système d'information de la route, repérage linéaire; système de repérage spatial de base SRB: assurage et matérialisation
SN 640 913 Système d'information de la route, repérage linéaire; géométries d'axes SN 640 914 Système d'information de la route, repérage linéaire; réseaux et leur topologie
SN 640 925b Gestion de l'entretien des chaussées (GEC); relevé d'état et appréciation en valeur d'indice
SN 640 925b Gestion de l'entretien des chaussées (GEC); mode opératoire pour le relevé visuel d'état avec le catalogue des dégradations
SN 640 926 Gestion de l'entretien des chaussées (GEC); relevé d'état visuel: indices individuels SN 640 931 Gestion de l'entretien; stratégies d'entretien pour les chaussées
SN 640 940 Norme; catalogue des données routières; principes fondamentaux, y compris annexe SN 640 940-1 Catalogue des données routières; données de base générales
SN 640 941 Catalogue des données routières: repérage dans l'espace
SN 640 942 Catalogue des données routières: géométrie et usage de l'espace routier SN 640 943 Catalogue des données routières: structure de la chaussée
SN 640 944 Catalogue des données routières: état de la chaussée SN 640 945 Catalogue des données routières: réparations de la chaussée SN 640 946 Catalogue des données routières: projet
SN 640 947 Catalogue des données routières: accidents de la circulation routière SN 640 948 Catalogue des données du trafic; principes fondamentaux
SN 640 948-1 Catalogue des données du trafic; données de base
SN 640 948-2 Catalogue des données du trafic; données du trafic selon séries temporelles
2 Considérations générales sur les banques de données
2.1 LA NOTION DE "BANQUE DE DONNEES"
Les banques de données jouent un rôle toujours plus important en informatique. Leur utilisation va de la simple gestion d'adresses jusqu'aux systèmes complexes de CAO (conception assistée par ordinateur). Alors qu'au début de l'informatique, les coûts portaient essentiellement sur le matériel ("hardware") puis par la suite sur le logiciel ("software"), ils se déplacent aujourd'hui de façon significative vers les données. Ce sont, par conséquent, ces dernières qu'il convient de particulièrement bien gérer et valoriser.
Par banque de données, il faut comprendre une organisation indépendante, flexible et pérenne des données, englobant un état de ces données, ainsi que des éléments de gestion. Les données peuvent être exprimées sous une forme structurée ou libre. Pour la gestion des données dans les banques de données, c'est en premier lieu la forme structurée qui est requise. Il est cependant souvent nécessaire de mémoriser également du texte sous une forme libre (p.ex. des documents entiers).
L'introduction d'une banque de données routières dans le cadre de la gestion routière est d'une grande importance. En effet, les données jouent un rôle essentiel dans l'exploitation des diverses applications informatiques. Dans les banques de données, la problématique se déplace du logiciel vers l'organisation des données, c'est-à-dire vers la manière et la méthode par lesquelles elles sont structurées et stockées. Pour une introduction rationnelle, il faut donc prêter une grande attention à l'organisation des données.
L'introduction d'une banque de données comprend trois activités essentielles : - la phase de projet de la banque de données,
- la saisie et la gestion des données, - la requête et la présentation des données.
La phase de projet d'une banque de données englobe l'élaboration du concept de la banque de données. Une banque de données simple peut être constituée essentiellement par une table divisée en colonnes (les champs d'une banque de données) et en lignes représentant chacune un enregistrement. Initialement, il faut définir l'aspect de la banque de données, puis il faut fixer la structure des données et ses interdépendances avec le domaine d'application, particulièrement le nom, le type et la dimension des champs de données.
Les champs de données peuvent être de différents types. Chacun fixe quels types de données sont saisis par champ, notamment les textes usuels (alphanumérique), les nombres (numérique), les valeurs logiques (oui/non), les dates (date), etc.
Les données sont saisies et gérées selon la structure définie. On peut également, à l'aide de masques de saisie, apporter des modifications aux données (mutations). Après saisie, les données peuvent faire l'objet de traitements. Pour ce faire, des langages dits de manipulation de données (Data Manipulation Language, DML) ont été développés; ils rendent possible l'accès aux données d'une banque de données.
Deux actions distinctes peuvent être effectuées sur une banque de données : la requête (interrogation) et la présentation des données. Lors de la requête, on détermine, grâce à une condition de filtre, la partie désirée de la banque de données. La présentation des données sert à visualiser les données sélectionnées. Des statistiques (sous forme numérique ou graphique), portant sur l'ensemble ou une partie des données de la BDR, peuvent en être extraites.
L'accès aux données peut s'effectuer de manière différente, selon les groupes d'utilisateurs. Des interrogations et des manipulations fréquentes sont programmées, alors que, pour des interrogations occasionnelles, l'utilisateur formule sa question dans le langage standard de requête (SQL : Standard Query Language).
Sur le support mémoire, les données ne sont, en règle générale, pas enregistrées selon l'ordre de saisie. Les banques de données peuvent être ordonnées au moyen du tri dit indexé, dans lequel on associe aux données des listes de tri sur lesquelles seuls les critères de tri figurent. La suite des données est, de la sorte, indiquée par le numéro d'enregistrement. On peut ainsi définir pour chaque application les tris les plus appropriés.
2.2 NIVEAUX D'ABSTRACTION DES DONNEES
Dans une banque de données, la partie du monde réel déterminante pour le domaine traité est représentée.
Pour une donnée d'adresses, ce ne sont évidemment pas les personnes, mais les informations relatives à ces personnes qui sont introduites.
En faisant une telle représentation, les six niveaux de données suivants sont considérés : 1. Réalité: monde réel
Dans le monde réel, il existe des objets concrets ou abstraits au sujet desquels des informations sont gérées. Ces objets d'information peuvent comporter de nombreuses propriétés ou caractéristiques. Un groupe d'objets d'information présentant les mêmes propriétés et caractéristiques peut être décrit par un type d'objet d'information.
2. Niveau sémantique: description sémantique des données issue de l' "analyse de l'information"
Les types d'objets d'information significatifs du monde réel sont pris en compte dans la description sémantique des données. Ils sont définis par leurs attributs (propriétés et caractéristiques), par leur genre et mode d'existence dans le monde réel et par leurs fonctions. Les associations entre types d'objet d'information sont représentées.
3. Niveau conceptuel: schéma conceptuel des données
Le schéma conceptuel des données décrit, au moyen d'un langage standardisé et adapté aux besoins informatiques, la partie du monde réel modélisée dans la banque de données. Pour les BDR, il est établi sur la base du modèle de données relationnel (voir chapitre 2.3).
4. Niveau logique: schéma logique de la banque de données, dépendant du système de gestion de banque de données (DBMS)
L'application du schéma conceptuel des données à un système de gestion de bases de données déterminé est effectuée à l'aide d'un langage de description (schéma logique de la banque de données).
5. Niveau physique: schéma interne de banque de données ("files", "records", etc.) 6. Niveau hardware: langage machine ("bits", "bytes").
Des ensembles standards pour banque de données (DBMS) dispensent l'utilisateur de considérer les niveaux 4 et 5. Le langage DBMS (langage de 4ème génération, 4GL) permet la représentation du modèle conceptuel dans un schéma logique de banque de données, en résolvant par lui-même les pas manquants.
Réalité ou monde réel Avec ses objets d’information - objets concrets ou abstraits - fonctions ou événements - organisation et démarches
Application Organisation
4. pas 3. pas
2. pas 1. pas
Schéma logique de banque de données pour
le DBMS-Software A (schémas externes) Schéma
conceptuel fonctionel
Analyse organisationnelle Analyse des
fonctions
Intégrité, schéma conceptuel
des données
Schéma conceptuel organisationnel Analyse des
informations : Description sémantique des
données g
Schéma logique de banque de données pour
le DBMS-Software B (schémas externes)
Schéma physique de banque de données
SW-A (schémas internes)
Schéma physique de banque de données
SW-B (schémas internes)
9010\BER\Dmodel1.drw 17.12.90 RO/ros
Fig. 3: Niveaux d’abstraction pour la conception d’un système de BD
Fig. 4: Résultats de la modélisation de données
9010\BER\DMODEL.DRW 17.12.90 RO/ros
Modélisation des données indépendamment du software Analyse de l'information:
Modèle de données sémantique
Entités et leurs types d'entité
Vue des données standardisée:
Tuples en relations
Structure des données pour relationales DBMS
Lignes de tabelles
modèle de données physique
Système de classement existant
Réalité
Attributs
Domaines de valeur Objet d'information =
"choses" du monde réel (incl. normalisation)
Colonnes Domaines
Relations types de relations
Clé sémantique
Clés conceptuelles (primaire)
Champs Procédures
Procédures, files, blocs, enregistrements Relations entre
objets d'information représentation de la réalité
Définition nouvelle clé sémantique
nouveau
système de classement
externe: interne:
Enregistrements dans des files, des blocs,...
- Top- Down par étapes clairement définies - selon certaines règles: procédé + but (modèle de -)
MODELISATION DES DONNEES: analyse et synthèse des structures de données
Clés externes et clé de système (y. c. règles) Règles (Bez.-) Tabellen Colonnes Règles
Champs, indices proccédures Modèle conceptuel des données
Cardinalités Bez.- Relationen
modèle de données logique
"Réalisation" logique et physique de nouveaux Système de classement, p. ex.
- système de repérage de base - référence temporelle Caractéristiques et domaine de valeurs
2.3 TERMINOLOGIE DU MODELE DE DONNEES RELATIONNEL
Applications pilotes Par applications pilotes, on comprend des applications qui contiennent le modèle de données complet selon le concept STRADA 2000, mais qui ne disposent que de fonctions de base minimales quant à la gestion des données.
Association
(Anglais : relationship)
Une association est la combinaison d'une correspondance (01, 02) avec sa correspondance inverse (02, 01).
Exemples :
Chaussure gauche - chaussure droite (1-1)
A chaque chaussure gauche appartient exactement une (1) chaussure droite / à chaque chaussure droite appartient exactement une (1) chaussure gauche
Axes - points de repère (1 - mc)
Des axes peuvent avoir aucun, un ou plusieurs (mc) points de repère - un point de repère appartient à un axe et un seul (1).
Intervenant - accident (m - mc)
Un intervenant peut avoir aucun, un ou plusieurs (mc) accidents - un accident a au moins un (m) intervenant.
Attribut
(Anglais: attribut)
Représentation d'une caractéristique d'un type d'objet d'information au stade de la modélisation des données. Un attribut (caractéristique) est la description d'une certaine propriété des objets d'informations d'un même type (p.ex. épaisseur d'une couche de revêtement).
Une telle propriété peut qualifier, identifier, classer, quantifier ou décrire un état. Chaque objet d'information peut n'avoir en un temps donné qu'une seule valeur par attribut : 1ère forme normale. Des attributs qui ne font pas partie de la clé d'identification (primaire) doivent dépendre seulement et complètement de cette clé (2ème et 3ème formes normales). Les attributs locaux sont des attributs qui n'apparaissent qu'à l'intérieur d'un seul objet d'information.
Champ de données Plus petite unité de donnée qui peut être identifiée
Clé Une clé est une caractéristique par laquelle on distingue des ensembles d'objets d'information.
Une clé de tri fixe l'ordre et une clé de recherche détermine un critère de recherche.
Clé conceptuelle Une clé conceptuelle est une clé d'identification significative pour l'utilisateur.
L'unicité au niveau suisse de cette identification est garantie par le responsable de la clé, dont la clé d'identification fait partie à cet effet de chaque clé conceptuelle.
Cette méthode est comparable à l'établissement des numéros d'immatriculation des voitures. Le numéro complet (p. ex. NE 33956) est la clé d'identification de la voiture, alors que "NE" identifie le responsable de clé. Chaque canton peut remettre et administrer lui- même ses numéros, une attribution de clés d'identification identiques par des cantons différents n'est pas possible grâce au responsable de clé.
Clé d'identification Une clé d'identification sert à la désignation univoque des objets d'information.
Elle évite de confondre des objets d'information possédant les mêmes caractéristiques (p.ex. deux personnes avec les mêmes noms et prénoms). Une clé d'identification usuelle est, p.ex., le numéro AVS Clé étrangère Une clé étrangère est un attribut dont les valeurs sont celles de la clé
d'identification d'un autre objet d'information.
Consistance La consistance est la cohérence de la description formelle et du contenu d'une banque de données.
Correspondance Une correspondance (01, 02) détermine combien d'objets d'information du type 02 peuvent être associés à un objet d'information de type 01.
Chaque correspondance est d'un type déterminé : Type 1 exactement une
Type c aucune ou une Type m au moins une
TYPE mc aucune, une ou plusieurs Domaine de valeurs
(Anglais : domain)
Un domaine de valeurs est l'ensemble des valeurs qui peuvent être associées à un attribut.
Ce domaine peut être défini par des règles ou par énumération de toutes les valeurs. Un domaine de valeurs statique ne se modifie pas au cours du temps (p.ex. les jours de la semaine, une échelle de notes, tous les jours de l'année 1989). Un domaine de valeurs dynamique peut évoluer (nouveau numéro de projet si un projet est mis en oeuvre). Des relations entre des types d'objets d'information peuvent être définies seulement s'ils comprennent des attributs ayant des domaines de valeurs comparables.
Enregistrement Ensemble des champs de données d'une table associée à une version d'un objet d'information
Intégrité
(Anglais: integrit)
L'intégrité des données comprend la consistance, la pérennité et la complétude des données, de même que la sécurité de conservation et la protection de leur accès.
Modèle de données Règles de représentation des données et de leurs associations selon un formalisme de description unifié
Objet d'information Objet concret ou abstrait du monde réel ou projeté au sujet duquel des informations sont enregistrées. L'abstraction d'un objet d'information au niveau de la description sémantique des données est appelée usuellement une entité. Dans le présent guide, le terme objet d'information est utilisé aussi bien pour la réalité que pour l'abstraction d'un objet.
Exemples :
Axe de maintenance VD:2100 "Lausanne-Genève"
M. Jean Meier
Redondance S'il existe de la redondance dans une banque de données, une partie de l'ensemble des données peut être abandonnée sans qu'il n'y ait perte d'information.
Table Plusieurs enregistrements appartenant à un même type d'objet d'information
Transaction Une transaction est une opération sur une banque de données au terme de laquelle la consistance reste maintenue (p.ex. passation d'écriture dans un système de comptabilité : après la transaction, les sommes des colonnes "doit" et "avoir" sont comparées).
Type d'objet d'information Classe d'objets d'information qui est décrite par des propriétés ou caractéristiques comparables
Exemples : NOEUD
ACCIDENT Version
(d'un objet d'information)
Chaque modification significative pour le SGE, qu'elle porte sur les aspects temporels, spatiaux ou en rapport avec le contenu d'un objet, engendre une nouvelle version de cet objet d'information. Ces versions décrivent l'historique de l'objet d'information
Les banques de données routières sont établies sur la base du modèle de données relationnel. Ce modèle est largement développé dans la littérature spécialisée. C'est pourquoi seuls quelques principes essentiels sont rappelés ci-après.
Dans le modèle de données relationnel, les entités sont décrites dans des tables (relations). A chaque type d'entité (AXE, INTERVENANT, PROFIL GEOMETRIQUE, USAGE DE LA CHAUSSEE, etc.) correspond une table. Par la normalisation de toutes les tables, les structures complexes sont décomposées en tables simples, de façon à rendre possible une mémorisation des données sans redondance incontrôlée.
Chaque table comprend des colonnes et des lignes. Les colonnes correspondent aux attributs (caractéristiques) et les lignes décrivent les entités en tant qu'enregistrements
Un enregistrement comprend tous les champs de données appartenant à une version d'une entité. Chaque champ de donnée indique la valeur de l'attribut correspondant. Chaque enregistrement est déterminé sans ambiguïté par un attribut spécifique ou une combinaison de plusieurs attributs : la "clé d'identification".
Des associations entre tables peuvent être établies lorsque des attributs comparables interviennent dans plusieurs tables. Ces associations permettent de formuler des interrogations complexes.
Les banques de données relationnelles peuvent être étendues par l'introduction de nouveaux attributs ou de nouvelles tables, ceci sans conséquence pour les structures de données et les traitements existants. Elles répondent ainsi à l'exigence d'une grande souplesse d'évolution pour l'élaboration des BDR.
Fig. 5: Situation dans la réalité
Fig 6: Table (relation) du type d'entité PROFIL GEOMETRIQUE DE LA ROUTE (table partielle)
Propriétaire Axe Point de repère
Distance de
Largeur de la chaussée
Colonne
(Attribut) Champ de données Début de
validité
AG AG AG AG
123 123 123 123
56 56 58 58
50 70 110 130
0 +1.75 +1.75 0
7.50 11.00 11.00 7.50
1.00 1.00 1.00 1.00
1.50 1.50 1.50 1.00
7.1.93 7.1.93 7.1.93 7.1.93 Largeur de
la partie latérale gauche
Ligne
enregistrement d'un objet d'information Code de
situation
Distance à l'axe du milieu de la
Fin de validité repère
chaussée
Largeur de la partie latérale droite
56
58
60
1.00
1.50
1.00 1.00
11.00
7.50
1.00 50.0
70.0 130.0
AG:123 110.0
7.50 Axe
1.50
point de repère désignation du point de repère
milieu de la chaussée 1,75 largeur de la banquette (largeur gauche)
largeur du chemin piéton (largeur droite) largeur de la chaussée
projection du point de repère
Exemple: Type d'objet d'information PROFIL GEOMETRIQUE DE LA ROUTE
3 La Banque de données routières STRADA-DB Aspects fondamentaux
3.1 ORGANISATION ET STRUCTURE DES DONNEES DANS STRADA-DB (les textes des chapitres ci-après sont extraits de la norme VSS SN 640 940) 3.1.1 Organisation structurelle d'une banque de données réparties 1
Les données routières sont gérées de façon décentralisée par les services des différents propriétaires. Il s'agit principalement des services des routes et travaux publics des cantons et des communes. Ceux-ci exploitent, à cette fin et sous leur propre responsabilité une ou plusieurs BDR. En vue de l'échange, de la comparaison et de la combinaison des données, l'ensemble des BDR établies selon la norme SN VSS 640 940 forme un système interconnectable.
L'exploitation de banques de données décentralisées rend plus complexe le maintien de l'intégrité des données. Celle-ci est assurée par le respect de règles de modélisation des données et par des procédures de déroulement des opérations adaptées à cette organisation. Avant tout, une définition précise des droits des différents utilisateurs est nécessaire. Dans les BDR, ces droits sont réglés par des attributs de gestion.
L'échange des données entre les cantons, les communes, l'Office Fédéral des Routes (OFROU) et d'autres services de la Confédération est réalisé pour chaque propriétaire par une banque de données principale jouant le rôle de banque de données de communication. La définition des données de base indispensables pour assurer la cohérence des données échangées (clés d'identification des propriétaires et des banques de données, codes et textes structurés communs, etc.) est assurée par la VSS en tenant compte de la solution retenue par l'OFROU pour les routes nationales.
Les propriétaires de routes peuvent ainsi exploiter une BDR principale et, selon les besoins, plusieurs BDR subordonnées. L'identification de chaque BDR est assurée par les deux clés partielles suivantes : Responsable de clé (selon liste VSS).
Exemples : canton : VS
commune : 6248 (Sierre) Clé de la banque de données
Exemples: pour BDR principale d'un propriétaire : répétition de la clé du propriétaire : VS pour BDR subordonnée : clé définie par le propriétaire : 01
Le nom complet d'une BDR serait ainsi, à titre d'exemple : BDR principale : VS:VS
BDR subordonnée : VS:01
1 cf. annexe 1 : chapitre 9. Gestion de la banque de données
3 siehe Schulungsunerlagen STRADA-DB
Fig. 7: Organisation structurelle et architecture de communication
3.1.2 Organisation fonctionnelle d'une banque de données réparties
Tous les flux de données suivent étroitement les chemins définis par la structure d'organisation et l'architecture de communication. Les chemins passent systématiquement par les banques de données principales.
Le déroulement de la saisie des données et de leurs modifications s'effectue selon les groupes d'opérations suivants :
Introduction d'un nouvel enregistrement (rôle de la BDR originale)
L'utilisateur de la banque de données introduit, en plus des données significatives, la clé conceptuelle du nouvel enregistrement. Les attributs de gestion sont en principe attribués par le système. La BDR dans laquelle le nouvel enregistrement a été créé est la première BDR de l'original de l'enregistrement.
Modification des données significatives d'un enregistrement (rôle du responsable de données) Des données significatives ne peuvent être modifiées que dans la banque de données où se trouve l'original de l'enregistrement et seulement par un utilisateur autorisé du responsable de données, et faisant partie du groupe d'utilisateurs spécifié. Si le changement de la réalité d'un objet d'information décrit par cette modification est effectif et pour le SGE significatif, une nouvelle version de l'objet d'information est créée. Les corrections d'erreurs n'engendrent pas de nouvelle version.
Modification de la clé conceptuelle d'un objet d'information (rôle du propriétaire de clé)
La plupart des objets d'information ont, pour les identifier, une clé conceptuelle. Des modifications de cette clé sont rares et ne peuvent être effectuées que par le propriétaire de la clé. Des modifications des clés conceptuelles conduisent toujours à la création d'une nouvelle version.
Changement du responsable de données ou du groupe d'utilisateurs d'un enregistrement
D A T E N A U S T A U S C H Schweiz
(Bund)
Kantone
Gemeinden
Dritte
Firma XY
Gemeinde N Gemeinde M
Kanton A Kanton B
ASB
Hauptdatenbank der Gemeinde N
Sub-Datenbank der Gemeinde N
andere Stellen ASTRA
En cas de changement, le responsable de données actuel transmet ses droits à un nouveau responsable, en modifiant l'attribut correspondant. Ceci s'applique par analogie pour un changement du groupe d'utilisateurs.
Exemple : un responsable transmet des données à un autre pour mettre à jour ou compléter les enregistrements.
Copie d'un enregistrement dans une autre banque de données
Des enregistrements peuvent être copiés d'une banque de données à une autre. Des modifications apportées à l'original d'un enregistrement ne se répercuteront pas sur les copies. En cas de doute avant l'exploitation d'une copie, il est préférable de la régénérer.
Changement de localisation de l'original d'un enregistrement
Dans une organisation de banques de données décentralisées, il peut être nécessaire de transférer l'original d'un enregistrement dans une autre banque de données. Avant le transfert, l'attribut "BDR de l'original d'un enregistrement" prend pour valeur l'identifiant de la BDR destinatrice. Une copie de l'enregistrement doit être conservée dans la BDR d'origine. Elle est alors désignée comme telle.
Le changement de localisation de l'original d'un enregistrement implique généralement le changement du responsable de données et du groupe d'utilisateurs.
3.1.3 Eléments constitutifs des enregistrements
Un enregistrement est composé d'attributs généraux et d'attributs spécifiques.
Les attributs généraux comprennent les attributs de gestion (I), ainsi que les attributs de validité temporelle (II) et, le cas échéant les attributs de repérage dans l'espace (III). Ils font partie intégrante de tous les enregistrements de la BDR. Les attributs de gestion sont décrits dans l'annexe 1 / chapitre 9.1 Métadonnées pour le maintien de l'intégrité et les attributs généraux de validité temporelle au chapitre 3.4.1. Les attributs de repérage dans l'espace sont traités dans l'annexe1 / chapitre 1.1 Système de repérage de base dans l'espace (SRB) et points de repères d'aide.
En ce qui concerne les attributs spécifiques, il faut distinguer fondamentalement les attributs locaux des clés étrangères. Les attributs locaux sont relevés directement, p. ex. comme résultat de mesures ou de comptages. Ils sont décrits dans les normes d'application correspondantes.
Les clés étrangères (F) permettent de faire référence à des informations qui se trouvent dans d'autres tables. Les codes sont une forme de clés étrangères. Ceux-ci servent en particulier à l'appel de textes de caractère descriptif ou explicite. Dans l'enregistrement proprement dit, seul apparaît le code qui sert de clé étrangère pour des informations provenant d'une liste de codes, de la table des propriétaires ou d'un catalogue de textes. Les principes fondamentaux des systèmes de codes font l'objet du chapitre 3.3 Catalogues de connaissances (catalogues de textes).
Avec d'autres clés étrangères, on peut au besoin accéder à d'autres types d'objets d'information. Ceci peut servir notamment à se référer à des informations détaillées provenant des tables "Intervenant" et
"Document". Ces types d'objets d'information généraux sont traités à l'annexe 1 / chapitre 8.2 Organisation structurelle et annexe 1 / chapitre 8.8 Documentation (gén.).
Chaque enregistrement peut être complété par un attribut "Commentaire" permettant de formuler librement des remarques.
Fig. 8: Structure des enregistrements dans des tables (voir SN 640 940) (les chiffres se rapportent à la norme SN 640 940)
Listes de code
Catalogues de textes Propriétaires
Intervenants
Documents
Tabelle
"y"
Tabelle
"x"
Tabelle
"z"
I II III
Attributs décrits dans les normes d'application
Attributs généraux
Attributs spécifiques
I = gestion
II = validité temporelle III = repérage spatial
(le cas échéant)
Attributs généraux chiffre 12, 13
Systeme de codes et Catalogues de connaissances chiffre 16, 17, 18
Types d'objet d'information généraux
chiffre 14, 15 (propriétaires)
*
*Relation de clé étrangère à une autre tabelle
Attributs locaux / Clés étrangères /
Commentaire
"C" "E" "T" "F" "F" "F"
3.2 REGLES GENERALES POUR LA CREATION DES CLES D'IDENTIFICATION 3.2.1 Généralités
Chaque occurrence d'un objet d'information est identifiée de façon univoque par sa clé d'identification.
Cette clé peut être identique au nom de l'objet, comme p.ex. le nom d'un axe, d'un itinéraire, d'un numéro d'arrondissement, d'une commune, etc.
Dans la réalité cependant, les objets d'information sont le plus souvent déterminés par un nom qui n'assure pas l'identification univoque de l'objet réel considéré. Dans la banque de données cependant, chaque objet doit être identifié pour un propriétaire donné, par sa clé d'identification qui elle, doit être unique et ne comporter aucune ambiguïté.
Pour cette raison, STRADA gère deux systèmes de clés. Des clés d'identification explicites sont d'une part définies en tant que clés conceptuelles. Parallèlement, et de façon indépendante, chaque objet d'information comporte une clé primaire appelée clé de substitution. C'est sur cette clé de substitution que sont construites toutes les relations entre les clés étrangères (voir chapitre 2.3) des objets d'informations. Ceci permet à l'utilisateur d'effectuer tous les changements qu'il désire au niveau de la clé conceptuelle sans risque d'inconsistance.
3.2.2 Règles de création
Les règles suivantes doivent impérativement être respectées afin d'éviter des problèmes imprévus lors du travail avec les données:
- Le nom doit être aussi court que possible.
- Des combinaisons de lettres et de chiffres peuvent s'avérer judicieuses.
- Si combinaison de lettres et de chiffres, commencer par des lettres.
- Créer des clés ne comportant que des majuscules.
- Dans la mesure du possible, ne pas utiliser des attributs ou des caractéristiques de l'objet dans le contenu du nom.
- Dans la mesure du possible, attribuer des noms dont l'ordre alphabétique respecte le classement des objets entre eux.
- En cas de clés combinant chiffres et lettres, proscrire le 0 et le O.
- Minimiser l'usage des signes "," "." "/" et "_" , car ils peuvent avoir des signification propres qui ne sont pas identiques dans tous les systèmes d'exploitation ou DBMS. Le signe '-' peut être utilisé dans les noms.
- Proscrire l'usage d'accents ou de trémas.
- En cas de clé comportant une structure mnémotechnique, ne pas créer de suite de 0 pour les champs non utilisés.
- Ne pas créer d'espace à l'intérieur d'une clé.
3.3 CATALOGUES DE CONNAISSANCES (CATALOGUES DE TEXTES)
Les utilisateurs de banques de données doivent pouvoir mémoriser des informations composées, en plus des informations élémentaires exprimées par des noms, des valeurs numériques ou des dates. Celles-ci peuvent être introduites sous forme de textes libres. Cette forme de mémorisation de l'information se prête très mal à des interrogations basées sur tout ou partie de son contenu, et la gestion de textes libres en différentes langues est particulièrement difficile. De plus, l'utilisateur de la banque de données est contraint d'écrire en toutes lettres ces textes lors de la saisie, ce qui implique un travail fastidieux comportant de fréquents risques d'imprécisions.
Une solution, qui permet d'éviter la mémorisation de textes libres, réside dans l'utilisation de listes de codes; les textes possibles pour la mémorisation d'une certaine information sont préalablement rassemblés dans une liste et munis d'un code d'identification (clé). Lors de la saisie, l'utilisateur donne le code à la place du texte complet, ce qui est plus fiable et accélère le travail de manière déterminante. En outre, le contenu des informations peut être interrogé, exploité et traduit en plusieurs langues à partir de ce code.
(p.ex. P: planifié, E: effectif).
Dans le sens usuel, les listes de codes sont des listes linéaires, c'est-à-dire que l'ensemble des choix possibles est rassemblé sous la forme d'une succession de valeurs. Si, pour un attribut donné, de nombreuses possibilités sont disponibles, la liste devient très longue et que la vue d'ensemble n'est plus possible. L'utilisation de systèmes de codes structurés constitue une réponse à cette problématique. . Dans le cadre de STRADA-DB, ces systèmes de codes structurés sont désignés comme catalogues de textes ou catalogue des connaissances. Ainsi, toutes les descriptions "verbales" qui soit comprennent de nombreux domaines de variation différents (et peuvent ainsi être structurées sous forme correspondante), soit doivent pouvoir être complétées et/ou modifiées par l'utilisateur, sont présentées dans STRADA-DB sous forme de catalogues de textes.
De cette façon, les données peuvent être disponibles en plusieurs langues. De plus, les problèmes liés à l'utilisation d'expressions différentes (redondances) pour signifier un même état de fait sont éliminés.
Les catalogues de textes structurés rassemblent une part importante des connaissances spécifiques au domaine de l'entretien des routes, et constituent ainsi une partie des méthodes et des règles du SGE.
Par la suite, nous utiliserons encore l'ancienne dénomination "catalogue de texte" pour la description des bases conceptuelles des ces catalogues. A l'avenir cependant, le terme de "catalogue de connaissances" devrait plutôt être utilisé.
3.3.1 Mode de fonctionnement des catalogues de textes
Chaque catalogue contient les textes qui correspondent à un domaine de valeurs que peut prendre un attribut. Un catalogue de textes s'apparente à une table dans laquelle chaque colonne (domaine) contient une caractéristique exprimée sous forme de textes dits élémentaires. Ces textes élémentaires peuvent ainsi apparaître dans n'importe quelle langue.
Les textes élémentaires sont combinés selon certaines règles pour composer les textes structurés. Les chemins d'accès expriment dans quel ordre les choix sur les textes élémentaires doivent être opérés pour sélectionner le texte final.
La saisie d'un texte est possible de différentes manières :
- le texte peut être fixé par l'entrée directe d'une clé courte et facile à retenir (abréviation). L'utilisateur trouve ces abréviations dans des catalogues imprimés ou dans l'affichage à l'écran de ces catalogues,
- l'utilisateur est conduit à travers l'application, d'un domaine à l'autre du texte et choisit dans chaque domaine le texte élémentaire souhaité. Le chemin d'accès fixe la séquence logique des réponses à donner : hiérarchie primaire !
- l'utilisateur détermine lui-même la suite des domaines à partir desquels il choisit les textes élémentaires: organisation libre et hiérarchique de tous les textes !
Les textes enregistrés peuvent être gérés jusqu'au niveau des textes élémentaires. Des changements dans l'usage de la langue, aussi bien dans les textes élémentaires que dans les textes complexes, peuvent être représentés dans les catalogues de textes. Les catalogues de textes structurés sont, dans le cas normal, étendus et actualisés au niveau des catalogues contrôlés par la VSS. Cependant, des catalogues de connaissances peuvent également être générés et gérés localement dans une banque de donnée par l'administrateur de la banque de donnée.
3.3.1.0 Aperçu
Une multitude de catalogues de textes sont utilisés dans STRADA-DB. Ceux-ci se réfèrent essentiellement au repérage spatial, à la description de la route, à l'état de la chaussée et aux aspects administratifs.
TYPES D'OBJET D'INFORMATION CATALOGUES DE TEXTES
AXE Type d'axe
POINT DE REPERE / SECTEUR Type de point de repère physique Type de plaquette
Type de marque
GEOMETRIE Type de géométrie
NOEUD Type de noeud
JONCTION Type de jonction
TOPO-RESEAU Type de topo-réseau
GEO-RESEAU Type de géo-réseau
USAGE DE LA CHAUSSEE Type d'usage
PARTIES LATERALES Type d'usage
Type de couche
STRUCTURE DE LA CHAUSSEE Type de couche
ACCIDENT Type d'accident
CHANTIER Type de chantier
Type d'entrave
REPARATIONS Type de réparation de la chaussée
VALEURS DE L'ETAT DE LA CHAUSSEE Type de contrôle CLASSES DE SURFACES DE ROUTES Type de contrôle
DOCUMENT Type de document
INTERVENANT Type de relation
Type d'en-tête
Type de caractéristique d'intervenant Type de fonction
PROJET Type de projet
PMS Type de mesure
Type de règle de formation de segment
Exemple:
A titre d'illustration du mode de fonctionnement des catalogues de textes, un exemple est présenté à partir du catalogue de textes Type de couche de structure.
Catalogue de textes Type de couche de structure (LAYTYP)
Description: Type des couches constituant le corps des chaussées
But: Etablissement du domaine de valeur des types de couche appropriés à la description de la superstructure des chaussées
Colonnes Couche (p.ex.. roulement/surface, liaison, support, fondation, etc.) (Texte élémentaire): Genre de matériau (p.ex. enrobé bitumineux, pavage, matériaux sans liant,
matériaux avec liant, imprégnation, etc.)
Sorte de matériau (p.ex. béton bitumineux (AB, HMT, TA), Grave bitume (HMF), béton armé, grave II, etc.)
Classe granulaire (p.ex. 3, 6, 8, 11, 16, 22, 32, etc.)
Type d'enrobé (p.ex. sollicitation légère (L), sollicitation normale (N), sollicitation sévère (S))
Genre de liant (p.ex. bitume (B), goudron (T), bitume-goudron (TB), Emulsion de bitume (ER, EM), Ciment Portland (CEM I), chaux hydratée, etc.)
Type de liant (p.ex. B40/50, B60/70, B80/100, ER60K, TB200/500 etc.) Additifs (p.ex. asphalte naturel, caoutchouc, matière synthétique,
polymère, pigment, etc.) Exemples textes: DRA 16, B101/150 avec polymères, C. de roulement
HMT 11N, B80/100, Remix Plus, C. de support Grave II 0/100, C. de fondation en matériaux non-liés
L'exemple ci-après présente un extrait du détail des colonnes et des textes élémentaires du catalogue de textes Type de couche de structure
En suivant toujours le même exemple du catalogue de textes Type de couche de structure, les trois illustrations qui suivent montrent comment les textes complexes sont constitués à partir des textes élémentaires contenus dans les différentes colonnes du catalogue texte.
3.4 REFERENCE TEMPORELLE DES DONNEES ROUTIERES (HISTORIQUE)3
La gestion efficace du domaine routier ne se satisfait pas seulement d'une connaissance de l'état actuel de la route et de sa fonction. D'autres connaissances sont aussi indispensables, dont notamment celles qui concernent l'évolution de la route dans le temps. C'est ainsi que les informations relatives aux modifications de la substance, à l'évolution de l'état, aux variations du trafic jointes à l'"histoire" (passé et futur) de nombreuses autres informations constituent des conditions-cadre essentielles pour la gestion des routes. Il doit être possible en tout temps de reconstituer une situation à un instant donné, resp. de déduire l'état actuel en se basant sur l'historique. On saisit ainsi dans STRADA-DB non seulement des données routières actualisées, mais également les informations référencées temporellement.
Dans la banque de données routières, on introduit à chaque enregistrement les indications de date et d'heure permettant des constats et des exploitations sur la validité temporelle des informations.
3.4.1 Référence temporelle
Les caractéristiques de validité temporelle d'un objet d'information, resp. d'une version correspondante, permettent des constats et des exploitations sur la durée pendant laquelle l'énoncé des donnée était, est ou sera vraie (= validité).
On considère ainsi trois attributs temporels:
− Début validité: indique le début de la validité temporelle d'un enregistrement
− Fin validité: indique la fin de la validité temporelle d'un enregistrement
− Date de référence: indique la date à laquelle la validité temporelle de la version a été établie (état des connaissances du responsable des données)
Attribut Source Format Description Exemple
DEBUTVALIDITE JJ.MM.AAAA et
evtl. hh:mm:ss Date du début de la validité de l'information 30.7.2005 FIN VALIDITE JJ.MM.AAAA et
evtl. hh:mm:ss Date de la fin de validité de l'information; peut
également être vide 17.8.2005
DATE DE
REFERENCE
JJ.MM.AAAA et
evtl. hh:mm:ss Date de référence de la validité temporelle 25.8.2005
Pour chaque type d'objet d'information, la description sémantique (annexe 1) établit selon quelles règles ces attributs temporels doivent être spécifiés et interprétés.
Attribut et source Description But Format Domaine de valeurs TEMPS Attribut selon "aspects
de validité temporelle“ : intervalle ouvert
Début de validité : instant à partir duquel tous les attributs de l’objet d’information sont vrais
Date JJ.MM.AAAA 19.04.1965
De même que pour la représentation spatiale, il est nécessaire de saisir également différentes dimensions pour décrire les aspects temporels. Selon la valeur prise par ces dimensions, le type
Figure 9: Extrait de la table des attributs du type d’objet d’information POINT DE REPERE /SECTEUR
d'objet d'information appartiendra à une catégorie temporelle spécifique. C'est ainsi que dans STRADA, on distingue trois catégories temporelles d'informations:
− Les événements sont des informations qui se réfèrent à un instant donné. Ils sont fixés temporellement de manière directe par l'indication de cet instant (p. ex. un accident). Un événement temporellement ponctuel est représenté par un intervalle fermé court. Des mutations ne sont envisageables que pour corriger des erreurs (pas de versions).
− Les activités sont des informations qui existent dans un intervalle temporel fermé avec un début et une fin définis (p. ex. un chantier). Des mutations ne sont envisageables que pour corriger des erreurs (pas de versions).
− Les états sont des informations qui se réfèrent à un intervalle temporel ouvert. Ils acquièrent leur référence temporelle par l'indication de leur début. Leur fin n'est pas encore connue, Leur état actuel sera "terminé" par un nouvel état (p. ex. une limitation de vitesse est valable
"éternellement", resp. jusqu'à nouvelle prescription). Le début de la nouvelle version définit la fin de la version actuelle. Si la validité de l'objet d'information devait être terminée, une fin est fixée (pour la "dernière" version). Pour les états, l'utilisateur doit différencier à chaque mutation s'il s'agit d'une correction d'erreur ou d'un changement affectant l'historique.
Il existe ainsi également pour l'aspect temporel les types d'étendue ponctuel, "de à" et continu.
La référence temporelle constitue un système de repérage simple (non spatial) des données routières.
3.4.2 Historique / Versions
Au cours de la vie d'une banque de données une multitude de mutations des enregistrements est effectuée, dont une partie doit être sauvegardée en tant qu'historique.
− Des mutations d'enregistrements sont nécessaires lorsque des attributs manquants ou erronés doivent être complétés ou corrigés. L'historique (versions) de telles mutations ne doit pas être sauvegardé. Dans ce cas, STRADA-DB sauvegarde automatiquement la date de changement et le nom de l'utilisateur opérant. Ces mutations peuvent être désignées comme corrections.
− Lors de mutations résultant d'une modification du SRB, l'historique du repérage de l'objet n'est pas pas sauvegardé. Il est en effet toujours possible de le reconstituer à partir de l'historique du SRB.
− Seule la description d'un état doit être mise à jour en tant qu'historique (n versions effectives).
Pour cela, on peut distinguer les états qui ne peuvent pas se recouvrir localement de ceux qui le peuvent. L'historique de chaque type doit être mis à jour. Les versions représentent des états au cours de la "vie " de cet objet d'information.
Une activité ou un événement peut ne pas posséder d'historique (1 version effective). L'objet est fermé et ne peut plus être modifié (à moins que l'entrée soit fausse, ce qui implique sa correction). C'est ainsi que selon sa nature, un travail peut être considéré comme un événement ou une activité, même si son exécution représente en fait un nouvel état (p. ex. pose d'une couche de revêtement).
La gestion de l'historique des enregistrements se fait par "duplication", c.-à-d. par la formation de versions. Chaque enregistrement pour lequel une modification ultérieure relative à l'objet d'information doit être sauvegardée est dupliqué. La version valable jusqu'alors est désignée comme
"historique" et la nouvelle version comme "active". Cette méthode permet l'élaboration d'enregistrements de manière standardisée, sans devoir tenir compte des ajouts. Cette formation de version ne s'applique qu'aux états.
Pour chaque objet d'information (activités ou événements) resp. pour chaque version (états), la forme d'existence de l'information sous-tendant l'enregistrement doit être indiquée:
− code de version "effectif": le constat se réfère à une chose effectivement présente.
− code de version "planifié": le constat suppose une prévision pour quelque chose d'effectif.
− code de version "modèle": l'information n'existe qu'en tant que modèle de réflexion (n'est pas implémenté dans STRADA)
Exemples (états):
− "Au cours de sa vie", un seul et même point de repère peut être signalé de manières différentes (changement de type de plaquette)
− "Au cours de sa vie", un usage (voie) peut servir à différents modes de trafic (changement de type d'usage)
− "Au cours de sa vie", une partie latérale (p. ex. piste cyclable) peut présenter différents revêtements (changement de type de couche)
− un texte issu d'un catalogue de connaissances peut voir sa dénomination changer tout en gardant sa même signification (p. ex. types de revêtement).
3.4.3 Aperçu référence temporelle/historique
TEMPS = date de référence + début validité (+ fin validité) Historique des ETATS Historique des ACTIVITES
n versions effectives- 1 versions effectives-
n versions planifiées n versions planifiées
(n versions modèles) (n versions modèles)
p. ex. pour objets d'information: p. ex. pour objets d'information:
Axes Structure de la chaussée (pose des couches de revêtement)
Points de repère Réparations de la chaussée
Profil géométrique Relevé de l'état de la chaussée
Usage de la chaussée Projets
Bandes latérales ...
Documents
Catalogues de connaissances
...
3.4.4 Consistance temporelle dans STRADA-DB
Versions effectives
La fin du prédécesseur marque le début du suivant.
La séquence des versions correspond à la séquence des date de référence.
Aujourd’hui Futur Passé
Date de référence
F
D F
D
D
Date de référence Date de référence
Date de référence
Versions planifiées
La chaîne des versions est formée par la séquence des dates de référence.
La planification de plusieurs versions, comme représentées par ex. au chapitre 3.4.4.1, est impossible.
Aujourd’hui Futur
Passé
Date de référence
D D
D D
Date de référence Date de référence
Date de référence Date de référence
3.4.4.0 Objets d'information dépendants
Des objets d'information ne peuvent être définis que lorsque l'objet "ancre" existe pendant la validité de l'objet dépendant.
ok
Aujourd’hui Futur
Passé
Date de référence
D
ok Axe
ok
D Type d’axe
F F
ok ok
Réparation couche
D Point de repère
D Profil géométrique
ok F D
Couche structure
Date de référence Date de référence
Date de référence
Date de référence
Date de référence
Date de référence
3.4.5 Paramètres temporels pour la sélection
Etat de départ
A l'origine, la sélection des états et des activités dans STRADA-DB était faite selon la vue des versions. Mais cette méthode présentait de nombreux inconvénients aussi bien pour les sélections que pour les calculs. D'une part, il était possible que plusieurs versions d'un même objet soient prises en
