hum...

bonjour,

Etienne a écrit:

Apparemment dans SQL Server 2005, on a plus le choix de la table source pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....

Ce n'est pas un problème de SQL Server. C'est un manque de culture sur des
concepts de SGBD relationnels !

Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?

Visiblement vous avez du mal parce que vous ne maitrisez pas le modèle
relationnel et en gros la modélisation de données.
Je vous conseille de vous familiariser avec ces concepts par exemple à travers
la méthode MERISE ou la notation UML.

Après vous pourrez facilement comprendre et applmiquer ce qu'est une intégrité
référentielle.

Commencez donc par lire cet article (MERISE) :
http://sqlpro.developpez.com/cours/modelisation/merise/
Puis, poursuivez par (intégrité référentielle) :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L2
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7

Si vous avez besoin d'explication supplémentaires, n'hasitez pas à me
questionner. En tant qu'auteur de ces articles, je peut vous guider !

A +

Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Désolé, j'ai du créer un nouveau post au lieu de répondre à :
SQL2005 - Relation clés multiples.
Sinon, concernant mon manque de culture, je ne suis que développeur de
métier en dotnet et SQL Sever depuis 10 ans. Donc je vous le garantis, mon pb
vient bien de l'interprétation de SQL server 2005 et pas d'un pb de
modélisation.

"Fred BROUARD" a écrit :

bonjour,

Etienne a écrit:
> Apparemment dans SQL Server 2005, on a plus le choix de la table source pour
> effectuer une relation, c'est forcément la table "étrangère". Donc pour moi
> Moderateurs.
> Il est possible que je me trompe car novice sur SQLS 2005....

Ce n'est pas un problème de SQL Server. C'est un manque de culture sur des
concepts de SGBD relationnels !

> Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
> mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la clé
> primaire est créée sur 2 champs, pourtant y a aucun rapport entre les champs
> de clé primaire et ceux de clé étrangère dans une même table ! Alors pourquoi
> je dois choisir 2 champs comme clé étrangère ???
> Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
> problème ?

Visiblement vous avez du mal parce que vous ne maitrisez pas le modèle
relationnel et en gros la modélisation de données.
Je vous conseille de vous familiariser avec ces concepts par exemple à travers
la méthode MERISE ou la notation UML.

Après vous pourrez facilement comprendre et applmiquer ce qu'est une intégrité
référentielle.

Commencez donc par lire cet article (MERISE) :
http://sqlpro.developpez.com/cours/modelisation/merise/
Puis, poursuivez par (intégrité référentielle) :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L2
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7

Si vous avez besoin d'explication supplémentaires, n'hasitez pas à me
questionner. En tant qu'auteur de ces articles, je peut vous guider !

A +

> Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Le langage SQL qui est une norme, d'ailleurs relativement bien respectée par MS
SQL Server impose qu'une référence d'intégrité porte sur :
- une contrainte de clef primaire de la table référencée
- une contrainte d'unicité de la table référencée
Peu importe que la contrainte possède une unique colonne ou plusieurs c'est la
contrainte donc toutes les colonnes qui la composent qui doivent être pris en
compte.

Si vous utilisez un outil de modélisation, par exemple comme Power AMC, cela se
fait automatiquement lors du passage du MCD au MPD.

Voilci un exemple de ce qu'il faut faire ou ne pas faire avec l'IR :

CREATE TABLE T_TEST_IR1
(IR1_ID INTEGER NOT NULL PRIMARY KEY,
IR1_NUM_SECU CHAR(13),
IR1_CODE_SECU CHAR(2),
IR1_NOM CHAR(16),
IR1_PRENOM VARCHAR(25),
CONSTRAINT CU_SECU UNIQUE (IR1_NUM_SECU, IR1_CODE_SECU))
GO

CREATE TABLE T_TEST_IR2
(IR2_CODE CHAR(8),
IR2_NUM_SECU CHAR(13) FOREIGN KEY REFERENCES T_TEST_IR1 (IR1_NUM_SECU))

=> ERREUR
Serveur : Msg 1776, Niveau 16, État 1, Ligne 1
Aucune clé primaire ou prototype dans la table référencée 'T_TEST_IR1' ne
correspond à la liste des colonnes de référence de la clé étrangère
'FK__T_TEST_IR__IR2_N__581D0306'.
Serveur : Msg 1750, Niveau 16, État 1, Ligne 1
Impossible de créer la contrainte. Voir les erreurs précédentes.

En effet la seule colonne IR2_NUM_SECU ne constitue ni une contrainte de clef
primaire ni une contrainte d'unicité.

