Guide d'introduction et d'exploitation

Transcription

1 Bern STRADA Guide d'introduction et d'exploitation Rosenthaler + Partner AG Management und Informatik Feldrebenweg 16 CH-4132 Muttenz 2 INSER SA ch. de Maillefer Le Mont-sur-Lausanne Version

2 Guide d'introduction et d'exploitation STRADA-DB Table des matières i Table des matières Préface à la deuxième édition... iii 1 Introduction Rôle du guide Structure du guide Normes Considérations générales sur les banques de données La notion de "Banque de données" Niveaux d'abstraction des données Terminologie du modèle de données relationnel La Banque de données routières STRADA-DB Organisation et structure des données dans STRADA-DB Organisation structurelle d'une banque de données réparties Organisation fonctionnelle d'une banque de données réparties Eléments constitutifs des enregistrements Règles générales pour la création des clés d'identification Généralités Règles de création Catalogues de connaissances (catalogues de textes) Mode de fonctionnement des catalogues de textes Référence temporelle des données routières (historique) Référence temporelle Historique / Versions Aperçu référence temporelle/historique Consistance temporelle dans STRADA-DB Paramètres temporels pour la sélection Effektiv Conclusions Données : Aperçu des types d'objet Repérage dans l'espace des données routières Description de la route Evénements dans l espace routier Entretien d exploitation Entretien constructir et reconstruction Contrôles et relevés d'état Modèles et simulation Direction du SGE Administration de la banque de données Structure des types d'objets d'information dans l'annexe Fonctions et traitements Aperçu du système général DB et View La structure fonctionnelle (hierarchique) STRADA-DB Fonctions-hiérarchie (3 niveaux)...47 m-guidestrada-isb.doc Version 2.01 /

3 Guide d'introduction et d'exploitation STRADA-DB Versions et remarques ii Versions et remarques Version Date Commentaires Statut Übernahme Leitfaden 2002 und Korrekturen in Bearbeitung Review Ro/CM Zum Internen Review freigegeben Traduction française Libéré m-guidestrada-isb.doc Version 2.01 /

4 STRADA-DB Guide d'introduction et d'exploitation Préface à la deuxième édition 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 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 DB ev. p. ex. PMS p. ex. Trafic... - ev. DB Données spécialisées Données spécialisées Données spécialisées utilisateur autres STRADA-DB source des données utilisation des données Interface STRADA / ASCII Interface STRADA / échange RADEF (TERN) Gestion (on-line) STRADA-DB STRADA-DB/Joker Géométries Réseaux STRADA-DB / trafic... STRADA-INFO Interface STRADA / ASCII STRADA- View Listes, p. ex. MS-Access graphiques MS-Excel... données et views (vues) compactées données générales données de base p:\9010\64\rm-g001a.dsf Fig. 1: Architecture générale STRADA 1 Introduction m-guidestrada-isb.doc Version 2.01 /

5 Guide d'introduction et d'exploitation STRADA-DB 1 Introduction 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. m-guidestrada-isb.doc Version 2.01 /

6 Guide d'introduction et d'exploitation STRADA-DB 1 Introduction 1-3 Domaine Objectifs pour STRADA-DB Maîtrise du domaine métier Terminologie, normes, connaissances de base, savoir méthodique et technique Maîtrise des instruments au niveau fonctionnel Principes d'application des méthodes pour les fonctions et instruments Maîtrise des instruments au niveau opérationnel Procédure d'utilisation Menu Interface utilisateur Standards d'utilisation Maîtrise de l'installation (plateforme) Hardware, réseaux, système d'exploitation, procédure d'installation, Updates, copies de sécurité 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 Compétence informatique Coordination Compétence métier Normes Guide pour l'introduction et l'exploitation Manuel utilisateur Manuel système 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é 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 m-guidestrada-isb.doc Version 2.01 /

