Relation UN à PLUSIEURS ?

Salut,

Albert wrote:

Bonjour / Bonsoir

J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.

Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM

Table deux avec les champs suivants

PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?

Merci de votre aide

Ne surtout pas faire cela !!!

Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?

En fait, il faut au minimum 3 tables:

T_Propriétés
-------------
# ID_Propriété
- Nom_Propriete
- ...


T_Popriétaires
----------
# ID_Proprio
- Nom_Proprio
- adresse
-

T_Popriétés_Poprios
--------------------
* ID_Propriété
* ID_Propriétaire

Cela permet d'avoir Nx propriétaires pour une propriété et
Nx popriétés pour un même propriétaire.

Autrement dit, une relation plusieurs à plusieurs entre la table
T_Propriétés et T_Propriétaires

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Merci et j'ai d'autres questions.

Je pars d'une table unique avec 79 champs, que je veux diviser en plusieurs
tables, et j'ai presque réussi à me prendre au piège.
Donc s'inspirer de votre BDD de généalogie,
http://www.3stone.be/access/articles.php?lng=fr&pg%5

Il y aussi les proprios à contacter pour urgence, les responsables
d'entretien (pas nécessairement proprio), le proprio responsable des
finances, etc....
Pour plusieurs c'est la résidence principale, et pour plusieurs une
résidence saisonniaire.
peut-on mettre tous les noms dans la même T_Popriétaires ?

plus tard il faudra ajouter les descriptions des propriétés, et les
redevances à payer etc.....
alors je reviendrai

Merci
Albert


"3stone" <sweet@home.be> a écrit dans le message de
news:i8lped$pmg$1@speranza.aioe.org...

Salut,

Albert wrote:

Bonjour / Bonsoir

J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.

Table UN Liste des individus avec No automatique, Champs NoAuto et
Champs NOM

Table deux avec les champs suivants

PropriétéNo, Proprio1, Proprio2, Proprio3
avec Relation un (NOM) à plusieurs les trois champs Proprio
Est-ce possible, ou puis-je trouver un exemple?

Merci de votre aide

Ne surtout pas faire cela !!!

Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?

En fait, il faut au minimum 3 tables:

T_Propriétés
-------------
# ID_Propriété
- Nom_Propriete
- ...


T_Popriétaires
----------
# ID_Proprio
- Nom_Proprio
- adresse
-

T_Popriétés_Poprios
--------------------
* ID_Propriété
* ID_Propriétaire

Cela permet d'avoir Nx propriétaires pour une propriété et
Nx popriétés pour un même propriétaire.

Autrement dit, une relation plusieurs à plusieurs entre la table
T_Propriétés et T_Propriétaires

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salut,

Albert wrote:

Je pars d'une table unique avec 79 champs,

Une grande feuille à la Excel, quoi... ;-)

que je veux diviser en
plusieurs tables, et j'ai presque réussi à me prendre au piège.
Donc s'inspirer de votre BDD de généalogie,
http://www.3stone.be/access/articles.php?lng=fr&pg%5

il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...

Il y aussi les proprios à contacter pour urgence, les responsables
d'entretien (pas nécessairement proprio), le proprio responsable des
finances, etc....
Pour plusieurs c'est la résidence principale, et pour plusieurs une
résidence saisonniaire.
peut-on mettre tous les noms dans la même T_Popriétaires ?

plus tard il faudra ajouter les descriptions des propriétés, et les
redevances à payer etc.....
alors je reviendrai

Je ne peux donner qu'un conseil :
- prendre un grande page blanche et "dessiner" les besoins.

Il faut qu'au final, on puisse appliquer les 3 premières "forme normale"

Une règle très importante à observer lors de cette organisation,
est de ne mettre dans chaque table, que ce qui concerne
*strictement* l'objet de cette table.

Donc, dans la table "Propriétés" que ce qui concerne celles-ci,
dans la table des Propriétaires ce qui les concerne...
idem pour toutes les tables.
Ne pas oublier un (bonne) clé primaire pour chaque table
Vérifier les relations "naturelles" qui se révèle lorsque les tables sont ok.

Cette partie de la conception, donc l'analyse préliminaire, est la plus
importante de toute la réalisation. La suite n'est plus que de la mise en place.

Lorsque les tables sont réalisées, on teste quelques requêtes provisoires
pour vérifier que l'organisation est correcte et permet l'intérogation
et l'extraction de toutes les données souhaitées.
Lorsque l'extraction n'est pas naturelle, vérifier la bonne organisation
des tables concernées, le problème venant souvent de la.

Tu peux t'inspirer sur ce site:
http://www.databaseanswers.org/data_models/index.htm
qui liste quantité de schémas.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Bonjour / Bonsoir
"3stone" <sweet@home.be> a écrit dans le message de
news:i8n385$jqf$1@speranza.aioe.org...

il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...

J'ai fait des petites tables liées, et je vois que si je crée une requête
avec deux tables liées, je ne peux pas modfier le contenu de mes champs.
Par ailleurs j'examine d'autres tables exemples avec deux tables liées où on
peut modifier, ajouter des champs sans problème.

Quelle est la solution, autre que le sous formulaire?

merci


--
albertri-at-videotron.ca.invalid

Salut,

Albert wrote:

Bonjour / Bonsoir
"3stone" <sweet@home.be> a écrit dans le message de
news:i8n385$jqf$1@speranza.aioe.org...

il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...

J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.

