Modélisation UML Des Données Géodésiques Et Implémentation En Objet Relationnel Sous Le SGBD Oracle 8i

Transcription

1 Modélisation UML Des Données Géodésiques Et Implémentation En Objet Relationnel Sous Le SGBD Oracle 8i Nassim DENNOUNI, Dr LEHIRECHE Ahmed Evolutionary Engineering and Distributed Information Systems Laboratory, EEDIS, Département d informatique, Université de Sidi Bel Abbès Phone/Fax: dennouninas@gmail.com, elhir@yahoo.com ملخص 3 في الجيوديزيا التعامل مع ملفات المعلومات يطرح عدة مشاآل مثل التكرار و عدم توافق المعلومات و ذلك خاصة أثناء زيادة أو حذف المعطيات و لهدا تعتبر منهجية قاعدة المعلومات آحل حتمي لهده المشكلة لكن يجب وضع نموذج ملاي م للمعلومات الجيوديزية. و لكي نقوم بوصف آامل للمعلومات الجيوديزية يجب استعمال لغة UML بهدف الاستفادة من مزايا هذه الطريقة لوضع نموذج خاص بالمعطيات يسمح بتفادي التكرار و عدم التوافق داخل قاعدة المعلومات وبعد دلك يترجم هدا النموذج إلى نموذج منطقي للمعلومات والدي سوف يحول بدوره إلى بنية يمكن لنظام تسيير قاعدة المعلومات ORACLEالتحكم فيها عن طريق مبدأ المشتري و المعطي. Résumé En géodésie, la gestion des fichiers des données géodésiques (points de géodésie classique, points GPS, données d altimétrie spatiale,...etc.) pose beaucoup de problèmes qui sont liés principalement à la redondance et la non cohérence des données et surtout aux différentes anomalies de mise à jour. Pour cela, l approche base de données est incontournable et le choix d une bonne modélisation des données est indispensable. Pour décrire la structure des données de la Base de Données Géodésiques (BDG), il faut choisir un langage de modélisation comme UML (Unified Modelling Langage) qui permet de bénéficier du vocabulaire précis de l approche objet pour créer un schéma conceptuel de données afin d éviter les redondances et les incohérences des données de la base de données à concevoir. Ce schéma sera traduit dans un modèle logique de données en objet relationnel qui sera implémenté sous forme d un modèle physique de données en utilisant le SGBD ORACLE 8i. Cette implémentation donne naissance à une base de données dans laquelle les mises à jour sont exécutées à un seul emplacement, les problèmes d incohérence des données sont éliminés, la recherche des données est rapide et la diffusion des données est facile grâce au mode client serveur. Abstract In geodesy, the geodetic data files management (traditional geodesy points, GPS points, altimetry space data...etc.) presents many problems which are related mainly on the redundancy and the coherence of the data and especially to the various anomalies of update. For that, the approach data base is impossible to circumvent and the choice of a good modelling of the data is essential. To describe the data structure of the geodetic data base, it is necessary to choose a modelling language as UML, which makes it possible to profit from the precise vocabulary of the approach object, to create a conceptual data diagram in order to avoid the data redundancies and the data inconsistencies of the data base and to be conceived. This diagram will be translated in a data logical model into relational object which will be implemented in the form of a data physical model by using the DBMS ORACLE 8i. This implementation gives rise to a data base in which the updates are carried out on only one site, the data inconsistency problems are eliminated, the data retrieval is fast and the data diffusion is easy, thanks to the mode customer server. Mots Clés: Modélisation UML, Base de Données Géodésiques, Objet Relationnel, SGBD Oracle, Altimétrie Spatiale. Page 1 sur 10

2 Introduction : La multiplicité des types d information que l on peut considérer en géodésie découle directement de la multiplicité des activités géodésiques. La géodésie effectue des mesures de types divers : Mesures terrestres classiques. (directions optiques horizontales, angles verticaux, ligne de base etc.) Mesures astronomiques. (azimut astronomique, déviation de la verticale, etc.) Mesure de géodésie spatiale. (GPS, altimétrie spatiale, SLR, LLR, DORIS etc.) Mesure de gravimétrie. Mesure de nivellement de précision. Ces mesures donnent naissance à plusieurs données hétérogènes et pour intégrer la structure de ces données dans une base de données géodésiques, trois voies peuvent être envisagées : la méthode MERISE, la méthode HBDS et le langage UML. Selon la méthode employée on obtient un modèle ou un schéma conceptuel de données qui devra permettre d avoir une conception cohérente et d éviter les redondances et de disposer d'une vue globale et complète de la base de données à concevoir. Après la normalisation de ce modèle conceptuel, il sera traduit dans un modèle logique de données qui sera implémenté en utilisant un SGBD. Cette implémentation donne naissance à une base de données dans laquelle les mises à jour sont exécutées à un seul emplacement, les problèmes d incohérence des données sont éliminés, la recherche des données est rapide et la diffusion des données est facile. 1. Apport du langage UML La méthode MERISE est une méthode qui a fait ces preuves dans le domaine de la gestion mais pour le domaine des données géodésiques, cette méthode a présenté certaines faiblesses qui sont liées à la complexité de la donnée géodésique. Le MCD global de la base de données géodésiques regroupe plusieurs entités qui se ressemblent, par exemple l entité transformation entre systèmes globaux et l entité transformation entre un système local et un système global sont presque identiques, la seule différence entre elles réside dans les liens utilisés pour chaque transformation et si on prend l entité point GPS et l entité point gravimétrique, on remarque facilement qu il y a des attributs communs aux deux entités. Donc pour y remédier aux différentes faiblesses de ce modèle conceptuel, et pour bénéficier du vocabulaire précis de l approche objet, le langage UML apparaît comme un outil incontournable qui dispose d une panoplie de langages performants pour le développement qui devront permettre d optimiser et d enrichir ce modèle conceptuel en se basant sur des concepts comme : Page 2 sur 10

