Discussion :

[Sun Downs]

Salut tout le monde,
j'ai comme mini projet à faire la conception et l'implémentation d'une base de données d'une agence de voyage pour cela je dois donc :
- Construire un modèle relationnel, entité-association, représentant la gestion des données de la BD,
- Créer les requêtes de création de la base et des tables au moyen d’un script SQL,
- Créer les formulaires, les états, les macros nécessaires au bon fonctionnement du projet.
- Développer vos interfaces :validation, alerte, masque de saisie, liste aux choix
modifiable, macro d’ouverture, macro de fermeture, Menu générale…
- Créer un formulaire et un sous formulaire basé sur des requêtes avec des champs calculés. Ajouter des champs totaux par formulaire si c’est necessaire…

et voici l'énoncé du sujet :

Description du monde réel
Une croisière est un voyage de loisirs organisé en bateau. Ces voyages se font par l’intermédiaire d’une agence de voyage.
-Une agence est identifiée par son numéro, son nom, le nom de la ville où elle se situe et une adresse.
-Le bateau appartient à une compagnie donnée, il est identifié par un numéro, un nom, le nom de cette compagnie et sa classe.
-Sur le pont d’un bateau, on trouve des cabines. Chaque cabine possède une situation, donnant sur l’extérieur ou l’intérieur du bateau. Elle est caractérisée par un numéro, une catégorie, le nom du pont, sa situation et le nombre de lit.
-Chaque voyage a une variante qui commence à une date et fini à une autre. Chaque variante est identifiée par son propre numéro.
-Chaque voyage possède un programme, il fait état d’un lieu de départ, d’un lieu d’arrivée et est complété de certaines remarques.
-Chaque programme a un certain nombre d’escales passant par des villes.
-Les diverses curiosités des escales sont répertoriées dans des observations.
-Chaque voyage a des fourchettes de prix, comprises entre une valeur minimale et une valeur maximale différentes suivant les saisons.

______________________


pour commencer, j'ai préparé le modèle conceptuel :



puis le modèle relationnel:
agence(num_a, nom_a, nom_ville, adresse)

bateau (num_b, nom_b, nom_compagnie, classe)

