table relation un à un [Résolu]

[profane]

Bonjour le forum,
voila j'aimerai savoir si quelqu'un avait dans sa besace
un pti exemple de base access utilisant la relation un à un
afin que je puisse m'en inspirer
actuellement je suis bloque a ce niveau
car lorsque j'utilise mon formulaire pour remplir cette table "maitre-détail(unique)" (formulaire et sous formulaire)
cela plante "éffrontément" au moment de mettre a jour les tables en relation
merci de vos lumieres
++

[Philippe JOCHMANS]

Bonjour

Pourquoi veux-tu une relation un à un, on ne l'utilise en général que lorsqu'une table dépasse 255 champs, cas assez rare.

Stare

[profane]

Bonjour Starec
disons que je veux faire un truc propre
du genre
une table Projet
Une table Investissement 2007
Une Table Investissement 2008
Une Table Investissement 2009
idem pour les charges, Ja.......
voila pour la petite histoire,
si c'est pas faisable "facilement" j'opterai pour la solution 255 colonnes
++

[Philippe JOCHMANS]

Re

Tu as un problème de conception, il te faut une seule table investissement avec un champ date pour faire les saisies et extraction, on ne rajoute pas une table à chaque année.

Starec

[profane]

re,
je detaille pour que tu y voies plus clair
les tables dont je parle sont des previsions de budget
avec en colonne janvier, fevrier, mars
en terme budgetaire on dit de la prevision mensuel (tu peux t en douter)
il ne s'agit donc pas de date de debut et de fin
pour en revenir a ces fameuses tables
comment etablir une relation un vers un qui ne fout pas le zouc ??
++

[Heureux-oli]

Starec a raison, on ne fait pas une table par année.

De la prévision budgétaire, j'en fait en permanence, On travaille en X-2, X-1, X, X+1, X+2, X+3
ET pour toutes mes prévisions, je n'ai qu'une seule table.
Ce qui me simplifie la tâche, si pour une raison quelconque, une de mes prévision change d'année budgétaire, je n'ai qu'une année à changer et pas basculer de table.
Les mouvements d'une année à l'autre s'en trouvent simplifiés.

[profane]

