Modifier une clé primaire d'une table
Résolu/Fermé
minos11
Messages postés
8
Date d'inscription
mercredi 16 juillet 2008
Statut
Membre
Dernière intervention
22 juillet 2008
-
16 juil. 2008 à 11:50
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 17 juil. 2008 à 19:31
cchristian Messages postés 921 Date d'inscription lundi 21 janvier 2008 Statut Membre Dernière intervention 6 mars 2012 - 17 juil. 2008 à 19:31
A voir également:
- Modifier une clé primaire d'une table
- Table ascii - Guide
- Clé windows 10 gratuit - Guide
- Cle usb non reconnu - Guide
- Comment faire une table des matières sur word - Guide
- Modifier une liste déroulante excel - Guide
2 réponses
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
16 juil. 2008 à 16:17
16 juil. 2008 à 16:17
Bonjour,
Clé primaisre :
Pour rester cohérent, toutes situations et tous SGBD ou méthodes d'accès confondus , j'ai tendance à penser qu'il est préférable :
1) de sauvegarder les données de l'enregistrement (la ligne, le tuple, .......) à annuler,
2) de procéder à l'annulation physique de cet enregistrement (ligne, tuple, .........) sur la valeur de clé primaire existante.
3) puis de créer le "nouvel" enregistrement (ligne, tuple, ......) avec les données sauvegardées et la nouvelle valeur de clé primaire.
Mais il est possible ave certains SGBD(R) (notamment avec l'instruction UPDATE en SQL/DB2) de procéder directement à la modification d'une clé primaire (sauf si une contrainte d'intégrité référencielle a été définie) .
Foreign key (SGBDR) :
Si une contrainte d'intégrité référencielle (option ON DELETE CASCADE de l'instruction CONSTRAINT en SQL/DB2) est définie sur une colonne (correspondante à la clé primaire à annuler de la table parente) de une ou plusieurs autres tables les lignes (tuples) seront autoatiquement détruites à la phase 2) ci-dessus. Dans le cas contraire (pas de contrainte type DELETE) il faut explicitement les détruire.
Clé primaisre :
Pour rester cohérent, toutes situations et tous SGBD ou méthodes d'accès confondus , j'ai tendance à penser qu'il est préférable :
1) de sauvegarder les données de l'enregistrement (la ligne, le tuple, .......) à annuler,
2) de procéder à l'annulation physique de cet enregistrement (ligne, tuple, .........) sur la valeur de clé primaire existante.
3) puis de créer le "nouvel" enregistrement (ligne, tuple, ......) avec les données sauvegardées et la nouvelle valeur de clé primaire.
Mais il est possible ave certains SGBD(R) (notamment avec l'instruction UPDATE en SQL/DB2) de procéder directement à la modification d'une clé primaire (sauf si une contrainte d'intégrité référencielle a été définie) .
Foreign key (SGBDR) :
Si une contrainte d'intégrité référencielle (option ON DELETE CASCADE de l'instruction CONSTRAINT en SQL/DB2) est définie sur une colonne (correspondante à la clé primaire à annuler de la table parente) de une ou plusieurs autres tables les lignes (tuples) seront autoatiquement détruites à la phase 2) ci-dessus. Dans le cas contraire (pas de contrainte type DELETE) il faut explicitement les détruire.
cchristian
Messages postés
921
Date d'inscription
lundi 21 janvier 2008
Statut
Membre
Dernière intervention
6 mars 2012
131
17 juil. 2008 à 19:31
17 juil. 2008 à 19:31
Bonjour,
En complément à mon dernier message je te propose ces quelques réflexions sur le problème posé. En ce sens elles ne constituent pas une solution mais plutôt un thème de discussion.
NB. Ce qui suit est traité dans une optique SQL/DB2, donc à actualiser sous ORACLE (que je ne connais pas).
Le changement que tu souhaites effectuer s'apparente davantage à une réorganisation (fonctionnelle) de plusieurs tables d'une base de données. En effet il est question de substituer à la colonne clé primaire "numero_de_bureau" de la table parente "direction" (colonne parente qui se trouve être clé étrangère de plusieurs autres tables dépendantes), une autre colonne "numero_direction" de cette même table.
La colonne "numero_de_bureau" n'étant pas reconduite dans la table "direction".
Remarque à propos de cette dernière supposition : Plusieurs « no_de_bureau » sont probablement rattachés à un même « no_direction » ? (et .......... une clé primaire n’admet pas les doublons)
Si tel est le cas et afin de contourner cette impossibilité il convient de conserver en suffix de la clé primaire, la colonne "numero_de_bureau" qui de ce fait assurera l’unicité de la nouvelle clé primaire, laquelle devra être constituée des colonnes : "numero_direction" + "numero_de_bureau".
Dans cette hypothèse il s'agirait d'une permutation de colonnes, où plus précisément d'une modification de la clé primaire.
Illustration :
table parente "direction" actuelle (2 no_bureau00x pour un même no_direction01):
col. bureau : col. direction :
no_bureau001 no_direction01 .....................
no_bureau002 no_direction01 .....................
no_bureau003 no_direction02 .....................
....................... ...................................
table dépendante col. bureau_dep (foreign key)
........................... no_bureau001 .........................
........................... ...................... .........................
qui est décrite vraisemblablement d'une manière analogue à ce qui suit :
CREATE TABLE table_dépendante
..................
Intégrité référencielle (SQL/DB) :
CONSTRAINT no_bur FOREIGN KEY (bureau_dep)
REFERENCES direction (bureau) ON DELETE NO ACTION (par exemple),
_____________________________________________________________
table "direction" après restructuration (éventuelle car il n'est pas obligatoire de permuter les colonnes) :
col. direction col. bureau :
no_direction01 no_bureau001 .....................
no_direction01 no_bureau002 .....................
no_direction02 no_bureau003 .....................
...............................................................
Il restera malgré tout à :
Foreign keys :
- actualiser (une foreign key doit avoir le même nombre de colonnes que la clé primaire de la table parente)
- ou à faire disparaître (si elles sont devenues obsolètes).
les foreign key sur les table(s) dépendante(s).
Modifications :
- Effectuer les modifications à apporter à l’existant.
En complément à mon dernier message je te propose ces quelques réflexions sur le problème posé. En ce sens elles ne constituent pas une solution mais plutôt un thème de discussion.
NB. Ce qui suit est traité dans une optique SQL/DB2, donc à actualiser sous ORACLE (que je ne connais pas).
Le changement que tu souhaites effectuer s'apparente davantage à une réorganisation (fonctionnelle) de plusieurs tables d'une base de données. En effet il est question de substituer à la colonne clé primaire "numero_de_bureau" de la table parente "direction" (colonne parente qui se trouve être clé étrangère de plusieurs autres tables dépendantes), une autre colonne "numero_direction" de cette même table.
La colonne "numero_de_bureau" n'étant pas reconduite dans la table "direction".
Remarque à propos de cette dernière supposition : Plusieurs « no_de_bureau » sont probablement rattachés à un même « no_direction » ? (et .......... une clé primaire n’admet pas les doublons)
Si tel est le cas et afin de contourner cette impossibilité il convient de conserver en suffix de la clé primaire, la colonne "numero_de_bureau" qui de ce fait assurera l’unicité de la nouvelle clé primaire, laquelle devra être constituée des colonnes : "numero_direction" + "numero_de_bureau".
Dans cette hypothèse il s'agirait d'une permutation de colonnes, où plus précisément d'une modification de la clé primaire.
Illustration :
table parente "direction" actuelle (2 no_bureau00x pour un même no_direction01):
col. bureau : col. direction :
no_bureau001 no_direction01 .....................
no_bureau002 no_direction01 .....................
no_bureau003 no_direction02 .....................
....................... ...................................
table dépendante col. bureau_dep (foreign key)
........................... no_bureau001 .........................
........................... ...................... .........................
qui est décrite vraisemblablement d'une manière analogue à ce qui suit :
CREATE TABLE table_dépendante
..................
Intégrité référencielle (SQL/DB) :
CONSTRAINT no_bur FOREIGN KEY (bureau_dep)
REFERENCES direction (bureau) ON DELETE NO ACTION (par exemple),
_____________________________________________________________
table "direction" après restructuration (éventuelle car il n'est pas obligatoire de permuter les colonnes) :
col. direction col. bureau :
no_direction01 no_bureau001 .....................
no_direction01 no_bureau002 .....................
no_direction02 no_bureau003 .....................
...............................................................
Il restera malgré tout à :
Foreign keys :
- actualiser (une foreign key doit avoir le même nombre de colonnes que la clé primaire de la table parente)
- ou à faire disparaître (si elles sont devenues obsolètes).
les foreign key sur les table(s) dépendante(s).
Modifications :
- Effectuer les modifications à apporter à l’existant.