3 1.1. L agrégation : Figure 1 : Exemple d agrégation Dans un MCD ce lien d agrégation ne peut pas être traduit et la seule modélisation possible est une simple entité point connu qui contient les attributs (code point connu, nom point connu, localisation, nom ville, code postal) 1.2. La composition Figure 2 : Exemple de composition Dans une modélisation de type MCD cette composition n apparaît pas dans l entité similitude 3D qui contient les attributs (code similitude,facteur d échelle, Tx précision globale,ty,tz,rmstx, RmsTy, RmsTz,Ex,Ey,Ez,RmsEx,RmsEy,RmsEz) 1.2. L héritage UML emploie le terme de généralisation pour désigner la relation de classification entre un élément plus général et un élément plus spécifique. La relation de généralisation signifie «est un» ou «est une sorte de». Ce type de relation est inexistant dans une approche de type MCD et pour obtenir le même résultat présenté précédemment on est contraint de dupliquer les informations relatives au point connu dans tous les autres points. Page 3 sur 10

4 Figure 3 : Exemple d héritage 2. Modélisation des données géodésiques avec UML Pour bien décrire les données géodésiques, le langage UML utilise les diagrammes de classes qui peuvent être groupées dans des packages comme le montre la figure qui suit : Figure 4 : Diagramme de classe UML des données géodésiques. Page 4 sur 10

5 Pour faire la différence entre le modèle conceptuel global de la base de données géodésiques issues de la méthode MERISE et ce diagramme de classe UML, ces liens d héritage sont présentés par la suite Les transformations Pendant la modélisation des données auxiliaires, les transformations sont divisées en trois transformations de base : la transformation polynomiale, la transformation géographique et la similitude tridimensionnelle, ces dernières peuvent être groupées par zone d application d ou la nécessité de définir une classe de transformation qui devra permettre de les grouper et de les lier à leurs jeux de coordonnées et leurs traitements respectifs comme le montre la figure qui suit : Figure5 : Liens d héritage entre les Transformations 2.2. Les observations Une observation peut utiliser deux instruments à la fois, donc ce n est pas possible de regrouper les observations par instrument, mais on peut les regrouper par opérateur, par date et par session en même temps, en définissant la classe observation qui est décrite comme suit : Observation (Code observation date observation, code opérateur, code session) Les observations d angle, de distance, de gravimétrie, d astrogéodésie, de nivellement ou de GPS héritent de toutes les propriétés de la classe observation comme le montre la figure qui suit : Page 5 sur 10

6 Observation de nivellement Observation classique Observation Observation astronomique Observation gravimétrique Observation astrogéodésique Figure 6 : Liens d héritage entre les Observations 2.3. Les Points Un point connu peut être un point gravimétrique,un point GPS,un point de LAPLACE, un point astronomique, un repère de nivellement ou un point de géodésie classique. Donc il est clair que les points de la BDG héritent de tous ou de certaines propriétés du point connu. Ces liens sont exprimés dans la figure qui suit : Repère de nivellement Point classique Point de LAPLACE Point GPS Point Connu Point gravimétrique Point astronomique Figure 7 : Liens d héritage entre Points 3. Implémentation des diagrammes de classe UML en objet relationnel 3.1. Présentation du modèle objet - Relationnel Le modèle objet - relationnel se fonde sur l'extension du modèle relationnel par les concepts essentiels de l'objet. Le cœur du système reste donc relationnel, mais tous les concepts clés de l'objet y sont ajoutés dans une forme particulièrement prévue pour faciliter l'intégration des deux modèles. Page 6 sur 10

7 Type défini par l utilisateur et encapsulation Référence Et Identité Héritage et Réutilisation Collection et objet complexe Figure 8 : Le modèle objet relationnel 3.2. Implémentation des diagrammes de classes UML L implémentation des diagrammes de classes UML de la BDG peut se faire en utilisant les tables issues du MLD relationnel mais pour profiter des avantages du modèle objetrelationnel, on va essayer de mieux affiner l implémentation de ce diagramme de classe UML en utilisant des tables objets relationnelles qui contiennent des éléments de type objet qui pourront être référencés grâce à leurs OID et liés grâce à l objet REF qui est un pointeur désignant des données d une autre table d'objets. Application SGBD SGBD relationnel objet objet Tables Objets Figure 9 : Architecture générale de la BDG 3.3. Choix du SGBD ORACLE8i est un SGBD qui permet de faire un accès en mode client serveur ainsi qu un couplage entre le modèle relationnel et le modèle objet donc il est adapté à faire une implémentation en objet- relationnel de ces diagrammes de classe Création de la BDG : Pour la création du MPD de la BDG, on utilise toujours l application SQL*Plus d ORACLE8i qui permet de créer l ensemble des types et des liens ainsi que les tables d objets nécessaires à l implémentation en utilisant uniquement le langage SQL. Page 7 sur 10

