Discussion :

[adelneo]

j'ai deux tables reliés par une relation 1:1.
mysql workbench me permet de définir les cardinalités :
reformes-|0-------||-cars (à un vehicule correspond zero ou une reforme)
est ce que cette représentation est différente par rapport à
reformes-||-------||-cars ??

j'ai essayé les deux représentations, mais dans le coté applicatif je n'ai pas trouvé de différence.
et s'il y a vraiment une différence du coté sgbd, je voix pas comment représenter ces cardinalités dans firebird (je doit migrer ma base vers firebird embedded)
voici en schéma le morceau du MLD approprié.

[gene69]

Dans le cas d'une 1,1 il suffit d'interdire la valeur NULL et de mettre une contrainte de clé unique et étrangère. (unique + non null ~= primaire, non?)

réponse positive.

EDIT: attention parce côté applicatif il faut gérer correctement la transaction en cas de 1,1 alors que 0,1 c'est plus laxiste.

[CinePhil]

Sémantiquement, les deux schémas sont différents.

Côté SQL, avec une association (1,1 - 1,1) il faut gérer les insertions par un trigger car les deux côtés de l'association doivent être présents en même temps en BDD.

Il convient aussi de se demander avec de telles cardinalités si les deux entités ne pourraient pas être fusionnées.

[adelneo]

je ne pense pas que la fusion soit possible, mais je vais vous expliquer le problème vous aurez peut être une idée:
un véhicule peut subir 0 ou une reforme.
j'ai ajouté une ligne "stat" à la table cars qui comprend deux valeur 0 ou 1.
si le véhicule est réformé stat reçoit 0.
s'il est transféré "stat" reçoit 1. (ma base contient une table transferts reliée à cars cars--1,1----------0,1--transferts).
si "stat" est à null donc le véhicule n'est ni transféré ni réformé.
que pensez vous ?

[CinePhil]

je ne pense pas que la fusion soit possible, mais je vais vous expliquer le problème vous aurez peut être une idée:
un véhicule peut subir 0 ou une reforme.
j'ai ajouté une ligne "stat" à la table cars qui comprend deux valeur 0 ou 1.
si le véhicule est réformé stat reçoit 0.
s'il est transféré "stat" reçoit 1. (ma base contient une table transferts reliée à cars cars--1,1----------0,1--transferts).
si "stat" est à null donc le véhicule n'est ni transféré ni réformé.
que pensez vous ?

Il y a donc quelque part une redondance de données puisque l'info sur la réforme ou le transfert figure par le biais des associations et par le biais de la colonne stat.

un véhicule peut subir 0 ou une reforme.

Vehicule -0,1----Subir----1,1- Réforme
|--------------0,1----Subir----1,1- Transfert

Que contiennent les entités Réforme et Transfert ?

[adelneo]

Il y a donc quelque part une redondance de données puisque l'info sur la réforme ou le transfert figure par le biais des associations et par le biais de la colonne stat.


Vehicule -0,1----Subir----1,1- Réforme
|--------------0,1----Subir----1,1- Transfert

Que contiennent les entités Réforme et Transfert ?

Transfert(idtransfert,date_transfert, lieu_transfert , n_decision)
reforme(id_reforme,date_reforme, n_decision)

[CinePhil]

Donc il n'y a que lieu_transfert de vraiment différent entre les deux.

On pourrait faire un héritage.

Un véhicule peut-il subir d'abord un transfert puis une réforme ou est-ce obligatoirement l'un ou l'autre ?

[adelneo]

Donc il n'y a que lieu_transfert de vraiment différent entre les deux.

On pourrait faire un héritage.

Un véhicule peut-il subir d'abord un transfert puis une réforme ou est-ce obligatoirement l'un ou l'autre ?

c'est l'un ou l'autre

[CinePhil]

Donc tu pourrais faire un héritage avec une contrainte d'exclusion mutuelle.
Véhicule -0,1----Subir----1,1- Mouvement
Réforme -(1,1)----Etre----0,1--------|
Transfert -(1,1)----Etre----0,1--------X

Dans la pratique, comme la réforme n'a pas d'attribut spécial, en réalité il n'y a que le transfert à implémenter. Sauf si la réforme est associée à autre chose.

La logique serait ici qu'un mouvement qui n'est pas un transfert est une réforme.

[adelneo]

j'avoue que j'ai pas trop d'informations sur l'héritage, je doit lire de la documentation avant de continuer.