Discussion :

[mamiberkof]

Salut,
je suis face à un dilemme , j'ai une table Employe et autre Situation administrative, l'association se fait par un 1-1 <--->1-1,
lors de la generation du MLD, les deux clé primaire migrent l'une vers l'autre (echange) ,donc quand j'ai creer la base, je voulais insereer des enregistrement, mais il me demande d'inserer la clé de l'autre table(ou plutot il ne trouve pas la valeur de la colonne du foreign key ), et si je veux insrer dans l'autre table, meme probleme
alors une idée comme sortir de ce cas ?

[Alexandre T]

Si deux entités sont en relation 1-1 , que l'une ne peut exister sans l'autre, alors ne doit résulter de la modélisation qu'une seule table.

[mamiberkof]

mais je voulais pas encombrer la table en fesant un tas de champs, on peut "faire sortie" et creer une table avec relation 1-1 1-1 non?

y a t il une autre solution ou comment gerer cette situation ?
merci

[Xo]

mais je voulais pas encombrer la table en fesant un tas de champs, on peut "faire sortie" et creer une table avec relation 1-1 1-1 non?

Oui, c'est possible, et c'est même conseillé si la nature des données gérées est différente. Un exemple que l'on donne souvent à ce sujet est le concept d'article : une table peut être utilisée pour gérer les caractéristiques intrinsèques de l'article, et une autre pour la gestion du stock le concernant par exemple. Bon, c'est un exemple un peu réducteur, mais c'est possible.

Par contre, si la clé primaire est la même dans chaque table, il est impossible que chacune de ces clés référence l'autre PK simultanément ...

La solution a ton problème : gérer la création de tes 2 enregistrements via une transaction, encapsulée par exemple dans une procédure stockée qui garantira l'intégrité de tes données.

[mamiberkof]

Par contre, si la clé primaire est la même dans chaque table, il est impossible que chacune de ces clés référence l'autre PK simultanément ...

non ils n'ont pas la meme clé

La solution a ton problème : gérer la création de tes 2 enregistrements via une transaction, encapsulée par exemple dans une procédure stockée qui garantira l'intégrité de tes données.

tu peut etre un peu clair concernant la transaction et procedure, car la je vois pas

[TheLeadingEdge]

Bonsoir,

l'association se fait par un 1-1 <--->1-1,
lors de la generation du MLD, les deux clé primaire migrent l'une vers l'autre (echange)

Non, pas d'échange, migration de l'1 dans l'autre. Comme l'a déjà répondu Alexandre T, dans le cas d'1 relation 1-1 si tu respecte les formes normales les 2 entités vont devenir 1 table unique. Si tous les champs de la table ne dépendent pas de la clef c'est que tu as 1 pb de modélisation.
Si, malgré tout tu as vraiment besoin de dénormaliser ton modèle, il te reste la solution de casser l'intégrité référentielle de l'une de 2 tables dans ton DML en ne déclarant pas de FK référençant la PK de l'autre.

[Alexandre T]

La seule raison pour laquelle je divise une table est deux est pour obtenir une taille non dynamique d'enregistrements.

Explications avec un exemple réducteur :
J'ai une table de news avec ce format :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
New
id_new integer (clef primaire)
cod_new char(12) (not null)
maj_new timestamp not null default current_timestamp on update current_timestamp
id_auteur not null (clef étrangère)
id_moderateur not null (clef etrangère)
debut_publication datetime
fin_publication datetime
des_new text

Seul le champ des_new est de longueur variable. Tous les autres champs sont de longueur fixe. Le champ des_new est rarement sélectionné par requête. Par contre le reste de la table est souvent utilisé. Pour simplifier l'indexation, j'ai décidé de diviser ma table en deux. La première table contient les champs de taille fixe. la seconde contient le champ des_news et une clef primaire informatique.

Cela donne

Code :

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

1
2
3
4
5
6
7
8
9
10
 
