> Tech > Créer une identité

Créer une identité

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

Pour créer une colonne d'identité dans DB2 UDB, on inclut la clause IDENTITY pour une colonne numérique lors de la création d'une table SQL. En même temps que les types de données entiers, on peut aussi utiliser les types décimal et numérique pour une colonne d'identité, tant que la précision

Créer une identité

pour ce type de colonne est zéro. Une
table peut avoir un maximum d’une colonne
d’identité.

La clause IDENTITY n’existe que pour des tables SQL et donc il n’y a pas
de support DDS pour les colonnes
d’identité. Il en était de même avec les
anciennes releases OS/400, dans lesquelles
une interface SQL est nécessaire
pour de nouvelles fonctions
(comme des BLOB), comme SQL dans
l’interface de base de données stratégique
pour iSeries. Malgré cette exigence
SQL, les applications natives (ou
non-SQL) peuvent bénéficier de la génération
de valeurs clé associées aux
colonnes d’identité. Si une table a une
colonne d’identité et qu’on insère une
nouvelle ligne, DB2 UDB génère une
valeur clé pour cette nouvelle ligne, indépendamment
de l’interface utilisée. Il importe peu à  DB2 UDB que la nouvelle
ligne ait été générée avec un RPG
Write, une instruction SQL INSERT, ou
une commande CL comme CPYF
(Copy File) ; une nouvelle valeur est
générée pour la colonne Identity.

Bien qu’il incombe à  DB2 UDB de
générer la prochaine valeur pour une
colonne d’identité, il ne lui incombe
pas d’imposer l’unicité de cette valeur
suivante. La colonne d’identité doit
avoir une contrainte de clé primaire,
contrainte unique, ou index unique,
pour garantir que les valeurs qu’elle
contient sont uniques. Nous verrons
plus loin plusieurs méthodes permettant
de sauter ou de remplacer une colonne
d’identité, susceptibles de causer
des valeurs en double sans un
index unique en place.

Comme le montre la figure 1, il
existe plusieurs options d’identité
pour définir un comportement de génération
de clé adapté à  vos besoins.
Par défaut, DB2 UDB démarrera une
colonne d’identité avec une valeur de 1
et ajoutera 1 à  cette valeur chaque fois
qu’une nouvelle ligne sera ajoutée à  la
table. On peut spécifier les clauses
START WITH et INCREMENT BY de
manière à  changer facilement ce comportement
par défaut, comme démarrer
avec une valeur 100 et incrémenter
de 10. La clause INCREMENT BY accepte
aussi une valeur négative pour
créer une valeur de clé décroissante.

Les clauses MINVALUE et MAXVALUE
permettent de générer une suite
de valeurs limitée pour une colonne
d’identité. Par exemple, une société
qui fabrique du mobilier de plein air en
deux couleurs pourrait définir une
MAXVALUE de 2 pour la colonne colorid
dans la table de couleurs, pour empêcher
quelqu’un d’ajouter une troisième
couleur à  la table :


CREATE TABLE colors (
colorid INTEGER GENERATED ALWAYS AS
IDENTITY (MAXVALUE 2),
color_name CHAR(3à˜))

Les valeurs minimale et maximale
pour une colonne d’identité sont
défaut les valeurs minimale et maximale associées aux types de données
de la colonne.

Quand DB2 UDB atteint la valeur
maximale ou minimale pour une colonne
d’identité, le comportement par
défaut de NO CYCLE empêche l’attribution
d’une nouvelle valeur à  la colonne
d’identité. Pour les cas où l’on
veut que DB2 UDB continue à  attribuer
de nouvelles valeurs de colonne
d’identité après avoir atteint la valeur
maximale ou minimale, on peut spécifier
CYCLE de manière à  ce que la colonne
d’identité redémarre au début.
Pour une séquence croissante, DB2
UDB commencerait l’attribution par la
valeur minimale ; pour des séquences
décroissantes, DB2 UDB utiliserait la
valeur maximale.

