Discussion :

[joker vb]

Salut à tous,

J'essaie de m'informer au maximum, malgré tout je n'arrive pas à mettre en place mon modèle.

Sur cette page j'ai lu :

- le Guide d'analyse des données à l'aide de la méthode Merise, par Frédéric BROUARD
- la modélisation par héritage, par Frédéric BROUARD
- et je suis actuellement sur la conception d'une base de données (MCD, MLD) (FTP), par Cyril Gruau

Malgré tout je pêche. Pouvez vous me filer un petit coup de main :

Si on veut mettre en place une BDD qui fournirait la liste du matériel wifi compatible sous Linux, dans le modèle il y aura forcément les entités :
1- Distribution, Version, et architecture pour la distribution que l'utilisateur a
2- Marque Carte, Référence carte, type de connectique de la carte et type de carte (si je veux pouvoir étendre le domaine à d'autres matériels comme webcam, carteTV, etc)

En 1, dois je considérer Version comme une association et non pas comme entité?

En 2, dois aussi considéré Reference Carte comme association et non pas comme entité?

Merci de me filer un petit coup de main, je commence et certainnes choses me paraissent bien abstraites.

Merci d'avance

J'espère ne pas avoir dit d'anneries dans ce que j'ai dit

[bach58]

Il est difficile de donner un avis sur qqchose que l'on a pas étudié.

Mais selon toute vraisemblance, il s'agit d'entités dans les deux cas.

[gwen_oc]

version et reference sont des renseignements, donc des champs de tables

petit rappel, table=entité
tu veux faire une table version et reference ? (mettre un identifiant sur une version et une reference, ça ne sert pas bcoup )

bon courage, et reposte si necessaire

[joker vb]

Salut et merci pour votre soutien

selon toute vraisemblance, il s'agit d'entités dans les deux cas.

Ok, alors il y a un passage que je n'ai pas bien compris...

petit rappel, table=entité
tu veux faire une table version et reference ? (mettre un identifiant sur une version et une reference, ça ne sert pas bcoup )

Alors si c'est cela ça va drôlement simplifier le problème, je vais alors vous expliquer pourquoi je ne comprends pas, corrigez moi si je me trompe :

Effectivment, la "Distribution", la "Version" et l'"Architecture" pourraient constituer une entité OS.

Je me suis dit que je devais détailler davantage pour empêcher les erreurs de saisie des utilisateurs. En effet, l'idée du projet est que l'utilisateur puisse :

• - Rechercher les cartes compatibles avec son OS installé
  - Rechercher les OS qui fonctionnent avec sa carte Wifi

Par conséquent j'imagine des formulaires de recherche avec des listes déroulantes. En continuant avec l'exemple de l'OS, l'utilisateur choisirait une distrib, puis une version et enfin l'architecture (à l'aide de listes déroulantes).

Et je ne vois pas comment réaliser des listes déroulantes si ces 3 entités sont regroupées, est-ce quand même possible?



Sinon j'avais aussi pensé à une autre solution avec3 entités :

• - Distribution (IdDistrib, Distrib)
  - Architecture (IdArchitecture, Architecture)
  - OS (IdOS, Version, IdDistrib, IdArchitecture)

Avec les champs IdDistrib et IdArchitecture en clés secondaires dans l'entité OS.

Mais je me suis bloqué en me disant que je ne pouvais pas faire comme ça, car les entités "Distribution" et "Architecture" devaient, elles aussi être liées, surtout lors de la saisie de l'entité "OS". En effet, si l'on regarde ce que les différentes distributions proposent :
Ubuntu = i386; amd64; PowerPC
SuSe = i386; x86-64; ppc
Mandriva = x86-32; x86-64
on comprend que, si "Distribution" et "Architecture" ne sont pas liées, alors un utilisateur ayant déjà sélectionné "Ubuntu" se verra proposer une des "Architecture" qui n'existent pas pour cette distribution, tels x86-64; ppc; x86-32 ou x86-64.

J'espère que vous allez me contredire, car si je suis dans le vrai ça va être beaucoup plus compliqué que je ne l'imaginais



Enfin, ne pas tenir compte des différentes nominations des Distributions permettrait-il de résoudre ce problème? En imaginant une entité "Architecture" simplifiée :

1. Architecture 32 bits
2. Architecture 64 bits
3. PowerPC

Ca se voit tant que ça que je suis complètement paumé?

[JPhi33]

petit rappel, table=entité

petit rappel (pour être complet), table = entité OU association

Je me suis dit que je devais détailler davantage pour empêcher les erreurs de saisie des utilisateurs. En effet, l'idée du projet est que l'utilisateur puisse :