CREATE TABLE T_TEST_IR2
(IR2_CODE CHAR(8),
IR2_ID INTEGER FOREIGN KEY REFERENCES T_TEST_IR1 (IR1_ID))
GO

=> pas d'erreur, la référence a bien été crée sur une contrainte valide (ici
primary key)

CREATE TABLE T_TEST_IR3
(IR2_CODE CHAR(8),
IR2_NUM_SECU CHAR(13),
IR2_CODE_SECU CHAR(2),
CONSTRAINT FK_SECU FOREIGN KEY (IR2_NUM_SECU, IR2_CODE_SECU)
REFERENCES T_TEST_IR1 (IR1_NUM_SECU, IR1_CODE_SECU))
GO

=> pas d'erreur, la référence a bien été crée sur une contrainte valide (ici unique)


Etienne a écrit:

Désolé, j'ai du créer un nouveau post au lieu de répondre à :
SQL2005 - Relation clés multiples.
Sinon, concernant mon manque de culture, je ne suis que développeur de
métier en dotnet et SQL Sever depuis 10 ans. Donc je vous le garantis, mon pb
vient bien de l'interprétation de SQL server 2005 et pas d'un pb de
modélisation.

Non, absolument pas ! Vous faites fausse route.

A +

"Fred BROUARD" a écrit :

bonjour,

Etienne a écrit:

Apparemment dans SQL Server 2005, on a plus le choix de la table source pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....

Ce n'est pas un problème de SQL Server. C'est un manque de culture sur des
concepts de SGBD relationnels !

Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?

Visiblement vous avez du mal parce que vous ne maitrisez pas le modèle
relationnel et en gros la modélisation de données.
Je vous conseille de vous familiariser avec ces concepts par exemple à travers
la méthode MERISE ou la notation UML.

Après vous pourrez facilement comprendre et applmiquer ce qu'est une intégrité
référentielle.

Commencez donc par lire cet article (MERISE) :
http://sqlpro.developpez.com/cours/modelisation/merise/
Puis, poursuivez par (intégrité référentielle) :
http://sqlpro.developpez.com/cours/sqlaz/techniques/#L2
http://sqlpro.developpez.com/cours/sqlaz/ddl/?page=partie2#L7.1.7

Si vous avez besoin d'explication supplémentaires, n'hasitez pas à me
questionner. En tant qu'auteur de ces articles, je peut vous guider !

A +

Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...

Apparemment dans SQL Server 2005, on a plus le choix de la table source
pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour
moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....
Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors
pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?
Merci.

Bonjour Med,
Voici mon problème, il est simple :
j'ai une table dont un champ doit être une clé étrangère d'une autre table,
ici une relation de 1 à n (je me place donc du côté n).
Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le cas
classique.
Considérons maintenant ce même exemple mais la table dispose d'une clé
primaire - le fait que la table est une clé primaire n'a aucun rapport avec
la clé étrangère à créer, j'en suis conscient ; cela reste archi classique et
je crée encore la relation sans difficulté.
J'arrive au cas qui me soucis, imaginons cette fois que cette table est une
clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
table est une clé primaire.
Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer une
clé étrangère sur 2 champs !
Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé étrangère
???

Pour étayer mon propos, voici un exemple qui correspond bien :
J'ai une table Users et une table Moderators ; Moderators comprend deux
champs clé primaires UserID et ForumID, car un utilisateur peut être
modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
est situé dans une autre table Users, je créé une relation 1 à n entre Users
et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a choisir
dans Moderators est donc UserID.
Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu de
un pour me satisfaire !).
Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
l'habitude, soit que je n'ai pas compris comment faire cela via la version
2005. Pouvez vous m'en dire plus svp ?

Merci d'avance.


"Med Bouchenafa" a écrit :

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...
> Apparemment dans SQL Server 2005, on a plus le choix de la table source
> pour
> effectuer une relation, c'est forcément la table "étrangère". Donc pour
> moi
> Moderateurs.
> Il est possible que je me trompe car novice sur SQLS 2005....
> Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
> mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
> clé
> primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
> champs
> de clé primaire et ceux de clé étrangère dans une même table ! Alors
> pourquoi
> je dois choisir 2 champs comme clé étrangère ???
> Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
> problème ?
> Merci.

Etienne a écrit:

