Discussion :

[fabriceMerc]

Bonjour;


Je suis en train de réaliser un mcd pour une base de données, les concepts ne sont pas faciles à apprehender et les relations entre les données sont aussi un peu compliqués donc je vais juste poser sur le forum l'extrait bien ciblé de ce qui me pose problème.

Textuellement :

A chaque version de la norme GERAN correspondent des tests cases. Chaque version de la norme GERAN est susceptible d’ajouter des nouveaux tests cases et d’en supprimer par rapport à la précédente. Un test case peut donc appartenir à plusieurs versions GERAN.

Un test case est identifié par un numéro (exemple : 12.1.1) et caractérisés par une description textuelle.

Ces tests cases sont classés par des organismes tel GCF et PTCRB. Chaque organisme délivre régulièrement des nouvelles versions de leurs tables de validation par rapport aux différentes versions GERAN. Chaque table rassemble une liste non exhaustive des tests de certifications pour chaque version GERAN. Comme un test peut appartenir à plusieurs versions GERAN, il appartient également à plusieurs versions de tables de chaque organisme.

Une table est définie par un numéro de version.

L’organisme donc va valider chaque test case dans une catégorie donnée pour une ou plusieurs bandes de fréquences et plateformes de test.

Une catégorie est définie par un code (A, B, N, P) et une description.
Une bande de fréquence est définie par sa valeur (850, 900,1900).
Une plateforme de test est caractérisée par un numéro et un nombre de transiever.

Bon pas trop mal à la tete ??

Le problème ici concerne l'unicité de l'ensemble VersionGSM-TABLEVersion-TC
On peut alors créé une clé composé avec les indentifiant relatifs mais alors ensuite je vais me retrouver avec des associations 0-n qui seront des tables avec une clé primaire de 7 éléments:super lourd à mon gout
Donc ma solution a été de créer un identifiant informatique pour chaque ligne de tables.
En conséquence l'unicité n'est plus garantie et pour résoudre ce problème je pense créer un trigger sur cette table qui se chargera de la vérifier.
Mais est ce une bonne solution ??? Est ce une grosse bidouille infame ? Mon modèle est-il bien pensée pour etre obliger de faire ce truc ?

[Médiat]

1) Ton post serait mieux dans le forum Modélisation, demande à un modo de le déplacer.
2) Je n'ai pas tout analysé, mais pour assurer l'unicité d'une clé alternative tu peux créer un index unique, comme cela pas besoin de trigger, et en plus comme cette clé est sans doute celle utilisée par les utilisateurs, si elle est fonctionnelle en plus, l'index (unique ou non) est sans doute utile pour des raisons de performance.

[Fredooweb]

Salut,

Certaines de tes cardinalités me semblent erronées si j'ai bien compris le cas:
* Relation Test_Case/Gsm_Version ==> 0,n/0,n puisque une version a plusieurs test_case et un test_case peut
participer à plusieurs versions.

* Pour ta relation Table_de_validation/Test_Case il me semble que c'est pareil. De plus, je n'ai pas bien compris si une table de validation s'applique aux Test_Case de la version ou s'il existe une table par Test_Case

Ensuite, je pense qu'il te manque une relation entre Table_de_Validation et Gsm_version car en l'état tu es incapable de dire à quelle version s'applique ta table_validation, les test_case pouvant concerner plusieurs
versions.

Cette relation te permettra de retouver immédiatement les test_Case sur lesquels appliquer la "table_de_validation" et du coup la relation "Table_de_validation/Test_Case" pourrait devenir inutile
mais à toi de préciser...

-------------------------------------------------------------------------------------
"Créer non posséder; oeuvrer, non retenir; accroître, non dominer."
Lao-Tsé

[fabriceMerc]

Salut,

Certaines de tes cardinalités me semblent erronées si j'ai bien compris le cas:
* Relation Test_Case/Gsm_Version ==> 0,n/0,n puisque une version a plusieurs test_case et un test_case peut
participer à plusieurs versions.

* Pour ta relation Table_de_validation/Test_Case il me semble que c'est pareil. De plus, je n'ai pas bien compris si une table de validation s'applique aux Test_Case de la version ou s'il existe une table par Test_Case

Ensuite, je pense qu'il te manque une relation entre Table_de_Validation et Gsm_version car en l'état tu es incapable de dire à quelle version s'applique ta table_validation, les test_case pouvant concerner plusieurs
versions.

Cette relation te permettra de retouver immédiatement les test_Case sur lesquels appliquer la "table_de_validation" et du coup la relation "Table_de_validation/Test_Case" pourrait devenir inutile
mais à toi de préciser...

-------------------------------------------------------------------------------------
"Créer non posséder; oeuvrer, non retenir; accroître, non dominer."
Lao-Tsé

Je pense mettre un UNIQUE sur les trois clés étrangères de TEST_CASE_ROW (en fait renommé en TABLE_ROW c'est plus logique)
Mais ta remarque sur la liaison entre GSM_VERSION ET TABLE_VERSION est intéressante.