7 Guide d'introduction et d'exploitation STRADA-DB 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 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 Planification et projets, recensement dans les transports SN a Gestion de l'entretien (GE); norme de base, y compris annexe Systématique des termes SN SGE; Système des objectifs SN SGE; guide pour la réalisation SN Banques de données routières: base SN Système d'information de la route, norme de base SN Système d'information de la route, repérage linéaire; norme de base SN Système d'information de la route, repérage linéaire; système de repérage spatial de base SRB SN 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 Système d'information de la route, repérage linéaire; géométries d'axes SN Système d'information de la route, repérage linéaire; réseaux et leur topologie SN b Gestion de l'entretien des chaussées (GEC); relevé d'état et appréciation en valeur d'indice SN b Gestion de l'entretien des chaussées (GEC); mode opératoire pour le relevé visuel d'état avec le catalogue des dégradations SN Gestion de l'entretien des chaussées (GEC); relevé d'état visuel: indices individuels SN Gestion de l'entretien; stratégies d'entretien pour les chaussées SN Norme; catalogue des données routières; principes fondamentaux, y compris annexe SN Catalogue des données routières; données de base générales SN Catalogue des données routières: repérage dans l'espace SN Catalogue des données routières: géométrie et usage de l'espace routier SN Catalogue des données routières: structure de la chaussée SN Catalogue des données routières: état de la chaussée SN Catalogue des données routières: réparations de la chaussée SN Catalogue des données routières: projet SN Catalogue des données routières: accidents de la circulation routière SN Catalogue des données du trafic; principes fondamentaux SN Catalogue des données du trafic; données de base SN Catalogue des données du trafic; données du trafic selon séries temporelles m-guidestrada-isb.doc Version 2.01 /

8 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 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. m-guidestrada-isb.doc Version 2.01 /

9 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-6 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. m-guidestrada-isb.doc Version 2.01 /

10 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-7 Réalité ou monde réel Avec ses objets d information - objets concrets ou abstraits - fonctions ou événements - organisation et démarches 1. pas Analyse des fonctions Analyse des informations : Description sémantique des données g Analyse organisationnelle 2. pas Schéma conceptuel fonctionel Intégrité, schéma conceptuel des données Schéma conceptuel organisationnel Application 3. pas Organisation Schéma logique de banque de données pour le DBMS-Software A (schémas externes) Schéma logique de banque de données pour le DBMS-Software B (schémas externes) 4. pas 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 RO/ros Fig. 3: Niveaux d abstraction pour la conception d un système de BD m-guidestrada-isb.doc Version 2.01 /

11 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-8 MODELISATION DES DONNEES: analyse et synthèse des structures de données - Top- Down par étapes clairement définies - selon certaines règles: procédé + but (modèle de -) Réalité représentation de la réalité Modélisation des données indépendamment du software Analyse de l'information: Vue des données standardisée: Modèle de données sémantique Modèle conceptuel des données Structure des données pour relationales DBMS externe: interne: modèle de données logique modèle de données physique Objet d'information = "choses" du monde réel (incl. normalisation) Entités et leurs types d'entité Tuples en relations Lignes de tabelles Enregistrements dans des files, des blocs,... Caractéristiques et domaine de valeurs Attributs Domaines de valeur Colonnes Domaines Colonnes Règles Champs Procédures Relations entre objets d'information Relations types de relations Cardinalités Bez.- Relationen Règles (Bez.-) Tabellen Procédures, files, blocs, enregistrements Système de classement existant "Réalisation" logique et physique de nouveaux Système de classement, p. ex. - système de repérage de base - référence temporelle Clé sémantique Définition nouvelle clé sémantique nouveau système de classement Clés conceptuelles (primaire) Clés externes et clé de système (y. c. règles) Champs, indices proccédures 9010\BER\DMODEL.DRW RO/ros Fig. 4: Résultats de la modélisation de données m-guidestrada-isb.doc Version 2.01 /

12 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données TERMINOLOGIE DU MODELE DE DONNEES RELATIONNEL Applications pilotes Association (Anglais : relationship) Attribut (Anglais: attribut) Champ de données Clé Clé conceptuelle 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. 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. 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. Plus petite unité de donnée qui peut être identifiée 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. 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 luimê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é. m-guidestrada-isb.doc Version 2.01 /