Bonjour Med,
Voici mon problème, il est simple :
j'ai une table dont un champ doit être une clé étrangère d'une autre table,
ici une relation de 1 à n (je me place donc du côté n).
Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le cas
classique.
Considérons maintenant ce même exemple mais la table dispose d'une clé
primaire - le fait que la table est une clé primaire n'a aucun rapport avec
la clé étrangère à créer, j'en suis conscient ; cela reste archi classique et
je crée encore la relation sans difficulté.
J'arrive au cas qui me soucis, imaginons cette fois que cette table est une
clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
table est une clé primaire.
Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer une
clé étrangère sur 2 champs !
Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé étrangère
???

Pour étayer mon propos, voici un exemple qui correspond bien :
J'ai une table Users et une table Moderators ; Moderators comprend deux
champs clé primaires UserID et ForumID, car un utilisateur peut être
modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
est situé dans une autre table Users, je créé une relation 1 à n entre Users
et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a choisir
dans Moderators est donc UserID.
Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu de
un pour me satisfaire !).
Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
l'habitude, soit que je n'ai pas compris comment faire cela via la version
2005. Pouvez vous m'en dire plus svp ?

Je crois vous avoir montré comment créer ces relations avec le langage SQL...

Que voulez-vous de plus ?

Autre exemple pour votre cas :

CREATE TABLE Users
(UserID INT NOT NULL PRIMARY KEY,
UserName VARCHAR(16))

CREATE TABLE Moderators
(UserID INT NOT NULL FOREIGN KEY REFERENCES Users (UserID),
ForumID INT NOT NULL,
CONSTRAINT PK_Moderators PRIMARY KEY (UserID, ForumID),
ColX VARCHAR(16))

C'est tout ce qu'il y a à faire !

A +

Merci d'avance.


"Med Bouchenafa" a écrit :

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...

Apparemment dans SQL Server 2005, on a plus le choix de la table source
pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour
moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....
Je peux choisir n'importe quel champ dans cette table comme clé étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors
pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?
Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Je vois mieux maintenant ton problème.
Je dois t'avouer que cette interface n'est pas intuitive du tout
J'ai créé deux tables USER(UserID) et MODERATEUR(UserID, ForumID) et j'ai
essayé de reproduire ton problème
En faisant les choses intuivement, cela n'a pas raté, j'ai eu le même
message d'erreur que toi.

Il est vrai que je suis pas trop habitué à ces interfaces graphiques mais je
connais tout de même bien les diagrammes de bases de données à la 2000
J'ai donc décidé de créer un diagramme de base de données et là quelle
déception
Les fonctionnalités des diagrammes de bases de données ont largement été
réduites par rapport à 2000.
Pourquoi? je ne sais pas trop.
Dans les versions beta, je crois qu' il a été question, à un moment donné,
de supprimer carrément ces diagrammes.
Il est possible qu'ils aient été rajoutés à la va-vite...avec un résultat
plus que décevant.


Quoi qu'il en soit, j'arrive très intuivement à créer une relation de clef
étrangère entre MODERATEUR(UserID) et USER(UserID)
Je reviens sur le menu relashionship et là miracle la relation y est...

Heureusement car la norme SQL est très claire sur le sujet
Elle permet à une colA d'une tableA de référencer une colonne colB d'une
tableB à condition qu'elle soit clef primaire ou en contrainte unique
La norme n'impose aucune restriction sur colA de la tableA. C'est une
contrainte de domaine.
Pourquoi ce message d'erreur alors

Je replonge dans la documentation et j'essaye de comprendre la nouvelle
logique.
Et je finis par comprendre.
La regle est simple :

1) On commence toujours par choisir la table qui possède la colonne clef
étrangère.
C'est logique car c'est une colonne de cette table dont on cherche à
restreindre le domaine.
Dans notre cas, tu choisis la table MODERATEUR.

2) Tu affiches le menu relationships... jusque ce que tu arrives à la
fameuse fenêtre.

3) Tu choisis à gauche la table avec la colonne de domaine
Dans notre cas USER

4) Tu sélectionnes ensuite les colonnes en correspondance
Dans notre cas UserID (USER) et UserID(MODERATEUR)

Maintenant avec le recul cela parait logique mais il est vrai que ce n'est
pas intuitif du tout.
J'étais habitué, tout comme toi peut-etre, à choisir deux tables et à les
mettre en correspondance.
Une deuxième chose qui m'a peut-etre dérouté est le fait que USER soit à
gauche et MODERATEUR à droite
J'étais plus habitué au contraire. Mais bon, on finira pas s'y faire...

Par contre, je regrette vraiment l'interface 2000 des diagrammes de bases de
données.
C'était vraiment pratique et intuitif
Cette nouvelle interface n'opporte vraiment rien de plus tout au contraire


