projet access : gestion du matériel informatique

[teamgirls]

Bonjour à tous les passionnés d'ACCESS,
Nous sommes 4 novices et nous avons besoin d'aide d'urgence!
Nous devons créer une base de données permettant la gestion du matériel informatique.

Notre principal problème est pour insérer la capacité du disque dur (1giga/2giga..) dans l'unité centrale ou l'ordinateur portable.

Nous avons créé les tables suivante :
-Disque dur (ref_disquedur; ref_capacité#)
-Capacité (ref_capacité)
-Unité centrale (.......;......;ref_disquedur#)
-portable (idem UC)

Est-ce que c'est juste ou avez-vous une autre solution à nous proposer (pour cette table et pour le reste du projet)?

Merci d'avance car nous sommes complètement perdues !!

[LedZeppII]

Bonjour et bienvenue sur le forum.

Je dirai qu'il manque un champ pour entrer la capacité dans la table Capacité.
Mais surtout il n'est peut-être pas utile de séparer cette information de la table "Disque Dur".
Est-ce qu'un disque dur peut avoir plusieurs capacités ?
Je suppose que ref_disque est un champ auto-incrémenté (NuméroAuto).

Personnellement je ferai deux tables:
Table Ordinateur
ref_ordi (type NuméroAuto)
numero_serie
type_ordi (UC ou portable)
Marque
Modèle
ref_disquedur
...

table Disque Dur
ref_disquedur (type NuméroAuto)
Marque
Modèle
Capacité

... et une table pour associé un ou plusieurs disques durs à un ordinateur.
table ordi_dd
ref_ordi
ref_disquedur

Mais bon ça dépend du niveau de détail voulu.
On peut très bien avoir une seule table ordinateur, et un champ pour le nombre de disques dur et un autre pour la capacité totale en Go.

Par exemple un intégrateur (assembleur) aura besoin de beaucoup de détails car son stock se compose de pièces qu'il devra assembler (Châssis, carte mère, mémoire vive, processeur, disque dur, CD ou DVD, etc...)

Si c'est juste pour inventorier des ordinateurs, on peut partir du principe que ce sont des éléments finis.
Donc une seule table.
Avoir une table séparée pour les disques durs a un sens (à mon avis) si on est amené à les démonter d'un ordinateur pour les mettre dans un autres.

A+

[teamgirls]

Merci beaucoup de votre réponse, nous sommes actuellement en pleine réflexion sur notre projet!
Nous n'avions pas précisé que toutes nos clés primaires (les ref_..) sont en texte et non en numéro auto, car pour nous la référence corespond au numéro de série, on veut donc l'entrer manuellement (l'informaticien chargé de nous donné des conseils nous a di cela).

Est ce que ça pose un problème si on n'a pas de numéro auto dans nos tables?

Que veut dire les messages d'erreures (quand on veut créer une relation):
- "Index unique introuvable pour le champs référencé d'une table principale". ?
-"La relation doit inclure le mème nombre de champs avec le mème type de données."

Nous vous joignons notre début de projet (juste table+relations), nous espérons que vous arriverez à comprendre quelque chose et nous dire ce qui ne vas pas.
Ps: Les relations non créées ne sont pas dûes à de la fénéantise mais aux messages d'erreurs nous empéchant de les créer!!!

Merci d'avance et A bientot !! nous croisons les doigts !

[LedZeppII]

Bonsoir,

ça ne pose pas de problème si ref_xxxx n'est pas un numéro auto.
Le problème que je vois est que
[Unité centrale].[Ref_UC] est de type numérique (NuméroAuto)
mais [UC_dd].[Ref_UC#] est de type texte.
Pour créer des relations il faut que les champs soient du même type.

Pareil avec ...
[Imprimante].[Ref_imprimante] (texte) et [Emplacement].[Ref_imprimante#] (numérique)
[Ecran].[Ref_écran] (texte) et [Emplacement].[Ref_écran#] (numérique)
[Facture].[Ref_facture] (texte) et [Unité centrale].[Ref_facture#] (numérique)
et il y en a d'autres.

1. Faire le choix du type de donnée pour Ref_xxxx dans les tables de référence (côté 1 de la relation).
2. S'assurer que le champ Ref_xxxx# est du même type

Si on fait le choix d'avoir un champ clé texte, il faut s'assurer que l'unicité sera toujours garantie.
La table Facture présente le risque que deux fournisseurs émettent une même ref de facture.
On pourraît alors définir la clé de la table comme étant une clé multi-champ (Ref_frs et Ref_facture)
mais cela oblige à mettre ces deux champs dans les tables que l'on veut mettre en relation avec la table Facture.
C'est pour cela que le type NuméroAuto est appréciable.
Ou alors on combine Ref_Frs + N°Facture pour créer le contenu du champ Ref_facture.
Cela garantit l'unicité mais c'est moins automatique qu'un Numéro auto.

Bon courage et A+