Discussion :

[Timbermatt]

Bonjour,

Voilà je crée une base de donnée pour une entreprise de livraison qui travaille pour des entreprises comme ikea. Elle possède deux agences.

Cette entreprise livre dans plusieurs villes qui sont réparties en zone. ( Ex : La zone représentant la livraison Nantes-Cholet est 1, mais la zone représentant la livraison Tours-Cholet est 5). De plus les zones changent selon le client. (Ex :
la zone représentant la livraison Nantes-cholet pour IKEA est 1 mais la zone représentant Nantes-cholet pour un autre client est 2). Ils existent différents tarifs de livraison selon les zones.

Au niveau de la BD, je pensais créer 3 tables qui seraient :

Table insee : clé primaire : CP, Commune,Agence. Autre champ : Departement
Table Zone : clé primaire : idZone, idClient. Autre champ : tarif, nomdelazone
table Client ...

Le problème c'est que je ne sais pas quel champ ajouté dans la table insee ou table zone pour qu'il y ait une relation entre les deux.

Si quelqu'un pourrait me donner un idée, ça serait super.

J'espère que j'ai été clair.

Merci

[agemis31]

Bonjour,

De plus les zones changent selon le client

Bizarre, mais soit.

J'ai du mal à cerner votre table insee.

Contient-elle les agences,comme la colonne Agence le laisse penser ou les communes couvertes par chaque zone ?

PS: Il n'y a pas de champs dans une bases de données. Un champ représente une notion visuelle. Il s'agit d'un héritage d'une vision formulaire des données. On parle de colonnes


@+

[Timbermatt]

C'est vrai que c'est bizarre comme ça.
En faite, je voudrais que la table contienne les communes couvertes par chaque zone en sachant que les zones sont différentes pour chaque Agence.

Il vaudrait mieux que la colonne (:p) se trouve dans la table zone alors. Et donc il y aurait 3 clé primaire dans la table zone.

Ca me parait un peu compliqué comme organisation ^^'.

[agemis31]

Bonsoir,

Et donc il y aurait 3 clé primaire dans la table zone

Ça, ça va être difficile Plutôt UNE clef primaire et éventuellement plusieurs clefs étrangères.

Puisque les zones couvrent des communes et que le tarif semble propre à la zone, vous pouvez faire une table zone (zoneid, tarif, ...) et une table zoneinsee (zoneid, inseeid).

Puisque le nom de la zone est propre au client, vous pouvez créer une table
clientzone (clientzoneid, clientid, zoneid, zonenom, ...).

J'ai mis les clefs primaires en gras, en choisissant d'avoir des clefs techniques. La clef primaire de clientzone pourrait aussi être clientid, zoneid.


@+

[fsmrel]

Bonjour,




Il serait bon de produire un diagramme logique (le mieux étant de produire d’abord un MCD).

En attendant, poursuivons le travail...

une entreprise de livraison [...] possède deux agences

Pour la suite, je nommerai XYZ cette entreprise.
Le modèle devant pouvoir évoluer, je considérerai que le nombre d’agences peut un jour être largement supérieur à deux (voyez l’histoire de l’épicier de Landerneau...)

La zone représentant la livraison Nantes-Cholet est 1

Je suppose que Cholet représente la ville où est localisé un client à livrer, par exemple IKEA.
Du point de vue du candide, Nantes serait la ville de départ de la livraison et Cholet la ville du client destinataire. Nantes peut elle être interprétée comme la ville où se trouve un dépôt de XYZ ?
La localisation de l’agence joue-t-elle un rôle ? Par exemple, correspondrait-elle à la ville du dépôt d’où part de la livraison ? Ou bien n’y a-t-il aucune relation ?
En attendant, je supposerai qu’il n’y a aucune relation entre la ville de l’agence et la ville du supposé dépôt.



Questions :

1) Un client est-il en relation avec une seule agence, ou peut-il être en relation en même temps avec les deux agences ?

2) La zone 1 est-elle propre au client IKEA, ou bien un autre client peut-il lui aussi être attaché à cette zone ? (indépendamment du fait que le couple (Nantes, Cholet) soit en relation aussi bien avec la zone 2 que la zone 1).

3) Si IKEA et un autre client peuvent être attachés tous les deux à la zone 1, la zone est-elle attachée à une agence en particulier, ou peut-elle être attachée en même temps aux deux agences ?

4) Pour une zone, on a bien un seul tarif ?

5) Doit-on historiser les changements de tarif ?


Hypothèses (à aménager quand cela est nécessaire) :

1) Le client IKEA est en relation avec la seule agence A1, plus généralement le client c est en relation avec la seule agence a,

2) La zone 1 est propre au client IKEA, plus généralement la zone z est propre au seul client c,

3) La zone z a (à une date donnée) un seul tarif t (lequel n’est caractérisé par aucune propriété supplémentaire, telle que, par exemple, la date à laquelle le tarif s’applique),

4) On ne traite pas des dépôts d’où partent les livraisons,

5) Il n’y pas de relation entre l’agence et la ville de départ d’une livraison,

6) On ne gère pas directement les liens entre les clients pour lesquels ont livre et les villes où ont lieu les livraisons, mais les liens entre les zones des clients et les villes.

Une ébauche de diagramme logique pourrait être la suivante :


Outil utilisé : Workbench (gratuit) !

[Timbermatt]

Merci de votre aide.