--
Avec mes meilleurs voeux 2006
Med Bouchenafa



"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: BDEEDF5F-AB0F-4D81-BB43-5F79FE8FEC9D@microsoft.com...

Bonjour Med,
Voici mon problème, il est simple :
j'ai une table dont un champ doit être une clé étrangère d'une autre
table,
ici une relation de 1 à n (je me place donc du côté n).
Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le
cas
classique.
Considérons maintenant ce même exemple mais la table dispose d'une clé
primaire - le fait que la table est une clé primaire n'a aucun rapport
avec
la clé étrangère à créer, j'en suis conscient ; cela reste archi classique
et
je crée encore la relation sans difficulté.
J'arrive au cas qui me soucis, imaginons cette fois que cette table est
une
clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
table est une clé primaire.
Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer
une
clé étrangère sur 2 champs !
Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé
étrangère
???

Pour étayer mon propos, voici un exemple qui correspond bien :
J'ai une table Users et une table Moderators ; Moderators comprend deux
champs clé primaires UserID et ForumID, car un utilisateur peut être
modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
est situé dans une autre table Users, je créé une relation 1 à n entre
Users
et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a
choisir
dans Moderators est donc UserID.
Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu
de
un pour me satisfaire !).
Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
l'habitude, soit que je n'ai pas compris comment faire cela via la version
2005. Pouvez vous m'en dire plus svp ?

Merci d'avance.


"Med Bouchenafa" a écrit :

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu
pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne
fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...
> Apparemment dans SQL Server 2005, on a plus le choix de la table source
> pour
> effectuer une relation, c'est forcément la table "étrangère". Donc pour
> moi
> Moderateurs.
> Il est possible que je me trompe car novice sur SQLS 2005....
> Je peux choisir n'importe quel champ dans cette table comme clé
> étrangère,
> mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
> clé
> primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
> champs
> de clé primaire et ceux de clé étrangère dans une même table ! Alors
> pourquoi
> je dois choisir 2 champs comme clé étrangère ???
> Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
> problème ?
> Merci.

donc, med, mieux vaut donc tout faire en SQL et finalement appuyer sur le bouton
pour qu'il "pisse" d'un seul coup, tout le diagramme.

De toute façon c'est plus pro de faire en SQL qu'en graphique. Le mieux étant de
passer par un outil de modélisation.

A +

Med Bouchenafa a écrit:

Je vois mieux maintenant ton problème.
Je dois t'avouer que cette interface n'est pas intuitive du tout
J'ai créé deux tables USER(UserID) et MODERATEUR(UserID, ForumID) et j'ai
essayé de reproduire ton problème
En faisant les choses intuivement, cela n'a pas raté, j'ai eu le même
message d'erreur que toi.

Il est vrai que je suis pas trop habitué à ces interfaces graphiques mais je
connais tout de même bien les diagrammes de bases de données à la 2000
J'ai donc décidé de créer un diagramme de base de données et là quelle
déception
Les fonctionnalités des diagrammes de bases de données ont largement été
réduites par rapport à 2000.
Pourquoi? je ne sais pas trop.
Dans les versions beta, je crois qu' il a été question, à un moment donné,
de supprimer carrément ces diagrammes.
Il est possible qu'ils aient été rajoutés à la va-vite...avec un résultat
plus que décevant.


Quoi qu'il en soit, j'arrive très intuivement à créer une relation de clef
étrangère entre MODERATEUR(UserID) et USER(UserID)
Je reviens sur le menu relashionship et là miracle la relation y est...

Heureusement car la norme SQL est très claire sur le sujet
Elle permet à une colA d'une tableA de référencer une colonne colB d'une
tableB à condition qu'elle soit clef primaire ou en contrainte unique
La norme n'impose aucune restriction sur colA de la tableA. C'est une
contrainte de domaine.
Pourquoi ce message d'erreur alors

Je replonge dans la documentation et j'essaye de comprendre la nouvelle
logique.
Et je finis par comprendre.
La regle est simple :

1) On commence toujours par choisir la table qui possède la colonne clef
étrangère.
C'est logique car c'est une colonne de cette table dont on cherche à
restreindre le domaine.
Dans notre cas, tu choisis la table MODERATEUR.

2) Tu affiches le menu relationships... jusque ce que tu arrives à la
fameuse fenêtre.

3) Tu choisis à gauche la table avec la colonne de domaine
Dans notre cas USER

4) Tu sélectionnes ensuite les colonnes en correspondance
Dans notre cas UserID (USER) et UserID(MODERATEUR)