• - Rechercher les cartes compatibles avec son OS installé
  - Rechercher les OS qui fonctionnent avec sa carte Wifi

Par conséquent j'imagine des formulaires de recherche avec des listes déroulantes. En continuant avec l'exemple de l'OS, l'utilisateur choisirait une distrib, puis une version et enfin l'architecture (à l'aide de listes déroulantes).

Et je ne vois pas comment réaliser des listes déroulantes si ces 3 entités sont regroupées, est-ce quand même possible?

Il y a juste un petit problème de démarche. Tu imagines déjà ton interface, alors que tu n'as pas défini les concepts que tu dois intégrer à ton périmètre d'étude. Il faut procéder par étapes :
1) identifier les données du monde réel dont tu as besoin
2) modéliser ces réalités (niveau conceptuel puis logique)
3) en déduire la base données pour les manipuler

Pour de "petites" applications c'est généralement suffisant pour définir une interface et les traitements nécessaires.

Pour des applications plus importantes, il faut aussi modéliser les traitements et valider les deux types de modèles l'un par rapport à l'autre. Pour de grandes applications du monde des entreprises, on mène des projets en s'appuyant sur les 2 autres composantes de MERISE que sont le cycle de vie et le cycle de décision (ce dont on a parlé avant est le cycle d'abstraction).

Effectivment, la "Distribution", la "Version" et l'"Architecture" pourraient constituer une entité OS.


Sinon j'avais aussi pensé à une autre solution avec3 entités :

• - Distribution (IdDistrib, Distrib)
  - Architecture (IdArchitecture, Architecture)
  - OS (IdOS, Version, IdDistrib, IdArchitecture)

Avec les champs IdDistrib et IdArchitecture en clés secondaires dans l'entité OS.

Mais je me suis bloqué en me disant que je ne pouvais pas faire comme ça, car les entités "Distribution" et "Architecture" devaient, elles aussi être liées, surtout lors de la saisie de l'entité "OS". En effet, si l'on regarde ce que les différentes distributions proposent :
Ubuntu = i386; amd64; PowerPC
SuSe = i386; x86-64; ppc
Mandriva = x86-32; x86-64
on comprend que, si "Distribution" et "Architecture" ne sont pas liées, alors un utilisateur ayant déjà sélectionné "Ubuntu" se verra proposer une des "Architecture" qui n'existent pas pour cette distribution, tels x86-64; ppc; x86-32 ou x86-64.

Si je comprends bien tu as identifié de 4 types d'informations : Distribution, Architecture, OS, Version (il faudrait préciser Version de quoi ; mais toi tu le sais et c'est le principal). Ca, c'est l'étape 1.

Pour l'étape 2, il faut que tu étudies les relations qui existent entre ces informations : qui identifie quoi, qui est en relation avec quoi. Pour ce faire, il te suffit d'écrire des phrases simples du genre : "pour une Distribution donnée, j'ai plusieurs Architectures possibles" ou encore mieux (enfin, je suppose) "un Distributeur distribue plusieurs Architectures". Pourquoi encore mieux ? Parce que j'ai remplacé le verbe Avoir par le verbe Distribuer, j'ai enrichi la sémantique, mon modèle aura une meilleure signification. A toi de trouver les verbes qui traduisent le plus fidèlement le monde réel. Plus tu es précis dans les termes que tu utilises, mieux ça vaut.
Donc, tu écris toutes tes phrases d'identification et de relation, et normalement, tu aboutis à un modèle conceptuel.

Exemple :
un Distributeur distribue plusieurs Architectures
une Architecture peut être distribuée par plusieurs Distributeurs

Traduction :
[ Distributeur ]--0,n----( Distribuer )----0,n--[ Architecture ]

Distributeur et Architecture sont des entités, Distribuer est une association.

Dans le modèle logique, tu obtiendras 3 tables :
Distributeur, Architecture et Distribution (je recommande de traduire un verbe d'association en un nom)

La clé de Distribution est composée des clés de Distributeur et Architecture. Donc dans cette table si tu sélectionnes un distributeur, tu auras la liste des architectures qu'il distribue (Mandriva distribue x86-32 et x86-64) ; et si tu sélectionnes une architecture, tu auras la liste des distributeurs qui la distribuent (x86-64 est distribué par Mandriva et SuSe).

J'espère que vous allez me contredire, car si je suis dans le vrai ça va être beaucoup plus compliqué que je ne l'imaginais

Tu vois bien que ce n'est pas si compliqué ! (enfin, j'espère).

JPhi33