Discussion :

[KissGround]

Bonjour à tous.

J'aimerais avoir votre avis sur la conception d'une table qui contient plusieurs dates et une localisation.
C'est un débat que j'ai actuellement avec un collègue.

Choix 1: Mon choix, une seul table


Choix 2: Mon collègue, 3 tables avec des liaisons 1to1:


Personnellement je ne vois aucun intérêt au choix n°2, c'est dans mes habitudes de conception... Mais je préfère avoir un avis externe au cas ou aujourd'hui l'on fait les choses différemment: plus de découpage côté base de données.

Quel serait votre choix?
Si vous avez besoin de plus d'explication... N'hésitez pas. Mais je pense qu'il n'y a ici pas besoin d'aller plus loin car cela reste assez simple.

Merci d'avance. Fabrice

[escartefigue]

Bonjour,

Avec des cardinalités 1,1 partout et si peu d'attributs dans chaque table, faire 3 tables semble en effet peu judicieux

Les tables additionnelles sont intéressantes si
- la cardinalité mini est zéro, pour éviter les attributs "nulls"
- la cardinalité maxi est > 1, pour répéter autant de fois que nécessaire

Quels sont les arguments de votre collègue en faveur de son modèle ?

Par contre, la cardinalité 1,1 entre "localisation" et "essai" me semble douteuse : etes vous sur que pour une localisation il n'y a qu'un et un seul essai ?
Si la réponse est non, le bon modèle comporte alors 2 tables : "essai" avec une FK vers "localisation" et "localisation"

[informer]

Bonjour KissGround

Le principe est que si les cardinalités sont (1.1) (11), il y a fusion des attribut dans une seule entité.