8 3.5. Développement de l application client : Après avoir crée le noyau de la base de données qui contient un ensemble de tables d objet, il reste à créer l application client qui permet d interagir avec cette base de données objet. Cette interface sera développée en utilisant toujours Form Builder 6i Définition des rôles et des droits des utilisateurs de la BDG : Figure 10 : Diagramme des cas d utilisation de la BDG 3.7. Description des différents acteurs des cas d utilisation : Les acteurs présentés dans le diagrammes de cas d utilisation sont décrit comme suit : Utilisateur interne : Il comprend tous les membres du laboratoires de géodésie qui utilisent les données de la BDG. Utilisateur externe : C est l ensemble des utilisateurs de la BDG qui n ont aucune connaissance sur la nature de l information géodésique. Page 8 sur 10

9 Opérateur de saisie : C est l ensemble des personnes qui utilisent la BDG pour y introduire les données qui sont issues des observations et des traitements. Programmeurs des applications : Ce rôle est associé aux informaticiens qui ont pour objectif de développer l application cliente. Le concepteur de la BDG : C est les personnes qui ont mis en place le schéma de conception de la BDG. Administrateur de la BDG : C est la personne chargée de l implémentation et de la maintenance de la BDG ainsi que de la gestion des droits et des privilèges de l ensemble des utilisateurs de cette dernière. Il est clair que la description des différents acteurs de la BDG, nous permet de : Définir les différents points de vues sur le système. Déterminer des droits d accès par type d acteur. Fixer des ordres de priorités entre acteurs Définition des rôles et des privilèges : Il est évident que l administrateur de la BDG doit disposé de tous les privilèges possibles sur les objets d'un schéma qui se résument comment suit : TABLE VUE SEQUENCE PROCEDURE FONCTION PACKAGE SNAPSHOT ALTER X X DELETE X X EXECUTE X INDEX X INSERT X X REFERENCES X SELECT X X X X UPDATE X X Pour notre cas, les acteurs précédemment présentés représentent les classes d utilisateur de la BDG qui peuvent être distinguées en utilisant des privilèges défini par l administrateur de la BD. Ces derniers sont présentés comme suit : Privilèges sur les objets d un Schéma utilisateur interne utilisateur externe opérateur de saisie programmeurs des applications ALTER X X DELETE X X X X EXECUTE X X INDEX X INSERT X X X X REFERENCES X SELECT X X X X UPDATE X X X X administrateur de la BDG concepteur de la BDG Page 9 sur 10

10 Conclusion Enfin, les travaux effectués pour l élaboration de la base de données géodésiques ne sont pas achevés car la phase de test de la BDG est à ses débuts, et les avis des utilisateurs sur les données déjà introduites dans la BDG diffèrent d un utilisateur à l autre, heureusement qu aucune remise en question de la structure du noyau n est à faire pour le moment mais plutôt plusieurs propositions pour rendre l interface de la BDG plus conviviale à l utilisation. Références: [AMANN, 1997] B.AMANN Bases de Données Orientés -Objet Bernd Amann Vertigo/CNAM, October 20, 1997 [Aviso, 2003] : AVISO and PODAAC,User Handbook,IGDR and GDR,Jason Products SMM-MU-M5-OP CN (AVISO) JPL D (PODAAC) Edition 2.0 April, 2003 [CONALLEN, 2000] J.CONALLEN, Concevoir des applications Web avec UML, Eyrolles, 2000 [DARMONT, 1997] J.DARMONT, Cours BASES DE DONNÉES, CNAM Centre associé de Clermont-Ferrand, Cycle A Année [DENNOUNI, 2004] Nassim DENNOUNI, Elaboration d une base de données géodésiques intégrant les nouvelles missions spatiales, mémoire de magister, CNTS, ARZEW, [DUQUENNE, 1988] François Duquenne, juillet 1988 : la base de données géodésique sa conception, son état de réalisation et les perspectives, instructions techniques IT/G N 63,département des traitement géodésiques,service de géodésie et de nivellement,institut géographique national. [GARDARIN, 2003] G. GARDARIN, Bases de données, édition Eyrolles, ISBN , [GARDARIN, 1991] G. GARDARIN, SGBD avancés Bases de données objets, Déductives, réparties Edition Eyrolles, [MEYLAN, 2003] E.MEYLAN 2003 Le modèle navigationnel, Implémentation d objets persistants avec Oracle, centre de compétence, haute école spécialisée de suisse occidentale.juin [SCHOLL, 2003] M. SCHOLL, BASES DE DONNÉES Orienté objet, Vertigo/CNAM, Paris, Page 10 sur 10