L’option d’identité CACHE est la
plus difficile à  comprendre. Pour améliorer
la performance de jobs et de
connexions multiples insérant de nouvelles
lignes dans une table, DB2 UDB
réserve le jeu (ou cache) suivant des
valeurs de colonne d’identité en mémoire.
Au lieu d’être obligé d’écrire la
valeur de colonne d’identité suivante
sur disque chaque fois qu’une ligne est
insérée, la cache des valeurs réservées
permet à  DB2 UDB de maintenir la valeur
de colonne d’identité suivante en
mémoire.

La valeur entière fournie avec le
mot-clé précise le nombre de valeurs
d’identité qui seront réservées. IBM recommande
d’utiliser simplement la valeur
par défaut (CACHE 20). Ainsi, la
première fois qu’une ligne sera insérée
dans une table avec une colonne
d’identité, DB2 UDB pré-allouera les
valeurs d’identité 1-20 en mémoire et
écrira sur disque que la valeur de colonne
d’identité suivante est 21. Les valeurs
1-20 seront attribuées aux 20 premières
lignes insérées et ce, bien que la
valeur stockée sur disque indique 21
pour la colonne d’identité suivante.

Si un crash système survient avant
que toutes les valeurs pré-allouées
n’aient été attribuées, les valeurs de colonnes
d’identité non encore attribuées
sont perdues et ne seront jamais utilisées. Après redémarrage du système,
21 sera la valeur d’identité suivante
utilisée. C’est une façon de faire
apparaître des trous dans la suite de valeurs
pour une colonne d’identité.
(Nous verrons plus loin comment cela
peut se produire d’autres manières.) Si
l’on autorise des tables distribuées à 
avoir des colonnes d’identité à  l’avenir,
l’option d’identité cache affectera également
la façon dont les valeurs d’identité
sont allouées à  chaque serveur sur
lequel une table distribuée est répartie
avec DB2 Multisystem.

Les options ORDER et NO ORDER
ne s’appliquent qu’aux tables distribuées
créées avec la fonction DB2
Multisystem. Mais elles n’ont pas d’effet
en V5R2 parce qu’il n’est pas permis
aux tables distribuées d’avoir des colonnes
d’identité.

Pour passer en revue les options
d’identité d’une colonne d’identité
existante, on peut afficher les propriétés
de sa table dans iSeries Navigator
ou examiner la sortie de la commande
CL DSP FFD (Display File Field
Description).

Les options d’identité comme
CACHE et MAXVALUE font en fait partie
de la clause GENERATED, qui détermine
quand DB2 UDB génère des valeurs
pour une colonne d’identité.
GENERATED ALWAYS, valeur par défaut
et recommandée, prescrit à  DB2
UDB de toujours générer une valeur
pour la colonne quand une ligne est insérée
dans la table. GENERATED BY
DEFAULT est l’autre possibilité. Elle ordonne
à  DB2 UDB de ne générer une
valeur de colonne d’identité que
quand une valeur n’est pas spécifiée
pour la colonne d’identité lors d’une
insertion de ligne. C’est l’une des raisons
pour lesquelles on a besoin d’un
index ou d’une contrainte unique sur
la colonne d’identité pour empêcher
des valeurs en double.

Si une ligne est ajoutée via une interface
d’application non-SQL (RPG
Write, par exemple), DB2 UDB génèrera
toujours la valeur de colonne d’identité
même si BY DEFAULT a été spécifié.

Téléchargez cette ressource

Préparer l’entreprise à l’IA et aux technologies interconnectées

Préparer l’entreprise à l’IA et aux technologies interconnectées

Avec la « quatrième révolution industrielle », les environnements hyperconnectés entraînent de nouveaux risques en matière de sécurité. Découvrez, dans ce guide Kaspersky, comment faire face à cette nouvelle ère de vulnérabilité.

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