Discussion :

[bracket]

pourquoi on utilise foreign key puis references puisqu'on peut n'utiliser que references reftable(id)

[anakronox]

Bonjour ou (c'est plus poli).
Je ne connais que la syntaxe foreign key + references, qui indique tout simplement que le champ est une clé étrangère faisant référance (c'est logique ...) à la clé primaire d'une autre table.
Mieux vaut respecter la syntaxe en fait (pour éviter des problèmes dans les requêtes avec jointure notamment...).

[bracket]

salut,

oui, ce que vous dite est vrais, mais si on fait juste references table(id), a le même effet, je pense qu'il ya une cause cacher que j'aimerais bien savoir, (juste par curieusité) lol

[fsmrel]

Je ne connais que la syntaxe foreign key + references, qui indique tout simplement que le champ est une clé étrangère faisant référance (c'est logique ...) à la clé primaire d'une autre table.

Ce que vous dites est juste, mais est à compléter. En effet, une clé étrangère ne fait pas nécessairement référence à une clé primaire, elle peut très bien faire référence à une clé alternative (voir la clause UNIQUE de l’instruction CREATE TABLE) qu’il faut alors préciser.

Exemple (SQL Server 2005) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
create table Commune (
   CommuneId int identity not null
 , CommuneInsee char(5) not null
 , CommuneNom varchar(48) not null
 , CommuneDepartement char(4) not null
, Constraint Commune_K1 Primary key (CommuneId)
, Constraint Commune_K2 Unique (CommuneInsee)
, Constraint Commune_K3 Unique (CommuneNom, CommuneDepartement)) ;
 
create table Fournisseur (
   FournisseurId int identity not null
 , FournisseurNom varchar(48) not null
 , FournisseurCommune char(5) not null
, Constraint Fournisseur_K1 Primary Key (FournisseurId)
, Constraint Fournisseur_FK1 Foreign Key (FournisseurCommune) 
                                    References Commune (CommuneInsee)) ;
 
Insert into Commune (CommuneInsee, CommuneNom, CommuneDepartement) Values ('2A004', 'Ajaccio', '2A') ;
 
Insert Into Fournisseur (FournisseurNom, FournisseurCommune) Values ('Pierre', '2A004') ;   
 
Select * from Commune ;
Select * from Fournisseur ;

Dans cet exemple, la clé étrangère Fournisseur_FK1 ne fait pas référence à la clé primaire de la table Commune, mais à une de ses clés alternatives, CommuneInsee.

[anakronox]

Envoyé par fsmrel
elle peut très bien faire référence à une clé alternative (voir la clause UNIQUE de l’instruction CREATE TABLE) qu’il faut alors préciser.

Autant pour moi , j'avais oublié cette possibilité. Merci pour le rappel !

[SQLpro]

references reftable(id)

Est une syntaxe illégale inconnue de la norme SQL. Ou avez vous pêché une telle horreur ? Dans un paquet de lessive ??? ;-)

Quand à l'intérêt des contraintes de clefs étrangères elle est immense :
0) respect du modèle relationnel
1) respect de la qualité des données (pas d'information orpheline polluant la base de données)
2) meilleure optimisation des requêtes

A +

[bracket]

Ce que vous dites est juste, mais est à compléter. En effet, une clé étrangère ne fait pas nécessairement référence à une clé primaire, elle peut très bien faire référence à une clé alternative (voir la clause UNIQUE de l’instruction CREATE TABLE) qu’il faut alors préciser.

Exemple (SQL Server 2005) :

bonsoir
je vois se que vous voulez dire, mais chez moi sa marche jamais si je fais reference a un clé qui n'est pas primaire regarder se code :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
create table employer 
(
   id_emp number constraint pk_emp primary key,
   nom_emp varchar2(40) NOT NULL,
   prenom_emp varchar2(40)
);
 
create table travail
(
  id_travail number constraint pk_travail primary key,
  id_emp varchar2(40) NOT NULL,
  label_travail varchar2(50),
  constraint fk_emp foreign key (id_emp) references employer(nom_emp)
);

voici le message d'erreure : ORA-02270: no matching unique or primary key for this column-list

et si je fait reference a la clé primaire de la table employer sa marche :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
create table travail
(
  id_travail number constraint pk_travail primary key,
  id_emp number,
  label_travail varchar2(50),
  constraint fk_emp foreign key (id_emp) references employer(id_emp)
);

et sans foreign key sa marche aussi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
create table travail
(
  id_travail number constraint pk_travail primary key,
  id_emp number constraint fk_emp references employer(id_emp),
  label_travail varchar2(50)
);

(je travail sous Oracle XE)

[fsmrel]

Oracle a raison, parce que vous n’avez précisé que, dans la table employer, l’attribut nom_emp fait l’objet d'une clé alternative, donc d'une d’une clause UNIQUE.

Par exemple :

Constraint Ak_emp UNIQUE (nom_emp)

[bracket]

voila une bonne nouvel,
comment oracle va savoir qu'elle est la table fille si on ne declare pas la contrainte de la clé etrangére dans la meme ligne que la cologne qu'on veut qu'elle en soit une, biensur grace a foreign key sinon il peut pas deviné .

[nibr84]

Bonjour,
L'utilité de clé etrangaire réside en fait à l'utilisation des jointures que ce soit
externe ou interne, celui qui permet de faire la liaison entre des tables.
Merci