In ne faut pas mélanger les champs de deux tables, si tu ne
peux faire la mise à jour, c'est que Access ne peux définir
soit à quelle table, soit à quel enregistrement les données
appartiennent...

Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?

Le sous-formulaire est la meilleure manière, car la clé externe
est attribuée automatiquement dans la table secondaire.

Pour ajouter un propriétaire, il faut que la propriété existe.

Selon la nécessité, on peut également, a partir du formulaire
principal, ouvrir un formulaire qui ne sera pas "inclus" dans
ce form principal.
Une simple liste indépendante, placée en haut d'un formulaire,
et contenant la liste des propriétés, est également une bonne
alternative au formulaire principal lorsqu'il s'agit de saisir les
propriétaires.

En fait, ce qu'il faut éviter à tout prix, c'est cette organisation
horizontale comme exprimée au départ, du style :

PropriétéNo, Proprio1, Proprio2, Proprio3

Les données *doivent* être organisées verticalement.
Pour rechercher un proprio, il faut qu'ils se retrouvent tous
dans la même "colonne".
La seconde problème avec cette disposition, s'est qu'elle
rend impossible l'ajout de nouveaux proprio... alors que
lorsqu'il sont "en colonne", il n'y a pas de limite.

Une table très large, avec beaucoup de champ, est presque
toujours le signe d'une mauvaise organisation. A l'inverse, il
ne faut pas créer des tables inutiles...
La question qu'il faut à chaque fois se poser est: à qui
appartient cette donnée ?...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Bonjour / soir

"3stone" <sweet@home.be> a écrit dans le message de
news:i90aie$2vb$1@speranza.aioe.org...

Salut,

Albert wrote:

Bonjour / Bonsoir
"3stone" <sweet@home.be> a écrit dans le message de
news:i8n385$jqf$1@speranza.aioe.org...

il ne faut surtout pas arreter la lecture avant la fin !
car, au début, j'explique l'approche "naturelle" des débutants
et qu'il ne faut *surtout* pas appliquer !...

J'ai fait des petites tables liées, et je vois que si je crée une
requête avec deux tables liées, je ne peux pas modfier le contenu de
mes champs.

In ne faut pas mélanger les champs de deux tables, si tu ne
peux faire la mise à jour, c'est que Access ne peux définir
soit à quelle table, soit à quel enregistrement les données
appartiennent...

Par ailleurs j'examine d'autres tables exemples avec deux
tables liées où on peut modifier, ajouter des champs sans problème.
Quelle est la solution, autre que le sous formulaire?

Le sous-formulaire est la meilleure manière, car la clé externe
est attribuée automatiquement dans la table secondaire.

Pour ajouter un propriétaire, il faut que la propriété existe.

Selon la nécessité, on peut également, a partir du formulaire
principal, ouvrir un formulaire qui ne sera pas "inclus" dans
ce form principal.
Une simple liste indépendante, placée en haut d'un formulaire,
et contenant la liste des propriétés, est également une bonne
alternative au formulaire principal lorsqu'il s'agit de saisir les
propriétaires.

En fait, ce qu'il faut éviter à tout prix, c'est cette organisation
horizontale comme exprimée au départ, du style :

PropriétéNo, Proprio1, Proprio2, Proprio3

Les données *doivent* être organisées verticalement.
Pour rechercher un proprio, il faut qu'ils se retrouvent tous
dans la même "colonne".
La seconde problème avec cette disposition, s'est qu'elle
rend impossible l'ajout de nouveaux proprio... alors que
lorsqu'il sont "en colonne", il n'y a pas de limite.

Une table très large, avec beaucoup de champ, est presque
toujours le signe d'une mauvaise organisation. A l'inverse, il
ne faut pas créer des tables inutiles...
La question qu'il faut à chaque fois se poser est: à qui
appartient cette donnée ?...

J'ai abandonné l'idée de proprio, proprio2, etc...


Je crois que j'ai trouvé mon erreur, j'utilise pour ID_propriété l'adresse
unique de chacune, il n'y a pas de doublon, mais il manque des numéros dans
la suite.
Access me cause des objections en cas de doublons.
Je vais reviser mes clés.
J'ai trouvé dans mon manuel Microsoft Access par Inisan à la page 312 une
partie de la réponse.
Je quitte pour ce soir... Demain est un autre jour


merci

--
albertri-at-videotron.ca.invalid

"3stone" <sweet@home.be> a écrit dans le message de
news:i8lped$pmg$1@speranza.aioe.org...

J'ai a faire une base de données pour une association de
propriétaires. Toutes les propriétés ont au moins deux ou trois
propriétaires en copropriété.
J'avais l'intention de créer deux tables, comme suit.

Ne surtout pas faire cela !!!

Pourquoi ? Simple... que fais tu lorsqu'une propriété aura
soudain (quelque soient les raisons) un douzaine de coproprios ??
Tu modifies ta base ?

En fait, il faut au minimum 3 tables:

Merci de votre aide, mais le problème des co-propriétaire est réglé.
En effet j'ai trouvé que lorsqu'il y a DEUX proprios, il s'agit de Monsieur
et Madame, alors il faut traiter Le COUPLE comme UN proprio, tout comme Moi
et mon épouse sommes propriétaire de notre résidence.
Il y a une exception, où c'est Monsieur, Madame et Fiston, mais cela ne
cause pas de problème.
merci


--
albertri-at-videotron.ca.invalid