13 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-10 Clé d'identification Clé étrangère Consistance Correspondance Domaine de valeurs (Anglais : domain) Enregistrement Intégrité (Anglais: integrit) Modèle de données Objet d'information Redondance Table 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 Une clé étrangère est un attribut dont les valeurs sont celles de la clé d'identification d'un autre objet d'information. La consistance est la cohérence de la description formelle et du contenu d'une banque de données. 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 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. Ensemble des champs de données d'une table associée à une version d'un objet d'information 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. Règles de représentation des données et de leurs associations selon un formalisme de description unifié 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 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. Plusieurs enregistrements appartenant à un même type d'objet d'information m-guidestrada-isb.doc Version 2.01 /

14 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-11 Transaction Type d'objet d'information Version (d'un objet d'information) 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). Classe d'objets d'information qui est décrite par des propriétés ou caractéristiques comparables Exemples : NOEUD ACCIDENT 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. m-guidestrada-isb.doc Version 2.01 /

15 Guide d'introduction et d'exploitation STRADA-DB 2 Considérations générales sur les banques de données 2-12 Exemple: Type d'objet d'information PROFIL GEOMETRIQUE DE LA ROUTE largeur de la banquette (largeur gauche) milieu de la chaussée 1,75 Axe largeur de la chaussée AG: largeur du chemin piéton (largeur droite) 60 projection du point de repère point de repère désignation du point de repère 58 Fig. 5: Situation dans la réalité Propriétaire Axe Code de Point de situation repère Distance de repère Distance à Largeur de l'axe du la chaussée milieu de la chaussée Largeur de la partie latérale gauche Largeur de la partie latérale droite Début de validité Fin de validité AG AG AG AG Colonne (Attribut) Champ de données Ligne enregistrement d'un objet d'information Fig 6: Table (relation) du type d'entité PROFIL GEOMETRIQUE DE LA ROUTE (table partielle) m-guidestrada-isb.doc Version 2.01 /

16 Guide d'introduction et d'exploitation STRADA-DB 3 La Banque de données routières STRADA-DB 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 ) 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 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 m-guidestrada-isb.doc Version 2.01 /

17 Guide d'introduction et d'exploitation STRADA-DB 3 La Banque de données routières STRADA-DB 3-14 Schweiz (Bund) Kantone Gemeinden andere Stellen Kanton A Gemeinde M D A T E N A U S T A U S C H ASTRA ASB Kanton B Gemeinde N Dritte Firma XY Hauptdatenbank der Gemeinde N Sub-Datenbank der Gemeinde N Fig. 7: Organisation structurelle et architecture de communication 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 m-guidestrada-isb.doc Version 2.01 /

18 Guide d'introduction et d'exploitation STRADA-DB 3 La Banque de données routières STRADA-DB 3-15 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 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 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. m-guidestrada-isb.doc Version 2.01 /

19 Guide d'introduction et d'exploitation STRADA-DB 3 La Banque de données routières STRADA-DB 3-16 I II III Tabelle Tabelle "z" Tabelle "y" "x" Attributs décrits dans les normes d'application Attributs généraux Attributs spécifiques Attributs locaux / Clés étrangères / Commentaire (propriétaires) "C" "E" "T" "F" "F" "F" * I = gestion II = validité temporelle III = repérage spatial (le cas échéant) Listes de code Propriétaires Intervenants Documents Catalogues de textes 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 * Relation de clé étrangère à une autre tabelle Fig. 8: Structure des enregistrements dans des tables (voir SN ) (les chiffres se rapportent à la norme SN ) m-guidestrada-isb.doc Version 2.01 /

20 Guide d'introduction et d'exploitation STRADA-DB 3 La Banque de données routières STRADA-DB REGLES GENERALES POUR LA CREATION DES CLES D'IDENTIFICATION 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 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é. m-guidestrada-isb.doc Version 2.01 /