Maintenant avec le recul cela parait logique mais il est vrai que ce n'est
pas intuitif du tout.
J'étais habitué, tout comme toi peut-etre, à choisir deux tables et à les
mettre en correspondance.
Une deuxième chose qui m'a peut-etre dérouté est le fait que USER soit à
gauche et MODERATEUR à droite
J'étais plus habitué au contraire. Mais bon, on finira pas s'y faire...

Par contre, je regrette vraiment l'interface 2000 des diagrammes de bases de
données.
C'était vraiment pratique et intuitif
Cette nouvelle interface n'opporte vraiment rien de plus tout au contraire


--
Avec mes meilleurs voeux 2006
Med Bouchenafa



"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: BDEEDF5F-AB0F-4D81-BB43-5F79FE8FEC9D@microsoft.com...

Bonjour Med,
Voici mon problème, il est simple :
j'ai une table dont un champ doit être une clé étrangère d'une autre
table,
ici une relation de 1 à n (je me place donc du côté n).
Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le
cas
classique.
Considérons maintenant ce même exemple mais la table dispose d'une clé
primaire - le fait que la table est une clé primaire n'a aucun rapport
avec
la clé étrangère à créer, j'en suis conscient ; cela reste archi classique
et
je crée encore la relation sans difficulté.
J'arrive au cas qui me soucis, imaginons cette fois que cette table est
une
clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
table est une clé primaire.
Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer
une
clé étrangère sur 2 champs !
Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé
étrangère
???

Pour étayer mon propos, voici un exemple qui correspond bien :
J'ai une table Users et une table Moderators ; Moderators comprend deux
champs clé primaires UserID et ForumID, car un utilisateur peut être
modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
est situé dans une autre table Users, je créé une relation 1 à n entre
Users
et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a
choisir
dans Moderators est donc UserID.
Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu
de
un pour me satisfaire !).
Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
l'habitude, soit que je n'ai pas compris comment faire cela via la version
2005. Pouvez vous m'en dire plus svp ?

Merci d'avance.


"Med Bouchenafa" a écrit :

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu
pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne
fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...

Apparemment dans SQL Server 2005, on a plus le choix de la table source
pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour
moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....
Je peux choisir n'importe quel champ dans cette table comme clé
étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors
pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?
Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

Merci beaucoup Med pour le temps passé à m'aider. Et grand merci !
Je dois avouer que je suis aussi dérouter par tes confirmations ; je trouve
ça fort de roquefort pour une nouvelle version !
Je partage pas trop ton avis Fred, les interfaces graphiques ont permis à
chacun de prendre facilement en main la conception d'application, dans autant
de domaines nécessaires aujourd'hui, sinon on revient à notre bon vieux DOS
ou à NotePad et on laisse tomber VS.NET. S'il faut être expert en SQL pour
créer relations, index et contraintes à la mano, pourquoi plus alors en SQL
qu'en C#, XML, Service Web... ?
Ah oui, ce n'est pas un forum de philo, je me laisse aller là...

"Fred BROUARD" a écrit :

donc, med, mieux vaut donc tout faire en SQL et finalement appuyer sur le bouton
pour qu'il "pisse" d'un seul coup, tout le diagramme.

De toute façon c'est plus pro de faire en SQL qu'en graphique. Le mieux étant de
passer par un outil de modélisation.

A +

