Types définis par l’utilisateur

différentes formes
de données. Par exemple, une colonne définie avec le type FRFrancs serait beaucoup
plus compréhensible pour le quidam qu’une colonne définie avec le type données
Decimal(11,2).

Les types définis par l’utilisateur les plus classiques sont les distinct data
types, qui s’obtiennent à  partir des types de données fournis par le système (comme
Integer ou Char par exemple). Les types de données distincts procurent de nouveaux
noms (et, lorsque cela s’applique, de nouvelles longueurs) aux types systèmes.
Plus important encore, ils définissent également un nouveau comportement qui s’applique
davantage à  un environnement de gestion spécifique.

Pour illustrer les bénéfices des types de données définis par l’utilisateur, prenons
le cas où le type de données Decimal(11,2) est utilisé pour définir d’une part
une colonne destinée à  stocker des montants en francs français et d’autre part
une colonne destinée à  enregistrer des montants en francs belges. Etant donné
les définitions de base de ces colonnes, il serait possible de comparer ou d’additionner
les deux colonnes, même si cela est aberrant. Les types de données distincts évitent
de telles opérations illogiques car une colonne définie à  l’aide d’un type distinct
ne peut servir que pour des opérations et des comparaisons qui impliquent une
autre colonne définie avec le même type distinct.

Dès que l’on crée un type de données distinct, les instructions SQL telles que
Create Table peuvent désigner et utiliser le nouveau type de la même façon qu’un
type système. Les sections de code suivantes illustrent comment définir et utiliser
les types distincts : Create Distinct Type FRFrancs
As Decimal ( 11, 2 )
Create Distinct Type BEFrancs
As Decimal ( 11, 2 )
Create Table Product (
ProductId Char( 5 ),
ProductDesc VarChar( 50 )
FRPrice FRFrancs,
BEPrice BEFrancs,
. . . )
Les instructions Create Distinct Type créent tout d’abord les types de données
FRFrancs et BEFrancs d’après le type système Decimal. Ensuite, la définition de
la table Product fait référence à  ces types. Plutôt que de redéfinir constamment
les mêmes attributs systèmes (par exemple, Decimal (11,2)) pour des colonnes identiques,
il est possible de définir un type de données distinct pour les besoins de l’application
et de le réutiliser dans toutes les définitions de la table.
Cette stratégie implique des définitions standards et homogènes des données de
l’entreprise au sein de toutes les applications (les programmeurs AS/400 confirmés
reconnaissent que les types SQL définis par l’utilisateur offrent des avantages
similaires aux fichiers DDS servant de champs de référence). Chaque fois que l’on
crée un type de données distinct, le système crée implicitement des fonctions
de casting pour permettre de convertir aisément les valeurs vers et à  partir du
nouveau type. Ainsi, dans l’exemple précédent, la création du type de données
FRFrancs induit la création de deux fonctions. La première fonction, appelée FRFrancs,
convertit le type de base (Decimal) en une valeur FRFrancs.
La deuxième fonction, appelée Decimal, convertit une valeur FRFrancs en une valeur
de type Decimal. Un analyste produit peut utiliser la fonction de conversion FRFrancs
pour rechercher des produits vendus à  un certain prix de gros. Une recherche de
ce type peut impliquer la comparaison d’une valeur FRFrancs avec une valeur numérique
constante (une comparaison qui ne peut être effectuée directement car la base
de données nécessite que les comparaisons soient réalisées sur des données de
types semblables).
Cependant, l’utilisation d’une fonction de conversion rend la comparaison possible,
comme dans l’exemple suivant :

Select * From Product
Where FRPrice =
FRFrancs( 100,00 )

Cette façon de coder peut sembler fastidieuse.
Toutefois, en exigeant que les valeurs comparées soient de types compatibles,
le SGBDR améliore l’intégrité des données et des opérations.