Discussion :

[Kropernic]

Bonjour,

Je suis actuellement en train de faire l'analyse d'un projet et je me pose une question au niveau de la conception de la DB. N'étant absolument pas DBA mais devant tout de même occupé cette fonction, je me tourne vers vous...

Ce qui suit décrit l'application, pour passer directement à la question, sautez le passage [NOTE].
[NOTE]
Pour situer un peu le contexte, il s'agit d'un projet destiné à gérer des entretiens "d'évolution" (d'évaluation en fait mais bon... ils ont appelé ça évolution^^).

Donc en gros, le supérieur s'entretien avec son subalterne puis après, reporte le contenu de l'entretien dans une application afin d'avoir un rapport. Dans l'application, il devra mentionner la personne concernée par cet entretien et sa fonction. Une fois la fonction choisie, le programme ira lui chercher les compétences qu'il faut évaluer pour cette fonction. Ces dernières sont organisées en groupe.
[/NOTE]

Pour le moment, j'ai donc une table TblEvoGroupe comme suit :

Code :

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

1
2
3
4
5
6
Id int not null identity(1,1) PK
IdGroupe int not null
IdLanguage int not null
Version int not null
Name varchar(150) not null
--divers champs de tracking

Déjà là, se pose la question de savoir s'il est préférable de choisir une clef primaire composée plutôt que d'ajouter un champ auto incrémenté.

Ensuite j'ai la table TblEvoCompetence comme suit :

Code :

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

1
2
3
4
5
6
7
Id int not null identity(1,1) PK
IdComp int not null
IdLanguage int not null
IdGroupe int not null
Version int not null
Texte varchar(1000) not null
--divers champs de tracking

La question que je me pose est :
Est-il possible d'établir une relation entre ces deux tables en sachant que le champ IdGroupe de la table TblEvoGroupe ne sera pas unique ?

Faut-il scinder cette table en 2 avec dans une, uniquement l'id du groupe et les champs de tracking et dans l'autre, les différentes traductions ? De cette manière j'aurai bien l'id de groupe qui sera unique pour servir de clef étrangère dans la table des compétences mais il y a peut-être une autre manière de faire...

NB : Une compétence ne peut appartenir qu'à un seul groupe.

Qu'en pensez-vous ?

Griftou.

[StringBuilder]

Il faudrait nous en dire plus sur le sens des différents attributs.

Je suis étonné par exemple de voir que les attributs IdLanguage, IdGroupe et Version sont présents dans les deux entités.

Aussi, je suis étonné de voir Id et IdComp dans l'entité des compétences : l'identifiant d'une compétence n'est-il pas unique ?

Idem pour l'entité des groups : on a déjà idgroup : à quoi sert le id ?

Si la langue et la version sont là pour apporter des traductions (et évolutions des traductions) alors ils doivent être dans deux entités alternatives "historique" et "traduction". Sinon, ça va être la croix et la banière.

D'autant que "organisation" est la même compétence que ce soit en français, chinois ou russe : à partir de là, il faut bel et bien un identifiant unique quelle que soit la langue, et utiliser cet identifiant comme clé étrangère, et non un id arbitraire comme tu as l'air de désirer faire.

[Kropernic]

Ok,

A la base, j'avais fait une table TblEvoCompetence et une table TblEvoCompetenceTrad.

Dans la première, uniquement un Id et des champs de tracking (createdOn, modifiedOn, createdBy et modified By) et le reste des champs dans la seconde (avec aussi des champs de tracking.

Mais vu que je n'avais comme données significatives que le champ Id dans la première table, cela me semblait bizarre...

Par contre, si je comprends bien ton explication, tu ferais une 3e table pour contenir les anciennes versions ? Est-ce bien cela ?

Griftou.

[StringBuilder]

En fait, ça dépend de ce que tu entends par "version".

Puisque la table des compétentes ne contient qu'un champ ID plus des dates de création/modification, je ne pense pas qu'il soit intéressant de gérer une version sur ces données.

On a donc une version sur les traductions.

Et à ce moment : à quoi sert cette version ? Pouvoir consulter le nom de la compétence l'an dernier ? (est-ce utile ?)

Si oui, alors personnellement, afin de ne pas alourdir la base, je rajouterais une table, dans laquelle je recopierais la donnée modifiée de la table de traduction, en mettant la date à laquelle le libellé historisé à été remplacé.

En effet, ce qui importe dans 99% des cas, c'est le nom de la compétence "là maintenant tout de suite", donc c'est domage de devoir faire des max() ou des filtres sur des dates dans tous les sens pour récupérer le dernier libellé, alors que l'utilité des libellés historisé est limitée.

Si c'était des tarifs par exemple, ce ne serait pas la même chose : il faut, dès qu'on gère une commande portant sur une date précise, retrouver les tarifs applicables à cette date, que ce soit les tarifs actuels ou ceux d'il y a 10 jours. Donc là, une plage de date d'application est pertinante.

Dans tous les cas un entier pour gérer une version me semble superflu : perte d'information par rapport à une date, et moins pratique à utiliser.

[Kropernic]

Le truc, c'est que donc, dans le contexte de l'application, l'utilisateur va encoder dans l'application une sorte de rapport d'entretien d'évaluation.

Si un an plus tard, on veut réimprimer ce rapport, je dois pouvoir retrouver le texte de la compétence tel qu'il était à ce moment là.

J'ai donc aussi une autre table que j'avais prévue comme ceci :

TblEvoNotation:

Code :

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

1
2
3
4
5
6
 
id int identity(1,1) PK
idComp int FK
VersionComp int
Note int
--divers champs de tracking

Qqch comme ça (je suis chez moi et je n'ai pas le document d'analyse sous les yeux).
Certes l'application permettra d'importer un document au format pdf pour réimpression mais, au cas où, j'aimerais pouvoir recréer le document à la volée. Je sauvegarde donc les notes accordées à chaque compétence et la version de la compétence en question. Après si c'est mieux de mettre une date plutot qu'un entier, soit. C'est un autre débat (qui m'intéresse fortement !!)

Est-ce plus cohérent/clair ?

Griftou.

[SQLpro]

Si vous modélisiez au niveau CONCEPTUEL et non PHYSIQUE vous verriez immédiatement les nombreuses erreurs de votre modèle à commencer par le nom des attributs des entités qui est absurde !
En effet une règle de modélisation veut que chaque attribut possède un nom unique dans le SI (norme AFNOR).

Par exemple l'attribut version se trouve dans les deux tables et devrait donc contenir les mêmes informations et servir à une clef étrangère d'une table envers l'autre, ce qui je suppose n'est pas le cas... Donc il faudrait avoir deux nom différents, par exemple GRP_VERSION et CPT_VERSION.
Sinon cela vous empêchera par exemple de faire des jointures naturelles.
A contrario, le fait d'avoir une clef étrangère dans une table, fait que la ou les attributs devraient porter les mêmes noms dans les différentes tables.
Ainsi on devrait avoir par exemple GRP_ID dans les deux tables et non ID dans la table des groupe et ID_GROUPE dans l'autre !

A +