Med Bouchenafa a écrit:
> Je vois mieux maintenant ton problème.
> Je dois t'avouer que cette interface n'est pas intuitive du tout
> J'ai créé deux tables USER(UserID) et MODERATEUR(UserID, ForumID) et j'ai
> essayé de reproduire ton problème
> En faisant les choses intuivement, cela n'a pas raté, j'ai eu le même
> message d'erreur que toi.
>
> Il est vrai que je suis pas trop habitué à ces interfaces graphiques mais je
> connais tout de même bien les diagrammes de bases de données à la 2000
> J'ai donc décidé de créer un diagramme de base de données et là quelle
> déception
> Les fonctionnalités des diagrammes de bases de données ont largement été
> réduites par rapport à 2000.
> Pourquoi? je ne sais pas trop.
> Dans les versions beta, je crois qu' il a été question, à un moment donné,
> de supprimer carrément ces diagrammes.
> Il est possible qu'ils aient été rajoutés à la va-vite...avec un résultat
> plus que décevant.
>
>
> Quoi qu'il en soit, j'arrive très intuivement à créer une relation de clef
> étrangère entre MODERATEUR(UserID) et USER(UserID)
> Je reviens sur le menu relashionship et là miracle la relation y est...
>
> Heureusement car la norme SQL est très claire sur le sujet
> Elle permet à une colA d'une tableA de référencer une colonne colB d'une
> tableB à condition qu'elle soit clef primaire ou en contrainte unique
> La norme n'impose aucune restriction sur colA de la tableA. C'est une
> contrainte de domaine.
> Pourquoi ce message d'erreur alors
>
> Je replonge dans la documentation et j'essaye de comprendre la nouvelle
> logique.
> Et je finis par comprendre.
> La regle est simple :
>
> 1) On commence toujours par choisir la table qui possède la colonne clef
> étrangère.
> C'est logique car c'est une colonne de cette table dont on cherche à
> restreindre le domaine.
> Dans notre cas, tu choisis la table MODERATEUR.
>
> 2) Tu affiches le menu relationships... jusque ce que tu arrives à la
> fameuse fenêtre.
>
> 3) Tu choisis à gauche la table avec la colonne de domaine
> Dans notre cas USER
>
> 4) Tu sélectionnes ensuite les colonnes en correspondance
> Dans notre cas UserID (USER) et UserID(MODERATEUR)
>
> Maintenant avec le recul cela parait logique mais il est vrai que ce n'est
> pas intuitif du tout.
> J'étais habitué, tout comme toi peut-etre, à choisir deux tables et à les
> mettre en correspondance.
> Une deuxième chose qui m'a peut-etre dérouté est le fait que USER soit à
> gauche et MODERATEUR à droite
> J'étais plus habitué au contraire. Mais bon, on finira pas s'y faire...
>
> Par contre, je regrette vraiment l'interface 2000 des diagrammes de bases de
> données.
> C'était vraiment pratique et intuitif
> Cette nouvelle interface n'opporte vraiment rien de plus tout au contraire
>
>
> --
> Avec mes meilleurs voeux 2006
> Med Bouchenafa
>
>
>
> "Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
> news: BDEEDF5F-AB0F-4D81-BB43-5F79FE8FEC9D@microsoft.com...
>
>>Bonjour Med,
>>Voici mon problème, il est simple :
>>j'ai une table dont un champ doit être une clé étrangère d'une autre
>>table,
>>ici une relation de 1 à n (je me place donc du côté n).
>>Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le
>>cas
>>classique.
>>Considérons maintenant ce même exemple mais la table dispose d'une clé
>>primaire - le fait que la table est une clé primaire n'a aucun rapport
>>avec
>>la clé étrangère à créer, j'en suis conscient ; cela reste archi classique
>>et
>>je crée encore la relation sans difficulté.
>>J'arrive au cas qui me soucis, imaginons cette fois que cette table est
>>une
>>clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
>>qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
>>table est une clé primaire.
>>Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer
>>une
>>clé étrangère sur 2 champs !
>>Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé
>>étrangère
>>???
>>
>>Pour étayer mon propos, voici un exemple qui correspond bien :
>>J'ai une table Users et une table Moderators ; Moderators comprend deux
>>champs clé primaires UserID et ForumID, car un utilisateur peut être
>>modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
>>est situé dans une autre table Users, je créé une relation 1 à n entre
>>Users
>>et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a
>>choisir
>>dans Moderators est donc UserID.
>>Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
>>SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu
>>de
>>un pour me satisfaire !).
>>Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
>>l'habitude, soit que je n'ai pas compris comment faire cela via la version
>>2005. Pouvez vous m'en dire plus svp ?
>>
>>Merci d'avance.
>>
>>
>>"Med Bouchenafa" a écrit :
>>
>>
>>>Tu as apparemment noté une différence entre 2000 et 2005.
>>>Je n'ai pas vraiment compris quelle était cette différence
>>>Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu
>>>pouvais
>>>être plus explicte
>>>Avec un petit exemple montrant ce qui fonctionnait et ce qui ne
>>>fonctionne
>>>plus...
>>>
>>>--
>>>Avec mes meilleurs voeux 2006
>>>Med Bouchenafa
>>>
>>>"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
>>>news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...
>>>
>>>>Apparemment dans SQL Server 2005, on a plus le choix de la table source
>>>>pour
>>>>effectuer une relation, c'est forcément la table "étrangère". Donc pour
>>>>moi
>>>>Moderateurs.
>>>>Il est possible que je me trompe car novice sur SQLS 2005....
>>>>Je peux choisir n'importe quel champ dans cette table comme clé
>>>>étrangère,
>>>>mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
>>>>clé
>>>>primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
>>>>champs
>>>>de clé primaire et ceux de clé étrangère dans une même table ! Alors
>>>>pourquoi
>>>>je dois choisir 2 champs comme clé étrangère ???
>>>>Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
>>>>problème ?
>>>>Merci.
>>>
>>>
>>>
>
>

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

