Discussion :

[Kenshin86]

Bonjour

Modélisant un système , je me retrouves bloqué.

J'ai les tables suivantes :
-Client (...)
-Ville (cp ville , nom , ville)
-Departement (code dep , nom dep)
-Pays (code pays , nom pays)

J'ai dis qu'un client habille dans une ville , qui elle est dans un département qui est dans un pays et j'ai également rajouté un lien entre ville et pays.

Le 1er cas serait pour les départements français
Le 2e pour les départements que le client remplirait lors de la saisie (dominique , usa , etc...)

Mais le problème ici , c'est que dans le 1er cas , il n'y a pas de soucis , mais pour le 2e oui , puisque à l'insertion d'une ville , il va me demander un code pays oui , mais un code_departement or je ne connais pas les codes de tous les départements dans le monde !

Cordialement,

[Metafire18]

Tu pourrais nous faire un modèle conceptuel pour que ca soit plus clair. Il faut savoir aussi que le système des départements n'est pas propre à touts les pays du monde Pourquoi tu te contenterais pas d'un champ idDep en clé primaire associé au nom du département ?

[Kenshin86]

Voici une capture d'écran en pièce jointe

[Kenshin86]

Donc tu veut me dire , de gérer uniquement les pays et pas les départements ?

Je pensais à un autre problème que je pourrais avoir par la suite.

Si je gardes que ville et pays.
Il me faudra entrer tous les codes postaux du monde dans la table ville ?

Puisque l'utilisateur se verrait jeté si il aurait saisi un code postal n'existant pas dans la table ville.

Peut-être que je me trompes mais comment pourrais-je contourner cela ?

[Kenshin86]

J'ai essayé ça en modifiant les cardinalités afin de "créer" une association entre ville et client.

De ce fait , j'ai une nouvelle relation "habiter" qui contient l'id de l'internaute , le code postal de sa ville ainsi que le nom de son département.

Qu'en pensez vous ?

[Metafire18]

Si ce que tu souhaites c'est ne pas être contraint de rentrer un département à touts les coups, modifie les cardinalités de la relation regrouper de cette facon :

Ville---0,1---REGROUPER---0,N---Departement

[Kenshin86]

Parce que la dans mon cas , ce n'est pas très bon , puisqu'un internaute habite dans plusieurs villes.

[Kenshin86]

Si ce que tu souhaites c'est ne pas être contraint de rentrer un département à touts les coups, modifie les cardinalités de la relation regrouper de cette facon :

Ville---0,1---REGROUPER---0,N---Departement

C'est ce que j'ai fais dès le tout début.

Mais le soucis c'est que je serais obligé de saisir un code département à chaque fois que je vais ajouter une ville. Or c'est quasiment ingérable ça.

[Metafire18]

Tu as une autre idée?

[Kenshin86]

Je penses que je vais rester sur ce modèle la.(cf.Ma réponse avant de te citer )

Et je verrais en sorte de gérer ce soucis (insérer un numéro client qu'une fois dans habiter) au niveau applicatif.

[Kenshin86]

Par contre , il n'y a pas eu de réaction sur cela :

Si on a :
Ville(cp,nom)
Client(id , cp#)

Il faudra remplir au préalable TOUTES les villes du monde dans la table ville ?


Il y a t'il une astuce pour contourner ça ?

[Metafire18]

Le client lors de l'inscription saisit sa ville. Une instance de l'entité ville est alors créé est associé au client. Si la ville existe déjà, on l'a récupère et on l'associe au client

[Kenshin86]

Ok , je pensais à quelque chose comme ça.

Merci

[CinePhil]

Quelques petites choses...

Ville---0,1---REGROUPER---0,N---Departement

Mais le soucis c'est que je serais obligé de saisir un code département à chaque fois que je vais ajouter une ville.

Non puisque la cardinalité mini du côté Ville est 1.
London ne fait pas partie d'un département français et la clé étrangère de la ville de London sera NULL. La cardinalité 0,1 impose que la clé étrangère puisse être NULL.

Par contre , il n'y a pas eu de réaction sur cela :

Si on a :
Ville(cp,nom)

Mauvaise idée !
Une ville peut avoir plusieurs codes postaux et un code postal peut contenir plusieurs villes.

D'une manière générale, je ne dirai jamais assez qu'il faut préférer des identifiants anonymes de type entier, non nul, non signé, et auto-incrémentés.

Par contre, une table de correspondance des codes-postaux et des villes est une bonne idée pour vérifier la saisie de l'adresse par l'utilisateur. Attention aux Cedex qui ne sont pas à prendre en compte dans la vérification !