[fsmrel]

L'utilité de clé etrangaire réside en fait à l'utilisation des jointures que ce soit externe ou interne, celui qui permet de faire la liaison entre des tables.

L’objet des clés étrangères n’est pas de permettre d’effectuer des jointures, mais ces clés sont un moyen de garantir l’intégrité référentielle (ce que SQLpro a appelé le respect de la qualité des données). Il s’agit une condition nécessaire (mais non suffisante) pour que la base de données soit intègre, par exemple qu’une commande fasse toujours référence à un client, bien présent dans la base de données.
Le résultat d’une opération de jointure ne dépend que du contenu des tables. Pour reprendre les tables de bracket, que des clés étrangères soient définies ou non, pour connaître le prénom des employés qui ont un travail on écrit :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
Select   a.prenom_emp
From     employer a  inner join travail b
         on a.nom_emp = b.id_emp ;

Ce qui vaut pour la jointure interne, vaut également pour la jointure externe.

N'oubliez pas que dans leurs premières versions, les SGBD tels que DB2 ou Oracle ne permettaient pas de définir de clés étrangères, alors qu'on effectuait des jointures à en veux-tu en voilà.

Point barre.

[bracket]

ééééé oui,

c'est pour ça quand les appele base de donnée relationnel. l'integrité d'une base de données c'est ce qui compt le plus, d'ici 10 ou 20 ans la programmation n'aura plus de valeur, c'est la conception qui compte, sa a déja commencé avec Windev qui nous fait un programme tout pres juste avec le MCD.

[fsmrel]

c'est pour ça quand les appele base de donnée relationnel. l'integrité d'une base de données c'est ce qui compt le plus

L’intégrité des données (ou validité, cohérence) concerne tous les types de bases de données et pas seulement les bases de données relationnelles. Un système non relationnel tel qu’IMS est opérationnel depuis quarante ans et fournit lui aussi les fonctionnalités permettant de garantir l’intégrité des données.

Ça n’est donc pas parce les systèmes offrent les moyens de garantir l’intégrité des données que les bases de données sont appelées relationnelles. Ce qui caractérise une base de données relationnelle, c’est le fait qu’elle soit constituée exclusivement de relations, manipulables au moyen d’opérateurs relationnels (RESTRICT, PROJECT, UNION, INTERSECTION, JOIN, etc.)

Mais, qu’est-ce exactement qu’une relation ?

Je cite Ted Codd, père du Modèle relationnel, qui a écrit en 1970 dans son article fondateur “A Relational Model of Data for Large Shared Data Banks” :

« Le terme de relation est utilisé ici dans son acception mathématique. Étant donnés les ensembles S1, S2, ..., Sn (non nécessairement distincts), R est une relation sur ces n ensembles si c’est un ensemble de n-uplets, le 1er élément de chacun d’eux tirant sa valeur de S1, le 2e de S2, et ainsi de suite (de manière plus concise, R est un sous-ensemble du produit cartésien S1 X S2 X ... X Sn). On fera référence à Sj comme étant le jième domaine de R. Suite à ce qui vient d’être énoncé, on dit que R est de degré n. Les relations de degré 1 sont souvent dites unaires, celles de degré 2 binaires, de degré 3 ternaires, et celles de degré n n-aires. »

Manifestement, Codd n’aborde pas ici le sujet de l’intégrité, qu’elle soit référentielle ou autre. L’intégrité est un volet très important, mais ça n’est pas le seul.
Je rappelle ici la règle fondamentale, la première des douze règles énoncées par Codd pour caractériser une base de données relationnelle :

Règle de l’information (Information Rule) :

« Toute l’information contenue dans une base de données relationnelle doit être explicitement représentée, et ce uniquement au moyen de valeurs dans des tables ».

(La table représente la version SQL de la relation).

Autrement dit :
Toute l’information contenue dans une base de données relationnelle est représentée de façon unique, sous forme de valeurs d’attributs, au sein de tuples, au sein des relations.

C'est-à-dire que les pointeurs, les listes, les tableaux, etc. n’ont pas à être explicitement représentés. Contrairement à ce qui se passe avec les SGBD non relationnels, aucun lien explicite ne lie les relations. Pour sa part, l’intégrité référentielle, avec son cortège de clés étrangères, ne contredit pas la règle fondamentale de l’information : elle représente seulement une contrainte générale, une métarègle qui me permet de signifier au SGBD que :

Si A désigne un ensemble d’attributs composant une clé (primaire ou alternative) d’une table T1,
Si B désigne un ensemble d’attributs d’une table T2,
Alors toute valeur prise par B doit être une valeur prise par A.

B représente une clé étrangère. Il n’existe aucun lien matérialisé tel qu’un pointeur dans cette affaire. La règle de l’information est préservée. Ce principe a permis à Codd de définir une algèbre et un calcul relationnels nous permettant, en mariant des relations, de produire des bébés (tables au sens SQL) qui sont aussi des relations (principe dit de fermeture), et cela sans limite, autrement dit, il n’y pas de relation que nous ne puissions produire à partir d’autres relations (principe de complétude).

d'ici 10 ou 20 ans la programmation n'aura plus de valeur, c'est la conception qui compte, sa a déja commencé avec Windev qui nous fait un programme tout pres juste avec le MCD.

Vous vous engagez beaucoup...