bonjour,

Etienne a écrit:

Merci beaucoup Med pour le temps passé à m'aider. Et grand merci !
Je dois avouer que je suis aussi dérouter par tes confirmations ; je trouve
ça fort de roquefort pour une nouvelle version !
Je partage pas trop ton avis Fred, les interfaces graphiques ont permis à
chacun de prendre facilement en main la conception d'application, dans autant
de domaines nécessaires aujourd'hui, sinon on revient à notre bon vieux DOS
ou à NotePad et on laisse tomber VS.NET. S'il faut être expert en SQL pour
créer relations, index et contraintes à la mano, pourquoi plus alors en SQL
qu'en C#, XML, Service Web... ?

Parce que SQL ne peut pas être représenté de façon graphique. Par exemple aucun
outil graphique ne permet de présenter des requêtes SQL SELECT avec toutes les
fonctionnalité de cette simple (?) commande.

De même vous inversez le problème : vous devriez commencer par modèliser (donc
faire votre graphique conceptuel) pour obtenir le SQL correspondant. Or vous
tentez de faire l'inverse, ce qu'aucun outil ne sait faire proprement.

Le fait que MS à envisagé de virer la partie graphique des relations entre table
me parait assez justifié. Ce n'est pas en effet au SGBDR de faire cela. par
principe un SGBDR ne s'occupe jamais de l'IHM quelle qu'en soit le niveau.
Le choix de faire disparaitre cet élément me parait à la foi souhaitable et
fondé dans la mesure ou cet outil ne fournit pas un service cohérent.
Or un service incohérent (parce qu'incomplet) dans un outil professionnel
conduit généralement à des erreurs.
Mon expérience (de plusieurs décennies maintenant...) m'a montré que les
développements fait sans un outil de modélisation propre, donc en l'absence
d'une méthode standard et cohérente (MERISE, UML...), étaient à terme voués à
l'échec.

Mais vous pouvez faire ce que vous voulez... Y compris considérer les conseils
que l'on vous donne comme des idioties... Cela m'arrange, car à terme c'est un
potentiel de client plus important !

A +

Ah oui, ce n'est pas un forum de philo, je me laisse aller là...

"Fred BROUARD" a écrit :

donc, med, mieux vaut donc tout faire en SQL et finalement appuyer sur le bouton
pour qu'il "pisse" d'un seul coup, tout le diagramme.

De toute façon c'est plus pro de faire en SQL qu'en graphique. Le mieux étant de
passer par un outil de modélisation.

A +

Med Bouchenafa a écrit:

Je vois mieux maintenant ton problème.
Je dois t'avouer que cette interface n'est pas intuitive du tout
J'ai créé deux tables USER(UserID) et MODERATEUR(UserID, ForumID) et j'ai
essayé de reproduire ton problème
En faisant les choses intuivement, cela n'a pas raté, j'ai eu le même
message d'erreur que toi.

Il est vrai que je suis pas trop habitué à ces interfaces graphiques mais je
connais tout de même bien les diagrammes de bases de données à la 2000
J'ai donc décidé de créer un diagramme de base de données et là quelle
déception
Les fonctionnalités des diagrammes de bases de données ont largement été
réduites par rapport à 2000.
Pourquoi? je ne sais pas trop.
Dans les versions beta, je crois qu' il a été question, à un moment donné,
de supprimer carrément ces diagrammes.
Il est possible qu'ils aient été rajoutés à la va-vite...avec un résultat
plus que décevant.


Quoi qu'il en soit, j'arrive très intuivement à créer une relation de clef
étrangère entre MODERATEUR(UserID) et USER(UserID)
Je reviens sur le menu relashionship et là miracle la relation y est...

Heureusement car la norme SQL est très claire sur le sujet
Elle permet à une colA d'une tableA de référencer une colonne colB d'une
tableB à condition qu'elle soit clef primaire ou en contrainte unique
La norme n'impose aucune restriction sur colA de la tableA. C'est une
contrainte de domaine.
Pourquoi ce message d'erreur alors

Je replonge dans la documentation et j'essaye de comprendre la nouvelle
logique.
Et je finis par comprendre.
La regle est simple :

1) On commence toujours par choisir la table qui possède la colonne clef
étrangère.
C'est logique car c'est une colonne de cette table dont on cherche à
restreindre le domaine.
Dans notre cas, tu choisis la table MODERATEUR.