cabine(num_c, catégorie, nom_pont, nbre_lit, #num_b)

variante(num_v, date_com, date_fin)

voyage(prix_min, prix_max, num_a, num_b, num_v) // ces clés primaires ont migré à voyage des classes d'entités agence, bateau et cabine

programme(lieu_dep,lieu_arri,remarques)

escales( ville, observations)

contient( doit contenir les clés primaires de programme et escales + un attribut de relation )


et j'ai besoin de réponses à ces questions:
- Si on a une participation (1,1) et aucune des deux tables ne possède un clès primaire, qu'est ce qu'on met dans le modèle relationnel (c'est le cas de la relation voyage-programme )??
- Quelle clès primaires dois-je mettre dans la classe d'entité "escales" ??
- Les attributs de voyage et programme sont-t-ils correctes ?
-vérifiez svp mon modèle conceptuel, !

j'ai très besoin de votre aide !!


et merci d'avance pour tout aide !

[ylarvor]

Je vais essayer de t'aider mais j'ai une question... Avec quoi as tu realise ton schema de modele conceptuel ? c'est genial !

Pour commencer, je mettrais un entier autoincremente comme cle numerique sur chacune de tes tables... cela resoudra plusieurs problèmes comme ta relation par exemple.

dans ton schema conceptuel, tu prevois un programme par voyage que l'on ne retrouve pas dans le modele relationnel... c'est une erreur!
voyage(prix_min, prix_max, num_a, num_b, num_v)

[Sun Downs]

salut ylarvor et merci pour ta réponse !

Je vais essayer de t'aider mais j'ai une question... Avec quoi as tu realise ton schema de modele conceptuel ? c'est genial !

les tables sont ajouter et disposées ainsi avec le bouton relation sous Microsoft Access 2003 (après les avoir créées bien sur)

, les relations et les cardinalités entre tables sont crées manuellement sous Microsoft paint .

Pour commencer, je mettrais un entier autoincremente comme cle numerique sur chacune de tes tables... cela resoudra plusieurs problèmes comme ta relation par exemple.

dans ton schema conceptuel, tu prevois un programme par voyage que l'on ne retrouve pas dans le modele relationnel... c'est une erreur!
voyage(prix_min, prix_max, num_a, num_b, num_v)

mais en modèle conceptuel, on n'élimine pas l'attribut "programme" dans voyage , une fois une relation est créé entre les deux tables (programme et voyage)?

[ylarvor]

merci pour le cours de graphisme.

tu dois inscrire une cle etrangere dans voyage qui fait reference à programme.

[Sun Downs]

tu dois inscrire une clés étrangere dans voyage qui fait reference à programme.

oui, étant donnée que la participation des ces tables est de (1,1) on doit migrer les clés de la classe programme vers la classe voyage (ou l'inverse, car leurs deux cardinalités sont égales (1,1) ) mais le problème c'est qu'aucune de ces classes ne possède de clés primaire (d'après ce que j'ai concu )

qu'en penses tu ?, est ce que je faire des changements sur les attributs de "programme" ou/et de "voyage" et affecter une clés primaire quelque part ?

[ylarvor]

comme je te l'ai dit, il est souvent préférable de créer une clé primaire ( entier autoincremente ) pour chacune de tes tables. Il est plus facile par la suite de faire des jointures lorsqu'il existe une clé primaire.

Par conséquent, tu dois rajouter une clé primaire à ta table voyage et à ta table programme.

Pourquoi n'as tu pas creer de cle primaire ?

[Sun Downs]

comme je te l'ai dit, il est souvent préférable de créer une clé primaire ( entier autoincremente ) pour chacune de tes tables. Il est plus facile par la suite de faire des jointures lorsqu'il existe une clé primaire.
Par conséquent, tu dois rajouter une clé primaire à ta table voyage et à ta table programme.
?

comment créer ce clés sur Access ?

Pourquoi n'as tu pas creer de cle primaire ?

Par définition, une clés primaire est un attribut ( ou un ensemble d'attributs) privilégié retenu comme descripteur des entités de la classe d'entités.
bon, pour la classe voyageur qui comprend les attributs prix_min, prix_max, variante et programme je ne vois pas laquelle pourrait être une clés primaire ?? et j'ai le même problème avec la classe d'entités "programme"


Probablement le problème vient du faite que j'ai toujours en tête les exemples classiques de BD, comme la clés primaire de la classe Client est num_client ou la classe Produit est code_prod et j'essaie de faire de même, ca marche pour bateau, cabine, compagnie et ca bloque pour les autres !

[ylarvor]

Il est tout à fait possible et recommande de creer une cle.
Il te suffit d'affecter un numero à chaque voyage. Tu appelles ta cle id_voyage. Ce numero sert de reference pour les jointures. Il est unique, chaque voyage a un numero different. Tu peux faire reference à ce voyage dans la table programme simplement en indiquant le numero ou reciproquement, tu peux indiquer un programme dans la table voyage en indiquant le numero de programme.
Je comprend ton probleme, la modelisation entite/relation n'a pas "besoin" de ce numero pour fonctionner... c'est vrai, mais tu verras que ton modele physique ( pour access ) sera plus performant si ton modele relationnel integre des clés primaires , numerique autoincremente, pour chacune de tes tables principales, on peut meme generalise à toutes les tables hors les tables qui ont une cle primaire reconnu par le modele entite relation...

Sur access, lors de la creation de ton modele physique, tu cree une table, tu saisis une colonne ID_TABLE, tu indique un type entier, tu choisis l'option autoincrement.

Je te propose que tu modelise le modele relationnel sous access, en indiquant les relations entre les tables crees et tu poste ton modele sur le forum comme tu l'as fait de ton modele entite relation.

[fsmrel]

Bonsoir Sun Downs,


Votre schéma a une tête sympathique, mais les liens que vous avez tracés manuellement sont malheureusement faux et ça n’est la mission de Paint de le vérifier. Vous avez utilisé Access 2003 pour représenter des tables : allez au bout et demandez-lui de "tirer" les liens qui unissent les tables. Access ne se trompera pas. Par exemple, si un voyage est proposé par une agence, le lien est ainsi représenté :




Dans le schéma ci-dessus, AgenceId est clé primaire de la table Agence et clé étrangère dans la table Voyage. Pour tirer le lien : cliquez sur la colonne AgenceId de la table Voyage et tirez-la jusqu’à l’attribut AgenceId de Agence.

N’oubliez pas non plus que le schéma ainsi représenté n’est pas un modèle conceptuel de données (MCD) mais un modèle logique de données (MLD).

Concernant les clés primaires : une table a toujours une telle clé, sinon on appelle ça un sac (bag), source de résultats imprévisibles quand l’on utilise les opérateurs relationnels : chacune de vos tables doit avoir une clé primaire (AgenceId, VoyageId, etc.). Imaginez que vous rouliez en moto sans casque, à fond les manettes et par temps de pluie : il y a des risques...

Une clé primaire peut être multi-attributs. Ainsi, une cabine est une propriété multivaluée d’un bateau : la clé primaire de la cabine est composée des attributs BateauId et CabineId (disons le n° de cabine sur le bateau). Vous procédez ainsi à ce que l’on appelle l’identification relative. A noter qu’en l’occurrence, l’attribut BateauId de Cabine est simultanément clé primaire et étrangère.





Pour définir une clé primaire (en l’occurrence, celle de Bateau), on utilise le symbole de la clé :





Pour une clé multi-attributs (celle de Cabine) :




Bon courage

[trolldom]

Bonsoir,
J'ai un comentaire sur la modélisation des prix.
Je ne trouve pas l'implémentation de ces règles.

-Chaque voyage a des fourchettes de prix, comprises entre une valeur minimale et une valeur maximale différentes suivant les saisons.

a-t-il été précisé par ailleurs que chaque voyage a une seule fourchette?

Comme je comprends l'énoncé il y a plusieurs saisons et chaque saison a un prix min et max.
Il faut donc définir ce qu'est une saison et cela doit être fait avec le "client". En effet il est commun dans le tourisme que "saison" ne signifie pas été, hiver mais "Haute saison", "basse saison", "moyenne saison".
De plus il est habituel d'avoir au cours d'une année plusieurs periodes dans chaque saison. Par example Noël, février et juillet aout sont des périodes de haute saison dans les alpes.


Par example quand un client demande le prix d'un voyage, cela peut signifer plusieurs choses.
Si il veut savoir la fourchette de prix pour le voyage, ce sera alors le maximum des prix hauts (resp. minimum des prix min) toutes saisons confondues.
Si le client veut pouvoir choisir la variante la moins chère en fonction de ses contraintes, il semble raisonnable de lui proposer par voyage, les fourchettes par saison et les periodes groupées par saison.

Si il demande en fait le prix d'une variante, il apparait alors le besoin de clarifier d'autre règles.
une fourchette de prix donne l'impression que chaque variante a un prix qui doit vérifier la contrainte:
"le prix de la variante est compris dans la fourchette de prix de la saison à laquelle la periode de la variante appartient"

il faut alors savoir dans quelle période la variante se déroule avant de pouvoir déterminer la fourchette
et là vient un autre rendez-vous avec le client: comment gérer les règles de chevauchements, c'est à dire quand une variante est à cheval sur deux périodes.
Une solution qui simplifie l'implentation: quand une agence de voyage saisie une nouvelle variante, il doit Être spécifié à quelle saison elle appartient. C'est beaucoup plus simple à implementer et il devient simple d'avoir des saisons qui fluctuent avec les voyages (ce qui est logique dans la réalité). Je crois que je serai très convaincant vis-à-vis du client pour éviter le mic-mac avec des intervals
Je mets en dessous une proposition où j'ai été convaincant . C'est loin d'être optimal spécialement pour le maintient des informations historiques. mais il n'est pas précisé dans votre énoncé qu'il faut garder les prix de chaque périodes.


relation depuis variante: il y a plusieurs possibilités et je vois pas quelle est la meilleure Celle ci me semble raisonable


Il est par ailleurs défini dans l'énoncé que chaque cabine appartient à une catégorie.Il y a donc certainement différentes catégories de prix et le prix n'est donc pas en relation seulement avec une variante mais aussi dépendantde la categorie de la cabine.


Voilà, en espérant pour vous que je me trompe sur l'interprétation des règles de tarification du problème.
Bon courage