Discussion :

[Kropernic]

C'est bien ce que je pensais que c'était ^^.

Et c'est vrai que ça n'a pas l'air dur à mettre en oeuvre. Je vais cependant laisser le champ id tout seul car une traduction ne sera pas plus utilisée qu'une autre. Je préfère donc laisser toutes les langues sur un pied d'égalité.

[Kropernic]

Une dernière chose...

Pour les langues, j'ai donc la table langue

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
/****** Object:  Table [dbo].[langue]    Script Date: 06/14/2011 16:23:12 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[langue](
	[langue] [smallint] NOT NULL,
PRIMARY KEY CLUSTERED 
(
	[langue] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

et la table langue_traduction

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
24
25
26
27
28
29
30
/****** Object:  Table [dbo].[langue_traduction]    Script Date: 06/14/2011 16:22:25 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[langue_traduction](
	[id] [smallint] NOT NULL,
	[langue] [smallint] NOT NULL,
	[description] [varchar](100) COLLATE Latin1_General_CI_AS NOT NULL,
 CONSTRAINT [PK_id_langue] PRIMARY KEY CLUSTERED 
(
	[id] ASC,
	[langue] ASC
)WITH (PAD_INDEX  = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
 
GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [dbo].[langue_traduction]  WITH CHECK ADD  CONSTRAINT [FK_langue_traduction_langue] FOREIGN KEY([id])
REFERENCES [dbo].[langue] ([langue])
GO
ALTER TABLE [dbo].[langue_traduction] CHECK CONSTRAINT [FK_langue_traduction_langue]
GO
ALTER TABLE [dbo].[langue_traduction]  WITH CHECK ADD  CONSTRAINT [FK_langue_traduction_langue1] FOREIGN KEY([langue])
REFERENCES [dbo].[langue] ([langue])
GO
ALTER TABLE [dbo].[langue_traduction] CHECK CONSTRAINT [FK_langue_traduction_langue1]

Est-ce normal d'avoir deux clés étrangères qui font références au même champ de la même table ? Cela peut-il poser des problèmes ?

Bien à vous,

Griftou.

[elsuket]

Est-ce normal d'avoir deux clés étrangères qui font références au même champ de la même table ? Cela peut-il poser des problèmes ?

Dans votre cas cela n'a pas de sens.
D'autre part si vos entités n'ont pas d'attributs, c'est qu'elles n'ont pas lieu d'être
Pour l'entité langue, il me semble que seul le libellé suffit, non ?
Dans ce cas il suffit de référencer la clé primaire de la table qui la représente.
Mais il existe probablement d'autres caractéristiques !

@++

[Kropernic]

D'autre part si vos entités n'ont pas d'attributs, c'est qu'elles n'ont pas lieu d'être

On retombe alors dans le cas des premiers scripts que j'ai donné non ?
Ce qui en résumé donne :

- la table personnel avec sa flopée de clefs étrangères (paramètres)
- pour chaque clef étrangère de la table personnel, une table composée de :
-- code du paramètre
-- code de langue
-- traduction
-- primary key (code du paramètre, code de langue)

Et j'en reviens alors mon problème de la création des relations dans mon diagramme dans management studio. Je me cite donc :

Rebonjour,

Je reviens vers vous car j'ai un nouveau souci suite à la modification des tables de ce que j'appelle les paramètres pour gérer les langues.

Une fois cela fait, j'ai évidemment voulu recréer également les liaisons entre les différentes tables. Et c'est là que ça coince. Forcément, puisque dans ma table caractere_juridique_contrat (pour continuer avec le même exemple) se trouve repris le même id pour chaque langue (2 fois donc dans mon cas). De ce fait, la contrainte d'unicité pour établir la relation de clé étrangère (toute mes excuses si j'utilise mal le vocabulaire) n'est pas respectée et la relation ne peut se faire.

Je conçois donc bien que je dois également tenir compte de la langue mais je ne comprends pas comment cela fonctionne en pratique...

Lorsque sur le diagramme je veux faire la liaison, Management Studio me propose bien :

1 : pour la table de clé primaire :
- caractere_juridique_contrat
- langue

2 : pour la table de clé étrangère :
- caractere_juridique_contrat

Je pourrais cliquer sur ok et passer à la suite mais je préfèrerais comprendre ce qu'il se passe exactement.

Pouvez-vous m'éclairer sur ce point ? (en fait c'est tellement flou que je ne suis même pas certain d'avoir correctement formulé ma demande...)

Griftou.

Bien à vous,

Griftou.

[elsuket]

Pour faire cela il faudrait que vous soyez certain que toutes les entités en relation avec l'entité personnel n'auront jamais d'autres attributs que leur nom.
Est-ce bien le cas ? Réfléchissez bien aux mots en gras ...

@++

[Kropernic]

Pour faire cela il faudrait que vous soyez certain que toutes les entités en relation avec l'entité personnel n'auront jamais d'autres attributs que leur nom.
Est-ce bien le cas ? Réfléchissez bien aux mots en gras ...

@++

Bonjour,

Pour votre question, oui j'en suis certain. Je vais tout de même être prudent et préciser à 95%.

Par contre alors, mon problème se situe au niveau de la liaison dans management studio. Je crée les liaisons à partir de la vue du diagramme de la db (car je trouve cela plus pratique en mode graphique). Je fais donc un drag&drop en partant du champ de clef étrangère de la table personnel vers l'id de la table adéquate. Mais là, management studio ne semble pas apprécier que la clef primaire de ladite table soit une clef composée. Et en fait, c'est tout à fait logique. Du coup, je comprends pas bien comment je dois procéder pour faire cette liaison.

Griftou.


EDIT : J'ai beau retourner le truc dans tous les sens, avec mes connaissances limitées (faut bien le reconnaître), j'en arrive toujours à la conclusion que pour faire cette liaison, il me faut cette entité avec juste l'id sinon la clef étrangère ne pourra pas se faire vu qu'il n'y correspondra pas une et une seule valeur dans la table du paramètre...

J'ai tenté de trouver de la documentation sur les règles à suivre en cas de clef composée mais je n'ai rien trouvé de probant. Pas même sur le site de sqlpro (mais il est aussi possible que je sois passer à côté au milieu de ces tonnes d'informations)

[elsuket]

Pour votre question, oui j'en suis certain. Je vais tout de même être prudent et préciser à 95%.

héhéhé

Pour ce qui est de la clé étrangère composée, comme je n'utilise jamais l'interface graphique que pour mes requêtes, je ne peux vous donner qu'un exemple de 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
15
16
17
CREATE TABLE dbo.A
(
	a int
	, b int
	, c varchar(16)
	, CONSTRAINT XPKA_a_b PRIMARY KEY (a, b)
)
GO
 
CREATE TABLE dbo.B
(
	i int NOT NULL CONSTRAINT PKB PRIMARY KEY
	, a int
	, b int
	, d varchar(16)
	, CONSTRAINT FKB_a_b FOREIGN KEY (a, b) REFERENCES dbo.A
)

EDIT : J'ai beau retourner le truc dans tous les sens, avec mes connaissances limitées (faut bien le reconnaître), j'en arrive toujours à la conclusion que pour faire cette liaison, il me faut cette entité avec juste l'id sinon la clef étrangère ne pourra pas se faire vu qu'il n'y correspondra pas une et une seule valeur dans la table du paramètre...

Vous ne pouvez pas faire cela sinon la table qui va référencer une fonction par exemple contiendra autant de lignes que de langues, ce qui est faux.

@++

[Kropernic]

Si seulement on pouvait faire des petits dessins plutôt qu'un long discours...

Dans votre exemple, votre clef étrangère est sur 2 champs également. Ce n'est pas mon cas ici .

Vous ne pouvez pas faire cela sinon la table qui va référencer une fonction par exemple contiendra autant de lignes que de langues, ce qui est faux.

Je ne crois pas... Plutôt que de rester dans la théorie, je vais tâcher de représenter un exemple concret (voir pièce jointe).

Nous avons donc la colonne fonction de la table personnel qui pointe vers la colonne id dans la table fonction et la colonne fonction de la table fonction_traduction qui pointe vers la colonne id de la table fonction.

Cela vous semble-t-il correct ?

Vous me disiez hier qu'une entité sans attribut n'a pas de raison d'être. A priori, je n'ai aucune raison de contredire cela mais alors, comment s'effectue la liaison entre la table personnel et fonction_traduction si on se passe de la table fonction ?

[Kropernic]

Hello, c'est encore moi.

J'espère que le fait que vous ne répondez plus est dû au fait que vous avez vous aussi du travail à faire et que je ne vous ai pas (trop) exaspéré jusqu'ici .

EDIT : Message déplacé dans ce topic pour ne pas créer de confusion.

Griftou.

[elsuket]

Absolument pas
Je comprend tout à fait que vous vous posiez ces questions.
C'est vrai qu'aujourd'hui j'ai eu pas mal de boulot, mais avec le décalage horaire, il était temps d'aller boire une petite bière avec mes collègues

Dans votre exemple, votre clef étrangère est sur 2 champs également. Ce n'est pas mon cas ici .

Certes. Je vous montre simplement comment faire pour ajouter une clé étrangère à une table vers une autre table dont la clé primaire est composite
C'est ce que vous cherchiez sans le post n° 26.

Vous me disiez hier qu'une entité sans attribut n'a pas de raison d'être. A priori, je n'ai aucune raison de contredire cela mais alors, comment s'effectue la liaison entre la table personnel et fonction_traduction si on se passe de la table fonction ?

Cela montre mes connaissances très limitées en modélisation ...
A priori je ferai comme je l'ai pensé un peu plus haut dans la conversation, c'est-à-dire stocker le nom "par défaut" du tuple ...
Mais quelqu'un comme SQLPro vous répondra sûrement bien mieux que moi à ce sujet ...

@++

[iberserk]

Cela montre mes connaissances très limitées en modélisation ...

C'est un cas particulier ou votre table identifiant FONCTION ne contient aucun "attribut" non lié à une langue.

Cette table a pour moi toute son importance et pourrait par exemple avoir des notions non lié à une langue (codeFonction, Archivé oui/non etc).

Donc pour vous répondre dans le cas de FONCTION(que vous pourrez étendre aux autres...)

Table FONCTION (PK: FNC_ID)
Table LANGUE (PK: LNG_ID)
Table FONCTION_TRADUCTION (FK:FNC_ID et LNG_ID, COLONNE TRADUCTION_VALUE)

caractere_juridique_contrat à juste à référencer la table FONCTION (FNC_ID)

Ensuite créez une FONCTION TABLE (je sais que vous êtes dedans en ce moment) comme celà:

Code :

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

1
2
3
4
5
6
7
CREATE FUNCTION dbo.FN_GET_PERSONNEL (@langue smallint) 
RETURNS TABLE AS
 
RETURN SELECT P.ID,FT.TRADUCTION_VALUE AS FONCTION
FROM dbo.PERSONNEL P
      LEFT OUTER JOIN dbo.FONCTION_TRADUCTION FT
         ON FT.FNC_ID=P.FNC_ID AND FT.LNG_ID=(@langue

Vous pourriez également créer une VUE avec CROSS JOIN sur les langues.

[iberserk]

Bien sûr a vous d'etoffer la fonction avec toutes les colonnes à traduire (etat civil etc.)... je vous ai montré l'exemple pour FONCTION...

[Kropernic]

Un tout grand merci !

J'avoue que je n'aurais jamais pensé à créer une fonction. En fait, le genre de fonction que vous proposez, ça produit tip-top ce que je pensais faire avec les vues paramétrables (qui n'existent pas ) dont j'espérais l’existence dans l'autre topic.

Je vais donc m'orienter vers cela.

Table FONCTION (PK: FNC_ID)
Table LANGUE (PK: LNG_ID)
Table FONCTION_TRADUCTION (FK:FNC_ID et LNG_ID, COLONNE TRADUCTION_VALUE)

Il s'agit bien de la structure que j'ai mis en place finalement

Mais je reste cependant toujours perplexe pour le cas de la table LANGUE_TRADUCTION(FK:LNG_ID1 et LNG_ID2, COLONNE TRADUCTION_VALUE) où LNG_ID1 est la valeur de la langue en elle-même et LNG_ID2 est la langue de la traduction.

Est-ce correct d'avoir 2 clefs étrangères qui référence la même clef primaire dans une table ?

Griftou.

[Kropernic]

Code :

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

1
2
3
4
5
6
7
CREATE FUNCTION dbo.FN_GET_PERSONNEL (@langue smallint) 
RETURNS TABLE AS
 
RETURN SELECT P.ID,FT.TRADUCTION_VALUE AS FONCTION
FROM dbo.PERSONNEL P
      LEFT OUTER JOIN dbo.FONCTION_TRADUCTION FT
         ON FT.FNC_ID=P.FNC_ID AND FT.LNG_ID=(@langue

Encore une question quelques questions...

1) Pourquoi utiliser un LEFT OUTER JOIN ici ? En anticipation du cas où un membre du personnel aurait une fonction qui ne serait pas répertoriée dans la table fonction ?

2) Comment s'utilise la fonction par après ? Dois-je l'utiliser côté applicatif ? Puis-je l'utiliser comme une table à proprement parler dans une requête ?

Merci d'avance,

Griftou.

[iberserk]

Simple: si vous faite un inner et que la fonction n'a pas de traduction dans la langue voulue vous ne verrez pas le personnel.... avec un left vous verrez le personnel avec FONCTION à NULL... a vous de voir...

[iberserk]

Mais je reste cependant toujours perplexe pour le cas de la table LANGUE_TRADUCTION(FK:LNG_ID1 et LNG_ID2, COLONNE TRADUCTION_VALUE) où LNG_ID1 est la valeur de la langue en elle-même et LNG_ID2 est la langue de la traduction.

Est-ce correct d'avoir 2 clefs étrangères qui référence la même clef primaire dans une table ?

Je ne comprends pas cette table,je pense que vous vous êtes mal compris...

[Kropernic]

Je ne comprends pas cette table,je pense que vous vous êtes mal compris...

Je vais essayer d'être plus clair.

Il y a donc une table personnel comme suit :
TABLE PERSONNEL(PK: PRS_REGISTRE_NATIONAL char(11),...,LANGUE smallint,...)
où la colonne langue est la langue maternelle de la personne.

Et donc, comme pour fonction, une table langue et une table langue_traduction.

Là où la table fonction_traduction référençait la table fonction et la table langue, la table langue_traduction référencera donc 2 fois la table langue.

N'étant pas rodé dans ce genre de pratique, cette situation me semble bizarre et je voulais savoir si cela vous paraissait normal.

Bien à vous,

Griftou.

[iberserk]

Compris... non je ne vois pas le problème...

[Kropernic]

Ok bien c'est cool alors ^^.

Je suis pas du tout DBA mais comme il n'y en a pas là où je bosse (je bosse pour une chaine de magasin qui a son propre p'tit service développement), et bien il faut bien que je m'y colle un peu.

Donc merci beaucoup !