New
id_new integer (clef primaire)
cod_new char(12) (not null)
maj_new timestamp not null default current_timestamp on update current_timestamp
id_auteur not null (clef étrangère)
id_moderateur not null (clef etrangère)
debut_publication datetime
fin_publication datetime
id_des_new integer not null

Code :

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

1
2
3
4
Des_new
id_des_new integer not null
des_new text

Dans les faits, j'insère la description de ma news dans la table des_new.
Puis j'insère toutes les autres informations de la news dans la table new avec la référence à la clef primaire de des_new.

A mon avis, si tes deux tables doivent forcément être séparées, alors vous pouvez donc transformer votre relation selon mon exemple. Cad virer une des deux contraintes. Vous pouvez être encore plus précis en rendant optionnelle la clef étrangère id_situation_administratif de la table employé, pui en la modifiant, après l'insertion dans la seconde table, .

Ce qui donne comme modèle :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
employe
id_employe integer pk not null
id_situation_administratif integer fk null
.....
....
 
situation_administratif
id_situation_administratif pk not null
id_employe integer fk not null
...
...

Votre algorithme d'insertion devient donc
Insertion dans la table employé sans renseigner id_situation_administratif
Insertion dans la table situation_administratif de tous les champs.
Modification dans la table employe du champ id_situation_administratif.

Mais cette méthode est lourde car la modélisation est erronée. Les données ne semblent pas avoir de raison valable d'être dans des tables séparées.

[SQLpro]

Une relation 1:1 <-> 1:1 est de la plus haurte fantaisir car c'est la même table. Elle est cepandant possible si votre SGBDR gère la déférabilité des contraintes (ce qui est rare, à ma connaissance seul Oracle le fait).

En effet une relation purement 1:1 <-> 1:1 suppose que lorsque l'on insère un tuple dans la table de droite, alors il doit y avoir un tuple dans la table de gauche ET lorsque l'on insère un tuple dans la table de gauche, alors il doit y avoir un tuple dans la table de droite. C'est le problème de l'oeuf et de la poule que seule un déférabilité des contraintes permet. C'est en outre une solution de modélisation assez stupide car dans ce cas il vaut mieux effectivement toute mettre dans le même table.
Lisez l'article que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/s...e=partie2#L7.4

Dans votre cas, la relation serait plutôt :
0:1 <-> 1:1
ou
1:1 <-> 0:1
ou
0:1 <-> 0:1

A +

[mamiberkof]

Dans votre cas, la relation serait plutôt :
0:1 <-> 1:1
ou
1:1 <-> 0:1
ou
0:1 <-> 0:1

A +

merci pour ces explications, il me parait que la relation 0:1 1:1 ne resoud pas le probleme de l'echange de key, j'ai cherché dans le cours de 'sql de A-Z 'et j'ai trouvé qu'il faut que ça soit la meme clé ,
http://sql.developpez.com/modelisati...passage#L5.1.1
donc pour mon cas, le passage au MLD sera

Employe
id_employe (not null)
nom_emp
...

Situation_admin
id_employe (not null)
echelle
...


merci

[mamiberkof]

un commentaire ?

[Alexandre T]

Avec la même clef, c'est une modélisation intéressante si vous souhaitez vraiment avoir deux tables. Sinon, je reste sur ma position d'une seule et même table.

[polux]

Salut
SQLpro a raison si les cardi. sont 1.1 / 1.1 c est la meme table
Perso je pense que tes cardi sont plustot du genre 0.1 / 1.1 ou 0,n / 1.1 , je ne voie pas trop ce qu est ton entite situation soit plus precis (c est peut etre un sous entite dans ce cas plus de probleme)
Mais pour revenir au cardi 0.1 / 1.1 certain outil de modelisation font un "enchange" des cles lors de la generation des scripts . Alors qu une clé etrangere cote 1.1 suffit .
A+

[mamiberkof]

merci pour votre aide