> Tech > Définition de la base de données

Définition de la base de données

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

La partie la plus simple de la coexistence avec SQL est celle de la description des données. Dès la V3R1, IBM a évité d'apporter des améliorations à  DDS et a préféré améliorer SQL ; à  tel point que de nouvelles fonctions de base de données iSeries, comme les déclencheurs de

niveau de colonne, ne
sont effectuées que via SQL. (Comme
les fichiers écran et les fichiers imprimante
n’ont pas d’équivalents SQL,
IBM continuera à  améliorer le support
DDS pour ces types de fichiers.)
IBM préfèrerait l’adoption généralisée
de SQL mais la réalité est que SQL
ne remplacera pas DDS pour la description
de données, dans un proche
avenir. Heureusement, il n’y a pas de
raison de choisir entre les deux techniques
de description de données. Un
petit nombre de mots-clés DDS n’ont
pas d’équivalents SQL mais, généralement,
on peut utiliser indifféremment
des fichiers définis avec DDS ou des
tables définies en utilisant SQL. On
peut même mélanger DDS et SQL. Par
exemple, on peut utiliser SQL pour
ajouter une contrainte ou un déclencheur
à  un fichier qui a été créé avec
DDS. Soulignons toutefois une exception
susceptible de gêner ceux qui supportent
d’anciennes applications : SQL
ne prend pas en charge des fichiers
multi membres.
DDS et SQL créent tous deux un
objet fichier physique qui présente
une définition de fichier externe que
vous pouvez utiliser dans vos applications
RPG et Cobol. Le même genre
d’information qu’un programme RPG
obtient à  partir d’une définition de fichier
externe existe dans SQL sous
forme de métadonnées. Les métadonnées
incluent des caractéristiques de
tables, comme des contraintes, et
des caractéristiques de colonnes
(champs), comme nom de colonne,
longueur et type de données. (La figure
1 présente une comparaison de la
terminologie SQL et iSeries.)
Si vous utilisez SQL pour la définition
des données, vous devez savoir
comment les types de données SQL
s’associent aux types de données
iSeries. La figure 2 montre une comparaison
de ces types de données.
(Notons que la table de la figure 2 ne
contient que des types de données très répandus ; d’autres types de données
sont possibles.) Dans une telle situation,
SQL varie quelque peu d’une
plate-forme à  une autre ; les types de
données basiques comme Char et
Decimal sont pris en charge de manière
homogène mais certains types de
données moins courants risquent de
ne pas être disponibles dans tous les
cas, ou peuvent être mis en oeuvre différemment
pour diverses bases de
données ou plates-formes.
Pour définir une clé unique pour
un fichier physique en utilisant SQL,
ajoutez une contrainte de clé primaire
ou une contrainte unique à  la définition
de table. (Pour plus d’informations
sur les contraintes, voir le
Redbook Advanced Functions and
Administration on DB2 Universal
Database for iSeries (SG24-4249.)
SQL supporte une gamme complète
de jointures et de sélections de
données, de sorte que l’on peut généralement
substituer une vue SQL à  un
fichier logique iSeries. Cependant, les
vues SQL sont toujours non ordonnées.
Par conséquent, si vous utilisez
des fichiers logiques pour imposer une
clé alternée pour vos fichiers physiques
ou pour éviter de définir des
clés sur des fichiers physiques, vous ne
pouvez pas remplacer les fichiers logiques
par des vues.
Quand vous extrayez des données
au moyen de SQL, le moteur SQL emploie
les chemins d’accès existants et
crée les chemins d’accès temporaires
qui s’avèrent nécessaires. Vous pouvez
définir un chemin d’accès à  l’aide de
SQL, en créant un index sur le fichier
physique. Un index permanent rendra
souvent l’extraction des données plus
performante, au prix bien sûr d’un surcroît
de maintenance de données. Ce
compromis n’est pas propre à  SQL :
chaque fois qu’on crée un chemin d’accès
permanent, on fait un compromis
entre le travail de maintenance et celui
d’extraction de données.
Pour SQL, vous pouvez bénéficier
de Visual Explain qui, au stade F4R5,
fait partie d’iSeries Navigator (auparavant
Operations Navigator), pour aider
à  déterminer si un index serait utile ou
non. Visual Explain analyse la performance
des requêtes SQL et avance des
suggestions concernant l’optimisation.
(Pour plus d’informations sur Visual
Explain, voir les IBM Redbooks DB2
UDB for AS/400 Visual Explain :
Illustrating the Secrets (REDP0505) et
Advanced Functions and Administration
on DB2 Universal Database for
iSeries.)

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 Renaud ROSSET - Publié le 24 juin 2010