DDS : une relique du passé ?

Milligan : En matière d’outils de
gestion de base de données exhaustifs, nous mettons l’accent sur Operations
Navigator. Bien qu’il existe des interfaces écrans passifs utilisables pour
créer des UDT, des LOB, des BLOB (Binary Large Objects), et autres, les dernières
releases de l’OS/400 ont beaucoup oeuvré pour que l’on puisse gérer les
nouvelles fonctions base de données, et s’interfacer avec elles, avec les
interfaces graphiques d’Operations Navigator. Dans les releases à  venir d’Operations
Navigator, nous avons l’intention d’ajouter des moyens pour gérer la
relation entre des objets de base de données SQL associés. 

Guthrie : Donc, aucun support DDS n’est
prévu pour ces nouveaux types de données ? 

A l’heure actuelle, il n’y
a pas de support pour des LOB, des UDT ou des datalinks dans DDS 

Anderson : A l’heure actuelle, il n’y
a pas de support pour des LOB, des UDT ou des datalinks dans DDS. Nous examinons
toutes les améliorations apportées à  la base de données et en avons mis
certaines dans DDS. Cela dépend de la manière dont, à  notre avis, la base de
clientèle va utiliser cet ensemble de fonctions. Dans le cas du support
relationnel objet, il était évident que la plus grande partie de ces
utilisateurs seraient basés sur SQL plutôt que DDS. En revanche, de nombreux
clients sont en train de passer à  Unicode ou UCS2, et nous avons donné
quelques moyens supplémentaires à  DDS pour traiter UCS2 (dans la clause
SelectOmit de DDS, par exemple) de manière plus favorable. Donc, nous améliorons
encore DDS, tout en faisant porter l’essentiel de notre action sur SQL. 

Hoffman : Pourriez-vous définir brièvement
Unicode et UCS2 ?  

Anderson : UCS2 est le nom d’un standard
appelé ISO 10646. Le support livré sur AS/400, étagé sur plusieurs releases,
constituait le niveau 1 de ce standard. Pour l’essentiel, ce standard est une
manière de coder des caractères, où chaque caractère pour le niveau 1 a une
largeur de deux octets. On peut, par exemple, stocker des caractères japonais,
arabes, anglais ou allemands dans une colonne. Dans notre économie globale,
surtout pour les grands clients internationaux, il est très important de
pouvoir stocker les noms, adresses, etc., des clients, sans perdre aucun caractère.
En n’utilisant qu’un octet par caractère, on ne dispose pas d’un nombre
suffisant de caractères pour loger tous les clients dans la base de données.

Hoffman : Lorsqu’on travaille DDS sur
des fichiers écran, on ramène le fichier physique DDS correspondant à  ce
fichier écran, et on choisit dans les DDS du fichier physique ou dans un
dictionnaire de données quelconque. Mais, que pensez-vous d’un outil qui
offrirait les mêmes possibilités pour des types de données définis en
utilisant SQL ? 

Anderson : Songez-vous à  la possibilité
de style référence à  l’intérieur de DDS ? 

Hoffman :
Oui. 

Anderson : Même si on crée des fichiers
à  partir de SQL, en utilisant Operations Navigator et du SQL pur par exemple,
on peut néanmoins utiliser les spécifications de fichiers REF pour les
fichiers écran. Et on peut encore obtenir les deux descriptions à  partir de ce
fichier physique. 

Hoffman : Selon moi, il y a une forte
pression pour abandonner DDS, mais ce sera long parce qu’il y a beaucoup de
DDS chez les clients, et de nombreuses applications qui en dépendent. Côté
fichiers de données, on a assisté à  la poussée de SQL pendant quelques années,
et on commence à  le voir côté fichiers écrans, avec le potentiel de certains
nouveaux outils. Donc, dans quelques temps, le fait que je puisse construire un
fichier avec SQL et le référencer en DDS ne résoudra pas vraiment mon problème
parce que DDS ne sera plus mon référentiel central / je ne traiterai plus les
données de cette manière. Comment les traiterai-je alors ? 

Anderson : L’industrie s’est éloignée
des interfaces de type session d’émulation d’écrans passifs. Et l’on voit de
plus en plus des interfaces externes basées sur le client ou sur le Web. Ces
types d’interfaces ne fonctionnent pas aussi bien avec un fichier écran créé
en DDS. On verra de plus en plus des technologies de type XML (Extensible Markup
Language), capables d’afficher tous les types de données avec un navigateur
ou un client. C’est en tout cas l’orientation majoritaire à  l’heure
actuelle. Mais, à  mon avis, DDS va encore durer très longtemps. Nous ne nous
en débarrasserons pas de sitôt. 

DDS va encore durer très longtemps. Nous ne
nous en débarrasserons pas de sitôt
Mark Anderson

Hoffman : Nous pouvons à  l’heure
actuelle gérer des données par l’intermédiaire de DDS et de SQL via
Operations Navigator, et quand nous créons un fichier écran, nous pouvons
amener ces informations dans les DDS. Mais, demain, quand nous créerons l’équivalent
d’un fichier écran à  l’aide de XML ou de toute autre technologie, il nous
faudra un pont conduisant aux données. Je ne vois pas bien d’où il peut
venir. 

Anderson : XML constitue lui-même un pont
possible, mais ce n’est certainement pas le seul. L’intérêt de cette
technologie est tel que la presse s’y est beaucoup intéressée récemment.
Nous sommes en train d’élaborer un pont entre les définitions de bases de
données et la manière de présenter concrètement ces données à  une
interface d’utilisateurs finals. Par conséquent, XML sera l’une des
technologies qui fourniront ce pont. 

Hoffman : Pouvons-nous attendre des
outils, provenant de Rochester ou de Toronto, servant de pont avec UDB/400 ? 

Anderson : Oui. Et des outils tiers
viendront aussi s’y ajouter. Kent peut vous parler de certains autres outils
disponibles, pour aider à  gérer la base de données en plus du pont applicatif
entre ce que l’on voit et ce qui se trouve dans la base de données. 

Milligan : Dans les comptes AS/400, nous
voyons ERwin à  l’oeuvre, un outil de modélisation de données bien
connu. Je suis certain que tous les fournisseurs d’outils de modélisation de
données suivront de près XML et son lien avec des bases de données
relationnelles, pour permettre aux utilisateurs d’obtenir, par "reverse
engineering" une sortie de type XML. D’ailleurs, certains produits
utilisent déjà  aujourd’hui des langages à  base d’étiquettes (tags) comme
XML, pour partager et échanger des informations de descriptions de données.
IBM possède Visual Warehouse, un produit qui procure une vue commune des métadonnées
au moyen d’un langage à  base de tags pour importer les métadonnées en
provenance de différents outils tiers que l’on pourrait utiliser dans la
solution de datawarehouse. On peut donc utiliser Visual Warehouse pour gérer et
voir toutes les descriptions des différents fournisseurs des données
auxquelles l’on accède ou que l’on déplace au moyen d’outils d’aide à 
la décision ou d’outils de réplication de données.