2) Tu affiches le menu relationships... jusque ce que tu arrives à la
fameuse fenêtre.

3) Tu choisis à gauche la table avec la colonne de domaine
Dans notre cas USER

4) Tu sélectionnes ensuite les colonnes en correspondance
Dans notre cas UserID (USER) et UserID(MODERATEUR)

Maintenant avec le recul cela parait logique mais il est vrai que ce n'est
pas intuitif du tout.
J'étais habitué, tout comme toi peut-etre, à choisir deux tables et à les
mettre en correspondance.
Une deuxième chose qui m'a peut-etre dérouté est le fait que USER soit à
gauche et MODERATEUR à droite
J'étais plus habitué au contraire. Mais bon, on finira pas s'y faire...

Par contre, je regrette vraiment l'interface 2000 des diagrammes de bases de
données.
C'était vraiment pratique et intuitif
Cette nouvelle interface n'opporte vraiment rien de plus tout au contraire


--
Avec mes meilleurs voeux 2006
Med Bouchenafa



"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: BDEEDF5F-AB0F-4D81-BB43-5F79FE8FEC9D@microsoft.com...

Bonjour Med,
Voici mon problème, il est simple :
j'ai une table dont un champ doit être une clé étrangère d'une autre
table,
ici une relation de 1 à n (je me place donc du côté n).
Dans SQLS 2005, je crée ma relation sur ce champ sans problème, c'est le
cas
classique.
Considérons maintenant ce même exemple mais la table dispose d'une clé
primaire - le fait que la table est une clé primaire n'a aucun rapport
avec
la clé étrangère à créer, j'en suis conscient ; cela reste archi classique
et
je crée encore la relation sans difficulté.
J'arrive au cas qui me soucis, imaginons cette fois que cette table est
une
clé primaire "multiple", ici basée sur deux champs - je reconnais toujours
qu'il n'y aucun rapport entre ma clé étrangère à créer et le fait que ma
table est une clé primaire.
Et bien, lorsque je créé la realtion, sql server 2005 m'impose de créer
une
clé étrangère sur 2 champs !
Je ne vois pas pourquoi, quel impact à ma clé primaire sur une clé
étrangère
???

Pour étayer mon propos, voici un exemple qui correspond bien :
J'ai une table Users et une table Moderators ; Moderators comprend deux
champs clé primaires UserID et ForumID, car un utilisateur peut être
modérateur de plusieurs Forum. Sachant que le nom du modérateur à afficher
est situé dans une autre table Users, je créé une relation 1 à n entre
Users
et Moderators : Users.UserID = Moderators.UserID ; ma clé étrangère a
choisir
dans Moderators est donc UserID.
Si j'effectue cette manipulation, lorsque je créé ma relation sur UserID,
SQL Sever 2005 m'impose le choix de 2 champs sur ma clé étrangère (au lieu
de
un pour me satisfaire !).
Il est évident que je me plante soit dans mon raisonnement, bien que j'ai
l'habitude, soit que je n'ai pas compris comment faire cela via la version
2005. Pouvez vous m'en dire plus svp ?

Merci d'avance.


"Med Bouchenafa" a écrit :

Tu as apparemment noté une différence entre 2000 et 2005.
Je n'ai pas vraiment compris quelle était cette différence
Je pourrais peut-être aider, ou du moins comprendre moi-même, si tu
pouvais
être plus explicte
Avec un petit exemple montrant ce qui fonctionnait et ce qui ne
fonctionne
plus...

--
Avec mes meilleurs voeux 2006
Med Bouchenafa

"Etienne" <Etienne@discussions.microsoft.com> a écrit dans le message de
news: 93630733-F065-4204-8DAA-B1F934958FC3@microsoft.com...

Apparemment dans SQL Server 2005, on a plus le choix de la table source
pour
effectuer une relation, c'est forcément la table "étrangère". Donc pour
moi
Moderateurs.
Il est possible que je me trompe car novice sur SQLS 2005....
Je peux choisir n'importe quel champ dans cette table comme clé
étrangère,
mais je suis obligé d'en mentionner 2. Pourquoi 2 ? La cause est que la
clé
primaire est créée sur 2 champs, pourtant y a aucun rapport entre les
champs
de clé primaire et ceux de clé étrangère dans une même table ! Alors
pourquoi
je dois choisir 2 champs comme clé étrangère ???
Avez-vous testé mon exemple sur SQL Server 2005 ? Comprenez vous mon
problème ?
Merci.

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************