On Fri, 5 Oct 2001, Francois Deppierraz wrote:
> Comment est-ce possible ? Car il me semble que les relations ne sont pas
> stock�es dans la base de donn�es, elles sont cr��es d'apr�s les requ�tes
> (JOIN and co), non ?
Oui, mais on structure en g�n�ral la base de donn�es en cons�quence, avec
des FOREIGN KEYS, contraintes d'int�grit�, etc.
Exemple:
CREATE TABLE utilisateur_news (id SERIAL NOT NULL,
login VARCHAR(8) NOT NULL,
UNIQUE(login),
UNIQUE(id),
PRIMARY KEY(id));
-- Contraintes d'int�grit�:
-- Un login ne peut exister qu'une seule fois.
CREATE TABLE forum (id SERIAL NOT NULL,
nom_forum VARCHAR(100) NOT NULL,
UNIQUE(nom_forum),
UNIQUE(id),
PRIMARY KEY(id));
-- Contraintes d'int�grit�:
-- Un nom_forum ne peut exister qu'une seule fois.
CREATE TABLE a_acces(utilisateur INT4 REFERENCES utilisateur_news NOT NULL,
forum INT4 REFERENCES forum NOT NULL,
UNIQUE(utilisateur, forum));
-- Contraintes d'int�grit�:
-- Un couple d'(utilisateur, forum) existe au plus � un
-- exemplaire.
Dans ce cas le graphe attendu est quelque chose comme
utilisateur_news ------- a_acces ------- forum
id*+ id
login nom_forum
Ce qui correspond � peu pr�s au diagramme entit�-relation qui serait:
utilisateur_news n ---- a_acces ---- n forum
Le programme *pourrait* deviner la cardinalit� n-n car il n'y a pas
d'UNIQUE(utilisateur) ou UNIQUE(forum) dans a_access, et/ou
utilisateur_news ou forum ne r�f�rencent pas directement l'autre, mais via
une relation interm�diaire a_access (sinon 1:n ou n:1).
NB: on aurait pu aussi utiliser directement login et nom_forum comme
identifiants sans passer par des SERIAL. On remarque �galement un bug de
PostgreSQL qui consiste � d�finir SERIAL comme un INT4: un type `SERIAL_T'
serait plus appropri� pour pouvoir le r�p�ter lors du REFERENCES.
(et tout cela ne nous avance pas pour trouver un tel programme)
--
http://www-internal.alphanet.ch/linux-leman/ avant de poser
une question. Ouais, pour se d�sabonner aussi.
