> Tech > Remplacer un fichier physique DDS par une table SQL

Remplacer un fichier physique DDS par une table SQL

Tech - Par iTPro.fr - Publié le 24 juin 2010
email

par Dan Cruikshank Mis en ligne le 22/02/2006 - Publié en Juillet 2005

L’utilisation de SQL pour définir des fichiers base de données iSeries présente plusieurs avantages, dont

  •  
  • une fonctionnalité absente dans DDS (Data Description Specifications)
  • l’utilisation d’un langage standard
  • la performance
Comme je l’explique dans l’article « Comparaison des performances entre fichiers définis par DDS et fichiers définis par SQL », les tables définies par SQL valident l’intégrité des données au moment où elles sont écrites dans la base de données, et les index définis par SQL ont une plus grande taille de page que les chemins d’accès indexés créés par DDS. Ces deux fonctions améliorent nettement la performance globale de la base de données.Cependant, pour en bénéficier sur les bases de données définies par DDS existantes, il faut d’abord disposer d’une stratégie pratique pour remplacer un fichier physique par une table SQL et pour traiter les fichiers logiques et les chemins d’accès associés. L’idéal serait de pouvoir effectuer ce changement sans vous obliger à modifier ou à recompiler vos applications en langage évolué (HLL, high-level language). Voici donc une méthode pas à pas pour procéder à ce changement.

Le procédé décrit comporte quatre étapes principales :

  • Remplacer un fichier physique créé par DDS, par une table créée par SQL.
  • Créer des index SQL pour remplacer les chemins d’accès indexés existants qui sont créés implicitement pour les fichiers créés par DDS.
  • Créer un fichier logique DDS comme « suppléant » du fichier physique remplacé à l’étape 1.
  • Modifier le DDS fichier logique existant pour référencer la table SQL créée à l’étape 1.

Pour expliquer ces étapes, j’utilise un jeu de fichiers créés par DDS, que l’on peut voir figure 1.
Le fichier physique ORDERHST a une clé UNIQUE sur quatre champs : ORDERKEY, PARTKEY, SUPPKEY et LINENUMBER.

Les quatre fichiers logiques référencent le fichier physique ORDERHST. Les fichiers ORDERHSTL1 et ORDERHSTL2 ont des définitions de champs individuelles, et tous deux ont un chemin d’accès indexé sur le champ ORDERDATE. Les fichiers ORDERHSTTX1 et ORDERHSTTX2 partagent le même format que le fichier physique (c’est-à-dire, le DDS fichier logique ne contient pas de définitions de champs individuelles). Ces deux fichiers ont un chemin d’accès indexé sur le champ PARTKEY, ainsi que des spécifications select/omit statiques.

Dans la configuration originale, il existe un chemin d’accès indexé interne associé à chacun des fichiers. Comme deux paires de fichiers logiques ont les mêmes définitions de clés, trois chemins d’accès seulement sont nécessaires.

Dans la nouvelle configuration, une table SQL nommée de façon unique remplace le fichier physique ORDERHST. Un nouveau fichier logique avec le même nom que le fichier original est créé à l’usage des programmes HLL existants.

Les fichiers logiques originaux restent en place mais sont modifiés de manière à référencer la nouvelle table SQL. Le changement fonctionnel le plus notable est le passage du traitement select/omit de statique à dynamique pour les fichiers ORDERHSTTX1 et ORDERHSTTX2.

De nouveaux index SQL sont créés (avant les fichiers logiques nouveaux et révisés) de telle sorte que quand les fichiers logiques sont créés, ils utilisent les index SQL existants.

Après ces changements, les programmes HLL existants devraient pouvoir s’exécuter normalement, sans aucune recompilation.

Téléchargez cette ressource

Guide de Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par iTPro.fr - Publié le 24 juin 2010