bonjour
en gros si je resume c'est :
les tables relations un a un c'est trop chiant a faire
donc mettez tout sur la meme table !
je demanderai a microsoft d enlever cette fonction car apparemment
personne n'en a l'utilité et personne ne sait s'en servir et me repondre
parce qu'a la base mon soucis c'est pas mes structures de table (chacun fait ce qu'il veux), c'est sur les relations un a un comme indique dans l'intitulé de mon message
vos reponses sont du bottage en touche !

++

[Heureux-oli]

Chacun fait ce qu'il veut.
Sur ce point nous sommes d'accord.

Pour le relations Un à Un on ne les utilise que dans des cas bien précis.

Tu es venu sur le forum pour trouver de l'aide, on t'explique gentiment comment faire pour ne pas te retrouver dans deux jours dos au mur et ne plus pouvoir avancer dans le développement de ta base de données.

Les règles de développement sont les mêmes pour tout le monde, si tu ne les respectes pas un tant soit peu, tu vas obtenir une db monstrueuse où plus rien ne va fonctionner.

Si c'est ton choix, tu dois alors assumer.

[Philippe JOCHMANS]

Re

Je suis d'accord avec Heureux-oli, on essaye de te dépanner, te t'expliquer comme je l'ai écris que tu as un problème de conception, et tu nous envoie balader.

Heureusement qu'il y'en a qui montre leur joie quand on a résolu leur problème.



Starec

[profane]

RE,
Sur le principe de depanner je suis pas contre
mais bon je demande un exemple sur les relations de tables un a un
et vous me repondez "erreur de conception"
si moi j ai envie de faire sur plusieurs tables , je fais quoi alors ?
si microsoft a concu des relations un a un , c'est que ca doit fonctionner
je m'enerve pas, mais vos reponses me font penser a cette phrases fort connue :
dis moi de quoi tu as besoin, je t'expliquerai comment t en passer

je veux juste faire fonctionner une table en relation un a un, rien de plus
et je demande un exemple pour regarder et comprendre
l'optimisation je verrai apres, ce qui m'interesse c'est de comprendre

++
ps: je ne m 'emporte pas, je suis quelqu'un de passionné

[Philippe JOCHMANS]

Re

Envoyé par Starec

Bonjour

Pourquoi veux-tu une relation un à un, on ne l'utilise en général que lorsqu'une table dépasse 255 champs, cas assez rare.

Stare

C'est mieux, mais à ma connaissance je ne vois que ceci, car une relation un à un est en fait un prolongement de table.

Mais mes connaissances sont très loin de ce qui peut exister.

Désolé de ne pouvoir t'en dire plus, car dans mes bases je ne vais pas si loin.

Starec

[francishop]

Bonsoir;

Effectivement c'est un cas d'école. Pour ma part je m'en suis servi une seule fois.
Exemple :
On imagine que la table principale inclus : Id_principal, Nom, prénom, adresse.
Id_principal = NuméroAuto, Incrément

La table secondaire : Id_secondaire, Téléphone, N°Sécurité sociale
Id_secondaire = Entier long

Il est très important que les deux champs liés soient en clé primaire, sinon, si l'un des deux ne l'est pas, ça ne fera pas une relation 1 à 1 mais 1 à plusieurs.

ATTENTION : Normalement, le sens dans lequel on tire un champ pour aller vers l'autre n'a aucune importance...
En tout cas pour tout ce qui concerne les champs de 1 à plusieurs. Mais dans le cas des champs reliés de 1 à 1,
Ça a VRAIMENT de l'importance. Il faut bien tirer de la table principale vers la ou les autres tables liées de 1 à 1.

La raison est qu'on ne peut créer de téléphone avant d'avoir un Nom.

Pour cela dans notre formulaire lors de la saisie du nom on va veiller à inscrire le N°--> Id_principal sur Id_secondaire par un :

Code :

1
2
3
Private Sub Nom AfterUpdate()
Me.Id_secondaire = Me.Id_principal
End Sub

A part ça, il vaut mieux ne pas créer de tables multiples "pour faire joli" ou pour se la jouer style genre "Je sais utiliser les relations 1 à 1"...
Tant qu'on peut tout stocker dans une table, ça facilite les choses...

Cordialement.

[timathias]

Bonsoir,

Il est très important que les deux champs liés soient en clé primaire, sinon, si l'un des deux ne l'est pas, ça ne fera pas une relation 1 à 1 mais 1 à plusieurs.

@francishop : Une autre solution est d'interdire les doublons. Car deux clès identiques c'est contraignant pour gérer les identifiants et source d'erreurs.
Je ne comprends pas ton exemple avec des identifiants non significatifs.
Rien n'empêche de regrouper les deux tables dans ton cas sauf si justement Nom est l'identifiant.


J'utilise des relations 1/1 lorsques je dois renseigner à un certain moment des données dans une table dont je ne connais pas encore l'identifiant.

Je crée donc une table "intermédiaire" comprendant les champs que je peux renseigner et un identifiant qui lui est relié par la suite à l'entité principale.
A condition que les identifiants soit significatifs et non de simple auto-incrément

Mais si tu connais l'identifiant une relation 1/1 est très souvent une erreur de conception

Mon cas d'utilisation :

Code :

1
2
3
ID_BOITE
B_Date_Création
Taille

Code :

1
2
3
ID_MALLE
M_Date_Création
#ID_BOITE

Si on devait mettre une boîte dans une malle et chaque malle n'a qu'une boîte alors on devrait avoir :

Code :

1
2
3
4
5
ID_MALLE
M_Date_Création
B_Code(si utile)
B_Date_Création
B_Taille

Or si la malle n'existe pas lors de la création de la boîte ce modèle ne fonctionne pas. Dans tous les autres cas il est plus adapté.
Car il est beaucoup plus performant.

[random]

pour en revenir à la conception tu as une double erreur de conception

on fait une table unique avec une seule colonne pour le temps
200701
200702

ton idée de clef unique ne s'applique pas dans ce cas

un investissement de 2009 ne peut pas figurer dans la table de 2008

d'autre part tu vas galérer les plans d'investissements sont prévus sur x années glissantes comment dans ton système ajouter une année sans modifier les requêtes, rapports ou autres .

j'imagine ta déception à lire les commentaires sur ton idée mais réfléchis bien
avant de poursuivre, à mon avis tu ne peux que regretter de ne pas avoir investi maintenant dans une refonte de schéma

ceci étant une clef unique ne pose aucun problème, il suffit de gérer dans chaque table un incrément automatique et d'encapsuler la création et suppression d'enregistrement dans une transaction opérant sur x tables
ou d'utiliser une des tables avec un clef auto dupliquée dans les autres (sans doublon)

[francishop]

Bonjour;
J'ai essayé de répondre à :

Envoyé par profane

vos reponses sont du bottage en touche !

Cordialement.

[random]

bien sur que c'est du bottage en touche !!
mais je ne vois aucun problème sur le terrain
si toute la difficulté est la gestion d'une clef unique et d'une relation un à un cela ne pose problème

[profane]

merci pour vos réponses
et pour l'exemple detaille francishop
ca me permet de mieux cerner ma propre comprehension du
programme access
cordialement

[f-leb]

Des exemples de relation -1------1- glanés ici et là…

Il s’agit d’observations d’espèces en milieu naturel :
- On recense les lieux géographiques où sont observés certaines espèces.
- Un lieu géographique est soit un lieu-dit, soit (quand le lieu-dit n’est pas connu) la commune où est rattachée le lieu dit.


Un autre exemple récent sur la gestion des personnels saisonniers d’une exploitation agricole (sans historique, uniquement la saison en cours):

Les personnels sont soit des saisonniers, soit des permanents. Les saisonniers doivent pointer. Un saisonnier appartient à une équipe dirigée par un permanent. Un permanent ne prend en charge qu’une seule équipe.

Deux possibilités dont la 1ère avec une relation -1-----1- :

 
Si on fait une table Personnel regroupant saisonniers et permanents, il faudra quelques traitements supplémentaires pour assurer les règles de gestion:
- s'assurer qu'un pointage concerne un personnel de type "saisonnier"
- s'assurer que chaque équipe comporte un et un seul personnel de type "permanent".
Et il y a un champ supplémentaire "Dernier_Jour_travaillé" qui sera à saisir seulement pour les personnels de type "saisonnier".

Non, les relations -1------1 ce n’est pas sale…